The more I learn about BGP, the more I can appreciate why it’s considered an application instead of a routing protocol. BGP might have been invented to distribute routes in a large, constantly changing topology but it has since been extended to do so much more. I won’t pretend to know all the different implementations of Multi-protocol BGP but there are a few that I have studied while learning VXLAN and MPLS.
Technically, all these different implementations of BGP are all just considered MP-BGP or MBGP. The Address Family Identifier (AFI) and the Sub-address Family Identifier (SAFI) uniquely identifies the implementation of MP-BGP. IPv4 has an AFI of 1 and IPv6 has an AFI of 2. The SAFI varies and identifies whether BGP is distributing VPNv4/v6, EVPN, Labeled Unicast (LU), Link State (LS) or Multicast (MVPN) information.
I would imagine that there is some text out there that consolidates the details for all of these sub families together. It’s far more natural to learn about these SAFIs separately, while researching some kind of networking problem (usually in a service provider network because those engineers deal with a lot of interesting use cases.)
BGP L2VPN EVPN, for example, was designed to replicate MAC learning in a switch. There are five route types that EVPN advertises and each has its own function. Type 2 is the NLRI that holds MAC address information and allows MAC address learning in the control plane. Depending on whether EVPN is being used in a VXLAN or MPLS environment, certain parts of this NRLI will change but the main part of it looks like this: ::::[002f.11a1.2e33]::[0.0.0.0]/216. It looks complicated but once you break it down, its not so bad. The first number indicates what type of route is being advertised while the next two provide information that’s usually not relevant. The next part, :[002f.11a1.2e33], is the length of the MAC address (48), followed by the MAC address that’s being advertised. This is the main information. The next part, :[0.0.0.0], is meant to hold the length and IP address associated with the MAC address. This IP information is actually populated in a second type 2 route and is also advertised into the control plane. The 216 is the bit length of all of this information.
When remote routers receive this advertisement, they place the MAC into a MAC table, just like a switch would, and instead of associating the MAC with an interface the routers associate it with a next-hop IP. Of course, the router advertising the MAC address would have placed its IP inside the NLRI. EVPN doesn’t just advertise the MAC information, it also advertises the IP address associated with the MAC. As mentioned above, this is also a type 2 route but with the IP fields populated. It might look something like this: ::::[002f.11a1.2e33]::[10.1.1.10]/272. The remote routers would place this IP information in their ARP cache and use this information to build a complete VXLAN packet with the correct inner and outer headers.
BGP allows routers to withdraw advertised routes and in EVPN, this allows MAC entries to be removed from the MAC table just as they would be on a switch after a period of inactivity. There are four other route types advertised in EVPN but route type 2 provides the bulk of the MAC learning functionality.
Just as EVPN was designed to mimic MAC learning, BGP MVPN was designed to mimic PIM messaging. Multicast functionality in an IP/MPLS network was originally proposed through an RFC draft dubbed draft Rosen. It advocated a mesh of GRE tunnels and actually used PIM within the provider network. Like any solution requiring a lot of GRE tunnels, it faced a scalability problem. Running PIM as an extra protocol through the MPLS core also went against the spirit of label switching which was to provide transport without caring about the type of frame being transferred.
Enter BGP MVPN. Because the provider network was already running BGP at the edge, implementing another address family was as easy as configuring a few lines under the routing process. Alright, maybe more than a few lines given IOS-XR’s sometimes verbose syntax but MVPN is a significantly better solution than draft Rosen.
There are seven route types for MVPN. Some of them have an analogous PIM counterpart and some don’t. All the multicast sources and receivers are customer devices that reside behind the customer edge routers (CEs.) The provider edge routers (PEs) become PIM neighbors with their respective CEs and then advertise their information into the control plane using route type 1s. These act similarly to PIM hellos but are only sent once instead of periodically. Type 6 routes are advertised when a receiver wants to build a shortest path tree (SPT) to a multicast source and functions the same way a PIM (S,G) join message does. Type 7 routes are analogous to PIM (*,G) join messages and finally type 5 routes serve the same function as PIM register messages indicating that a multicast source is behind a certain router.
The result of the different route types is a multicast network over MPLS that functions like any other multicast network over regular IP. Examining the NRLIs with show commands shows that a lot of other information is provided (RD, extended communities, etc.) but the big picture is that BGP provides the desired functionality. I recently listened to a podcast where BGP-LS or Linked State BGP was mentioned. As its name implies, it takes information from link state IGPs like OSPF and IS-IS and distributes that throughout the control plane, allowing BGP-LS peers to have a complete LSDB across multiple domains!
What can’t BGP do?