QoS LLQ (Low Latency Queueing) on Cisco IOS

Hello Nicolas

Yes, I think you’ve described it very well. Your description is comprehensive and understandable, and I believe it is correct. Thanks for your clear explanantion and for the way you framed the issue.

Laz

Thanks Laz for the great support.

I do have another question & I’m Interested in hearing your thoughts.

When it comes to classification and marking when implementing congestion management, If I were to classify traffic by subnet-only with ACLs & not include any dscp markings, is there a risk for my underlay network traffic to be impacted or is it best to mark everything so that you avoid a situation when your routing protocol traffic gets blackholed ( e.g OSPF underlay w MPLS & MP-BGP). The network I am dealing with has no voice traffic but the intent is to give priority to mission critical subnets priority while the transport links are at capacity.

Hello Nicolas

It is possible to classify traffic by subnet only with ACLs. However, there are a few implications and caveats that you must keep in mind when you do this:

First, concerning the underlay network, if your congestion management strategy does not account for the specific needs of routing protocol traffic (like OSPF, MPLS, MP-BGP), there is a risk that this critical traffic could be deprioritized or dropped in congested scenarios. Routing protocol traffic is essential for the stability and efficiency of your network. If it’s impacted, it could lead to routing inefficiencies or even outages.

Secondly, by classifying traffic solely based on subnets, you may not fully distinguish between different types of traffic within the same subnet. You may not have voice traffic, but there are other traffic types that you may want to ensure will not be affected by congestion. This could result in a prioritized subnet being treated equally, regardless of its actual importance or requirements.

While classifying traffic by subnet-only with ACLs is a valid approach, it’s generally beneficial to incorporate DSCP markings for more nuanced and effective traffic management, especially for ensuring the priority of mission-critical traffic and the integrity of your routing protocol traffic (regardless of the subnet from which they originate). So I would say that you can go ahead and use an implementation that prioritizes based on the subnet, but you should also include some QoS mechanisms for other important traffic as well. So a combined approach would help mitigate the risks of network instability and ensure efficient utilization of network resources. Does that make sense?

I hope this has been helpful!

Laz

Hi Laz,

Yes it does , I definitely agree with you but with the way our network is designed, our most mission critical traffic is fully distinguished at the VRF level & that’s why I think the classification with ACLs should be ok for us. That said, I do agree that there should be some type of marking applied anyway so that our routing protocols & such remain unaffected - do you have any resources or guidelines on “normal critical traffic types” that I can make reference too?

This needs to be configured on a WAN link between ASR1000s Version 16.09.03 ( egress queuing only)

Tx!

Hello Nicolas

For your situation, you need to ensure that QoS is applied to control plane traffic. That is, routing protocol traffic and any other control plane messages that may be used in your topology. This feature is called Control Plane Policing or CoPP. Take a look at this lesson for more info:

First, you should identify what control plane traffic you have on your link, and then think about the kind of priority you want to give that traffic. Based on this, you can devise your strategy for ensuring control plane traffic is not dropped. This can be applied in conjunction with your classification based on subnets using ACLs. Here is some more useful information from Cisco documentation about CoPP.

I hope this has been helpful!

Laz