Manually configuring the specific attributes of BGP peers on dozens of routers doesn’t make sense anymore. It makes less sense to do it on a large scale. Why invest time in automatable tasks if operational expenses comprise much of your enterprise network budget?
The Border Gateway Protocol, or BGP, is highly tunable, with many available settings and configuration options. Unlike other routing protocols, it uses a path vector rather than a distance vector or link state. BGP makes path selection decisions based on more factors than an IGP, like OSPF or EIGRP.
Because of its tunability, BGP has been making its way from the WAN into the data center for segmentation, from segmenting racks of servers to dividing individual servers into separate Layer-3 domains. It’s immensely useful, considering that one robust ESXi host can run dozens of servers simultaneously. BGP is ubiquitous in the WAN and is becoming a standard in the data center as well.
NetBrain automates what we did manually for years. The old way doesn’t make sense anymore, and really, it never did.
Engineers may use BGP in the data center to route to individual hypervisors or the WAN to route to networks worldwide. Either way, BGP configuration can quickly become complex.
A common network design uses multi-protocol BGP over an MPLS core using multiple VRFs and one or more IGPs with route redistribution. In extensive networks, this can turn into hundreds of lines of code per router to:
Imagine copying this kind of configuration onto multiple routers and having to remember:
Automation makes this process more efficient without the risk associated with a bleary-eyed engineer staring at a few dozen PuTTY windows.
We encounter the same problem when building a full mesh iBGP network at scale. Every single BGP speaker in the full mesh needs the entire configuration. Add the complexity of routing protocols needed for reachability, which becomes an adventure in copying and pasting.
In extensive networks, an IT department team may have a couple of sharp engineers using on-box EEM scripts or off-box Python scripts. Historically, most network devices haven’t supported much in terms of on-box or off-box programmability options. As a result, network automation never took off.
This is finally changing, though. Network operators have long wanted to simplify the configuration of many devices with complex configurations. Now, vendors are finally responding. Though this is excellent news, there are some significant hurdles to face.
This is why I love what NetBrain is doing. They don’t build their own switches or network operating systems. Their overlay manages everything without manual border gateway protocol configuration. Therefore, they aren’t beholden to any particular vendor’s operating system or specific automation mechanism. NetBrain’s platform can programmatically interact with devices from dozens of networking vendors and hundreds of platforms. As network vendors continue to adopt the network automation paradigm, NetBrain’s automation platform will only become more robust.
The screenshot below shows a built-in automated BGP workflow called a Runbook. With one Runbook, I can simultaneously check various real-time BGP information across many devices.
Usually, this requires logging into each device and studying the output of each show command one by one. The built-in Runbook gives me that same visibility into the network, but programmatically. Consider that this is a basic Runbook. You can also create custom and elaborate workflows.
With Runbooks, you easily check a variety of real-time BGP information across many devices at once — instead of logging into each device and studying the output of each show command one by one.
Even with all these outputs at our disposal, a multi-layered BGP design can be difficult to visualize. Multi-layer Visio diagrams don’t help much, either, because cramming so much information into a usable diagram is difficult.
NetBrain’s BGP configuration automation visualizes abstraction using Dynamic Maps, a core technology. Dynamic Maps aren’t a fancy Visio, though. They’re dynamic, representing the state of the network in real time. Every node is interactive, which means all the information is available on one screen. Typically, we would cram this information into tab after tab of an outdated Visio diagram.
Dynamic Maps enable engineers to:
Notice below that iBGP neighbors are denoted automatically by a dotted line after an automated network discovery. NetBrain built this dynamic map for you, and each item, including links and devices, can be analyzed further.
In this screenshot from NetBrain’s Trial environment, BGP neighbors are denoted automatically by a dotted line after an automated network discovery.
If you need to focus on just a single router such as BGP-R1, it’s just a matter of selecting the device and choosing BGP configuration from the menu to get an automatic output.
To focus on a single router, such as BGP-R1, select the device and choose BGP configuration from the menu to get an automatic output.
Troubleshooting BGP neighbor relationships usually starts with checking configuration errors, such as a misconfigured eBGP multihop. The built-in BGP troubleshooting Runbook programmatically checks for several common configuration errors across all network devices with one click. Here, we can see that NetBrain discovered a misconfiguration on router BGP-R3.
Learn firsthand how automation can change enterprise network operations. Experiment with NetBrain’s core technologies using the Instant Trial. The BGP labs aren’t nearly as scary as the example I gave earlier. However, they showcase how powerful Dynamic Maps and Runbooks are in managing a BGP domain.
NetBrain automates what we did manually for years. The old way doesn’t make sense anymore, and really, it never did. Automation through Dynamic Maps and Runbooks reduces operational expenses. You can manage an enterprise WAN running BGP without losing any of the benefits of our most beloved routing protocol.