cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
975
Views
8
Helpful
7
Replies

Why C2960 is dropping packets?

EvaldasOu
Level 4
Level 4

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?

7 Replies 7

Leo Laohoo
Hall of Fame
Hall of Fame

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?

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?

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.

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?

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.

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
Level 4
Level 4

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

Review Cisco Networking for a $25 gift card