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. Previous: Installing SD-WAN Manager 20.18: first boot and a stable GUI. Next: Enterprise root CA for Cisco SD-WAN without a Smart Account.
For SD-WAN Manager (formerly vManage) and the other old names, see the name map.
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 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-quitThe 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-quitRemoving 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.
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/4OMP 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 explains those errors.