QoS 2911 - LLQ - Priority queue seems to not work?

[Matthew burnley]

Hi all,

I have an issue and i hope somebody can help.

I have configured a priority queue on my 2911 to prioritize ICMP traffic in its own queue of 1000 kbps and all other traffic shares the remaining 100% of the bandwidth.  My WAN interface is hardwired to 10mbps full duplex and seemingly when i do the "show policy-map interface gi0/0" everything seems to check out but when i max out my internet connection downloading multiple test files the ping latency is always a standard 67-80 ms but as soon as i stop my downloads its around 13ms solid.  I'm using NBAR to identify the ICMP traffic and this seems to work.  I was under the impression that LLQ guaranteed latency as well as bandwidth?

Can anyone see anything wrong with my config or offer an explanation why my priority queue traffic is suffering high latency issues when downloading/under-load.  I was using this as a test to implement on VoiP traffic but it does not seem to work :/

class-map match-any icmp-class
match protocol icmp

policy-map PMAP_LLQ

class icmp-class
priority 1000

class class-default
bandwidth remaining 100
fair-queue

interface gi0/0    <--WAN

service-policy output PMAP_LLQ

interface gi0/2 <--LAN

ip nbar protocol-discovery

Router Output for troubleshooting

Router#show policy-map interface gi0/0

GigabitEthernet0/0

  Service-policy output: PMAP_LLQ

    queue stats for all priority classes:

   queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 301/236567

    Class-map: icmp-class (match-any)

      301 packets, 236567 bytes

      5 minute offered rate 16000 bps, drop rate 0 bps

      Match: protocol icmp

        301 packets, 236567 bytes

        5 minute rate 16000 bps

      Priority: 1000 kbps, burst bytes 25000, b/w exceed drops: 0

    Class-map: class-default (match-any)

      35118 packets, 1898687 bytes

      5 minute offered rate 57000 bps, drop rate 0 bps

      Match: any

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops/flowdrops) 0/0/0/0

      (pkts output/bytes output) 35118/1898687

      bandwidth remaining 100% (9000 kbps)

      Fair-queue: per-flow queue limit 16

Router#

[chrihussey]

Pinging is a two way operation. The ICMP echo and reply. Unless you have the ability to prioritize in both directions you may very well be taking caring of things on the outbound, but the delay may be on the inbound from the WAN.

Hope this makes sense.

[Matthew burnley]

Thanks for the reply chirhussey,

What is common practice then when applying QOS - on the egress point of the CE router and then again for reply traffic on the PE router ? 

The articles i have read have not hinted at this - The high latency is not good enough for voice calls and i need to figure out the best approach to resolve it :)

Thankyou

[chrihussey · Accepted solution]

In the most general sense ISP / MPLS providers are able to prioritize traffic across their networks to accommodate voice, video, etc. just as the private user implements QoS on their own network. The priotized bandwidth amount is usually based on IP precedence or DSCP and determined on a case by case basis or defined by different tiers of service. There is obviously a cost involved depending on what you get.

With regard to what being a common practice (egress on the CE or PE), QoS is an end to end operation. So anywhere the traffic goes it needs to be prioritized. If not, at any potential choke point could result in poor quality.

Regards

[Matthew burnley]

Thanks Chris.

For reference i tested the theory by setting up a dummy PE router and set it in front of my CE.  I limited the transit network between the two to 10mbps.  I applied the same policy map outbound on the transit network facing my CE and the ping response times certainly improved considerably.