BGP routing

Once the overlay network is built, routing information must be exchanged between all the SD-WAN nodes (Hubs and Spokes), to ensure site-to-site reachability. All the routing design flavors described in the next sections use BGP for this purpose. BGP is an industry-standard dynamic routing protocol that is famous for its flexibility and rich feature set.

On a very high level, the routing information is exchanged as follows:

The following guidelines are shared by all the described routing designs:

• A single BGP Autonomous System number (AS) is assigned to each region.

• Every Spoke advertises its LAN prefixes to the Hubs using IBGP.

• Every Hub uses Dial-Up BGP configuration (neighbor-group feature).

• Every Hub then acts as a BGP Route Reflector (RR), readvertising the prefixes to all other Spokes within the region.

• EBGP peering is used between the Hubs to exchange routing information between the regions. These routes are then readvertised to the Spokes within the region. The exact prefixes that are exchanged depend on the chosen routing design and on whether or not ADVPN stretches across the regions.

• Additionally, the Hubs advertise their own LAN prefixes, as well as any destinations learned from outside of the SD-WAN network.

• All the learned BGP routes are recursively resolved through all available overlays, therefore providing complete reachability information to each SD-WAN node.

In other words, by the end of this process, every SD-WAN node learns about all available paths towards all corporate destinations. Then the SD-WAN rules can select an optimal overlay path for each application, at each given moment.

It is important to highlight the difference in the role of the routing in the SD-WAN network compared to a traditional network. In the traditional network, the routing is in charge of steering the traffic. It is, therefore, the responsibility of the routing to select the best path out of all available options. To achieve this, multiple route selection techniques can be used. Some are protocol-agnostic (for example, weight) and others are protocol-specific (for example, BGP local-preference, MED, AS_PATH prepending, and so on). While all these techniques remain available on a FortiGate device, we must recall that our goal is only to learn about all available paths towards all destinations!

Remember that the duty to steer the traffic in our solution is delegated to the SD-WAN rules! Therefore, it is (generally) not recommended to apply any route selection techniques to the routes learned through BGP within the overlay network. Rather than selecting a single best route, we would like to end up with Equal-Cost Multi-Path (ECMP) routes to all remote sites, through all available overlays.

As the picture above highlights, it is still perfectly valid to tag certain incoming routes, for example, by applying a route-tag. It can be then used as a matching criteria in your SD-WAN rules, proving useful in many scenarios. Note the difference: in this case all the routes remain in the routing table and visible to the SD-WAN!

In other words, what we (generally) don't want is to "hide" some of the BGP routes from the SD-WAN, because the SD-WAN uses wider range of inputs to select the best path per application at any given moment, and is therefore generally more intelligent than conventional BGP routing.

To avoid any confusion, it is still perfectly valid to apply any above-mentioned route selection techniques at the boundaries of the SD-WAN network, when learning or advertising routes from/to the outside world.