Fortinet black logo

SD-WAN Architecture for Enterprise

Home FortiGate / FortiOS 7.0.0 SD-WAN Architecture for Enterprise
7.0.0
7.2.0
7.0.0

Route Exchange

Route Exchange

The spokes establish separate IBGP sessions to each gateway over each overlay. Using the previous sections’ example for one-to-one overlay mapping, that means our branch device should have four separate BGP session via four available overlays to Datacenter 1 and Datacenter 2:

The BGP Neighbor Group feature is used on the gateway for this peering. Each spoke then advertises its local site prefix(es) over each of the IBGP sessions. The gateway acts as a BGP Route Reflector (RR), readvertising the prefixes to all other spokes when ADVPN is used. Additionally, each gateway advertises its prefixes (such as the datacenter LANs) to every branch location. At the end of this process, all the sites exchange their routes over all available overlays.

Additional Routing Notes

  • Routing inside in the datacenter is typically handled by each gateway via BGP or OSPF. Datacenter networks are readvertised to the Branches via BGP.
  • IBGP sessions are terminated on the IPsec overlays, and hence, they are using the tunnel IPs as BGP next-hops (NH). This requires IP addresses to be configured on the tunnel interfaces. Each gateway will have its own overlay network that can automatically allocate tunnel IPs to the spokes using the IKE Mode Config feature to simplify provisioning and administrative overhead.
  • Since the spokes establish separate IBGP sessions with the hub over each overlay, there are multiple BGP routes for each prefix. To keep all the routes available, the following two BGP features must be enabled on all participating devices (hub and spokes):
  • BGP Multipath ensures that all the available routes are installed into the routing tables
  • BGP ADD-PATH ensures that the hub between the spokes reflects all available routes

ADVPN

For the correct operation of ADVPN, it is required to preserve all sites’ prefixes unchanged, including their original BGP next-hop values. Hence, it is impossible to replace the specific routes with summaries (unlike in a static hub-and-spoke topology). Hence, the BGP RR function is mandatory: the gateway must reflect the original routes between the spokes without altering them.

FortiOS 6.4 and earlier:

We have already mentioned the critical property of overlay stickiness that we must guarantee for proper ADVPN shortcut creation. For example, if Branch1 sends traffic to Branch2 using an internet overlay via the hub, the hub must select the same internet overlay for the second half of the path. Failing to preserve the overlay might result in an attempt to create an ADVPN shortcut between two physically disconnected transports (such as the internet and MPLS), and this attempt would, of course, fail. The overlay stickiness is achieved using Policy Routes (PBR) on each of the gateways.

Previous
Next

Route Exchange

The spokes establish separate IBGP sessions to each gateway over each overlay. Using the previous sections’ example for one-to-one overlay mapping, that means our branch device should have four separate BGP session via four available overlays to Datacenter 1 and Datacenter 2:

The BGP Neighbor Group feature is used on the gateway for this peering. Each spoke then advertises its local site prefix(es) over each of the IBGP sessions. The gateway acts as a BGP Route Reflector (RR), readvertising the prefixes to all other spokes when ADVPN is used. Additionally, each gateway advertises its prefixes (such as the datacenter LANs) to every branch location. At the end of this process, all the sites exchange their routes over all available overlays.

Additional Routing Notes

  • Routing inside in the datacenter is typically handled by each gateway via BGP or OSPF. Datacenter networks are readvertised to the Branches via BGP.
  • IBGP sessions are terminated on the IPsec overlays, and hence, they are using the tunnel IPs as BGP next-hops (NH). This requires IP addresses to be configured on the tunnel interfaces. Each gateway will have its own overlay network that can automatically allocate tunnel IPs to the spokes using the IKE Mode Config feature to simplify provisioning and administrative overhead.
  • Since the spokes establish separate IBGP sessions with the hub over each overlay, there are multiple BGP routes for each prefix. To keep all the routes available, the following two BGP features must be enabled on all participating devices (hub and spokes):
  • BGP Multipath ensures that all the available routes are installed into the routing tables
  • BGP ADD-PATH ensures that the hub between the spokes reflects all available routes

ADVPN

For the correct operation of ADVPN, it is required to preserve all sites’ prefixes unchanged, including their original BGP next-hop values. Hence, it is impossible to replace the specific routes with summaries (unlike in a static hub-and-spoke topology). Hence, the BGP RR function is mandatory: the gateway must reflect the original routes between the spokes without altering them.

FortiOS 6.4 and earlier:

We have already mentioned the critical property of overlay stickiness that we must guarantee for proper ADVPN shortcut creation. For example, if Branch1 sends traffic to Branch2 using an internet overlay via the hub, the hub must select the same internet overlay for the second half of the path. Failing to preserve the overlay might result in an attempt to create an ADVPN shortcut between two physically disconnected transports (such as the internet and MPLS), and this attempt would, of course, fail. The overlay stickiness is achieved using Policy Routes (PBR) on each of the gateways.

Previous
Next