> ## Content Index > Fetch the complete content index at: https://www.pinglabz.com/llms.txt > Use this file to discover other available public pages before exploring further. # Validator and Controller initial configuration on SD-WAN 20.18 - URL: https://www.pinglabz.com/sd-wan-validator-controller-config/ - Published: 2026-11-05T20:34:34.000Z - Updated: 2026-11-05T20:34:34.000Z - Description: The minimal Validator and Controller bootstrap used in a working SD-WAN 20.18 fabric. Why local matters, which interfaces we used, and how to verify orchestration and OMP separately. - Author: Jaime - Tags: SD-WAN, Cisco The Manager is reachable, but a branch still needs somewhere to register and somewhere to learn routes. We configure those two jobs here on Cisco Catalyst SD-WAN 20.18.2.1, with C8000v edges on IOS XE 17.18.02, built in my home lab. This is part of the [Cisco SD-WAN series](https://www.pinglabz.com/cisco-sd-wan/). Previous: [Installing SD-WAN Manager 20.18: first boot and a stable GUI](https://www.pinglabz.com/install-sd-wan-manager/). Next: [Enterprise root CA for Cisco SD-WAN without a Smart Account](https://www.pinglabz.com/sd-wan-enterprise-root-ca/). For SD-WAN Manager (formerly vManage) and the other old names, see the [name map](https://www.pinglabz.com/vmanage-vsmart-vbond-names/). ## Separate the two jobs The Validator is the reception desk. An edge registers there and learns where the Manager and Controllers are. The Controller is closer to a routing protocol's route reflector: it distributes reachability information after the edge joins. Use the [name map](https://www.pinglabz.com/vmanage-vsmart-vbond-names/) when a command says `vbond` or `vsmart`. Those are the old names for the Validator and Controller. A default hostname or login banner can still say `vsmart` on the Validator, so check configuration and role before changing anything. The plan assigns the Controller system IP `1.1.1.2` and transport address `172.16.20.20`. The Validator gets `1.1.1.3` and `172.16.30.30`. Both belong to site 1000 and organization `pinglabz-lab`. ## Configure the Validator's local role These are the bootstrap commands used in the successful build: ``` config system host-name validator system system-ip 1.1.1.3 system site-id 1000 system organization-name pinglabz-lab system vbond 172.16.30.30 local vpn 0 interface ge0/0 ip address 172.16.30.30/24 vpn 0 ip route 0.0.0.0/0 172.16.30.1 commit and-quit ``` The last word in `vbond ... local` makes this device the Validator. Without it, the command points at a Validator elsewhere. This command block changes the existing appliance defaults. It does not show the entire running configuration. A fresh capture confirms the resulting transport interface includes these lines, with unrelated service settings omitted: ``` vpn 0 interface ge0/0 ip address 172.16.30.30/24 tunnel-interface encapsulation ipsec ! no shutdown ! ip route 0.0.0.0/0 172.16.30.1 ! ``` Match the interface name to the device you actually have. In this build the Validator uses `ge0/0`, while the Controller uses `eth1`. ## Configure the Controller The Controller points at the same Validator address, without `local`: ``` config system host-name controller system system-ip 1.1.1.2 system site-id 1000 system organization-name pinglabz-lab system vbond 172.16.30.30 vpn 0 interface eth1 no ip dhcp-client vpn 0 interface eth1 ip address 172.16.20.20/24 vpn 0 ip route 0.0.0.0/0 172.16.20.1 commit and-quit ``` Removing the Dynamic Host Configuration Protocol (DHCP) client prevents it from competing with the planned static address. After committing, inspect `show running-config system` and `show running-config vpn 0`. Our current Controller configuration contains `172.16.20.20/24`, a tunnel-interface stanza, `no shutdown`, and the default route through `172.16.20.1`. Those values were checked again for this draft. Do not copy the lab's service allowances as a security policy. Restrict management access and use Cisco's release-specific port guidance. The commands above leave unrelated defaults untouched. [![The Manager registers the Validator and Controller; edges register at the Validator and exchange OMP with the Controller](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-validator-controller-config.png)](https://storage.ghost.io/c/ff/28/ff28db4a-11e1-4835-b928-158974cf96c1/content/images/2026/11/sd-wan-validator-controller-config.png?ref=pinglabz.com) ## Register both in the Manager The devices need IP connectivity before certificate work. From the Manager's administration network, check that the addresses you will register are reachable and that the login credentials work. Cisco's documented GUI entry point is Configuration > Devices > Control Components. Older documentation calls the tab Controllers. Add the Validator and the Controller, using the appropriate device type and reachable address. Our build used the Manager API for those adds, then retrieved the certificate signing requests from `system/device/controllers`. That is the tested path. The GUI menu description comes from Cisco docs and the saved end-state screens, not a new recording of the add dialog. Do not try to manufacture controller authorization with `request vsmart add serial-num`. Our build notes record that command as invalid on both 20.18 appliances. Keep registration and certificate records in the Manager. ## Complete trust before expecting peers The base configuration alone does not produce authenticated control connections. Each device needs the enterprise root certificate and its own signed device certificate. The next post covers that process. In our completed build, we signed and installed certificates in this order: Manager, Validator, then Controller. Each install finished before the next started. The Manager then distributed the authorization information. Cisco documents certificate installation and sending control-component serial numbers to the Validator as separate parts of authorization. A reachable device without its certificate is an intermediate state, not a completed onboarding. ## Verify each role from its own CLI On the Validator, use `show orchestrator connections | tab`. Our fresh output contains both edge system IPs, the Controller, and the Manager. On the Controller, use `show control connections`. After the two branches joined, this trimmed Controller output proved the routing role was working: ``` controller# show omp peers PEER TYPE DOMAIN ID OVERLAY ID SITE ID STATE R/I/S 10.0.0.1 vedge 1 1 100 up 12/0/4 10.0.0.2 vedge 1 1 200 up 12/0/4 ``` OMP means Overlay Management Protocol. The counters mean routes received, installed, and sent. The CLI's `vedge` label includes these C8000v peers. If the Validator sees an edge but the Controller has no OMP peer, check the edge certificate and authorization state before adding routing policy. If neither sees it, start with the underlay route, the Validator address, and the control-connection history. The [control-connections guide](https://www.pinglabz.com/sd-wan-control-connections/) explains those errors.