04-23-2010 03:11 PM - edited 03-06-2019 10:46 AM
Gig0/5 is a physical on the 3550 that is connected to a series of 2950s.
I see a lot of input drops on the SVI and none on the physical at the input level.
Can someone explain why. See output below and please don't remind me that they are EOS.
Why would the packet input also differ? It is the only physical that is part of vlan 402.
Thanks
igabitEthernet0/5 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is 0011.920d.1305 (bia 0011.920d.1305)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 6226000 bits/sec, 1848 packets/sec
5 minute output rate 10323000 bits/sec, 2176 packets/sec
4143239674 packets input, 3046175017 bytes, 0 no buffer
Received 272197062 broadcasts (0 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 245954151 multicast, 0 pause input
0 input packets with dribble condition detected
715336262 packets output, 2425681709 bytes, 0 underruns
0 output errors, 0 collisions, 1 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
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
sh int vlan 402
Vlan402 is up, line protocol is up
Hardware is EtherSVI, address is 0011.920d.1300 (bia 0011.920d.1300)
Internet address is 10.10.10.1/23
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:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/135255/0 (size/max/drops/flushes); Total output drops: 153
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 110000 bits/sec, 18 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
236346813 packets input, 4048074528 bytes, 0 no buffer
Received 0 broadcasts (191415273 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
22053572 packets output, 1393209506 bytes, 0 underruns
0 output errors, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
04-28-2010 10:37 AM
What's the output of "sh ip traffic" ?
04-28-2010 11:07 AM
Input queue drops are drops of process switched traffic which is not switched in hardware and is handled by the CPU. Process switched
traffic is often packets which are either destined for the router (i.e.telnet/ssh packets, routing protocol updates, pings, SNMP, etc...) or
packets which are not able to be handled by CEF/fast switching. Process switched packets take more CPU time than CEF/fast switched packets and also
require buffering in the public buffer pools. In an optimal situation, process switched traffic would be minimal, however, some configurations /
uses for Cisco products can cause significant process switching.
* There shouldn't be too much Process Switched traffic hitting the interface, as it would result it in Packet Drops when there no space left
for the interface buffers. This generally happens when there is flooding of such kind of traffic which needs to be processed in CPU.
Are you running multicast traffic ?
Are you able to ping, telnet to the switch normally?
What is the IOS featureset and verion you are running on the switch?
04-28-2010 11:38 AM
236346813 packets input, 4048074528 bytes, 0 no buffer
Received 0 broadcasts (191415273 IP multicasts)
You have around 80% of traffic received that is IP Multicast.
Do you have PIM or IGMP Querier configured on that Vlan?
IGMP Snooping is on by default by it does need a querier.
04-30-2010 02:21 AM
Hi Edison,
As per the outputs If more than one routed protocol is configured on the interface, first determine the protocol that congests the input queue. Here is the fastest way to do this is:
Determine the suspect protocol. Check the CPU utilization in
router#show processes CPU | i ^PID|Input
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
10 8503 1713 4963 0.00% 0.00% 0.00% 0 ARP Input
24 69864 11429 6112 0.08% 0.11% 0.10% 0 Net Input
28 55099 8942 6161 26.20% 20.07% 19.26% 0 IP Input
37 4 2 2000 0.00% 0.00% 0.00% 0 SSCOP Input
40 8 2 4000 0.00% 0.00% 0.00% 0 ILMI Input
49 8 1 8000 0.00% 0.00% 0.00% 0 Probe Input
50 28209 4637 6083 0.00% 0.03% 0.04% 0 RARP Input
59 8 2 4000 0.00% 0.00% 0.00% 0 SPX Input
61 8 2 4000 0.00% 0.00% 0.00% 0 Tag Input
68 20803 3392 6132 0.00% 0.03% 0.00% 0 IPX Input
104 4 1 4000 0.00% 0.00% 0.00% 0 IPXWAN Input
107 8 1 8000 0.00% 0.00% 0.00% 0 AT Input
Table 1 lists the possible input processes and types of packets that can congest the input queue:
show ip traffic
show ipx traffic
show appletalk traffic
You can refer the following link for more better understanding:
Troubleshoot input queue drops:
You can also use the hold queue increase command as workaround:
To resolve the input drops and throttles, adjust the input hold queue on the interface.
The input hold queue is configured by issuing the hold-queue length {in | out} interface command.
I hope this helps!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: