NetBrain’s Network Data Model and the Foundation for Automation
IT’s Big Data When IT problems strike, the key to prompt resolution is hiding in the data – data produced when the fault occurs, historical data, and live data obtained…
August 8, 2018
Data should drive a network diagram, not beautiful artwork. I’ve spent countless hours arranging lines just right, and I’ve spent many bleary-eyed evenings searching online for just the right Visio icon. Network diagrams don’t have to be works of art – they have to be useful.
The first thing I look for when kicking off a project with a customer is a current network map. I’ve seen some that look like building schematics crammed with so much information they’re almost unusable. I’ve also seen some that are clearly meant for someone outside of technology because of how pretty they are, though lacking in information.
Network diagrams don’t have to be works of art – they have to be useful.
Cramming as much information as possible onto a diagram comes at the expense of clarity, and making diagrams overly simple comes at the expense of usefulness. In my experience, network engineers prefer to create diagrams that focus on one or two areas at a time rather than create one overwhelming masterpiece.
1. WAN Topology
First, a common way to diagram a network is by the WAN topology. This sort of diagram might be relatively simple and include only mission-critical hardware such as core switches and WAN routers. It tends to focus more on site-interconnectivity rather than the many layers of abstraction a modern network may have.
Though this kind of diagram may not have every single network device, IP address, and switchport on it, it’s still a very useful tool for a quick-glance understanding of an overall topology. Often this is the only type of diagram an organization has, and that may be sufficient in many cases.
Especially in a multi-site organization using route redistribution, having a map that accurately displays the routing topology is much faster than logging into devices one at a time. Organizing a network in this way is important to understanding traffic flows and how information propagates throughout a WAN.
Take a look at the WAN map below. It’s a simple overview of WAN routers running OSPF for inter-site connectivity. On this map we focus on WAN routers, OSPF areas, route redistribution, and so on.
ABR and ASBR devices are highlighted by color; interfaces are color-coded by area number; OSPF configurations are annotated as device notes; and OSPF table data is embedded for each device.
Note that with a Dynamic Map, nothing is static, and nothing is beyond your reach. In this case, when we zoom in on the map we can select a link or a specific router, examine configuration of a specific device, and layer our map any way we like. This is all real-time information available at an engineer’s fingertips without having to search through various device command lines.
1. Clicking on a device icon reveals more information — L3 topology, OSPF neighbors, and more.
2. Clicking on a link discloses specifics such as redistribution parameters and OSPF neighbor information.
This is possible because instead of manually creating static maps by hand, a Dynamic Map constantly checks in with devices to present the engineer with the most accurate and functional network map possible.
2. Physical Topology
A second way to map a network is by physical topology. In this case, it isn’t the routing processes an engineer is necessarily concerned with, but the physical layout of devices, cables, and interfaces. Though less glamorous than a WAN diagram, a map of a network’s physical topology is priceless when working in the trenches of network closets and data center racks. Seldom are these well-labeled parts of the network, and even rarer is having an accurate diagram of this mission-critical aspect of the infrastructure.
Tracing a layer 2 path through a network means knowing what interfaces switches use to connect to each other and what switch is the spanning tree root bridge for a particular VLAN. Especially in a data center where there is an incredible amount of east-west traffic, layer 2 connectivity and actual physical device rack locations is extremely important to keeping all the blinking lights on.
In the screen shot below, notice how we can see an entire FabricPath topology including interfaces and port-channels.
FabricPath configuration is annotated as a device note, and FabricPath route table is displayed as a device label — both accessible with a single click.
This is extremely important information when working in data center networking, and a Dynamic Map that provides this data accurately is absolutely critical when making changes such as adding devices, moving virtual machine hosts, or migrating applications.
When we zoom in to the VTP map below we can see individual switches, critical hosts, interface names, and trunks. Because this map is dynamic, like with the OSPF map above, we can drill down into specific devices with one click and gather physical layer and layer 2 information very quickly.
Drill down into the Dynamic Map to get virtually all VTP physical layer and layer 2 information instantaneously.
3. Live Network Map
Third, a useful map for regulated industries is a live map of traffic flow and link utilization. I’ve dealt with this in the pharmaceutical and financial industries in which regulatory bodies required we keep updated flow diagrams for audits. In fact, we were required to keep normal state and failed state diagrams for all our data centers and WAN paths.
This type of map is difficult to create manually because it means logging into a variety of devices to check routing information in order to understand real-time traffic flows and link utilization. However, a dynamically created map of live traffic flow that updates itself periodically can make this requirement much easier to meet.
Dynamic Maps showing how traffic flows at any given moment is invaluable in demonstrating network compliance.
These are typical questions I have to answer when auditors stop by, and Dynamic Maps that can speak to network devices as well as third-party tools to gather this information programmatically can save tremendous time and ensure accuracy. Creating this kind of map from scratch and by hand means it’s error-prone and static. It likely doesn’t reflect the live network closely enough to be reliable.
4. Campus Map
A fourth type of network map is the campus map containing all the VLANs and relevant layer 3 information such as the location of gateways and NAT devices. This is probably one of the most common network maps I deal with, and for campus networks, it makes sense. However, I rarely trust them when I’m given one at the beginning of a project.
Campus maps are created by network administrators, often part of a very small team, managing a variety of environments. A network map, then, reflects the task they were working on at the time they created it — which means they aren’t truly data-driven and reliable. It assumes a network admin logged into dozens if not hundreds of devices one at a time and accurately captured all the information.
When I’m swapping out a LAN core, I want to know about every VLAN in the organization including VTP information, the spanning tree root bridge, and simple layer 3 information such as gateway IPs and subnet masks. I want to know where all the VLANs are in the campus and where their gateways live. Getting my bearings in a new network is difficult, though.
A useful campus map includes up-to-date data that enables you to decode and visualize the network for the job at hand.
An accurate campus map gives engineers the ability to get their network bearings quickly without having to log into many devices. Doing it manually means the map is likely incorrect or out of date. A campus map that’s dynamically created provides exactly what most network administrators and VAR engineers like me crave when we start a new project: something thorough, something current, and something trustworthy.
5. Open Tickets
Finally, a fifth type of network map displays open tickets related to network devices. This map doesn’t highlight traffic patterns or routing domains, and it doesn’t showcase rack elevations in a data center; however, it does allow an engineer, working in a network operations center, to immediately see if there is an issue with a device without having to wait for helpdesk tickets to start pouring in.
In the image below we can see how an incident can be displayed on a Dynamic Map. Instead of helpdesk tickets from end users, this sort of map allows engineers to click on a router and immediately drill into the problem without guesswork and without wasting time. After I left the helpdesk, I spent some time as a NOC engineer which required I knew what was going on with devices so that I could resolve issues as quickly as possible.
A diagram that maps the network by open incident tickets enables NOC engineers to immediately see what’s going on with problem devices.
Today, as a VAR engineer, I work on networks I’ve never seen before and for which I have no documentation. The biggest hurdle for me is rarely the technology I’m configuring — it’s usually getting my bearings on the network. That can take days, and often I find myself confused by old diagrams that don’t have sufficient information or are just plain wrong.
I don’t need any beautiful artwork, and I’m not impressed with really cool Visio icons. I need a network map that is useful, and that means a map that’s dynamic and data-driven.