Packets dropping

[willemvwyk]

Hi

Below is a sh interface s0/2/0 from my router indicating that packets are being dropped. I am trying to figure out why the packets are dropped. I checked the buffers and memory but can't find any problems there. The line is not flapping. No errors. No acl's & QoS. On router2 that connects to this router via the s0/2/0 interface there was 2 QoS applied to the interfaces on the serial and the ethernet. I thought that was causing a bottleneck and removed it, but still no joy. Router2 also indicates that packets are dropped although not as many as with router1 (output below).

thanks

wvw

Serial0/2/0 is up, line protocol is up

Hardware is GT96K Serial

Description: (128K)

Internet address is 172.16.16.1/21

MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,

reliability 255/255, txload 67/255, rxload 33/255

Encapsulation HDLC, loopback not set

Keepalive set (10 sec)

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

Last clearing of "show interface" counters 00:00:02

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

Queueing strategy: weighted fair

Output queue: 55/1000/64/12 (size/max total/threshold/drops)

Conversations 10/42/256 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

Available Bandwidth 96 kilobits/sec

5 minute input rate 17000 bits/sec, 21 packets/sec

5 minute output rate 34000 bits/sec, 20 packets/sec

149 packets input, 17668 bytes, 0 no buffer

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

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

137 packets output, 39404 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

0 carrier transitions

DCD=up DSR=up DTR=up RTS=up CTS=up

[mheusing]

Hi,

actually you are overloading the interface and thus queueing starts. You can see this from your output:

Queueing strategy: weighted fair

Output queue: 55/1000/64/12 (size/max total/threshold/drops)

Conversations 10/42/256 (active/max active/max total)

This means at the time the command was executed, 55 packets were queued, i.e. waiting to be served. Without queueing those 55 packets would have been dropped. The implemented queueing method is weighted fair (your factory default QoS policy). You had a maximum of 42 concurrent flows (TCP or UDP) through your 128 kbps interface. Given the bandwidth and the number of flows, it is no wonder your router does drop packets, but weighted fair queueing does a fine job here avoiding to drop even more. The number of dropped packets seen, would lead me to increase the line speed (get more bandwidth) or try compression.

Ah, before I forget: the lines

5 minute input rate 17000 bits/sec, 21 packets/sec

5 minute output rate 34000 bits/sec, 20 packets/sec

are pretty useless, when it comes to understand packet drops. Assume you send for a minute at 256 kbps towards the interface, i.e. 128 kbps is dropped, and then you stop sending. The 5 minute average would report 20% usage, which could look small and yet you would see dropped packets. The averaging time is simply much to long to make any reasonable statement about dropped packets.

So in summary: the bottleneck is your interface speed of 128 kbps. Queueing does not create a bottleneck, but saves you from dropping even more.

Hope this helps! Please rate all posts.

Regards, Martin

[Joseph W. Doherty · Accepted solution]

Beside Martin's information, understand some drops are routine. One general rule of thumb is a up to 1% is usually okay. However, your stats show 12 drops for only 137 packets, about 8.8%, which is worth reviewing.

First thing you might do, let the stats accumulate longer and see how the drop ratios holds.

Second, while the link is busy, try a "show queue s 0/2/0", and see if all flows are experiencing drops, or just one. If just one, if it's just some background file transfer, is a higher drop rate for it acceptable?

Third, you can often adjust the default FQ settings, try "fair-queue 2000".

Lastly, you can get very involved in managing this congestion with advanced QoS configurations, but at only 128 Kbps, might be worthwhile attempting to obtain a more bandwidth first.

[willemvwyk]

Thanks for all the help :)

I would like to know what the meaning is of the fair queue command Number Dynamic Conversation Queues

CT(config-if)#fair-queue 4094 ?

<16-4096> Number Dynamic Conversation Queues

Thanks

wvw

[Joseph W. Doherty]

from: http://www.cisco.com/en/US/products/ps6350/products_command_reference_chapter09186a00804367af.html#wp1135459

fair-queue (WFQ)

To enable weighted fair queueing (WFQ) for an interface, use the fair-queue command in interface configuration mode. To disable WFQ for an interface, use the no form of this command.

fair-queue [congestive-discard-threshold [dynamic-queues [reservable-queues]]]

no fair-queue

Syntax Description

congestive-discard-threshold

(Optional) Number of messages allowed in each queue. The default is 64 messages, and a new threshold must be a power of 2 in the range from 16 to 4096. When a conversation reaches this threshold, new message packets are discarded.

dynamic-queues

(Optional) Number of dynamic queues used for best-effort conversations (that is, a normal conversation not requiring any special network services). Values are 16, 32, 64, 128, 256, 512, 1024, 2048, and 4096. See Table 4 and Table 5 in the fair-queue (class-default) command for the default number of dynamic queues.

reservable-queues

(Optional) Number of reservable queues used for reserved conversations in the range 0 to 1000. The default is 0. Reservable queues are used for interfaces configured for features such as Resource Reservation Protocol (RSVP).