Cool! Notice that they think it's a router, when it's really a switch. So a few things might not apply, thought they probably do.
Also their runt verbiage is weak. :-) They say this: WARNING: More than 0.1% of input traffic are 'runts'. I guess 0.1% must be their threshold, which seems really low. On this network, the runt statistic is much higher and they should have mentioned this. Priscilla > (undersized packets). Symon Thurlow wrote: > > From the output interpreter on www.cisco.com (you may need a > cco login for it) > > ========================================================================== > SHOW INTERFACE FAST/GIGABIT/ETHERNET NOTIFICATIONS (if any) > ========================================================================== > > Interface FastEthernet0/48 (up/up) > WARNING: The counters have never been cleared on this > interface and may not > accurately reflect the current status of this interface. > TRY THIS: Use the 'clear counters' command to reset the > counters and monitor > the interface parameters over time (less than 24 hours). > Reset the counters > and wait a few minutes to resubmit the output to Output > Interpreter. > > WARNING: The collision rate is 1.4108%, which is greater than > 0.1%. > TRY THIS: Look for unterminated or overly long ethernet > cables, and/or > malfunctioning transceiver(s). This may require a > host-by-host inspection or > the use of a protocol analyzer. > Consider reducing the number of hosts on the segment to > reduce the collison > rate, or subdividing the collision domain using > switches/bridges. > REFERENCE: For further information, see: > Troubleshooting Ethernet > > Troubleshooting Ethernet Collisions > > Optimizing Your Network: Replacing Hubs with Desktop Switches > > > WARNING: More than 0.1% of input traffic are 'runts' > (undersized packets). > Runts indicate the number of packets which are discarded > because they are > smaller than the medium's minimum packet size. For example, > any Ethernet > packet which is less than 64 bytes is considered a runt. > Excessive runts > are normally the result of a collision, a faulty device on > the network, or > malfunctioning software. Runts may result from collisions, or > may may indicate > busy network. However, they may also indicate a hardware > (packet formation), > transmission (corrupted data), or network design (more than > four cascaded > repeaters) problem. > TRY THIS: Verify network topology and use a protocol analyzer > to identify the > source of the runts. > REFERENCE: For further information, see: Troubleshooting > Ethernet > > Troubleshooting Ethernet Collisions > > > WARNING: There have been 2417684 'underruns' reported. > This indicates the number of times that the transmitter has > been running > faster than the router can handle. > TRY THIS: Monitor the level of underruns over time. If they > continue > increasing, consider buffer and queue tuning or upgrading > hardware. > REFERENCE: For further information, see: Troubleshooting > Ethernet > and > Buffer Tuning > > > INFO: The 'deferred' counter represents the number of times > the interface has > tried to send a frame, but found the carrier busy at the > first attempt > (Carrier Sense). This normally does not constitute a problem, > and is part of > Ethernet operation. However, if the deferred counter becomes > excessive, verify > you have the proper duplex and speed configured on both sides > of the link. > If you are using autonegotiation on this port, then hard code > the speed and > duplex instead. Do the same on the neighboring device. > > INFO: There have been 2417684 'output buffer failures' > reported. > If outgoing interface buffers are not available, an output > buffer failure is > reported. If an interface buffer is available but the > Transmit Queue Limit is > reached, the packet is dropped. However, if 'transmit-buffers > backing-store' > > is enabled, the packet is placed in a System Buffer (which > has to be obtained > from an appropriate Free-List), and enqueued in the Output > Hold queue for > future transmission at the Process level, and an Output > Buffer Swap is reported. > nd a frame, but found the carrier busy at the first attempt > (Carrier Sense). This normally does not constitute a problem, > and is part of > Ethernet operation. However, if the deferred counter becomes > excessive, verify > you have the proper duplex and speed configured on both sides > of the link. > If you are using autonegotiation on this port, then hard code > the speed and > duplex instead. Do the same on the neighboring device. > > INFO: There have been 2417684 'output buffer failures' > reported. > If outgoing interface buffers are not available, an output > buffer failure is > reported. If an interface buffer is available but the > Transmit Queue Limit is > reached, the packet is dropped. However, if 'transmit-buffers > backing-store' > > is enabled, the packet is placed in a System Buffer (which > has to be obtained > from an appropriate Free-List), and enqueued in the Output > Hold queue for > future transmission at the Process level, and an Output > Buffer Swap is reported. > > ________________________________ > > From: Sam Sneed [mailto:[EMAIL PROTECTED]] > Sent: Thu 06/02/2003 3:59 PM > To: [EMAIL PROTECTED] > Subject: Re: Switch Port Healthy [7:62567] > > > No, too many errors. The are caused by the having the router > set to half > duplex. On 2600 routers you can set the interfaces to full > duplex. You > should do this on the router and on the switch for that port. > > ""Steiven Poh-(Jaring MailBox)"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Hi Group, > > > > This port is connected to my 2600 router, can anyone comment > whether the > > bandwidth is healthy? Thanks > > > > > > FastEthernet0/48 is up, line protocol is up > > Hardware is Fast Ethernet, address is 000a.f477.662c (bia > 000a.f477.662c) > > MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, > > reliability 255/255, txload 1/255, rxload 2/255 > > Encapsulation ARPA, loopback not set > > Keepalive set (10 sec) > > Half-duplex, 10Mb/s > > input flow-control is off, output flow-control is off > > ARP type: ARPA, ARP Timeout 04:00:00 > > Last input 00:00:06, 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: 0 > > Queueing strategy: fifo > > Output queue :0/40 (size/max) > > 5 minute input rate 82000 bits/sec, 19 packets/sec > > 5 minute output rate 52000 bits/sec, 55 packets/sec > > 76531109 packets input, 2985431130 bytes, 0 no buffer > > Received 4019174 broadcasts, 4440080 runts, 0 giants, 0 > throttles > > 4440080 input errors, 0 CRC, 0 frame, 0 overrun, 0 > ignored > > 0 watchdog, 986257 multicast, 0 pause input > > 0 input packets with dribble condition detected > > 139742667 packets output, 3729299934 bytes, 2417684 > underruns > > 0 output errors, 1999663 collisions, 1 interface resets > > 0 babbles, 0 late collision, 513798 deferred > > 0 lost carrier, 0 no carrier, 0 PAUSE output > > 2417684 output buffer failures, 0 output buffers swapped > out > ============================================= > > This email has been content filtered and > subject to spam filtering. If you consider > this email is unsolicited please forward > the email to [EMAIL PROTECTED] and > request that the sender's domain be > blocked from sending any further emails. > > ============================================= > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=62593&t=62567 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
