I have a HUB where I have connected several important network nodes and routers. Lately, I have noticed several transitions failures especially with ftp. I decided to do a constant ping on some of the devices on the HUB and noticed that on average 1/25-30 pings is timing out. My first thought is that the time outs are caused by collisions, but how can be sure of the actual reason of the timeout and how can see which services could be affected by the time-out to ultimately fix the problem? Is there a way to monitor the traffic?
Collisions generally don't result in packet loss. A packet has to experience a collision 16 times before the device trying to transfer it will give up. This is referred to as an excessive collision.
You probably either have a bad cable (or cables) somewhere or a shotty hub. 3-4% packet loss on a LAN should be considered unacceptable, especially when you consider that the pings you're sending are very small packets. Full-sized packets are most likely being dropped at a higher rate -- you can test by telling ping to use larger packets.
Things like this need to be troubleshooted in a methodological fashion. You need to ping between various devices to determine if one device has a bad cable, multiple devices have bad cables, or if the hub itself is the culprit (either one or more bad ports or just a bad hub in general). Other possibilities include bad network cards, overloaded hosts, etc.
Thanks for the tips. I did ping several devices on the same HUB and got the same results. DO you know of a good article or documentation that will provide additional info on troubleshooting this type of problems?
I'm not aware of anything written about this type of thing. Where were you pinging from? Perhaps the cable or hub port that the pings travel through to reach the hub is where the problem lies. It essentially boils down to a process of elimination -- ping from various sources to various destinations, record which source/destination pairs result in occasional timeouts, and determine which pieces of equipment are common to these device pairs.
Try using a sniffer (www.ethereal.com) on the hub. Connect the sniffing PC to a spare port. Then ping from a host experiencing the packet loss. If you don't see all the echo requests, sourced from that PC, then I would agree that the hub is not "broadcasting" the packets correctly. If you do, then I would use trace route (and the sniffer still) and see if the packets take the same path everytime! One might be taking a different route and getting dropped...
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...