Go back

Finding the Right Network Mapping Tool for Better Path Calculation

December 4, 2021

The NetBrain PDA System’s network mapping tool behaves much like a network engineer does when he or she diagnoses any network problem; identifying the topology and associated hops, and then accessing each device hop-by-hop to follow the actually expected path of a packet along with a network. NetBrain’s A/B Calculator will consider policies, ACLs, routing tables, and indicate to the user when these attributes prevent a packet from crossing a network threshold. And putting all of this investigation together confirms whether the information will flow properly. In other words, it tests the network’s ability to support business information flow, usually from consumer to service or vice versa.

In this article, I’m going to go over the elemental logic of the NetBrain PDAS A/B path calculator and illustrate how it stands far and away out from any other approach currently available on the market, and in specific how it is lightyears ahead of trying the same investigation using; CLI, Traceroute, and Ping.

Mapping Application Network Dependencies

Part of the PDA System, A/B path calculation increases in necessity as the size of the network grows. In complex hybrid and software-defined networks, it becomes nearly impossible to accomplish the same investigation manually.  The result is applications are ‘assumed’ to be up and running and performing at required levels unless users report problems. Simply put, most NetOps teams don’t have the ability to map application dependencies… so they don’t.

In the context of NetBrain PDAS, an application dependency refers to an external device on the network that the application relies on to function properly. Using A/B path, a user can clearly trace the dependencies of applications and workflows across their environment.

New Map App Dependencies pic


The Device Log

The device log is a display panel within the A/B calculation capability that demonstrates to the user what logical steps NetBrain PDAS is taking to determine the path of the desired flow, and is dependent on the type of traffic it is being asked to investigate. Once it determines the logic each device is using to forward this specific type of traffic, it will find the next hop in the path.

Regular Network Device AB Path Device Log

Regular Network Device AB Path Device Log Part 2

Here, we can see in close detail how NetBrain PDAS is automatically parsing the CLI configs of each device it manages to give the user a more complete understanding of their own network and how traffic flows within it.

What may be surprising is that this investigative logic must change based on the specific device that’s being analyzed at each step which is not a small undertaking, but trivial when NetBrain’s device-aware dynamic data model is in use.

Software-Defined ACI Path & VRFs

In this example, the NetBrain A/B Path calculator is investigating traffic flow on a network running a Cisco ACI data center SDN deployment. Here, you can see the packet encountering VRFs within each of the leaf devices and posting specific notes on the map to point out specific interfaces, VLANs, Virtual IP translations, and ACLs permitting traffic throughout the network.ACI Path

Here, in this calculation, we can see the device logic changes when dealing with ACI (SDN) devices. It prioritizes virtualized network functions in order to understand traffic logic, but it still indicates when traffic was permitted through an ACL. In addition, NetBrain A/B path also indicates where a Virtual IP translation occurred along the next hop.

Cisco ACI AB Path device log

Access Control Lists

In this example, NetBrain’s A/B Path calculator is encountering an issue with a device’s ACL. NetBrain shows you which device had the deny the event, and places a note specifying which ACL caused the packet to be denied. Earlier in the investigation, you can see it also identifies to the user which ACL allowed the packet through on a different device.

ACL Deny Port 80

Device Mode

NetBrain A/B Path supports Layer 2, Layer 3, and Layer 3 Active mode. The difference between the latter 2 types is that Layer 3 Active requires the use of live data but takes into account more port types. As stated earlier, the usual gauntlet of tools available to troubleshoot network outages are limited to Layer 3 analysis and would be hard-pressed to detect Layer 2 or Layer 4 movement.

Path Settings

In addition, the NetBrain A/B path can track the progress of specific applications and port numbers across the network. NetBrain A/B Path supports more than 150 of the most common and application supporting layer-4 protocols. Using these, the NetBrain A/B path can track the critical path of nearly any specific application or service on the network!

IP Settings

Historical Data Comparison

Users can also check changes that have occurred between several iterations of the network. The way that the network looked today isn’t necessarily the way it looked a week or a month ago. For comparative purposes, you can also see how things looked in the past which will draw attention to areas that have changed from know working conditions. By selecting benchmarked data, NetBrain’s A/B path calculator will provide the delta results at-a-glance!

5. Map Historical Paths

In this example, a user was trying to find out why the WEB-SERVER-1 device suddenly isn’t able to communicate with the Bos-Core-Demo device through a specific interface. The user discovers through a live analysis and comparison to previous conditions that the devices now have an asymmetric routing path thanks to a VPN!

As you can see, the NetBrain PDA System’s A/B path function is incredibly versatile, and its functionality extends far beyond the examples listed out here. A/B path can also be used to detect the presence of NAT translation, Virtual IPs, L2/L3 environments, which VPNs traffic is flowing through, or even whether there is cloud infrastructure involved in the network path. NetBrain A/B Path will parse through CLI config files and enumerate the device’s attributes in a way that’s clear and accessible and acts as a powerful instrument to quickly eliminate service degradations and outages, resulting in dramatically lower remediation times (MTTR).