Start simply and work your way up. Networks can be complex beasts with a lot of moving parts--especially if you're moving across sub nets--and if you have high

Start simply and work your way up. Networks can be complex beasts with a lot of moving parts--especially if you're moving across sub nets--and if you have high traffic volume etc. For your immediate problem, traceroute would be a good place to start to help figure out where you're dying on the local network. If the switch is eating packets and connections, the traceroute should die at the switch. With the switch being faulty, before you assign hardware as a cause, check the bandwidth load you're pushing across the switch. If you're saturating the link and trying to push more stuff through the switch than it can support, it will cause what appears to be connection loss. Also check for a feedback loop somewhere, i.e. someone plugging a cable back into the switch creating a packet storm that doesn't die. Learning networks takes time and experience, and each network is a different beast with different usage patterns, hardware, and characteristics. A couple useful rules of thumb that I've found helpful when dealing with network debugging are as follows: 1) Start simply. Ping/traceroute/tcpdump/nc (netcat) are your first best friends on Linux and should be the first place you start when you're debugging by hand. NC is a pretty sweet program because it allows you to set up arbitrary TCP connections between two machines without having to standup a full software stack. nc -l <portnum> to set one up. This can be incredibly helpful if you have software that's supposed to connect over the network and isn't work, set up a nc instance on the target port to see if there's a connection attempt. If so, it means the bug is further up the stack. 2) Networks can be complicated beasts with a lot of interchanging parts that interact in complex and sometimes unpredictable ways. Start simply and work your way up in complexity when trying to ascertain cause. 3) Make sure your system logging and system monitoring are paying attention to your network activity and issue warnings when things happen like connectivity outages. Decent monitoring software can save a lot of debugging time because it'll tell you want happened. Our IT guys used Icinga to monitor everything. Bit of a PITA to setup, but worth it to be able to see what/where things were going wrong. 4) Bandwidth isn't finite. Check your hardware to see if it's saturated. We had several issues where our internal network traffic was saturating the original network design causing everyone on the network to experience absolutely torrid performance. After we rewired the network and isolated the chatty boxes on their own switches, network performance improved drastically. Don't assume the network in general hasn't outgrown the network design or that burst traffic isn't overloading the setup. It's possible and also explains the intermittent outages.