Hello,
The site I maintain has around 2000 ports, mainly ALE switches ranging from 63xx, 64xx, 2260 and 6360. Core is 2x 6900-T40. The voip system has around 300 extensions. Most of the extensions are physical IP phones, some users are starting to migrate to softphones, but we still have less than 50 of those.
Everything is working fine even on mostly 1g uplinks but I start to notice some eventual drop in voice quality as traffic increases on the network, and I want to take action before it becomes a problem. I have no traffic prioritization in place and I want to set it up initially for VoIP traffic.
I see the 6900 has a default ip phone traffic prioritization but as I understood it is meant to work with AL phones, which we have none. So I suppose I can disable that with qos no phones. I have a few doubts that I'd like to share with you before I move on.
1 - Traffic is being generated at the edge, say on a 6350, and reaches the core via an uplink. VoIP server runs on VMware, VMware hosts are attached to the core. I suppose I have to configure prioritization also on the 6350 and not only on the core, is that right?
2 - Softphones run on PCs that are connected to different VLANs depending on their location department etc. Post #23060 in this forum suggests that the VoIP VLAN should be added to Windows and the VoIP traffic should be directed to that VLAN. I agree that this would be the perfect solution as it would keep all VoIP traffic in its original VLAN, but configuring desktop versions of Windows to use a second VLAN is neither straightforward nor usual. Would it make sense to add the IPs that use softphones to the prioritization rule? I know this would not make sense on a future scenario where all PCs use softphones, but maybe at this initial stage this could work? Or, as also mentioned in post #23060, prioritize traffic for the relevant UDP ports on VLANs other than the VoIP VLAN? UDP 5060?
3 - How should I prioritize the traffic? Simply set a high priority, say 5, to the whole voice VLAN traffic? Mark packets with DSCP 46? What would that marking do, I mean who would look at the mark and expedite that traffic?
Thank you!!
Tales
VoIP traffic prioritization
Re: VoIP traffic prioritization
Hi, ALE switches all prioritize ALE phones by default (not just the 6900) and that's due to a built-in QoS group rule.
That group can have 4 custom MAC ranges added in. You can do this with:
Change xx:xx:xx with the correct MAC-OUI from the vendor you're using and you're good to go. As for the VMware voice server, this second rule (the 22:22...) also adds that particular MAC to the relevant group instead of the OUI. Apply this to all your switches.
Remember you can only have 4 rules. Also note that the group name is case-sensitive (alaPhones). You can read more about this in the QoS section in the network configuration manual.
Now for the softphones, this is something I never had to worry about and I will also be following this post to see what I can learn from the more experienced people in these forums. Some ideas come to my mind though:
- Maybe you can configure the softphones to use a custom MAC address instead of using the default in the NIC? If so, simply add another alaPhones rule with that new range for the softphones, and then go PC by PC and set the softphones up to use a MAC within that same range.
- I also know that you can setup an LLDP network policy for softphones but I never used it before. Something like:
But I wonder if this implies that the softphone itself needs to support LLDP? I'd love to know more about this myself.
- setting up a rule for windows voice vlan would be awesome. No idea on how to do that, but maybe you could deploy it as a policy in that domain for all the hosts? I'm everything but a Sysadmin so I can't help here. This really seems like the best solution for the softphones!
- prioritizing traffic to/from UDP 5060 only takes care of your SIP signaling, you'd still have some issues with your RTP traffic and I'm guessing you won't be able to predict all the ports for that traffic, and I'm sure sooner or later some applications would also use these ports...
These are my ideas so far, and I'm also very interested in reading additional solutions for the softphone part.
That group can have 4 custom MAC ranges added in. You can do this with:
Code: Select all
qos phones trusted
policy mac group alaPhones xx:xx:xx:00:00:00 mask ff:ff:ff:00:00:00
policy mac group alaPhones 22:22:22:22:22:22 mask ff:ff:ff:ff:ff:ff
qos apply
Remember you can only have 4 rules. Also note that the group name is case-sensitive (alaPhones). You can read more about this in the QoS section in the network configuration manual.
Now for the softphones, this is something I never had to worry about and I will also be following this post to see what I can learn from the more experienced people in these forums. Some ideas come to my mind though:
- Maybe you can configure the softphones to use a custom MAC address instead of using the default in the NIC? If so, simply add another alaPhones rule with that new range for the softphones, and then go PC by PC and set the softphones up to use a MAC within that same range.
- I also know that you can setup an LLDP network policy for softphones but I never used it before. Something like:
Code: Select all
lldp network-policy 1 application softphone-voice vlan 1234 l2-priority 5 dscp 46
lldp chassis med network-policy 1
- setting up a rule for windows voice vlan would be awesome. No idea on how to do that, but maybe you could deploy it as a policy in that domain for all the hosts? I'm everything but a Sysadmin so I can't help here. This really seems like the best solution for the softphones!
- prioritizing traffic to/from UDP 5060 only takes care of your SIP signaling, you'd still have some issues with your RTP traffic and I'm guessing you won't be able to predict all the ports for that traffic, and I'm sure sooner or later some applications would also use these ports...
These are my ideas so far, and I'm also very interested in reading additional solutions for the softphone part.
- thermseeker
- Member
- Posts: 38
- Joined: 08 Jul 2016 08:40
Re: VoIP traffic prioritization
Hi,
Cristek, thank you for replying.
I had at first considered using alaPhones but as I have several vendors I did not advance on that idea. But maybe it's indeed the best option, use three rules for the 3 brands I use the most and use the last one for the server. The other brands I use are for a few legacy phones using ATA devices so it's no big deal if they are left out. And for the softphones, I will too be watching here to see if any ideas come up.
I could also manually config the MAC for the VM in VMware to be in the same range as one of the vendors, leaving one slot free.
Will do that on all switches as soon as I get back from my vacations that start on monday
and I'll post any noticeable results here.
Cristek, thank you for replying.
I had at first considered using alaPhones but as I have several vendors I did not advance on that idea. But maybe it's indeed the best option, use three rules for the 3 brands I use the most and use the last one for the server. The other brands I use are for a few legacy phones using ATA devices so it's no big deal if they are left out. And for the softphones, I will too be watching here to see if any ideas come up.
I could also manually config the MAC for the VM in VMware to be in the same range as one of the vendors, leaving one slot free.
Will do that on all switches as soon as I get back from my vacations that start on monday

Re: VoIP traffic prioritization
If the voip packets are marked with DSCP 46 than the traffic will forwarded at the outgoing ports to queue SP5 (SP0 is the lowest - and SW7 the highest). For this the switches need to trust the incoming DSCP. One way is to use "qos phones" like Cristek explained. Other way is independend from the ALE vendor mac of the phones to trust all ports (qos trust ports). Or you write your own policies (f.e. for the RTP ports)
BR Silvio
BR Silvio
Re: VoIP traffic prioritization
I’ve had to do this too — just make sure the remote phones are added in the numbering plan and that IP routing between sites is working fine. That fixed mine.