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. We use BGP for this purpose—an industry-standard dynamic routing protocol, famous for its flexibility and rich feature set.

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

The following guidelines apply:

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

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

• Every Spoke establishes an IBGP session towards each of the Hubs and advertises its LAN prefixes.

• The Hubs can (optionally) act as BGP Route Reflectors (RR), to advertise the routes between the Spokes. They can also summarize the routes. Alternatively, the Spokes can simply use default routes towards their Hubs, via all available overlays. We return to these options later.

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

• While IBGP is used to propagate routing information within each region, EBGP sessions are established between the Hubs to propagate routing information between the regions.

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

The routing design is discussed in much more detail in a dedicated section. At this point, we shall conclude that, 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.