Orchestration Plane
The final, and probably the most important, component in Cisco Catalyst SD-WAN is SD-WAN Validator (formerly vBond). This component is very important because it provides initial authentication for participation in the fabric and acts as the glue that discovers and brings together all other components. Multiple SD-WAN Validator instances can be deployed to achieve high availability. Since a WAN Edge router can point to only a single SD-WAN Validator, it is recommended to configure WAN Edge routers to use a DNS name that has a single A record pointing to the IP addresses of all SD-WAN Validators. When the WAN Edge router tries to resolve the DNS record for the SD-WAN Validator, the DNS server provides multiple IP addresses for the hostname, and the WAN Edge router tries to connect to each of them sequentially until a successful control connection is made.
When a WAN Edge router first joins the overlay, the only thing it knows about the SD-WAN network is the IP address or DNS name of the SD-WAN Validator. It receives this information via one of these methods:
PNP/ZTP
Bootstrap configuration
Manual configuration
The WAN Edge router attempts to build a temporary connection to the SD-WAN Validator over each transport. Once the control plane connectivity is up to SD-WAN Controller and SD-WAN Manager, the connection to the SD-WAN Validator is torn down. When the WAN Edge router connects to the SD-WAN Validator, they both go through an authentication process in which each component authenticates the other and, if successful, a Datagram Transport Layer Security (DTLS) tunnel is established. The SD-WAN Validator then distributes the connectivity information for the SD-WAN Controller and SD-WAN Manager to the WAN Edge router. You can see why the SD-WAN Validator is referred to as the glue of the network: It tells all the components about each other. (This process is discussed in more detail in Chapters 3 and 4.)
One remaining functionality that the SD-WAN Validator provides is NAT traversal. By default, the SD-WAN Validator operates as a STUN server (RFC 5389). A WAN Edge router operates as a STUN client. What this means is that the SD-WAN Validator can detect when WAN Edge routers are behind a NAT device such as a firewall. When a WAN Edge router goes to establish its DTLS tunnel, the interface IP address it knows about is written into the outer IP header and noted within a payload of the message. When SD-WAN Validator receives this information, it compares the two values. If they are different, it can be inferred that NAT is in the transit path of the WAN Edge router (since the outer IP header was changed to a NAT IP address and no longer matches the IP address noted in the payload of the packet). The SD-WAN Validator communicates this back to the WAN Edge router, and the WAN Edge router can communicate this information to the rest of the overlay components—ultimately allowing data plane connectivity to be established through a NAT device. There are, however, some scenarios where this won’t work, such as with symmetric NAT (as discussed in more detail in Chapters 3 and 4). Figure 2-11 explains how STUN is used to detect when a WAN Edge router or another SD-WAN Control Component is subject to NAT.
)
Figure 2-11 STUN NAT Detection Method
When deploying an SD-WAN Validator, one special consideration is that it must be reachable directly from all transports with enabled control connectivity. This implies that SD-WAN Validator needs a public IP address (or a private IP address with 1:1 static NAT) when Internet transports are used in SD-WAN fabric.
Other SD-WAN Control Components (including SD-WAN Managers and SD-WAN Controllers) can use private IP addresses as long as they have connectivity to SD-WAN Validator since they use the same NAT discovery method (STUN) as the WAN Edge routers.