Cisco SD-WAN WAN Edge Onboarding: — vEdge vs cEdge, Certificates, ZTP & PnP

① The WAN Edge router — vEdge vs cEdge, and its identity

The WAN Edge is the router that actually sits in your branch and builds the encrypted overlay. It comes in two flavours. A vEdge runs Viptela OS — the original code Cisco inherited when it bought Viptela in 2017. A cEdge is a regular Cisco router — ISR, ASR, or Catalyst 8000 — running IOS-XE SD-WAN software. Same job, two operating systems.

Cisco converged on cEdge / IOS-XE for one practical reason: it's the same IOS-XE your CCNA/CCNP brain already knows, so SD-WAN, classic routing, security and SD-Access all live on one code train. vEdge still shows up in older estates and the labs, and the field — plus the ENSDWI 300-415 exam — still uses the Viptela names every day (vBond, vSmart, OMP, TLOC). New deployments are almost all cEdge: from Catalyst SD-WAN Manager 20.18, even the small ISR 1100 routers default to IOS-XE, and Manager hides the old migration menu once it sees IOS-XE.

Whichever flavour, every edge carries the same identity triple. The system-IP is the device's name in the overlay (a unique /32, e.g. 10.0.1.1 — think of it as the overlay loopback). The site-ID says which physical location it lives at. And the organization-name names the whole overlay — and it must be byte-identical on every controller and every edge.

Think of it like an Aadhaar number. The system-IP is the unique number that is yours alone; the site-ID is your district; the organization-name is the country whose database you're enrolled in. Get any one wrong and the verification at the gate fails — not because you're a bad person, but because the records don't line up.

system
 host-name      BLR-BRANCH-01
 system-ip      10.0.1.1
 site-id        101
 organization-name "Infosys-OV"
 vbond          203.0.113.10

Building configuration...
[OK]
BLR-BRANCH-01# show sdwan system status | inc System
System IP                 : 10.0.1.1
Site ID                   : 101

Four vocabulary anchors for the whole lesson

Tap each card — these four ideas come back in every section.

② The trust model — certificates, serial numbers & the whitelist

Onboarding is a trust handshake, and trust starts with a certificate. The edge's certificate can be signed by a public CA (historically Symantec/DigiCert, the cloud default), your own enterprise CA, or — for the automated paths — an on-box certificate the device already carries from the factory. A hardware vEdge stores its cert in a TPM chip; a hardware cEdge stores it in a SUDI chip. That chip is what proves the box is genuinely yours.

But a valid certificate alone isn't enough — the controllers also need to be told which serial numbers are allowed in. That list is the WAN Edge list: a signed file of chassis numbers and serial numbers you download from Cisco PnP Connect (in your Smart Account) and upload into vManage. vManage then distributes it to vBond and vSmart. Until that push happens, the controllers' whitelist doesn't include your new edge — so it gets turned away at the gate.

Here's the part beginners miss: uploading the list to vManage is not the same as the controllers knowing about it. You must click Send to Controllers so vBond and vSmart get the updated whitelist. Skip that, and the edge's cert is fine, its IP reachability is fine — but vBond still says "who are you?" and rejects the handshake. It's the classic "I uploaded it, why won't it join?" ticket.

Now the org-name trap. The organization-name is baked into the certificate's identity and checked at the gate. If the edge's org-name doesn't match what the controllers expect — even a hyphen-vs-underscore difference like "Infosys-OV" versus "Infosys_OV" — vBond raises CTORGNMMIS and the device never joins. There's no warning email; the edge just sits in connect forever.

show sdwan control local-properties | include organization|serial|certificate

organization-name              Infosys-OV
certificate-status             Installed
certificate-validity           Valid
serial-num                     1A2B3C4D
root-ca-chain-status           Installed

③ Onboarding methods — ZTP, PnP & bootstrap

Once trust is prepped, you pick how the box gets its first config. There are three methods, and the site usually decides for you. Zero-Touch Provisioning (ZTP) and Plug-and-Play (PnP) are the automated, ship-it-to-the-branch options; bootstrap/manual is the air-gapped fallback. All three end at the same join — they only differ in how the edge first learns its vBond and org.

ZTP is the vEdge path. Power on, the VPN 0 transport interface grabs an IP, gateway and DNS via DHCP, then the edge resolves ztp.viptela.com and makes an HTTPS call to the ZTP server. That server hands back the enterprise vBond IP, the organization-name, and the root certificate. From there the edge calls home to your vBond and the normal join takes over. (Air-gapped? You can run an on-prem ZTP server, as long as the edge can resolve ztp.viptela.com to it.)

PnP is the cEdge path. Same idea, IOS-XE flavour: the edge reaches devicehelper.cisco.com (Cisco's PnP Connect service). Your Cisco Smart Account must hold a controller profile that maps this device's serial to your vBond and org-name. PnP Connect returns that, and the cEdge redirects to your vBond. No profile in the Smart Account = the device phones home and gets told nothing useful.

Bootstrap is the no-cloud fallback. For an air-gapped site or one with no DHCP at install, you generate a bootstrap config file in vManage and drop it on a USB stick or the device flash. The filename matters: ciscosdwan.cfg on most platforms (some use ciscosdwan_cloud_init.cfg). On boot the edge reads the file, learns its vBond/org/system-IP, and joins. The fully-manual cousin is just typing the system block (system-ip, site-id, organization-name, vbond) at the console — useful in the lab.

An everyday analogy: ZTP/PnP is Aadhaar-OTP onboarding — you show up, the system already has your record, an automated check verifies you, and you're in within minutes with no paperwork. Bootstrap is the offline KYC form you carry in by hand when there's no network at the counter — slower, but it works where the cloud doesn't reach.

④ The join sequence — edge → vBond → vManage → vSmart

Now watch the whole thing run. After the transport is up, the edge climbs a four-rung ladder. Rung 1 — vBond (Validator): the edge opens a DTLS session to vBond, authenticates with its certificate, and vBond — the only controller reachable across NAT — authenticates the edge and hands back the list of vManage and vSmart addresses. vBond is the matchmaker; it introduces, then steps out of the data path.

Rung 2 — vManage (Manager): the edge forms a permanent DTLS/TLS control connection to vManage and pulls its device template (the full config — interfaces, policies, OMP settings). Rung 3 — vSmart (Controller): the edge connects to vSmart and runs OMP over that session, learning the overlay's routes and TLOCs. Once OMP is up and BFD tunnels form, the edge is a full fabric member.

When it doesn't work, resist the urge to ping. The first-look on "control connections down" is two commands. show sdwan control connections tells you which controllers are up vs stuck in connect; show sdwan control connections-history prints the Local Error / Remote Error code that says why. Read the code, then act: CTORGNMMIS → fix org-name; CONACTREJ → push the WAN Edge list; DCONFAIL → open UDP 12346 on the firewall; NOACTVBMS → vBond unreachable; CRTVERFL → certificate/root-chain problem.

show sdwan control connections

PEER    PEER                            SITE        DOMAIN  PEER
TYPE    PROT  SYSTEM IP        ID          ID      STATE
-----------------------------------------------------------------
vbond   dtls  -                0           0       up
vmanage dtls  10.255.255.1     1           0       up
vsmart  dtls  10.255.255.5     1           1       up

show sdwan control connections-history | include vbond|ERROR|CTORGNMMIS|CONACTREJ

PEER     PEER   SYSTEM IP      LOCAL ERROR   REMOTE ERROR   REPEAT
vbond    dtls   -              CTORGNMMIS    NOERR          14
  -> org-name on this edge does not match the controllers
  -> fix organization-name, then: clear sdwan control connections