What causes Layer 2 interface "input queue drops" to increase ?

Unanswered Question
Apr 26th, 2007

Hi All,

I have observed that on almost all of our Layer 2, fastEthernet ports, on the Catalyst 6500 /w SUP720, the input queue drop is always increasing, albeit slowly.

e.g

FastEthernet2/1 is up, line protocol is up (connected)

Hardware is C6k 100Mb 802.3, address is 000b.466b.a608 (bia 000b.466b.a608)

Description: CI_T1_S045_SW3

MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,

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

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s

input flow-control is off, output flow-control is unsupported

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

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

Last clearing of "show interface" counters 00:51:20

Input queue: 0/2000/308/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 6000 bits/sec, 1 packets/sec

5 minute output rate 31000 bits/sec, 24 packets/sec

9791 packets input, 2472760 bytes, 0 no buffer

Received 742 broadcasts (505 multicasts)

0 runts, 0 giants, 0 throttles

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

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

78242 packets output, 11831951 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 PAUSE output

0 output buffer failures, 0 output buffers swapped out

I have tried to search the internet for an explanation of this but can find very little information. It has been suggested that it could be caused by Layer 2 control frames that are being punted to the CPU and then dropped, such as DTP, or BPDU messages.

Can anyone shed any light on this ?

Incidentally, all links are very low utilisation, with no layer 1 / layer faults.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
sachinraja Thu, 04/26/2007 - 03:39

hello ,

have u enabled ip cef ? if not, this can be a factor for the input queue drops to increase as this will reduce the amount of packet switched datagrams.

Input queue drops are due to process-switched traffic, either traffic destined to the router itself or going to the process-switching code..

Show buffer input-interface f3/1 header is one of the good commands to troubleshoot this, but i would recommend you to open a TAC for further analysis, as this requires a lot more understanding of the packets which are forced to the queue and why is it getting dropped !! This command will show you the source and destination, type of packet, and so on. Of course, if the input queue is empty, this command won't return anything.

Hope this helps. rate replies if found useful.

Raj

cbeswick Thu, 04/26/2007 - 04:35

Hi,

Thanks for your response. IP Cef is enabled. The input queue is permanently empty so I am unable to check the buffer pools.

Do you think it is worth performing a "SPAN" session on the RP ? I havent done this before and have read that this should give me some indication of which packets are being punted to the CPU. However, I suspect that I will have trouble trawling through the data as quite alot is being punted to the CPU at the Layer 2 Interface and Layer 3 Sub Interface level.

sachinraja Thu, 04/26/2007 - 04:53

Hello chris

i guess you can try this, but if there are too many packets hitting the CPU, you will need to be more cautious.. if your product is under support, i think my best advice will be to open a TAC case.. they will have better tools to investigate your issue.. :) as i said before on some other post, Netpro is a real good first-aid center,and most of the times, your problems are solved, but TAC is the last-hop hospital. :)

Hope this helps.. all the best.

Raj

cbeswick Mon, 05/14/2007 - 06:31

Hi,

I haven't yet raised this with TAC due to the fact that it isnt service affecting and appears to only increasing at a very slow rate, about 1 packet every 3 - 5 secs.

On further investigation we have found that the input queue drop is only occuring on Fast Ethernet interfaces, and only on those that are configured to trunk using dot1q encapsulation.

This points to either a control frame or some other kind of unknown unicast ?

Any help is greatly appreciated.

cbeswick Mon, 05/14/2007 - 23:45

Hi there,

Thanks for your reply.

That document was my first port of call. However my problem doesnt seem to map to any of the issues raised there.

That document works on the premise that input queue drops only occur if the input queue buffer is full. I am not convinced becuase the input queue buffer doesnt fill up. It very rarely hits 1 so input queue drops cannot be as a result of utilisation or buffer issues.

The fact that it is only occuring on a select type of configured port (fast ethernet trunk ports) raises additional quesions. Ports configured for just access vlans (not trunking) are not experiencing the drops. This pattern indicated something software related.

Actions

This Discussion