Overview

This example demonstrates a scalable configuration using options that help simplify head-end traffic-steering in an SD-WAN setup that uses a hub and spoke topology. In this example, the hub and branches have basic configurations, with one set of SD-WAN rules on the hub to cover all branch instances.

The hub does not need to reference branch addresses in the SD-WAN rules to steer traffic to each branch over the healthy VPN overlay. It also does not need to run health checks to the branches to determine what paths are healthy. Instead, the branches configure health checks to monitor the links, and use BGP and BGP communities to satisfy both requirements by updating the hub with the status of the links over BGP. This avoids manual maintaining health checks from the head-end, allowing for better scalability.

Hub

The hub is connected to two ISPs, and forms VPN overlays with each branch over two interfaces. When it learns the routes from the branches, it matches the BGP communities and assigns route-tags to them. Using SD-WAN service rules it steers traffic to a branches subnet based on the active route-tag. It does not require health checks to determine the healthy path because this is handled by each branch.

Branches

Each branch is connected to two ISPs, and for each ISP a VPN overlay connects to the hub. The branch monitors the health status of its VPN overlays. It advertises the branch subnet over iBGP to its peer on the hub that is acting as a route reflector. Each branch selectively advertises its preferred overlay using route-maps that tag the advertised routes with BGP communities. When the primary link is out of SLA, it advertises a failed BGP community, and the secondary link advertises its normal BGP community.

There are two branches in this example, but the solution can be scaled up with more branches that use the same configuration.