Causes for Input Queue Drops

[yuchenglai]

Hi All,

Does anyone know what cause Input queue drops? Can a "buffer miss" cause the input queue drop to increment? According to Cisco document 14620 "Understanding Buffer Misses and Failures," that is what I understand.

Also, would security ACLs or QOS ACLs cause input queue drops to increment? Or do these ACLs process these packets before they even get to the input queue? Any advice is appreciated.

Thanks,

[Tshi M]

"These are the conditions for input queue drop counter. They usually occur when the router receives bursty traffic and cannot handle all packets.

The Rx FIFO which is accessible by the interface PHY and interface DMA is full and any new frames that arrive in this condition will be dropped (normally called as overflow) and the rx_overflow counter (seen through show controller interface-id) will be incremented. When rx_overflow counter is incremented by one, it indicates that overflow condition has occurred once and is not indicative of the number of frames dropped.

The Rx ring which is accessible by the interface DMA and interface driver code is full. Any new frame transfers from the DMA cannot proceed with this condition, since there are no free entries in Rx ring and hence the frames sent are dropped (termed as overrun condition). The rx_int_drop counter (seen through show controller interface-id) is also incremented by one. Again, if rx_int_drop is incremented by one it indicates that there is one occurrence of an overrun condition, and the number of frames dropped is not known."

In regards, to ACL, I once was told by a TAC engineer that ACL will cause packets discard.

regards

[yuchenglai]

what is the interface PHY and DMA ?

[Tshi M]

Physical layer and Direct memory Access. I overlooked to include the link from the quote earlier:

http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml

rgds,

[yuchenglai]

Looking at the output of this "sh int vlan x," would you say there are problems?

Vlanxxx is up, line protocol is up

Hardware is EtherSVI, address is 001c.5731.c800 (bia 001c.5731.c800)

Description: xxx

Internet address is x.x.x.x/x

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive not supported

ARP type: ARPA, ARP Timeout 04:00:00

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

Last clearing of "show interface" counters never

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

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 958000 bits/sec, 188 packets/sec

L2 Switched: ucast: 3724399858 pkt, 1414990366287 bytes - mcast: 1467199605 pkt, 125137510195 bytes

L3 in Switched: ucast: 90243569 pkt, 38375932854 bytes - mcast: 119656930 pkt, 178280412735 bytes mcast

L3 out Switched: ucast: 792623037 pkt, 542742487722 bytes mcast: 3297621968 pkt, 4764137444678 bytes

257781963 packets input, 222817396626 bytes, 1 no buffer

Received 47193027 broadcasts (128816774 IP multicasts)

0 runts, 0 giants, 18807 throttles

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

805968744 packets output, 541389773902 bytes, 0 underruns

0 output errors, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

[Tshi M]

Could you please counters and take a look at it again in few minutes or hours. According to this output, the counters were never cleared.

It does however show a lot of drops.