[nsp] Cisco 3524 ignored packets

[Steve Francis]

We've seen this problem where these low end switches incremented ignores 
when they had to flood packets out all ports, due to the destination MAC 
not being in the CAM table.
(Which is generally due to assymetric routing, where the packets come in 
via one path on one switch, but the replies go out via another core 
switch to reach the default gateway, so the first switch times out the 
CAM entry before the ARP entry, has to flood out all ports, and the 
little distribution switches that should not be involved in the 
conversation get overwhelmed with the flooding that they have to do.)

Simon Lockhart wrote:

>I'm in the middle of trying to diagnose a strange packet loss problem on one of
>our LANs. The nearest I can get to isolating the problem is that when I get a
>bad burst of packet loss, the ignored count on one of the switches in the path
>goes up significantly.
>
>FastEthernet0/5 is up, line protocol is up 
>  Hardware is Fast Ethernet, address is 0030.946d.7705 (bia 0030.946d.7705)
>  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, 
>     reliability 255/255, txload 20/255, rxload 21/255
>  Encapsulation ARPA, loopback not set
>  Keepalive not set
>  Auto-duplex (Full), Auto Speed (100), 100BaseTX/FX
>  ARP type: ARPA, ARP Timeout 04:00:00
>  Last input 00:00:07, output 00:00:01, output hang never
>  Last clearing of "show interface" counters 00:36:47
>  Queueing strategy: fifo
>  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
>  5 minute input rate 8432000 bits/sec, 2154 packets/sec
>  5 minute output rate 8097000 bits/sec, 2041 packets/sec
>     4833762 packets input, 2403042086 bytes
>     Received 2344769 broadcasts, 0 runts, 0 giants, 0 throttles
>     0 input errors, 0 CRC, 0 frame, 0 overrun, 10919 ignored
>     0 watchdog, 2344712 multicast
>     0 input packets with dribble condition detected
>     4667093 packets output, 2461139718 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
>
>Is this likely to be caused by the amount of multicast traffic? Is it exhausting all the
>buffers? Working from the packet counts, it's less than 5Mbps of Multicast - surely
>the 3524 should be able to cope with this?
>
>Any ideas?
>
>Simon
>  
>