Fortinet white logo
Fortinet white logo

SD-WAN Deployment for MSSPs

Configuring Hub devices

Configuring Hub devices

The second part of the solution is to configure the Hub, so that it makes use of the information signaled by the Edge.

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

config router community-list

edit "SLA_OK"

config rule

edit 1

set action permit

set match "$(as):99"

next

end

next

end

config router route-map

edit "EDGE_IN"

config rule

edit 1

set match-community "SLA_OK"

set set-route-tag 99

next

edit 100

next

end

next

end

config router bgp

config neighbor-group

edit "EDGE"

set route-map-in "EDGE_IN"

next

end

end

This CLI Template defines the same custom BGP Community on the Hub side and uses a new route-map EDGE_IN to assign a custom route-tag (99 in our example) to the routes with that Community attached. This route-map is applied as route-map-in to all the routes learned from the Edge devices.

As a result, all the routes learned via healthy overlays will be assigned the route tag 99 (in our example).

Add the new CLI template to the group Hub-Template applied to the Hub:

Note

One common idea is to apply a higher local-preference (or weight) to the routes marked with SLA_OK community, so that BGP on the Hub prefers them over the routes via unhealthy overlays. While this approach would work in a basic case, we do not recommend it.

Recall that in the SD-WAN solution, the duty to steer the traffic must be delegated to SD-WAN! We would like BGP to keep all available routes and let SD-WAN select the preferred path for each case. For example, certain non-business-critical traffic might be still steered via an unhealthy (but cheaper) overlay. Whether it is Edge-to-Hub or Hub-to-Edge traffic, it requires a valid route on the Hub via the unhealthy overlay. Giving this route lower local-preference (or weight) would remove it from the routing table, thus violating this requirement.

We will now configure SD-WAN Rules on the Hub that will prefer the healthy overlays, based on the route tags:

  • Edit the SD-WAN Template Hub-Template (assigned to the Hub).
  • Create an SD-WAN Rule called INET_OK, matching the Route Tag as Destination and explicitly specifying the EDGE_INET member for it (using Manual strategy):

  • Similarly, create another SD-WAN Rule called MPLS_OK, matching the same Route Tag as Destination and explicitly specifying the EDGE_MPLS member for it (using Manual strategy):

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

Configuring Hub devices

Configuring Hub devices

The second part of the solution is to configure the Hub, so that it makes use of the information signaled by the Edge.

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

config router community-list

edit "SLA_OK"

config rule

edit 1

set action permit

set match "$(as):99"

next

end

next

end

config router route-map

edit "EDGE_IN"

config rule

edit 1

set match-community "SLA_OK"

set set-route-tag 99

next

edit 100

next

end

next

end

config router bgp

config neighbor-group

edit "EDGE"

set route-map-in "EDGE_IN"

next

end

end

This CLI Template defines the same custom BGP Community on the Hub side and uses a new route-map EDGE_IN to assign a custom route-tag (99 in our example) to the routes with that Community attached. This route-map is applied as route-map-in to all the routes learned from the Edge devices.

As a result, all the routes learned via healthy overlays will be assigned the route tag 99 (in our example).

Add the new CLI template to the group Hub-Template applied to the Hub:

Note

One common idea is to apply a higher local-preference (or weight) to the routes marked with SLA_OK community, so that BGP on the Hub prefers them over the routes via unhealthy overlays. While this approach would work in a basic case, we do not recommend it.

Recall that in the SD-WAN solution, the duty to steer the traffic must be delegated to SD-WAN! We would like BGP to keep all available routes and let SD-WAN select the preferred path for each case. For example, certain non-business-critical traffic might be still steered via an unhealthy (but cheaper) overlay. Whether it is Edge-to-Hub or Hub-to-Edge traffic, it requires a valid route on the Hub via the unhealthy overlay. Giving this route lower local-preference (or weight) would remove it from the routing table, thus violating this requirement.

We will now configure SD-WAN Rules on the Hub that will prefer the healthy overlays, based on the route tags:

  • Edit the SD-WAN Template Hub-Template (assigned to the Hub).
  • Create an SD-WAN Rule called INET_OK, matching the Route Tag as Destination and explicitly specifying the EDGE_INET member for it (using Manual strategy):

  • Similarly, create another SD-WAN Rule called MPLS_OK, matching the same Route Tag as Destination and explicitly specifying the EDGE_MPLS member for it (using Manual strategy):

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