Dropped packets on Multilink interface

mmertens · ‎05-17-2007

I'm looking for input on the following: My customer has 4 T-1s multilinked together. The multilink interface is showing about 500 drops/hour. We have LLQ enabled on the interface for voice and a "show policy-map interface" does NOT show drops. Therefore, I do not suspect QoS causing the drops. I would suspect the drops are from insufficient BW on the WAN and the packets being held (and eventually dropped) on the output queue, although I hadn't noticed (the short time there) where BW was approaching maximum.

Please see below:

Multilink1 is up, line protocol is up

Hardware is multilink group interface

Internet address is 1.1.1.1/30

--More-- MTU 1500 bytes, BW 6000 Kbit, DLY 100000 usec,

reliability 255/255, txload 48/255, rxload 17/255

Encapsulation PPP, LCP Open, multilink Open

Listen: CDPCP

Open: IPCP, loopback not set

Keepalive set (10 sec)

DTR is pulsed for 2 seconds on reset

Last input 00:00:00, output never, output hang never

Last clearing of "show interface" counters 2d04h

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 21466

Queueing strategy: Class-based queueing

Output queue: 0/1000/64/21466 (size/max total/threshold/drops)

Conversations 0/107/256 (active/max active/max total)

Reserved Conversations 1/1 (allocated/max allocated)

Available Bandwidth 0 kilobits/sec

30 second input rate 407000 bits/sec, 479 packets/sec

30 second output rate 1132000 bits/sec, 498 packets/sec

99009892 packets input, 3278541751 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

98147723 packets output, 1237843171 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

-------------------------------

sho policy-map int

Multilink1

Service-policy output: WanOut

Class-map: WanVoip (match-any)

55455406 packets, 3052106708 bytes

30 second offered rate 96000 bps, drop rate 0 bps

Match: ip dscp af31 (26)

8349051 packets, 354070734 bytes

30 second rate 14000 bps

Match: ip dscp ef (46)

6042361 packets, 957987596 bytes

--More-- 30 second rate 0 bps

Match: protocol mgcp

41063996 packets, 1740048622 bytes

30 second rate 81000 bps

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 25 (%)

Bandwidth 1500 (kbps) Burst 37500 (Bytes)

(pkts matched/bytes matched) 13731736/693294746

(total drops/bytes drops) 26/37391

QoS Set

dscp ef

Packets marked 55455408

Class-map: WanBusiness (match-any)

34926 packets, 9510480 bytes

30 second offered rate 0 bps, drop rate 0 bps

Match: access-group 100

34926 packets, 9510480 bytes

30 second rate 0 bps

Queueing

Output Queue: Conversation 265

--More-- Bandwidth 74 (%)

Bandwidth 4440 (kbps)Max Threshold 64 (packets)

(pkts matched/bytes matched) 5900/1873969

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

QoS Set

dscp af41

Packets marked 34926

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

42785124 packets, 23141113724 bytes

30 second offered rate 1454000 bps, drop rate 0 bps

Match: any

Manoj Wadhwa · ‎05-17-2007

The drops indeed seem to be due to QoS policy. As per the policy map output, for the class-map WanVoip, you can see the output

"(total drops/bytes drops) 26/37391 "

This indeed proves that there are drops for this class. No other class are showing up any drops. Probably, increasing the strict priority from 25% to somewhat higher (30%) can mitigate these drops. Thanks!

- Manoj