[c-nsp] 1700-series router falls off the Ethernet

Ed Ravin eravin at panix.com
Wed Aug 24 15:59:11 EDT 2005


The story so far - a few users with Cisco 1700-series routers
have reported that every now and then (once or twice a month?)
the router stops receiving Ethernet packets on FastEthernet0.

It just hit me again: as usual, "clear interface faste0" fixed it.
I ran a few "show int" commands, but forgot to do "show controller" as
suggested below.

Here's what I saw with "show int faste0":

  MTU 1500 bytes, BW 100000 Kbit, 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, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:06:47, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/148038/0 (size/max/drops/flushes); Total output drops: 0
  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
     610775024 packets input, 1948694396 bytes
     Received 87789888 broadcasts, 0 runts, 0 giants, 0 throttles
     38153 input errors, 0 CRC, 0 frame, 38153 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     433012508 packets output, 3503679533 bytes, 135000 underruns
     135000 output errors, 0 collisions, 8 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

And when I ran "show int" a second time around 15 seconds later:

  MTU 1500 bytes, BW 100000 Kbit, 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, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:07:02, output 00:00:05, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/148038/0 (size/max/drops/flushes); Total output drops: 0
  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
     610775024 packets input, 1948694396 bytes
     Received 87789888 broadcasts, 0 runts, 0 giants, 0 throttles
     38153 input errors, 0 CRC, 0 frame, 38153 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     433012511 packets output, 3503679789 bytes, 135000 underruns
     135000 output errors, 0 collisions, 8 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Notice that input queue, errors, and input packets are all frozen,
while output packets seem to still be going out (3 packets totaling
256 bytes - other than that and the last input time, none of the
numbers changed).

I was pinging the router during the interval between the two "show
int" commands, just to make sure there was input traffic.

Any ideas?  This is clearly a bug, since I'm not the only one getting
it, and it's not limited to any one router.  I've already swapped out
the router, the cable, and upgraded the IOS at least once.

	-- Ed

On Thu, May 05, 2005 at 01:47:16PM -0500, Adam Maloney wrote:
> On Thu, 5 May 2005, Kern, Tom wrote:
> > I have a 1700 router which is my internet router. it has a frame-relay
> > serial int and an etherent int.  About twice a month, the ethernet
> > int dies. Actually, it says eth0 up, line protocol up but i can't
> > connect to the internal network from the router. I can
> > however ping out on the frame.
...
> 
> > well, the router says nothing. I was wondering what I should turn on to 
> > make it more verbose.
> 
> Get some show int eth0 and show controller eth0 output (twice, a few 
> seconds apart).  Look at the interface queues and "last input" timers. 
> Check if these or the packet counters or error counters are increasing 
> between the two times you get the output.
> 
> Check bugtool and see if this is a known bug for your IOS version.  There 
> have been bugs in the past where an interface input queue will wedge under 
> certain conditions.
> 
> I would also try unplugging the ethernet cable from the cisco, waiting a 
> few secs, and then plugging it back in to see if that bounces the 
> interface hardware.
> 
> You might also try putting a cheap hub or switch between the cisco and the 
> firebox, and see if that makes any difference.
> 
> > Rebooting the firebox doesn't help. only reloading the router clears the 
> > issue
> 
> I assume you did a shut/no shut on the interface before reloading?
> _______________________________________________


More information about the cisco-nsp mailing list