cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3501
Views
0
Helpful
9
Replies

input queue drops are increasing

amitmarathe
Level 1
Level 1

I am facing input queue drops on the Gi interface. Please give the troubleshooting tech note. Here is the output of show interface.

GigabitEthernet1/1 is up, line protocol is up

Hardware is C6k 1000Mb 802.3, address is 0005.7485.4014 (bia 0005.7485.4014)

Description: << Uplink to Primary Core Switch - 10.15.3.65[Gig 5/1] >>

Internet address is 10.15.29.2/30

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

reliability 255/255, txload 6/255, rxload 8/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s

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

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

Input queue: 0/1000/304/304 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue :0/40 (size/max)

30 second input rate 34437000 bits/sec, 5598 packets/sec

30 second output rate 26262000 bits/sec, 5891 packets/sec

L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes

L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast

L3 out Switched: ucast: 0 pkt, 0 bytes

992671 packets input, 898355211 bytes, 0 no buffer

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

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

0 input packets with dribble condition detected

953918 packets output, 426466273 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 output buffer failures, 0 output buffers swapped out

Appreciate immediate reply.

9 Replies 9

Istvan_Rabai
Level 7
Level 7

Hi Amit,

You have 992671 packets input, and 304 packets dropped, which is about 0.03%, and this can even be acceptable.

These packet drops could happen because of temporary overloads of the interface input queue.

Cheers:

Istvan

Can i manipulate configuration to nullify the drops. Please revert.

1-issue a "clear counter GE1/1" command , and then u can monitor efficiently ( I see u have done that ).

2- what platform is this ?

3- "sh int ge1/1 queuing" this will give u an idea about Q status.

Sam

even after clearing the counter the drops are increasing. If you see the output

Input queue: 0/1000/304/304 (size/max/drops/flushes);

queue size is 0.

Do i need to configure QOS for this.

u probably need to make Q deeper, let see what can be done once we know which platform it is.

what is the state of conncted port at other end ?

On the other end switch output queue drop not found. both end MTU is default. platform is 6509. Its a L3 port. Even after increasing load-interval to 1000 drops are increasing in same rate. Is any issue with gibic module.

u had already 1000 to start with , so u need to go over a bit. Could be some bursty traffic causing this.

Input queue: 0/1000/304/304 (size/max/drops/flushes); Total output drops: 0

Sam

Under GE1/1

"hold-queue X in"

X=1000 in ur case, keep increasing slowly and monitor if it solves the issue.

Sam

Joseph W. Doherty
Hall of Fame
Hall of Fame

Cisco's "Output Interpreter" has this to say:

"INFO: There have been 304 flushes on this interface. Flushes are similar to input

drops, but are proactively forced by the router before the input queue is full.

Selective Packet Discard (SPD) is the congestion avoidance mechanism used, where

non-control packets are dropped in preference to control packets (i.e. routing

updates). Monitor the number of flushes. If they continue to increment, consider

increasing the size of the input queue and/or improving the switching mechanism

used by this interface (e.g. change process switching to fast switching). 'Flushes'

troubleshooting can be treated similar to input drops.

REFERENCE: For more information, see Troubleshooting Input Drops."

The actual link reference is: http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml

The above doesn't directly address trouble shooting this issue on a 6500, so I found two more references, although neighter is specific:

http://www.cisco.com/en/US/products/hw/routers/ps167/products_tech_note09186a0080094320.shtml

http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml

Considering the low drop %, I also agree with poster that it might be left alone.

Perhaps part of the problem might be related to the type of 6500 card you're using?

If a "cure" can't be found on the 6500, you might be able to fix by slowing the traffic on the other side's egress. In this interface snapshot, slowing to 100 Mbps would decrease possible bursts yet might preclude the drops.

Review Cisco Networking products for a $25 gift card