«

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
Citrix
and IPCC

During high traffic volumes (>40%) we see drops in the citrix and/or
IPCC
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
Serial0/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
Queueing
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
Queueing
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
Queueing
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
Queueing
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
pen-router1#

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
------------------------------------------------------------------------
opensource's Profile: http://www.CertificationChat.com/member.php?userid=67
View this thread: http://www.CertificationChat.com/showthread.php?t=50743

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
about..

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.

Thanks, I'll check into Corvil.


--
opensource
------------------------------------------------------------------------
opensource's Profile: http://www.CertificationChat.com/member.php?userid=67
View this thread: http://www.CertificationChat.com/showthread.php?t=50743

[lueckenhoff]

Originally Posted by opensource

Thanks, I'll check into Corvil.

Well, what was the outcome?

Bruce

[lueckenhoff]

Dear Jay,

Originally Posted by jay

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.

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

Originally Posted by jay

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.

Don't take marketing too seriously 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!
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.

thanks,
Bruce