Mapping Application Dependencies with A/B Path Calculator

Sep 27, 2018

It’s every engineer’s nightmare to end up in a position where they need to defend their network during an outage without the proper documentation. I ended up in that situation about six months into my first IT management position, when our PO tracker went down, and everyone had already convicted the network before I understood what the problem was. Even worse, most of the documentation I had was out of date, and I ended up going back through the network, one device hop at a time, to figure out exactly what went wrong and where. Eventually, I found out that I had never moved a backup application server onto the appropriate network segment, and even though it had failed over correctly, it wasn’t allowed through to the rest of the network thanks to an implicit deny policy on our firewall.

The truth is, I learned a lot about the importance of network documentation that day, but the “hard way” that people tend to deify through rose-tinted glasses often translates into a critical loss of business productivity. All I wanted throughout that outage was something that could make my life a little easier.

These days, I’m fortunate enough to be involved with the product I wish I’d had all those years ago. With it, I could have mapped out every single network dependency in a fraction of the time that it took me.

I’d like to talk about one of the keystone features of NetBrain – the NetBrain A/B Path Calculator – and how it can help you solve your problems.

“What is the critical path?”

The sole purpose of a network is to pass traffic between two or more points. Any conversation involving a networking issue needs to begin with the question “What is the critical path?” or in other words, “Where does my traffic need to travel to be useful?”

A/B Path is essentially a very enhanced traceroute. It calculates the desired network path by analyzing access lists, NAT, policy routes, and other networking elements not included in the standard command line tools. A/B Path is effective at mapping specific protocols and applications across a network, finding asymmetrical paths, and collecting both L2 and L3 data

As the network grows more and more complex, it’s not enough to just use manual diagrams and simple tools such as traceroute when attempting to navigate and map the critical path of applications or find the root cause of an issue. Having a powerful yet accessible instrument like A/B Path at your disposal reduces the amount of legwork required to get to the heart of what’s breaking your network right now.

A/B path calculations help you look at the traffic with more granularity and precision than most standard tools available to you – unlike traceroute, it can detect and record L2 hops over the network, and it can find asymmetrical paths that may be implemented in the network for security or performance purposes.

“Most of the time spent during troubleshooting is identifying where the problem actually is.”

Even when there isn’t a dire and immediate issue to resolve, A/B Path enables you to quickly map out different application flows within your own network and help you proactively understand where to go in the event something inevitably fails.

Rewind the clock about four years and put this tool in my hands during that outage – I would have resolved it within minutes.

In addition to the enhanced traceroute capabilities, A/B path mapping can provide specific error messages to the user in the event it encounters problems along the designated path. In addition, with the combination of other analytic tools within NetBrain, it can present specific QoS monitors to gauge causes of specific performance issues.

A/B Path behaves like a network engineer, logging into devices hop-by-hop in order to mimic the actual path of a packet along a network. It will consider policies, ACLs, routing tables, and indicate to the user when these attributes prevent a packet from crossing a network threshold.

A/B Path Calculator clearly indicates to the user what path their traffic is taking, and whether or not the problem actually exists within the network – for example, if the simulated traffic can clearly cross over its critical path, then it’s clear the network operators are not facing a routing and switching issue (as the path logic is shown clearly in the execution log.) When a similar problem occurs in the future, I’ll understand the signs to look for when attempting to diagnose. This tool is also a teacher, and any engineer would count themselves lucky to have it in their arsenal.