Design example - basic SD-WAN/ADVPN

This design is the most fundamental building block of our solution. The more advanced multi-hub and multi-regional examples that we cover later will essentially be extensions of basic SD-WAN/ADVPN.

The sites are interconnected by IPsec overlays, forming hub-and-spoke topology. Two primary flavors can be distinguished:

• In the Enterprise flavor, the hub is located at the customer’s central office or a datacenter. The spokes (edges) are distributed across all remote sites (branch offices, retail stores, homeworkers, and so on). Most traffic is either spoke-to-hub (sites accessing workloads hosted in the datacenter, remote internet access through centralized breakout, cloud on-ramp services, and so on) or direct internet access from spokes (workloads hosted on public clouds—*aaS, non-business-critical internet browsing, and so on). Occasional spoke-to-spoke communication is flowing through direct ADVPN shortcuts.
• The Managed Service flavor is suitable for managed security service providers (MSSPs). The hub is located at MSSP premises, while the spokes (edges) are distributed across all end-customer sites, acting as CPEs. All types of end-customer sites are spokes in this flavor, including branch offices, datacenters, and so on. As a result, nearly all the traffic is either spoke-to-spoke (flowing through ADVPN shortcuts) or direct internet access from the spokes. There are often no workloads behind the hubs in MSSP premises, which reduces traffic flow through the hubs to a minimum, leaving them mainly with a control plane function. For this reason, the hubs are often called SD-WAN Gateways in this flavor. Optionally, they can be shared between multiple endcustomers (also called tenants), using either virtual routing and forwarding (VRF) instances or virtual domains (VDOMs).

Regardless of the chosen flavor, the rest of the design remains the same.

The hub acts as a dial-up IPsec server for the spokes, having a separate dial-up IPsec endpoint terminate on each underlay interface. Each endpoint defines a point-to-multipoint overlay. Every spoke will typically connect to all the overlays to have multiple alternative paths. However, it can also happen that some of the spokes do not have all the underlay transports available. Hence, they will be able to connect only to a subset of the overlays.

The spokes establish separate IBGP sessions to the hub over each overlay. BGP Neighbor Group feature is used on the hub for this peering. Each spoke then advertises its local site prefix(es) over each of the IBGP sessions. The hub acts as a BGP Route Reflector (RR), readvertising the prefixes to all other spokes. Additionally, the hub advertises its prefixes (such as DC LAN in the Enterprise flavor). At the end of this process, all the sites exchange their routes over all available overlays.

Once all the routes have been distributed across all the sites, the application traffic flow can be controlled by SD-WAN rules according to the design principles described in the previous chapter.

Let us list different types of traffic flows present in this topology. See Traffic flows.