Why C2960 is dropping packets?

EvaldasOu · ‎12-26-2012

Hello guys!

We have a customer who uses about 20 x c2960's switches for access layer and 2 x c3560e for distribution layer. C2960's uses C2960-LANLITEK9-M , Version 12.2(58)SE1. Everything was working fine. Now we got information, that sometimes there are problems with connectivity. Customer tries to reach internet.

SW11#sh int fa0/18

FastEthernet0/18 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is e8ba.806a.4412 (bia e8ba.806a.4412)

Description: Bilietu kasos

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, media type is 10/100BaseTX

input flow-control is off, output flow-control is unsupported

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

Last input never, 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: 132218

Queueing strategy: fifo

Output queue: 0/40 (size/max)

30 second input rate 0 bits/sec, 0 packets/sec

30 second output rate 0 bits/sec, 0 packets/sec

7947681 packets input, 1048599076 bytes, 0 no buffer

Received 323439 broadcasts (238935 multicasts)

0 runts, 0 giants, 0 throttles

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

0 watchdog, 238935 multicast, 0 pause input

0 input packets with dribble condition detected

19465465 packets output, 20732928366 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 unknown protocol drops

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

With #show logging command , we can see that interface was flapping:

Dec 26 15:58:59.607: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to up

Dec 26 18:54:34.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to down

Dec 26 18:54:36.296: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to up

Dec 26 19:03:35.406: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to down

Dec 26 19:03:37.410: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to up

Dec 26 19:03:40.724: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to down

Dec 26 19:03:42.729: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to up

Dec 26 20:12:57.166: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to down

Dec 26 20:12:59.180: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to up

Maybe you have some ideas how we can troubleshoot this issue?

Leo Laohoo · ‎12-27-2012

Make sense. Firstly, the output drops is caused by the switch trying it's best to send 100 Mbps worth of data down the "tube". Unfortunately, whatever is connected to this is having some kind of issue. So instead of accepting the data, the data is being "dropped" by the switch because the remote end's connection has gone down.

Your 2960 has two Gig ports. Is any one of those NOT used to do a simple TDR?

EvaldasOu · ‎12-27-2012

Thank you very much for your answer Leo.

All the switches uses both Gig ports for Uplink connection. Topology looks like this:

These switches are online for about 500days. Maybe it is time for a reload?

Leo Laohoo · ‎12-27-2012

The problem is not as simple as a reload.

Whatever is connected to this port is having major issues.

This is why I'm asking if you have a GigabitEthernet port to run TDR. I'm suspecting the client connected to this port has a failing NIC card.

jimmysands73_2 · ‎12-27-2012

Not related...but

>> 1 interface resets

Does this mean layer 1 is dropping or layer 2? I thought when the line protocol went up / down this caused the reset counter to go up...but looks like it a layer 1 stat...is this correct?

Leo Laohoo · ‎12-27-2012

Does this mean layer 1 is dropping or layer 2?  I thought when the line protocol went up / down this caused the reset counter to go up...but looks like it a layer 1 stat...is this correct?

1 interface reset is very, very common. I have no idea how this counter works but I tend to ignore interface resets if it ain't >10.

atef yamin · ‎12-27-2012

Just saw this link:

http://www.cisco.com/en/US/docs/ios/12_3/interface/command/reference/int_s3g.html

"

Number of times an interface has been completely reset. This can happen if packets that were queued for transmission were not sent within several seconds. On a serial line, this can be caused by a malfunctioning modem that is not supplying the transmit clock signal or by a cable problem. If the system notices that the carrier detect line of a serial interface is up, but the line protocol is down, it periodically resets the interface in an effort to restart it. Interface resets can also occur when an interface is looped back or shut down."

EvaldasOu · ‎12-28-2012

Thanks guys. I will check it again in a few days. Maybe there is a problem from ISP side. I will let you know