As a network increases in complexity, the chances of network failure and sub
optimal performance increase. Problems that might have remained undetected, in
simpler networks, may combine to cause problems in a more complex one.
To resolve these problems, develop a profile of the symptoms and use this as
a starting point for troubleshooting activities.

Keep in
mind that some network problems can be triggered or made more obvious as a
result of user behavior. For example, staff at a remote site might need to
backup data to a central site every afternoon before going home causing the WAN
link to become congested. This activity is likely to impact other users who are
still working over the link. This particular problem may be solved by changing
the work process (stop backing up across the WAN link), by provisioning more
bandwidth, or possibly by implementing superior routing technologies such as
Link Fragmentation and Interleaving to better utilize the link bandwidth. When
the symptom is regular and predictable, it makes it easier to find the cause
and solve the problem.
Intermittent network problems are significantly
more complicated to troubleshoot because the ability to collect solid
information becomes increasingly difficult. Again, intermittent problems may be
caused by user behavior. For example, assume a user is loading a large file
across the WAN. This impacts the performance of the WAN link, generating a
support call to the IT help desk. By the time the IT help desk has been made
aware of the problem and investigates the issue, the file transfer has finished
and the WAN link performance has returned to normal.
Intermittent
problems can also be caused by the interaction of various technologies.
Firewalls running dynamic NAT, configuring NAT for load balancing, and running
parallel links between systems can all present intermittent problems in network
communications. The key to solving these sorts of issues is in understanding
the technologies involved.
Communication cannot be established between
Host A and Host F because of misconfigured ACLs on both Router C and Router D.
Using
the traditional problem solving methodology of reversing changes before trying
another possible solution would fail to resolve this problem.
In Figure
, communication
between Host B and FTP Server D fails intermittently. This time, the problem is
caused by dynamic NAT timeouts being too finely tuned. When the Internet is not
congested, communications are successful. Because the Internet intermittently
gets congested, packets returning from FTP Server D occasionally take too long
and the dynamic NAT connection on the router closes, breaking the connection.
In each of these situations, the network engineer would need to be able
to recognize the misconfiguration as such, repair the configuration, and even
though the problem is not immediately resolved, be confident that it was a
contributing factor.