06-29-2009 09:58 PM - edited 03-04-2019 05:16 AM
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.
06-29-2009 10:31 PM
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
06-29-2009 10:35 PM
Can i manipulate configuration to nullify the drops. Please revert.
06-29-2009 11:02 PM
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
06-29-2009 11:07 PM
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.
06-29-2009 11:09 PM
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 ?
06-29-2009 11:38 PM
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.
06-30-2009 12:05 AM
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
06-29-2009 11:16 PM
Under GE1/1
"hold-queue X in"
X=1000 in ur case, keep increasing slowly and monitor if it solves the issue.
Sam
06-30-2009 04:16 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide