Routing overview
In a conventional (non-SD-WAN) design, routing oversees the steering of traffic. It is, therefore, the responsibility of routing to select the best path out of all available options. While different routing techniques to steer traffic are compatible with Fortinet’s SD-WAN implementation, it is recommended to use the SD-WAN intelligence to select the best path to steer traffic. This is the purpose of SD-WAN, as it accounts for various types of link and application qualities, like the health of each path and the type of applications, before steering traffic towards an SD-WAN member.
In the case of direct internet access on a single site, it is recommended to implement ECMP (Equal cost multi-path) routes over all available paths, and allow SD-WAN rules to then specify the traffic steering. For more information about ECMP, see Equal cost multi-path.
In multi-site Hub and Spoke SD-WAN deployments, routes over your SD-WAN overlay network can be learned several ways. Static routing is supported; however, most routing implementations will leverage dynamic routing to ensure their network scales and can respond to changes in the environment. BGP is recommended to exchange routes between all sites over the overlays. When utilizing BGP for dynamic routing, several options for BGP peering are available.
BGP per overlay
This is the traditional way of sharing routes between all SD-WAN nodes. BGP per overlay builds an iBGP session using each end of the tunnel as a peer. This reduces the complexity of the deployment but results in a large number of iBGP sessions and routing table updates on the hub device(s). This method of routing is still supported, however it is not recommended.
BGP on loopback
In the BGP on loopback design, every Spoke establishes a single iBGP session towards the hub(s). This single iBGP session is terminated on the loopback interface, which uniquely identifies each SD-WAN node (Hub and Spokes). The Spoke advertises its LAN prefix(es) over this single iBGP session per Hub. This method of routing reduces the load on the Hub(s) and is required for ADVPN 2.0.
Dynamic BGP versus route reflection
Starting from FOS 7.4, a new method to exchange routes directly between a pair of Spokes by dynamically building a BGP session between them over an ADVPN shortcut was added. This new mechanism is called “Dynamic BGP”. While the Hubs learn all the Spoke routes, they no longer have to re-advertise them to other Spokes, meaning BGP Route Reflection (RR) on the Hubs is no longer required.
|
Routing method |
BGP per overlay |
BGP on loopback |
|---|---|---|
|
BGP add-path |
Required |
No |
|
Route exchange method |
Route Reflector or Dynamic BGP |
Route Reflector or Dynamic BGP |
|
Main advantage |
Simplicity |
Reduced routing table ADVPN 2.0 support |
|
Main limitations |
Limited scalability Does not work with ADVPN 2.0 |
None |