[c-nsp] 1700-series router falls off the Ethernet
Ted Mittelstaedt
tedm at toybox.placo.com
Thu Aug 25 02:38:14 EDT 2005
Hi Ed,
When I've dealt with these problems before in the past I've always
traced it down to Ethernet network incompatibilities particularly between
the router and the hub, although at one place a guy was using a
fiber converter that was doing it.
There are a lot of real crappy hubs/switches out there. I realize the
last thing a customer wants to hear is they need to drop $1K into
a decent switch. Particularly when they see Fry's advertising 4 port
switches for $9.95 on sale. Few smaller customers understand what
a managed switch is.
For the really poor customers I've gone to Ebay and
bought older 3com 3300's as those older switches are better than
the older Cisco switches of the same era.
One other hack that you can do which I did for one customer, is
you can ping the ethernet interface remotely from a script running
on a UNIX box, and when the script ping fails, the script issues a
command to the router to clear the interface. Run that once a minute
out of cron. Naturally you have to setup port mapping (if your running
NAT) and access lists and all that in order to reach the inside
ethernet interface. And of course it's a hack that is in the disgusting
realm.
Ted
>-----Original Message-----
>From: cisco-nsp-bounces at puck.nether.net
>[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Ed Ravin
>Sent: Wednesday, August 24, 2005 12:59 PM
>To: Adam Maloney
>Cc: tkern at CHARMER.COM; cisco-nsp at puck.nether.net
>Subject: [c-nsp] 1700-series router falls off the Ethernet
>
>
>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?
>> _______________________________________________
>_______________________________________________
>cisco-nsp mailing list cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.10.15/80 - Release Date:
>8/23/2005
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.15/80 - Release Date: 8/23/2005
More information about the cisco-nsp
mailing list