QoS over WAN questions

[Oerlikon_NZ]

Just wondering if I can bounce something off the forum concerning the way congestion/QoS will work over one of our site-to-site WAN links.  Having read up on documentation I'm still a little confused.

My goal is to prioritize voice(LLQ priority) and other traffic(CBWFQ bandwidth & police) across a 20Mb/s site-to-site WAN link.

* The HQ site is connected to the WAN via FastEthernet(100-FD) 
* The remote site is connected to the WAN via FastEthernet(100-FD) 
* The WAN service provider has a 20Mb/s rate-limit configured for the circuit

1.  Will all of the QoS mechanisms be invoked here?

2.  LLQ should work regardless if there is congestion or not?

3.  Would the outgoing interfaces at either side experience congestion given the circuit is rate-limited by the SP to 20Mb/s, and would this prevent the CBWFQ mechanisms to work?

4.  Does the interface bandwidth command have any effect on QoS?

5.  Does the order of class-maps mater within the policy-map?  i.e. two different class-maps with LLQ priority in the same policy-map

[Edison Ortiz · Accepted solution]

1. Yes, during congestion

2. Depends on the platform, but in general LLQ traffic will always be de-queued first

3. Ideally, you need to implement a shaper that matches the provider's circuit speed.

Without a shaper, the router won't experience congestion and the provider will simply drop the oversubscribed packets.

4. Only when using % values on the QoS configuration

5. There is only one priority queue.

Configuring multiple classes with priority queues would be the same as configuring one class with several matches.

[Joseph W. Doherty]

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 whatsoever (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

#1 depends on configuration and actual traffic

#2 LLQ only engages when there's congestion (NB: if no congestion, implicit class policer can be exceeded)

#3 possibly and possibly (NB: as Edison notes, normally you would shape your egress to artificially congest before you hit provider's rate limits but without shaper you could congest on interface - BTW you sometimes need to allow for L2 overhead, i.e. shaper might only "count" L3 bandwidth but provider "counts" L2 bandwidth)

#4 depends on the IOS version and QoS configuration, i.e. some do, some don't  (e.g. Edison's %)

#5 yes (NB: Edison is correct there's only one actual LLQ but different LLQ classes can have different implicit policed values and other class settings)

[Oerlikon_NZ]

Cheers for the replies!

#2 LLQ only engages when there's congestion (NB: if no congestion, implicit class policer can be exceeded)

The following does seem to suggest otherwise.  Meaning the LLQ priority traffic is serviced ahead of any other traffic(up to it's configured  priority) regardless if there is congestion or not. 

http://www.ciscopress.com/articles/article.asp?p=102233&seqNum=5

[Joseph W. Doherty]

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 whatsoever (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

The following does seem to suggest otherwise.  Meaning the LLQ priority traffic is serviced ahead of any other traffic(up to it's configured  priority) regardless if there is congestion or not. 

From this statement "The priority command guarantees that the requested bandwidth is available whether the interface is busy or not."?

It does guarantee the bandwidth, but that's not the same as LLQ being actively engaged.  NB: congestion is the state where a packet has to wait to be transmitted.

Basically it takes congestion, a queue or queues to form, for CBWFQ policy to having something for its dequeuing scheduler to work upon; including LLQ.  You could even have 100% link utilization without congestion.  For example, traffic coming solely from one 100 Mbps link egressing another 100 Mbps.  There would be no congestion and all this traffic could even be LLQ class, but none would be queued.

Conversely, even with almost zero utilization LLQ can engage.  For example, if one packet is being currently transmitted and if two packets arrive, those packets will be queued.  Ignoring tx-ring, those packets can be placed into separate queues and if one is a LLQ packet and the other isn't, then the LLQ packet will dequeued next, i.e. LLQ is now actively engaged.

So, you're correct that LLQ is serviced ahead of other trafffic, but there has to be queued traffic for the dequeueing prioritization to operate against.  Again, no queued traffic (no congestion), LLQ isn't engaged.

On the point of the implicit policer also only enages when LLQ has congestion, your referrence explicitly agrees, i.e.: "During low interface utilization, the class map may use more bandwidth than requested by the priority command."