Routing

The overlays provide us with multiple paths between the sites (over different underlay transports). Still, we must also ensure that all edge devices have the correct routing information needed to use these paths. We recommend using BGP to exchange routes between all sites over the overlays.

BGP fits well into hub-and-spoke overlay topologies, and it is also the recommended routing protocol to use with ADVPN. As we will show in design examples, the hubs will act as BGP route reflectors (RR) so that the spokes will not have to peer directly with each other—not even over ADVPN shortcuts! This design is in-line with the zero touch strategy: once again, when adding or removing a spoke, the BGP configuration of all other devices remains untouched.

A crucial difference between a traditional design and our SD-WAN solution is in the role of the routing pillar. In a conventional design, routing oversees the steering of traffic. It is, therefore, the responsibility of routing to select the best path out of all available options. Multiple route policy techniques can be used to achieve this—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 full-featured FortiGate edge device, we must recall that our goal is only to learn about all available paths to all possible destinations!

Remember that the duty to steer the traffic in our solution is delegated to the fifth pillar—the SD-WAN. Therefore, it is (generally) not recommended to apply any route policy techniques to the routes learned via BGP. Rather than selecting a single best route, we would like to end up with equal-cost multi-path (ECMP) routes to all remote sites via all available overlays.