QOS drops in LLQ/CBWFQ queues

Discussion in 'Cisco' started by opensource, May 5, 2006.

  1. opensource

    opensource Guest

    We've configured LLQ on one of our Point to Point
    circuits. We uses LLQ to protect the following traffic on our network.
    Voice (Priority Queue)
    Voice control
    and IPCC

    During high traffic volumes (>40%) we see drops in the citrix and/or
    queue even though there is plenty enough bandwidth on the circuit.
    Please see
    the example below;

    pen-router1#sh policy-map int ser 0/0

    Service-policy output: VoiceFirst

    Class-map: VOICE-media (match-all)
    12982 packets, 830848 bytes
    30 second offered rate 87000 bps, drop rate 0 bps
    Match: ip precedence 5
    Strict Priority
    Output Queue: Conversation 264
    Bandwidth 500 (kbps) Burst 12500 (Bytes)
    (pkts matched/bytes matched) 5101/326464
    (total drops/bytes drops) 0/0

    Class-map: VOICE-sig (match-all)
    966 packets, 70016 bytes
    30 second offered rate 8000 bps, drop rate 0 bps
    Match: ip precedence 3
    Output Queue: Conversation 265
    Bandwidth remaining 10 (%) Max Threshold 64 (packets)
    (pkts matched/bytes matched) 559/45246
    (depth/total drops/no-buffer drops) 0/0/0

    Class-map: CITRIX (match-any)
    24578 packets, 5580021 bytes
    30 second offered rate 752000 bps, drop rate 20000 bps
    Match: protocol citrix
    0 packets, 0 bytes
    30 second rate 0 bps
    Match: access-group 101
    24578 packets, 5580021 bytes
    30 second rate 752000 bps
    Output Queue: Conversation 266
    Bandwidth remaining 70 (%) Max Threshold 64 (packets)
    (pkts matched/bytes matched) 13781/4892001
    (depth/total drops/no-buffer drops) 0/267/0

    Class-map: IPCC-traffic (match-all)
    126 packets, 7480 bytes
    30 second offered rate 0 bps, drop rate 0 bps
    Match: access-group 100
    Output Queue: Conversation 267
    Bandwidth remaining 20 (%) Max Threshold 64 (packets)
    (pkts matched/bytes matched) 72/4158
    (depth/total drops/no-buffer drops) 0/0/0

    Class-map: class-default (match-any)
    1068 packets, 218716 bytes
    30 second offered rate 23000 bps, drop rate 0 bps
    Match: any

    As you can see the drop rate on the citrix queue is 20000. However,
    only around
    50-60% of the T1 is currently being using. So, in my opinion, there
    should be
    no reason for drop packets in this queue. Am I correct?
    opensource, May 5, 2006
    1. Advertisements

  2. opensource

    jay Guest

    If you see 50-60% usuage, it is at 30 sec averages (do you have
    'load-inteval 30' on the inteface?)

    This is saying that Citrix is cetainly bursting above 70% of the CBFWQ
    bandwidth (75%reservation by default, less any LLQ reservation) and the
    link is certainly peaking at access speed at millisecond intervals.
    Notice how its less than 1% of packets ? this is nothing to worry

    If you ran a SNMP get of ifOctects at the 10 secs intervals, you would
    probably sees peaks of 75% utilisation on the T1. If ran it at one
    second interfals, you would probably see T1 usuage peaks at 90%
    utilisilation. If the ran a sub-second intervals (when I dont think the
    SNMP engine update that quick), you would see the 100% peaks... you get
    the picture.

    So a) your really getting T1 peaks at 100%, which is normal - and that
    what QoS is for
    b) you probably dont realise that is not simply 70% of the T1 reserved
    - less voice, and CBFWQ max-reserved Bandwidth.

    Search for Corvil at Cisco.com.. you can get sub-millisecond visibility
    to how bursty the traffic is, without SNMP polling info out of the
    rotuer every second. Requires 12.3T/12.4 though.
    jay, May 7, 2006
    1. Advertisements

  3. opensource

    opensource Guest

    Thanks, I'll check into Corvil.
    opensource, May 9, 2006
  4. opensource


    May 26, 2006
    Likes Received:
    Followup Re: QoS drops in LLQ/CBWFQ queues

    Well, what was the outcome?

    lueckenhoff, May 27, 2006
  5. opensource


    May 26, 2006
    Likes Received:
    Minor clarifications on Bandwidth Estimation in Cisco IOS (aka Corvil)

    Dear Jay,

    That's a great explanation; you've cut right to the heart of what makes this feature so neat.

    Don't take marketing too seriously :razz: I implemented all the IOS-resident aspects of this feature, and can say definitively, that it does not give sub-millisecond visibility. However, what you do get with this feature is really cool:

    1. queueing and congestion visibility down to the eight-millisecond range
    2. automatic synchronization with router configuration changes. For example, if the operator changes maximum allowable queue depth, this feature automatically takes that new setting into account.
    3. all this happens for free using the existing statistics/instrumentation logic--not one instruction of additional per-packet overhead! :veryprou:
    4. all this can happen at any outbound interface--even those that would be difficult or impossible to instrument otherwise--like MLP bundles, FR or ATM sub-interfaces.
    5. efficient export to Corvil's offboard statistics appliance and analysis programs.

    lueckenhoff, May 27, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.