Input queue drops/flushes on vlan interface

burruss · ‎11-10-2008

We have a 6500 w/ Sup 720 (12.2(18)SXD5,) in our data center, one of the vlan interfaces is receiving alot of input queue drops/flushes. It is only roughly 0.002% of the packets, and doesn't appear to be causing any major issues.

Increasing the queue from the default of 75 to 2000 didn't appear to have much affect (there was a slight decrease, but that could be just reduced traffic on the weekend). Showing the interface as quickly as possible, I can see the drops increment, yet I never see more than 25 packets in the queue at a time.

Anybody know a way to help determine what is getting dropped, or anything else to look at?

Vlan15 is up, line protocol is up

Hardware is EtherSVI, address is 00d0.048f.0000 (bia 00d0.048f.0000)

Description: Intel server VLAN

Internet address is 167.96.15.1/24

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

reliability 255/255, txload 4/255, rxload 9/255

Encapsulation ARPA, loopback not set

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 2d15h

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

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 35719000 bits/sec, 9917 packets/sec

5 minute output rate 19213000 bits/sec, 8986 packets/sec

L2 Switched: ucast: 631380511 pkt, 516541676011 bytes - mcast: 5033890 pkt, 2385591857 bytes

L3 in Switched: ucast: 8742105965 pkt, 5644789517947 bytes - mcast: 26470837 pkt, 36532718776 bytes mcast

L3 out Switched: ucast: 3180301623 pkt, 860376692022 bytes mcast: 92730 pkt, 28690491 bytes

8774322059 packets input, 5654149552761 bytes, 0 no buffer

Received 17290569 broadcasts (26478504 IP multicast)

0 runts, 0 giants, 0 throttles

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

3221100805 packets output, 870697943393 bytes, 0 underruns

0 output errors, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

adc_sw-1_6509#sho int vlan 15

Vlan15 is up, line protocol is up

Hardware is EtherSVI, address is 00d0.048f.0000 (bia 00d0.048f.0000)

Description: Intel server VLAN

Internet address is 167.96.15.1/24

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

reliability 255/255, txload 4/255, rxload 9/255

Encapsulation ARPA, loopback not set

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 2d15h

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

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 35719000 bits/sec, 9917 packets/sec

5 minute output rate 19213000 bits/sec, 8986 packets/sec

L2 Switched: ucast: 631380511 pkt, 516541676011 bytes - mcast: 5033890 pkt, 2385591857 bytes

L3 in Switched: ucast: 8742105965 pkt, 5644789517947 bytes - mcast: 26470837 pkt, 36532718776 bytes mcast

L3 out Switched: ucast: 3180301623 pkt, 860376692022 bytes mcast: 92730 pkt, 28690491 bytes

8774322320 packets input, 5654149629266 bytes, 0 no buffer

Received 17290864 broadcasts (26478504 IP multicast)

0 runts, 0 giants, 0 throttles

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

3221101063 packets output, 870698016704 bytes, 0 underruns

0 output errors, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

dominic.caron · ‎11-10-2008

Did you review that link:

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

glen.grant · ‎11-10-2008

You have a lot of multicast traffic going on there and if that is not configured correctly all that multicast traffic will hit the cpu when that is running . Most normal traffic should never even hit the the CPU or SVI however you want to look at it as it is switched in hardware and never has to hit the cpu. We saw this on one of our boxes , also it will usually drive the cpu way up when the person is doing the multicast if multicast routing is not configured correctly. We could almost watch the input queues fill and drop the traffic when this guy started his ghost multicast on our network and it took us a while to find out who was doing it . . Just something to keep in mind .