Qos on every network device in the path?

[craig.cartlidge1]

Hi

Apologies as I am new to QoS but this is somthing I cannot find a straight answer too,

I understand the concept of QoS on routers, this is usually the area that I can easally see QoS happening as WAN links tend to be 10Mb/20Mb etc so we need to prioritise traffic as these bandwidth links can get congested.

I understand the use of class / policy maps to identify traffic and prioritise bandwidth then apply the service policy to the outbound interface on the interface that connects to the WAN link.

Do we need to QoS on the LAN that connects into the WAN ? Even the layer 2 switches ?? ... is this per port , how do we identify traffic at the switch level and prioritise it?

Please help!!

Thanks

[Mark Malone]

Hi

qos should always be done end to end where possible but there is the argument well I only use a fraction of my gig pipes and 10gig on the LAN in bandwidth do I really need it , its all a personal choice on what type of traffic you have is it critical occasionally do you flood the LAN with updates and do you need to make sure that at least you voice is prioritized as its real time as that cant be retransmitted , some switches are on by default will mark anyway in the background without user intervention like the IOS-XE/NX-OS now trusts DSCP marking by default and your switch will set that at the source so your voice by default is becoming prioritized without any intervention on LAN anyway, we do mark everywhere on our network but we don't build policy's for layer 2 but we do mark mls qos trust dscp say at layer 2 so our voice and interactive video would never take a hit where possible, we allow srr queues in some platforms but closely monitor the qos statistics, you need to be careful with Qos at layer 2 as well if not properly maintained or altered incorrectly in queuing you can end up causing more issues than fixing , that's why some avoid the queuing aspect where possible and just trust the  source marking like a cisco phone etc

any questions just ask il try and answer them for you , another note there is different layer 2 qos for different platforms and supervisors ,  the types of hardware queues in 6500s and auto qos and mls qos in non modular switches , nearly all do same thing some just have bigger buffers queues etc and slightly diff ways of doing it

[Karsten Iwen]

In addition to Marks very good answer: If you want to dig deeper into QoS and are not afraid of some "harder" stuff. The Enterprise Medianet Quality of Service Design 4.0 is already some years old, but still a very good read.

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I'm not an advocate of end-to-end QoS, just because you can, or it's what "the book" suggests.  There's a cost to QoS implementations and their maintenance, and if done incorrectly, QoS can degrade service.

Where you ought to have QoS is on any interface where congestion forms that's adverse to the application's service needs and which can be remediated by QoS.  (Sometimes the "right" solution is more bandwidth, although often more bandwidth is obtained when QoS might have been a more optimal solution.)

Often there's adverse congestion on WAN interfaces, because as you note, they often provide less bandwidth than LAN interfaces.  (Also WAN bandwidth is often also more expensive to provide than LAN bandwidth.)

Placing QoS on interfaces that don't actually need it is somewhat like buying insurance.  It adds to your "cost", but provides some "protection" for the unexpected.  Again, like whether you should buy insurance, for what coverage and cost, QoS implementations should also consider coverage, and expected benefit vs. cost.

So . . .

Do we need to QoS on the LAN that connects into the WAN ?

Maybe, maybe not, although also again, often if you do need effective QoS, LAN to WAN is a common place.

Even the layer 2 switches ??

Another maybe, maybe not.

... is this per port , how do we identify traffic at the switch level and prioritise it?

Actually how depends on the device.

Often you have an ingress policy that examines the traffic, and based on what it "sees" might allow self marked traffic to go as marked or mark/remark traffic as needed.

Device may have egress policy that determines hows traffic is treated, including priorities, when there's congestion.

The thing to understand about QoS is about meeting the service needs of your traffic, done by  managing traffic queuing and/or drops.

Often QoS becomes a point of discussion when dealing with VoIP.  However, not all VoIP needs QoS in all cases, and even cases like bulk data transfers, might be improved by QoS.

Unfortunately, QoS corresponds with the old cliche, "cannot see the forest for the trees".  Most QoS material explains how to deal with the "trees", but doesn't well explain how the forest should be managed.