If you are really really lucky, you have been blessed with either a properly designed network, or a very small network. But for some we are not blessed with that luxury.
The most complex of these are the Legacy networks which have too many systems, legacy applications, and legacy thinking. These are the things that make troubleshooting networks very difficult if not impossible.
Before we begin, a few things that I will assume, first you will know at least something about Ethernet, and that you are at least familure with the OSI 7 layer model, or at least the lower 2, because some of this information deals with those lower layers.
Too many systems on the same Network Segment
A single network segment can be considered a broadcast domain, this is a segment of the network in which a device could be reached by sending a frame to the datalink broadcast address (For ethernet FF:FF:FF:FF:FF:FF)
For many networks you will see at least, ARP requests, and Gratuitious ARPs. But you may also see many other packets travelling around depending on the Protocols that are in use on the network such as IPX/SPX, NetBEUI, TCP/IP and too many to count.
Now many websites, and books recommend to limit the number of devices and it depends on the Network, for a pure TCP/IP Network it can be pushed to 500 IP's, but for network with a more diverse network makeup, it would be better to have 300 unique network addresses.
Legacy Systems
Legacy systems can be an annoyance at best, down right troublesome at worst. These are the systems that were bought so far back that no one knows what it's purpose is, or how to maintain it. There may be even a chance the company that built it, doesn't even exist.
These can be problems from the side point that as the hardware ages it may not support the newer protocols, or the device may become faulty just from age (For those of us who remember, is it even possible to find an MCA network card anymore). What is worse, is often they become the forgotten child of the organization, to the point that they get misplaced (I've seen it happen, a system was drywalled into a wall).
These are also the systems that prevent the network from improving as the technologies that can assist in this, could potentially not work with this device, such as a 10base2 card, when upgrading to a 10baseT network.
When there is a chance to upgrade and replace this system, time should be taken to replace it, but ideally systems should be cycled out of the environment on a regular basis, for some organizations this may be yearly, for most it can be between 3 and 5 years, or even more. But the policy of "If it's not broke, don't fix it" should not apply, as tomorrow it could break, and it might take you a long time to recover.
Legacy Applications
They have many of the same items in common with the Legacy Systems. They are often even hosted on Legacy Systems, but not always. But they have many of the same problems, and same solutions.
The biggest difference is that if you are building in-house applications, care should be taken to work towards making it future proof, which means programming the application in such a way that modifications can be done with ease. Growth should be easy to accomplish through simple means, and communication to external modules of the application should be standardized, to allow for rapid changes. But more importantly documentation is the key.
Legacy Thinking
This is probably the most difficult task to overcome, you often can not say anything overtly to change a person's mind. The only easy way to accomplish a change in someone who is a "Legacy Thinker", is to show by example. The thing is that you must make the person, want to know more about the changes you would like to see, so one of the most effective methods of influencing change is talking to the people involved, find out what issues are they dealing with, what is currently being used, and what are the final requirements, and see if your solution would fit into those requirements, and then explain how this new solution would meet the person's requirements.
Final Thoughts
Networks are very difficult to troubleshoot, at the best of times. But with many of the other unknowns that exist on most networks, it can be down right impossible to troubleshoot, but persistence will pay off in the end, as more and more changes occur.
