Monday, December 21, 2020

Advantages for BGP in Virtualized Topologies

BGP Advantages in Virtualized Networking

BGP is more like an Application

BGP, by design, is a lot more capable than most typical routing protocols. Here are a few ways MP-BGP/BGPv4 is fundamentally unique:

I'll keep this short to avoid beating a dead horse too much.

The following advantages are specific to NSX-T/V or virtualized routers:

  • Link-state adjacencies don't change if a virtual system is down. If a hypervisor hosting a VM stays up and a VM is down, link-state doesn't change, so you're going to wait for the entire dead interval as an outage.
  • I'll repeat this again, with virtualized network functions Link-state adjacencies failover at their maximum dead interval, nullifying the primary advantage to these routing protocols!
  • Interlinks from a physical network must be specifically engineered to prevent non-determinism. If you're multi-homing a virtual router via the same Layer 2 domain, LSAs will not only flow between the physical network endpoints and your desired Virtual Network Function (VNF) but *between physical network devices.
    • This can be designed around, but you lose the ability to scale multi-pathed machines easily and automatically.
    • You can get the dynamic adjacency capability with the BGP Neighbor Range feature on nearly all datacenter network equipment today.

TL;DR, So What if you don't run BGP currently?

This is where most people get hung up - if a network doesn't currently use BGP, it'll potentially introduce problems by adding a new thing for engineers to maintain, major forklifts to pick up hardware support, and so on.

These are all very valid concerns. I'd recommend that instead of shutting down the argument, try some of these solutions on for size instead:

We Inflate eBGP's complexity because we've been conditioned to

Most of the complicated stuff is iBGP loop prevention or pro-grade tuning. Cisco education mechanisms have failed the community somewhat here and with IS-IS (you can only test on SO MUCH in the CCNA/CCNP!). These advanced capabilities are rarely necessary for most typical enterprise deployments. The typical enterprise BGP deployment responsibilities will consist of:

This can be either really difficult and complex or really simple depending on needs. If it's not an enterprise-wide deployment of BGP (usually it won't be) just plan it out on paper before implementing - there will be learning experiences, accept that they'll happen, and maximize end results. You can't get this education without getting your hands dirty, so make sure it won't hurt the business / use a lab if you can

If you can't, contain the deployment: Set up a prefix for whatever workload is being used, and redistribute that instead of BGP until you've hit maturity. In many cases, it'll just stay there, and that's OK.

BGP to Security Appliances

This is probably where I'd start - it's got the highest value to effort ratio. Given your vendor choices, it's probably not that complicated and doesn't necessarily need to be redistributed to campus or other internet edge modules. For most enterprise deployments, this is totally cool. If you're me, you'll start getting annoyed by NLRIs not propagating across sites, which brings you to...

Run BGP on top of an IGP

This is actually how most Service Provider networks work! BGP isn't designed to synchronize - it doesn't modify any next-hop addresses for advertised prefixes and needs another routing protocol to do that. There are some applications where you can go all-BGP but they're usually reserved for hyper-scaler applications or shops that already are very familiar with BGP. Physical network routes can continue to propagate in this scenario just like they always did, and you're using BGP for the virtual ones. The only redistribution required would be a zeroes/default route from your point of origin to keep things nice and intuitive.


This is pretty complicated unless you contain the use cases. In the two scenarios above, you're mostly off the hook on this one - at most, you'll be installing a default route.

Workloads that benefit from BGP competency in the enterprise

  • VMware NSX-T
  • VMware Cloud on AWS
  • Avi Networks Load Balancer
  • Amazon AWS
  • Project Calico (Kubernetes!)
  • Vyatta Vyos
  • F5 LTM
  • Microsoft Azure
  • All SD-WAN
  • All firewalls

Needless to say, if you're a shop that consumes more than vCenter and ESXi, you probably should be dipping your toes in the water. How far is up to you, but it cannot be avoided.

Some things to remember

  • If it's providing value, you're doing well.
  • If you don't know something, that's OK. We're in an ever-changing industry.

No comments:

Post a Comment

PAN-OS IPv6 Error: bgp peer local address 0:0:0:0:0:0:0:0 does not belong to interface

  When encountering this error, please ensure that "Enable IPv6" is set under interfaces: Hope this helps! Happy IPv6ing!