A deep understanding of how a particular network really operates gives network engineers and IT managers a valuable...
advantage in daily network operations, planning, and in providing end users with the best experience possible. How are network resources actually consumed? How will the network react in a failure scenario? Knowing the answers to these types of questions is not just good network engineering, it's good business -- and enterprise network testing helps fulfill this need.
Have a plan
One of the first things to do when working with a new customer or starting a new position is to seek out network documentation, such as diagrams, spreadsheets and device configurations. In the event that there is little to no documentation available, it's important to begin a fresh discovery.
A methodical approach to enterprise network testing is extremely important in making sense of the large amount of data captured in a typical discovery. Working from a good spreadsheet to capture only the necessary information will guide the process quickly and efficiently. For example, a first step can be to capture device names and locations, code versions, serial numbers, uplink ports, active routing protocols, and passwords. This isn't the most glamorous part of networking, but having all this information accurately recorded in one place will be absolutely invaluable to the network operations team.
Understanding the physical and logical topology of a network is also critical. Without the requisite knowledge of how the network actually functions day-to-day, NetOps will be fighting an uphill battle in their troubleshooting. There is software that can create diagrams dynamically and provide valuable analytics from only a single scan, but an enterprise that has no documentation on record likely has no software available either.
Use the tools you already have
There are good software tools for enterprise network testing at a variety of price points, such as SolarWinds, ThousandEyes or Paessler, but there are also plenty of free and built-in tools already at a network engineer's disposal.
For example, as part of a large Cisco Identity Services Engine implementation, an engineer needs to know what switch platforms are on a network, what code they're running, what virtual LANs are in use, and how traffic moves over the WAN among branch offices and back to HQ.
With no other software tools available, a network engineer can manually crawl a Cisco network with show cdp neighbors in order to slowly build a topology of the LAN. WAN traffic can quickly be mapped using simple commands like traceroute and various show commands to discover Enhanced Interior Gateway Routing Protocol and Border Gateway Protocol neighbors. Yes, this can take significant time -- especially with larger sites and without some programming knowledge -- but it will provide an accurate picture of how intermediate distribution frames link to main distribution frames and how branch networks connect over a WAN.
Furthermore, without a baseline of how traffic flows during steady states and failure states, it will be difficult to understand why an outage occurred or how to integrate new technology. As a simple example scenario, consider why the egress to ISP-B didn't take over when ISP-A failed. A network engineer with an understanding of the topology and traffic baselines of his or her network would know, for example, that, one, there is no failover configured, or, two, it takes a full 30 seconds to fail to ISP-B in which case the brief outage is normal behavior.
Create bandwidth utilization baselines for WAN links as part of enterprise network testing. Use the resources at your disposal. Even the most basic version of SolarWinds can provide analytics of ingress and egress traffic of the WAN interfaces of a pair of Cisco ASR routers. The free trial version of Paessler's PRTG would likely be more than enough to do targeted data collection for a specific group of devices and links.
Finally, test, test your network
With a fresh inventory spreadsheet in hand, accurate network diagrams showing topology and traffic flow, and a solid understanding of network traffic baselines, test the network for various failure scenarios. This is much easier said than done with a production network; nevertheless, it is a vital component to understanding how a network truly behaves. Does routing reconvergence happen as expected? Which path does spanning tree protocol select when a mission-critical switchport goes down?
For many network engineers, IT managers and NetOps team leads, having a truly deep understanding of the network is an elusive goal, so start with the basics. Capture inventory data and build upon that. There is no perfect documentation, and there certainly is no permanent documentation. Ultimately, having a strong understanding of a network's inventory, topology and traffic baselines will provide a sense of how network resources are consumed and provide end users the best experience possible.
For security, make friends with network operations
Outsourcing network operations
Best practices for enterprise network testing