Avoid Flying Blind With Your Network Capacity Planning

Phillip Gervasi
By Phillip Gervasi November 2, 2017 4 minute read
Phil Gervasi is a senior network engineer currently focused on security and with experience as a consultant to global enterprise and with Cisco Gold Partners. Passionate about his craft, he’s committed to professional development and working with others to become better network engineers as well.

How do you know what’s going on in your network? I mean, how do you really know? If you’re planning any sort of infrastructure upgrade, you absolutely need to know what your current network capacity and utilization are. If you don’t, you’re flying blind.

Network capacity planning is the practice of determining the availability of network resources with regard to WAN bandwidth, link utilization, port density, traffic baselines, points of congestion, and the CPU/memory utilization of key appliances. Some organizations go even further by identifying staffing requirements, types of traffic by volume, packet loss on critical links, and mean time to repair (MTTR) for network-related incidents. Knowing today’s network capacity is a prerequisite for determining a strategy for tomorrow’s network capacity.

There are two specific hurdles to really understanding the current state of the network when planning for growth. The first is a lack of documentation, and the second is the weakness of some of our current network management protocols, namely SNMP.

Often, we’re lacking sufficient or accurate documentation. Even some basic notes saved on a department share can help an engineer determine some quick statistics, such as where trunk ports are located, where layer 3 boundaries are configured, and how many 48-port switches are in a hard-to-get-to IDF. Unfortunately, good documentation is pretty rare, and without it, having to find out “what is” wastes a tremendous amount of time and money.

Programmatic network mapping can help solve this problem and give network engineers the information to determine network inventory, port density, and platform allocation all within a matter of minutes. Ultimately, this information forms a critical part of the baseline for determining how to grow the network to meet the future needs of the business.

But documentation can tell us only so much. We also need to know the current state of the network in the context of how the business is consuming it. We have built-in tools that can start us off on the right foot, such as SNMP MIB data, but to really dig into the network and determine current state before determining future state, SNMP isn’t enough.

SNMP uses a management information base, or a MIB, to manage all of the interrelated objects within the MIB table related to network elements. SNMP MIBs ship with network devices and are loaded on a management station.

But not all SNMP managers are the same. That means that your SNMP manager may not be able to understand messages coming from a newly deployed network device. MIBs can be customized to an extent to account for this, but it becomes a process of writing custom MIB files to work with divergent platforms and to accommodate changing telemetry needs.

Being an open standard, you’d think SNMP would work across vendors, but actually the opposite is true. There’s very little standardization across vendors or even among devices from the same vendor. Also, MIBs require querying and provide no real-time streaming telemetry, so it can be cumbersome to get specific flow data.

This isn’t to say that SNMP is all bad. It’s great for what it is – it’s just not the silver bullet to gather information from a variety of vendor devices and platforms. In spite of lousy documentation and a simple network management protocol that leaves me wanting, I still need to get the job done, and I need to get it done now. I’ve crawled networks manually logging into devices one at a time, and it’s miserable. And though it’s mind-numbing to crawl a network that way, I got the information I needed.

This is where the beauty of NetBrain’s dynamic mapping really shines. NetBrain discovers a network programmatically, which means it gets the information I need without me having to write custom MIBs, without relying on lousy documentation, and without having to log into devices myself one at a time.

Network-Discovery-

 

The difference is that NetBrain primarily discovers a network through Telnet and SSH. SNMP is used only initially to determine a device’s make and model so that the appropriate syntax can be sent to the device. From there, the software can gather any information available via CLI commands, including routing tables, link utilization, interface statistics, and anything else an engineer might want to look at.

In the context of network capacity planning, this means CDP and LLDP can be used to discover neighbors. This is how NetBrain can build a network Benchmark including a topology, port densities, link utilization, top talkers, and any other criteria an engineer would need to get a quality snapshot of today’s network and plan for tomorrow.

We’re solving two problems here. Lousy documentation and the weaknesses of SNMP are both overcome by programmatic network discovery. How do you know what’s going on in your network? I mean, how do you really know? If you don’t prefer flying blind when planning for network capacity, you need to know the current state of your network so you can determine what tomorrow’s network should look like.