BGP on loopback

Starting from FOS 7.0.4, we support a new routing design called "BGP on Loopback". It simplifies the configuration significantly and greatly reduces the number of routes advertised throughout the network.

• Every Spoke establishes a single IBGP session towards each of the Hubs.

• This IBGP session is terminated on the loopback interface, which uniquely identifies each SD-WAN node (Hub and Spoke).

• The Spoke advertises its LAN prefix(es) over this single IBGP session per Hub.

The following diagram depicts the same Single-Hub SD-WAN/ADVPN region as in the previous section and illustrates a LAN prefix 10.0.2.0/24, which is advertised by "site1-2" and is propagated to "site1-1":

As can be seen, for each LAN prefix, a single BGP route is generated, with a copy sent to each of the Hubs:

• BGP next-hop (NH) is the loopback IP of the originating Spoke.

• The Hubs still act as BGP RRs, but they need to reflect a smaller number of routes. Furthermore, BGP ADD-PATH is no longer required, because there is just a single BGP NH for each prefix in the network.

• Besides reflecting the routes, the Hubs also advertise a loopback summary to the Spokes. It summarizes all the loopback addresses in the overlay network (10.200.0.0/14 in our example). BGP NH of this summary route is the loopback of the Hub itself.

• On the receiving Spokes, the BGP NH of the LAN prefix is recursively resolved through the loopback summary, which in turn is resolved through a static /32 route towards the Hub loopback, and injected by an extension to the IKE protocol (exchange-ip-addrv4 feature). See the Example of route resolution with BGP on loopback.

The following diagram shows the same region with an active ADVPN shortcut between "site1-1" and "site1-2":

As can be seen when ADVPN shortcut is established, it injects a /32 route towards the loopback IP of the remote Spoke. This allows to recursively resolve the earlier learned BGP route through the shortcut. At the same time, an extension to the BGP resolution algorithm (called "Tag-based Recursive Resolution" and covered in BGP extension: tag-based recursive resolution) ensures that alternative paths (through the other available overlays) are still included in the resolution results. (See the Example of route resolution with BGP on loopback.)

Before seeing an example of route resolution, we must elaborate on the two proprietary extensions that have been implemented to support this design:

• IKE extension: exchange-ip-addrv4

• BGP extension: tag-based recursive resolution