A virtual branch with nothing configured
BR-01 is a Catalyst 8000V (a virtual router) just created in a lab. It has an interface in a transport network and nothing else. The Manager (formerly vManage) already lists a placeholder for it but cannot reach it. The steps below are a procedure to carry out on a lab or your own device: this site does not run them, and the output further down is written for the lesson, not captured.
The order of the steps
- Enable controller mode. The router must run in controller-managed mode rather than autonomous mode. It reloads.
- Enter the bootstrap configuration. System block, transport interface and default route.
- Check that the controllers can be reached. Before certificates and tokens, prove the path.
- Install the root certificate chain. So the router trusts the controllers.
- Activate with the chassis number and token. So the controllers accept the router.
- Watch the control connections come up. Then move on to verification.
The order matters. A token cannot help if the path is closed, and a root certificate cannot help if the router is not yet in the right mode.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Step 1: controller mode
controller-mode enable
show versionEnabling controller mode makes the router reload. After the reload, the show version output includes the operating mode; look for the line that says controller-managed. Check your release for the exact wording.
If the router stays in autonomous mode, the SD-WAN commands in the next steps are not available or have no effect. This is the first thing to check when a command is rejected as unknown.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Step 2: the bootstrap configuration
These are example values for BR-01, with transport addresses from a documentation range. The system block gives the router its identity, and the interface and route give it a path.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
config-transaction
system
system-ip 10.255.2.1
site-id 101
organization-name "LAB-EXAMPLE"
vbond 10.255.0.12
exit
interface GigabitEthernet1
ip address 192.0.2.10 255.255.255.0
no shutdown
exit
interface Tunnel0
ip unnumbered GigabitEthernet1
tunnel source GigabitEthernet1
tunnel mode sdwan
exit
sdwan
interface GigabitEthernet1
tunnel-interface
encapsulation ipsec
color biz-internet
exit
exit
exit
ip route 0.0.0.0 0.0.0.0 192.0.2.1
commitExample values only, shortened. The system block, the transport interface, the tunnel interface and the default route are the core. Allowed services on the tunnel interface are left out here: choose them to suit your design. Where lines sit, and which are needed, depends on the release.
| Block | What it does | Wrong value shows as |
|---|---|---|
system-ip, site-id | The router's identity and site in the fabric. See System IP and Site ID. | Rejected or conflicting identity at the controllers |
organization-name | Must match the controllers exactly. See Organization Name. | Connection refused after the handshake |
vbond | Where to find the Validator (formerly vBond). | No attempt to connect, or a connection stuck at the first step |
| Transport interface and route | The path to the Validator in the transport side of the router. | Ping to the Validator fails |
tunnel-interface | Marks the interface as a transport, with its colour and encapsulation. See TLOC. | No control connection on that interface |
The Validator address may be a name instead of an IP address. A name needs DNS to work on the transport side, which is one more thing that can fail.
Step 3: reach the controllers first
Before installing a certificate, test the path from the transport interface. A failure here has nothing to do with trust, and fixing it later wastes time.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
ping 10.255.0.12 source GigabitEthernet1Run from the router. If the lab blocks ping at a firewall, a failed ping does not prove the path is closed, so use any other test that fits your lab. In a real network, the controllers are usually reached through the ISP and NAT, not by a private address.
Learn more: Transport-Side IP and ISP ReachabilityNAT, DNS and Firewall
Step 4: the root certificate chain
Copy the root CA certificate file from where the fabric keeps it onto the router's storage, using a file transfer method that your lab allows. Then install it. Confirm the file is present before installing.
dir bootflash: | include <root-ca-file>
request platform software sdwan root-cert-chain install bootflash:<root-ca-file>
show sdwan certificate root-ca-certThe file name is a placeholder, and the storage name depends on the platform. The last command displays the certificate that was installed. Compare its issuer with the CA that signs your controllers.
Step 5: chassis number and token
For a virtual router, the Manager creates a record for the device and can generate its bootstrap details, which include a chassis number and a one-time token. Where that option sits in the GUI changes by release. Both values are then used in one activation command on the router.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
request platform software sdwan vedge-cloud activate chassis-number <chassis-number> token <token>The words vedge-cloud are part of the command on virtual routers and are not a sign of an old platform. The chassis number and token come from the Manager; treat the token as a secret and do not paste it into tickets or chats.
A token is meant to be used once and to expire, so generate a fresh one if the first attempt is late or fails. How long it lasts depends on the release. Hardware routers do not use this step; they authenticate with their own certificate and serial number, and the authorisation is added to the device list instead (release dependent).
Step 6: watch it come up
BR-01#show sdwan control connections PEER TYPE PEER SYSTEM IP SITE ID LOCAL COLOR STATE vbond - - biz-internet connect vsmart 10.255.0.11 1 biz-internet up vmanage 10.255.0.10 1 biz-internet up
Where the procedure tends to go wrong
On small screens, swipe sideways or focus the diagram and use the arrow keys.
- Typing a command in the wrong mode or block. The SD-WAN lines are accepted in a configuration transaction in the style shown; check your release.
- An organisation name with a different capital letter or a space. Copy it from the Manager.
- A site ID that matches another site, or a system IP already used by another device.
- Activating before the root certificate is installed, then reading the failure as a bad token.
- A wrong date on the lab VM. Fix the clock before assuming the certificate is bad.
Test yourself on the bootstrap
A Catalyst 8000V rejects the sdwan interface commands as unknown. What do you check first?
BR-01 cannot ping the Validator from its transport interface. Which step is the sensible one next?
Which description of the chassis number and token is correct?
The control connections to the Controller and Manager stay down after activation, and the clock on the VM is two years behind. Which fix is the most sensible?