Do I need to configure queuing on our LAN

[de1denta]

Hi All,

I need some quick advise regarding LAN QoS. I have been asked to implement QoS on our network to prioritise voice traffic that will be transiting our VPLS WAN. I have already configured policies to classify and mark voice traffic as required and ensure that these markings are maintained to our egde routers where the provider has then configured the required polices to prioritise voice traffic. So far this is all good.

I have been asked if I should be also configuring queuing on our LAN switches, specifically on the interfaces facing our VoIP equipment and WAN routers. From what I can see, the interfaces that connect to our voip equipment only carry voice traffic so I cant see a need for queuing as we are not contending with other traffic? Also the interfaces that connect to our WAN routers show no signs of congestion so do we really need queuing here as well?

I'm not trying to avoid the implementation of queuing on our switches but if its not needed then is really required or recommended?

Happy to hear your thoughts?

[Mark Malone]

Probably dont need it by the sounds of it , if switches aren't under any congestion , does the voice sound ok now without any qos from lan to lan phone and test video calls are not laggy or choppy ?

what type of lan switches are they

did you wireshark the packets make sure the EF ,markings  are being held while transmitting the LAN network , if they are your probably good

[de1denta]

Hi Mark,

Thanks for the response.

Voice/video calls between devices on the LAN are fine and it was only issues with inter-site calls that we were having issues with but WAN QoS has since fixed this. 

Sorry the access switches are Cisco 2960Xs and the core are 6500s

Markings are being maintained end-to-end so thats all good from what I can see

Thanks

[Mark Malone · Accepted solution]

If markings are being maintained end - end id say its good
on our 2960s to be sure we did use mls qos trust dscp on uplinks and access ports to make sure the marking were carried as its originally sent from source phone
on our 65s most blades were default to trust the DSCP anyway under the queuing by default you can check your own with

The end decision though is yours and whether as you said you need it but from what you said so far everything seems to be working well without it on LAN side , remember these are 1gb ports takes a lot of traffic to max it out at lan user that qos would need to kick in to prioritize the packets , QOS is a definite on the WAN but LAN you can get away with not using it at all and now a lot of newer switches and ios-xe all come with trust DSCP default enabled

xxxxxx#sh queueing interface g1/4/1 | i Trust state
Trust state: trust DSCP

[de1denta]

Great, thanks for the feedback Mark

[Joseph W. Doherty]

"From what I can see, the interfaces that connect to our voip equipment only carry voice traffic so I cant see a need for queuing as we are not contending with other traffic?"

When there's only one kind of traffic, yes, QoS queuing is often less needed, but not always, as you sometimes want to use QoS for drop management, and sometimes the best way to do that is using different equal cost queues.

"Also the interfaces that connect to our WAN routers show no signs of congestion so do we really need queuing here as well?"

So you know there's never any queuing?

"I'm not trying to avoid the implementation of queuing on our switches but if its not needed then is really required or recommended?"

From what you've described, perhaps you don't "need" QoS, as least at the moment, but it's recommended, as insurance to insure your VoIP traffic is "protected". Without it you never know when some "new" app might sling enough traffic across your network to degrade your VoIP traffic.

[de1denta]

Hi Joseph,

Thank you for the response, that makes sense

Actually stating that there is no congestion is incorrect, what I meant to state was that I cant see any output drops on the interfaces which is different. Maybe I need to implement some monitoring to check if the output queues are being filled at all to confirm this

Thanks again

[Joseph W. Doherty]

No drops is a good sign, but with VoIP, delay and jitter can be issue even when there's no drops.

I personally define congestion whenever any frame/packet needs to be enqueued. However, QoS is only really needed when congestion and/or drops is actually adverse to the service needs of the traffic. Again, even if there's no adverse issues today, QoS provides insurance for tomorrow.