input drop physical versus SVI

Unanswered Question
Apr 23rd, 2010

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

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Amit Singh Wed, 04/28/2010 - 11:07
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?


Edison Ortiz Wed, 04/28/2010 - 11:38

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.

rahurao Fri, 04/30/2010 - 02:21

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 Input processes. To do so, run the show processes cpu exec command. If Cisco IOS Software version 12.1 or higher currently runs on the router, you can shorten the output of the show processes CPU command through the output modifiers:

          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:

If packets are destined for  the router, find out which higher-layer             protocol congests the input queue. For this, use one of these show              traffic exec commands:


show ip traffic


show ipx traffic


show appletalk traffic

You can refer the following link for more better understanding:


Troubleshoot input queue drops:

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

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!

Actions

This Discussion