Onboard a Catalyst 8000v 17.18 in controller mode

The C8000v boots, but it does not appear as a working branch in the fabric. We give it transport connectivity, trust, and a software identity on Cisco Catalyst SD-WAN 20.18.2.1 with IOS XE 17.18.02, built in my home lab.

This is part of the Cisco SD-WAN series. Previous: Uploading the WAN edge serial list manually: the C8000v caveat. Next: Autonomous vs Controller Mode on IOS XE. The file-transfer sibling is “tclsh not supported in Controller mode”: installing SD-WAN certificates.

For SD-WAN Manager (formerly vManage) and the other old names, see the name map.

Check the mode before pasting configuration

Controller mode lets the router participate in the SD-WAN fabric. Autonomous mode is the router's conventional IOS XE operating mode. Think of choosing which control system the router answers to before configuring its WAN links.

Our fresh edge1 capture confirms the starting point:

edge1#show version | include IOS XE|operating
Cisco IOS XE Software, Version 17.18.02
Router operating mode: Controller-Managed

The output is trimmed. If your router is autonomous, stop here and follow Cisco's platform mode-change procedure. Switching modes can require a reload and affect configuration. I did not change the mode of either working edge for this draft.

You also need the previous posts complete: stable control components, an installed enterprise root, and two generated WAN edge identities already sent to the controllers. Use software you are entitled to run. No cloud signup is part of this procedure.

Configure edge1's identity

The successful bootstrap used a configuration transaction:

config-transaction
system
 system-ip 10.0.0.1
 site-id 100
 organization-name pinglabz-lab
 vbond 172.16.30.30 port 12346
exit

A transaction collects the edits until commit. Do not expect half a pasted block to be active before the commit succeeds.

Use a unique system IP and the exact organization string from the control components. The Validator address is its transport address, not its system IP 1.1.1.3.

Configure the two transports

Continue the same transaction:

interface GigabitEthernet2
 ip address 10.10.1.11 255.255.255.0
 no shutdown
exit
interface GigabitEthernet3
 ip address 10.20.1.11 255.255.255.0
 no shutdown
exit
interface Tunnel2
 ip unnumbered GigabitEthernet2
 tunnel source GigabitEthernet2
 tunnel mode sdwan
exit
interface Tunnel3
 ip unnumbered GigabitEthernet3
 tunnel source GigabitEthernet3
 tunnel mode sdwan
exit
sdwan
 interface GigabitEthernet2
  tunnel-interface
   encapsulation ipsec
   color mpls restrict
  exit
 exit
 interface GigabitEthernet3
  tunnel-interface
   encapsulation ipsec
   color biz-internet
  exit
 exit
exit
ip route 0.0.0.0 0.0.0.0 10.10.1.1
ip route 0.0.0.0 0.0.0.0 10.20.1.1
commit
end

These are the identity and transport portions of the tested configuration, with the lab's broad allow-service all lines omitted. Review service allowances for your management path rather than exposing every service on a WAN interface. The snippets are not a replacement for existing access or security configuration.

A color labels a transport. Here mpls restrict allows same-color data tunnels, while biz-internet has no restrict flag. The colors post shows why this produces two tunnels between the two edges.

For edge2, use system IP 10.0.0.2, site 200, Gi2 10.10.2.12/24, Gi3 10.20.2.12/24, and gateways 10.10.2.1 and 10.20.2.1. Keep its chassis identity separate from edge1's.

Install the public enterprise root

Transfer rootCA.pem to bootflash:rootCA.pem using your approved file-transfer path. Then install it:

request platform software sdwan root-cert-chain install bootflash:rootCA.pem
show sdwan certificate root-ca-cert

Confirm that the root's subject matches your CA. A copied file alone does not install trust. Our current root store includes PingLabz Lab Root CA with CA:TRUE.

Old tutorials sometimes write this file with tclsh. Our router returns “This command is not supported in Controller mode.” Use the file-transfer casebook instead.

Activate one software identity

Use the chassis and token generated for this router in the Manager. Treat the token like a one-time enrollment secret:

request platform software sdwan vedge_cloud activate chassis-number <CHASSIS_UUID> token <TOKEN>

That is the spelling used by our working script on 17.18.02. Do not invent a token from a physical serial number, and do not give both routers the same generated identity.

The Manager's device record then supplied a certificate signing request (CSR) in vedgeCSR. Our notes measured about 45 seconds from activation to that request appearing. Poll the state instead of assuming every router takes exactly that long.

This series uses manual identities. In a PnP workflow, portal inventory and controller discovery replace some of these manual bootstrap inputs. We did not exercise that cloud path.

Sign and install the device certificate

Save the router's own CSR as edge1.csr, then use the enterprise CA signing command from the previous post:

openssl x509 -req -in edge1.csr \
  -CA rootCA.pem -CAkey rootCA.key -CAcreateserial \
  -out edge1.crt -days 2000 -sha256 -copy_extensions copy

Install the raw PEM through the Manager's signed-certificate endpoint. Wait for the task and the device state to finish before activating the next edge. In the successful run this took around 70 to 90 seconds per edge.

Cisco documents a certificate staging test from 20.18.1: the edge tries the certificate against the Validator before installation completes. A task that is waiting for the device response has not necessarily failed after a few seconds.

Compare the certificate serial with the Manager record before the final authorized-list push. A local certificate install can leave the Manager's inventory stale, as the serial-list post explains.

Verify trust, routing, and tunnels separately

A fresh check found five control rows on edge1: the Controller on both transports, the Validator on both, and the Manager on mpls. All were up. The old peer labels are vsmart, vbond, and vmanage.

Then check routing:

edge1#show sdwan omp peers
PEER       TYPE    SITE ID  STATE  R/I/S
1.1.1.2    vsmart  1000     up     12/2/4

This output is trimmed. Overlay Management Protocol (OMP) carries the routes and transport information. A Manager connection alone does not prove OMP is up.

After both edges join, check Bidirectional Forwarding Detection (BFD), which tests each data tunnel:

edge1#show sdwan bfd sessions
SYSTEM IP  SITE ID  STATE  SOURCE COLOR  REMOTE COLOR
10.0.0.2   200      up     mpls          mpls
10.0.0.2   200      up     biz-internet  biz-internet

The original completed build also passed five host-to-host pings in service VPN 10. That forwarding test needs LAN interfaces and service routing, which are separate from the transport-only snippets above. Do not copy those snippets and expect a user subnet to be present automatically.

If only the Validator and Manager connect, inspect certificate installation and authorization before working on service routing. If OMP is up but BFD is down, check the edge-to-edge underlay and color restrictions. The failed step tells you where to look next.