Fortinet white logo
Fortinet white logo

SD-WAN Deployment for MSSPs

Configuring Edge devices

Configuring Edge devices

The first part of the solution is to configure the Edge to signal the SLA status of its overlays to the Hub.

Create (or import) a new CLI Template, called 04-Edge-Signal-SLA:

config router route-map

edit "SLA_OK"

config rule

edit 1

set set-community "$(as):99"

next

end

next

end

config router bgp

config neighbor

edit $(h1-inet-tunnel-ip)

set route-map-out-preferable "SLA_OK"

next

edit $(h1-mpls-tunnel-ip)

set route-map-out-preferable "SLA_OK"

next

end

end

This CLI Template defines a new route-map SLA_OK that will attach a custom BGP Community (65001:99 in our example) to the BGP routes advertised by the Edge over the overlay that meets the SLA. If an overlay does not meet the SLA, the BGP Community will not be attached. This will allow the Hub to distinguish between healthy and unhealthy overlays, as will be shown shortly.

In order to achieve this goal, we apply the new route-map as route-map-out-preferable to all the BGP sessions towards the Hub.

  • The route-map-out-preferable will be applied to all the outgoing BGP routes, when the respective BGP neighbor is marked as healthy (meets the SLA). In this case our custom BGP Community will be attached to the routes.
  • When the respective BGP neighbor is not healthy (out of SLA), the regular route-map-out will be applied instead. Since we do not configure it, then nothing will be applied, and no BGP Community will be attached to the routes.

Add the new CLI template to the group Edge-Template applied to the Edge devices:

What is still missing is the mechanism that will mark the BGP neighbors as healthy or not healthy, based on the current SLA status of their respective overlays. We will configure this mechanism in our SD-WAN Template:

  • Navigate to SD-WAN > BGP Neighbors, and define two BGP Neighbors BGP_INET and BGP_MPLS that will map to the neighbor IPs configured on the Edge devices. (Keep their Role as standalone.)

    BGP Neighbor

    Neighbor IP

    BGP_INET10.201.1.1
    BGP_MPLS10.202.1.1

  • Edit the SD-WAN Template Edge-Template (assigned to the Edge devices). Add the two BGP Neighbors to it, linking each one of them to the HUB Performance SLA. Make sure you use the right overlay member for each BGP Neighbor:

Note

The above configuration can be literally read as follows:

  • BGP_INET neighbor is healthy, if H1_INET member is healthy, according to the SLA target 1 of the HUB Performance SLA
  • BGP_MPLS neighbor is healthy, if H1_MPLS member is healthy, according to the SLA target 1 of the HUB Performance SLA

Recall that when a neighbor is healthy, route-map-out-preferable is applied to the routes advertised to it. This should now complete the whole picture.

Save the changes and install the configuration on all the Edge devices by using the Quick Install (Device DB) method.

Configuring Edge devices

Configuring Edge devices

The first part of the solution is to configure the Edge to signal the SLA status of its overlays to the Hub.

Create (or import) a new CLI Template, called 04-Edge-Signal-SLA:

config router route-map

edit "SLA_OK"

config rule

edit 1

set set-community "$(as):99"

next

end

next

end

config router bgp

config neighbor

edit $(h1-inet-tunnel-ip)

set route-map-out-preferable "SLA_OK"

next

edit $(h1-mpls-tunnel-ip)

set route-map-out-preferable "SLA_OK"

next

end

end

This CLI Template defines a new route-map SLA_OK that will attach a custom BGP Community (65001:99 in our example) to the BGP routes advertised by the Edge over the overlay that meets the SLA. If an overlay does not meet the SLA, the BGP Community will not be attached. This will allow the Hub to distinguish between healthy and unhealthy overlays, as will be shown shortly.

In order to achieve this goal, we apply the new route-map as route-map-out-preferable to all the BGP sessions towards the Hub.

  • The route-map-out-preferable will be applied to all the outgoing BGP routes, when the respective BGP neighbor is marked as healthy (meets the SLA). In this case our custom BGP Community will be attached to the routes.
  • When the respective BGP neighbor is not healthy (out of SLA), the regular route-map-out will be applied instead. Since we do not configure it, then nothing will be applied, and no BGP Community will be attached to the routes.

Add the new CLI template to the group Edge-Template applied to the Edge devices:

What is still missing is the mechanism that will mark the BGP neighbors as healthy or not healthy, based on the current SLA status of their respective overlays. We will configure this mechanism in our SD-WAN Template:

  • Navigate to SD-WAN > BGP Neighbors, and define two BGP Neighbors BGP_INET and BGP_MPLS that will map to the neighbor IPs configured on the Edge devices. (Keep their Role as standalone.)

    BGP Neighbor

    Neighbor IP

    BGP_INET10.201.1.1
    BGP_MPLS10.202.1.1

  • Edit the SD-WAN Template Edge-Template (assigned to the Edge devices). Add the two BGP Neighbors to it, linking each one of them to the HUB Performance SLA. Make sure you use the right overlay member for each BGP Neighbor:

Note

The above configuration can be literally read as follows:

  • BGP_INET neighbor is healthy, if H1_INET member is healthy, according to the SLA target 1 of the HUB Performance SLA
  • BGP_MPLS neighbor is healthy, if H1_MPLS member is healthy, according to the SLA target 1 of the HUB Performance SLA

Recall that when a neighbor is healthy, route-map-out-preferable is applied to the routes advertised to it. This should now complete the whole picture.

Save the changes and install the configuration on all the Edge devices by using the Quick Install (Device DB) method.