FreePBX in School Division and DCSP traffic

Hello everyone, I know the hot debate that goes on here about VLAN’s, Free PBX and QoS. I am more leaning towards, I don’t need more VLANS with my new VoIP setup but want to explain my scenario and get confirmation on my thought process with this.

We are a large K-12 environment that spans 3 large geographical areas. We have 30 sites, and staff per site ranges from about 5 - 60 per site. All staff will get a VoIP phone. We are blessed to have fibre on a government network between all of these schools that we operate our VLANS on. We have one flat named VLAN, with routing between all sites to flow traffic. On all the Edge devices, QoS is on and DSCP 46 and 26 traffic (SIP and RTP) are designated as Priority 3 and 5, accordingly, with DSCP 46 being Priority 5 Expedited Forwarding.

We Use Grandstream phones that are already set to mark RTP traffic as DSCP 46, and SIP traffic as DCSP 26, for layer 3 routing which all of our edge devices support as mentioned above. So all of our traffic in the current our current network is prioritized using DSCP, to ensure QoS. Since QoS doesn’t kick in until the shared interface for the edge devices is congested, and that interface and bandwidth is shared for all VLAN’s I don’t see the need to VLAN or QoS any more since A. another VLAN wouldn’t help, the traffic is already segmented via VLANs and Subnets, and B QoS is on…I don’t see any advantage at this point since QoS is already implemented and so are any needed VLAN’s. In my eyes, if the edge interface becomes congested for a site, a VLAN is not going to help, and QoS will prioritize the traffic, in the same way, no matter what VLAN is implemented, they are separate entities. QoS and CoS work the way they work with the DSCP protocol, and priority 1 - 7. In my eyes, my thinking is sane and clear on this. Do I seem sane, does my logic seem correct. I will also say to date our calls have been crystal clear, with this scheme. We are about to expand voip now to more sites.

1 Like

This is the most well thought out reasoning I have seen on this subject in ages.

You are exactly correct in all particulars. This is the best way to handle things.

This can happen anytime if some single process pegs the interface or the trunk interfaces even for a few seconds. That is why it is important to use QoS always.

Excellent. Glad to know I’m still sane.

If your firewall allows for bandwidth shaping or dedicated bandwidth based on packet marking this is the better way to do things. Some people and equipment cant mark traffic very well so using vlans is easier.

VLANs are only useful in a LAN context. I infer there is more WAN than LAN interaction for this application, and if that’s the case, VLANs may not be the cure-all that he needs here. If there was a desire to reduce the local bandwidth and shape it into smaller collision domains, I could see the usefulness, but VLANs, in this specific case, wouldn’t seem to add a lot of facility to the mix and over complicates the networks in a way that just doesn’t pay dividends.

Lets say you want to setup bandwidth shaping. You could mark connections, packets via source or destination and apply bandwidth queues that way to the wan. No lets say you need the same to happen for inter vpn traffic. You could also do the same but no traffic isnt going from 1 pbx to 1 provider. I dont like vlans but Im saying sometimes it makes it easier for people to mark traffic to setup dedicated bandwidth.
Especially if using cloud phones. Again you could mark traffic based on source or destination to the cloud pbx ip ranges. There could be several and ips might change but vlans dont. They have their place sometimes.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.