Fortinet white logo
Fortinet white logo

SD-WAN / SD-Branch Architecture for MSSPs

Routing design

Routing design

The ADVPN 2.0 mechanisms are independent from the routing design. However, the routing design must properly perform its direct duties, in order to guarantee correct traffic steering with and without the shortcuts.

Let us summarize these duties:

  • Reachability for user traffic. All the LAN prefixes must be reachable across the entire SD-WAN overlay network. This is the basic requirement for any routing design.

  • Shortcut steering. These are the basic requirements for the ADVPN support (unchanged compared to the earlier version of ADVPN):

    • When no shortcuts exist towards a given remote Spoke, all its LAN prefixes should be resolved through the Hubs, to guarantee initial reachability once the user traffic starts flowing.

    • Whenever a shortcut is built, all the LAN prefixes belonging to the remote Spoke in question must be automatically resolved through the new shortcut, so that the traffic can be steered through it.

    • When multiple, active shortcuts exist towards the same remote Spoke, its LAN prefixes must be resolved through all of them, to allow the SD-WAN intelligence to select an optimal path at any given moment.

    • When all the shortcuts towards a given remote Spoke are torn down, the routing must automatically revert to the initial state—that is, its LAN prefixes must be resolved via the Hubs.

  • Loopback reachability. All the SD-WAN node loopbacks must be reachable across the entire SD-WAN overlay network. This is the only requirement specific to ADVPN 2.0. It guarantees that the SD-WAN nodes (mainly the Spokes) can communicate with each other, for example, when triggering additional shortcuts between them.

In the next section we demonstrate how our recommended routing design performs all these duties.

Routing design

Routing design

The ADVPN 2.0 mechanisms are independent from the routing design. However, the routing design must properly perform its direct duties, in order to guarantee correct traffic steering with and without the shortcuts.

Let us summarize these duties:

  • Reachability for user traffic. All the LAN prefixes must be reachable across the entire SD-WAN overlay network. This is the basic requirement for any routing design.

  • Shortcut steering. These are the basic requirements for the ADVPN support (unchanged compared to the earlier version of ADVPN):

    • When no shortcuts exist towards a given remote Spoke, all its LAN prefixes should be resolved through the Hubs, to guarantee initial reachability once the user traffic starts flowing.

    • Whenever a shortcut is built, all the LAN prefixes belonging to the remote Spoke in question must be automatically resolved through the new shortcut, so that the traffic can be steered through it.

    • When multiple, active shortcuts exist towards the same remote Spoke, its LAN prefixes must be resolved through all of them, to allow the SD-WAN intelligence to select an optimal path at any given moment.

    • When all the shortcuts towards a given remote Spoke are torn down, the routing must automatically revert to the initial state—that is, its LAN prefixes must be resolved via the Hubs.

  • Loopback reachability. All the SD-WAN node loopbacks must be reachable across the entire SD-WAN overlay network. This is the only requirement specific to ADVPN 2.0. It guarantees that the SD-WAN nodes (mainly the Spokes) can communicate with each other, for example, when triggering additional shortcuts between them.

In the next section we demonstrate how our recommended routing design performs all these duties.