# Cisco SD-WAN WAN Edge Onboarding: — vEdge vs cEdge, Certificates, ZTP & PnP Source: https://ai.techclick.in/blog_cisco_sdwan_wan_edge_onboarding Markdown: https://ai.techclick.in/blog_cisco_sdwan_wan_edge_onboarding.md Publisher: Techclick Infosec Pvt Ltd Onboard a Cisco SD-WAN WAN Edge end to end: vEdge (Viptela OS) vs cEdge (IOS-XE), TPM vs SUDI certs, the WAN Edge list whitelist, org-name, ZTP vs PnP vs bootstrap, and the vBond→vManage→vSmart join sequence with real show sdwan commands. Cisco SD-WAN WAN Edge Onboarding: — vEdge vs cEdge, Certificates, ZTP & PnP student learning map A visual study map for Cisco SD-WAN WAN Edge Onboarding: — vEdge vs cEdge, Certificates, ZTP & PnP showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Cisco SD-WAN WAN Edge Onboarding: — vEdge vs cEdge,... Cisco SD-WAN · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① The WAN Edge router — vEdge vs... 4. Practice ② The trust model — certificates,... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most engineers think onboarding a WAN Edge is "rack it, give it an IP, point it at vBond, done" — so when it doesn't join they reach for ping and routing first. Wrong — and you'll burn an hour chasing the wrong layer. The edge can have perfect IP reachability and still never join, because onboarding is a trust handshake , not a routing problem. If the device's serial isn't on the synced WAN Edge list, or its organization-name is off by one character, or its certificate isn't trusted, vBond rejects it before OMP ever starts. The first move on "control connections down" is show sdwan control connections-history to read the error code — not ping . ## ① 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. 👉 So far: vEdge = Viptela OS, cEdge = IOS-XE, same role. Next: the three numbers that turn a box into a known member of YOUR fabric. 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. Figure 1 — WAN Edge identity and the controllers that must already know it Two WAN Edge routers, a vEdge running Viptela OS with a TPM certificate chip and a cEdge running IOS-XE SD-WAN with a SUDI certificate chip, both carry the same identity triple of system-IP, site-ID and organization-name. Each sits behind two transports, MPLS and Internet. They reach up to three controllers: vBond Validator for authentication, vManage Manager for templates, and vSmart Controller for OMP routing. - One identity, two flavours of WAN Edge, three controllers control plane — controllers (must already trust this edge) vBond · Validator authenticate + introduce vManage · Manager push template vSmart · Controller OMP routes vEdge — Viptela OS TPM cert chip system-ip 10.0.1.1 site-id 101 · org "Infosys-OV" cEdge — IOS-XE SD-WAN SUDI cert chip system-ip 10.0.2.1 site-id 102 · org "Infosys-OV" MPLS Internet MPLS Internet DTLS to controllers Same org-name on both edges AND all 3 controllers — change one letter and the join silently fails underlay/untrusted overlay/trusted control/policy key insight allowed/joined Look at the two edge boxes: a vEdge with a TPM cert chip and a cEdge with a SUDI cert chip — but the same system-IP/site-ID/org-name pattern. The org-name (bottom line) is the one that must match the three controllers up top. cEdge CLI — the minimum identity (system block) system host-name BLR-BRANCH-01 system-ip 10.0.1.1 site-id 101 organization-name "Infosys-OV" vbond 203.0.113.10 Expected output 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. 🟦 vEdge (Viptela OS) tap to flip Original Viptela router; cert lives in a TPM chip. Onboards via ZTP (ztp.viptela.com). Still in older estates and the exam. 🟩 cEdge (IOS-XE) tap to flip A Cisco ISR/ASR/Catalyst-8000 on IOS-XE SD-WAN; cert in a SUDI chip. Onboards via PnP. The default for new builds. 🆔 Identity triple tap to flip system-IP (unique /32 name) + site-ID (location) + org-name (the overlay). All three feed the trust check. So: get them right BEFORE power-on. 🔡 organization-name tap to flip One text string naming the overlay. Must be byte-identical on every controller and edge. One typo = CTORGNMMIS = no join. Quick check · Q1 of 10 Rahul at TCS racks a brand-new Catalyst 8000 running IOS-XE SD-WAN for a greenfield site. A teammate calls it "the vEdge." What's the correct term, and why does it matter for onboarding? a) It's a cEdge — IOS-XE means it onboards via PnP and stores its cert in a SUDI chip, not the vEdge ZTP/TPM path b) It's a vEdge — all SD-WAN routers are vEdges c) The name is cosmetic; onboarding is identical either way d) It's a vSmart because it's brand new Correct: a. IOS-XE SD-WAN = cEdge. That matters because a cEdge uses Plug-and-Play (devicehelper.cisco.com) with a SUDI-chip certificate, whereas a vEdge uses ZTP (ztp.viptela.com) with a TPM-chip certificate. Calling it a vEdge would send Rahul down the wrong onboarding method. It is certainly not a vSmart — that's a controller. Pause & Predict Predict: two edges at the SAME branch are accidentally given the same system-IP (10.0.1.1). What breaks, and which command exposes it fastest? Type your guess. Reveal answer Answer: The system-IP is a unique overlay identifier — duplicating it triggers a SYSIPCHNG/duplicate-system-IP condition and one edge's control connections flap or stay down. The fastest check is `show sdwan control local-properties` (it shows the device's own system-IP and org-name); compare the two boxes and you'll see the collision. Site-ID can be shared by design; system-IP cannot. ## ② 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. vManage → Configuration → Certificates → WAN Edge List . Real menu path and field labels. (Recreated for clarity — your Manager matches this.)"> 🖥️ This is the screen you load the whitelist on — vManage → Configuration → Certificates → WAN Edge List . Real menu path and field labels. (Recreated for clarity — your Manager matches this.) vmanage.lab.local · Configuration · Certificates · WAN Edge List 1 Sync Smart Account / Upload WAN Edge List viptela_serial_file.viptela (signed) 2 Chassis Number C8K-9AF0… · Serial: 1A2B3C4D 3 Validity Valid 4 Send to Controllers Push list to vBond + vSmart Certificate state Installed Send to Controllers 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. Figure 2 — The trust chain — cert, serial, whitelist, and the two ways it fails Trust flow. A root CA, Symantec or DigiCert or an enterprise CA or the on-box automated root, signs the device certificate. The chassis and serial number live in the WAN Edge list, a signed file you download from PnP Connect and upload to vManage. vManage pushes that whitelist to vBond and vSmart. When an edge calls vBond, vBond checks three things: certificate signed by a trusted root, serial number on the list, and matching organization name. Pass all three and it joins. Fail any one and it is rejected. Three checks at the gate: trusted cert · serial on the list · org-name matches Root CA Symantec/DigiCert · ent CA · on-box WAN Edge list chassis + serial # from PnP Connect (signed) vManage holds + distributes whitelist vBond · Validator the gate vSmart · Controller also gets the list edge passes all 3 ✓ cert trusted + serial listed + org-name matches → JOINS the fabric wrong org-name "Infosys_OV" vs "Infosys-OV" vBond rejects → CTORGNMMIS serial not synced list never pushed to vBond handshake denied → CONACTREJ DTLS to vBond ok No serial sync + no org match = no fabric. Upload the WAN Edge list and send to controllers BEFORE you power on the edge. underlay/untrusted overlay/trusted control/policy key insight allowed/joined Trace the arrows: root CA signs the cert; the WAN Edge list (chassis+serial) goes into vManage and out to vBond/vSmart. Bottom row shows the two classic failures — wrong org-name (CTORGNMMIS) and serial not synced (CONACTREJ). 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. Common mistake — "I uploaded the list, it still won't join" Symptom: the edge shows control connections down to vBond , history says CONACTREJ (connection actively rejected). Cause: the WAN Edge list was uploaded to vManage but never pushed — so vBond's whitelist doesn't include this serial yet. Fix: Configuration → Certificates → WAN Edge List → Send to Controllers , then clear sdwan control connections on the edge. Reachability was never the problem. cEdge CLI — prove your own org-name and serial (the gate's view) show sdwan control local-properties | include organization|serial|certificate Expected output organization-name Infosys-OV certificate-status Installed certificate-validity Valid serial-num 1A2B3C4D root-ca-chain-status Installed Quick check · Q2 of 10 Priya at ICICI sees a new edge stuck in 'connect'. History shows CTORGNMMIS. Reachability to vBond is fine. What's wrong and where does she fix it? a) The DTLS port 12346 is blocked — open it on the firewall b) The vSmart is down — restart it c) The system-IP is duplicated — change it d) The org-name on the edge doesn't match the controllers — fix the organization-name string so it's byte-identical everywhere Correct: d. CTORGNMMIS = organization-name mismatch. The cure is to make the org-name byte-identical on the edge and all controllers (watch for hyphen vs underscore, trailing spaces, case). A blocked 12346 would show DCONFAIL, not CTORGNMMIS; a down vSmart or duplicate system-IP produce different symptoms entirely. Pause & Predict Predict: the device certificate is valid AND the serial number is on the WAN Edge list in vManage — but the new edge still gets CONACTREJ from vBond. What single action was forgotten? Type your guess. Reveal answer Answer: The list was never pushed to the controllers. Uploading to vManage updates Manager's view, but vBond and vSmart only learn the new serial after 'Send to Controllers'. Click that, then clear control connections on the edge and it joins. Trust = cert + serial + the controllers actually having the serial. ## ③ 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. Figure 3 — Pick the onboarding method by what the site has A decision flow for the three onboarding methods. If the site has DHCP plus internet and the edge is a vEdge, use ZTP via ztp.viptela.com. If it is a cEdge running IOS-XE, use PnP via devicehelper.cisco.com tied to a Cisco Smart Account PnP Connect profile. If the site is air-gapped or has no DHCP, use a bootstrap config file, ciscosdwan.cfg or ciscosdwan_cloud_init.cfg, on a USB stick or flash, generated by vManage. All three paths converge on the same join: authenticate to vBond, pull a template from vManage, then OMP to vSmart. Three ways to onboard — let the SITE choose for you DHCP + internet at site? and which platform? ZTP — vEdge DHCP → resolve ztp.viptela.com learns vBond IP, org, root cert → joins + zero on-site touch − needs reachable ZTP DNS PnP — cEdge (IOS-XE) DHCP → reach devicehelper.cisco.com PnP Connect profile on Cisco Smart Account + same idea, IOS-XE side − SA controller profile must exist Bootstrap / manual air-gapped / no DHCP ciscosdwan.cfg on USB generated by vManage, or console minimum config + works with no cloud − you walk to the site All three converge on the SAME join: vBond authenticate → vManage template → vSmart OMP underlay/untrusted overlay/trusted control/policy key insight allowed/joined Read the decision top to bottom: platform + reachability send you to ZTP (vEdge), PnP (cEdge), or bootstrap (air-gapped). Notice all three converge on the SAME join at the bottom. 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. Karthik at Airtel faces this Karthik ships a pre-staged Catalyst 8200 (cEdge) to a new branch for true zero-touch. The on-site tech racks it, it gets a DHCP lease and Internet — but it never calls home and stays unprovisioned. Likely cause The serial was added to the WAN Edge list in vManage, but no controller profile was created in the Cisco Smart Account PnP Connect. So when the cEdge reaches devicehelper.cisco.com, PnP Connect has nothing to tell it about which vBond/org to use. Diagnosis He's onboarding a cEdge, so the method is PnP — and PnP depends on a Smart Account controller profile, not just the vManage list. Cisco Software Central → Plug and Play Connect → Controller Profiles (confirm a profile maps to this vBond + org); then vManage → Configuration → Certificates → WAN Edge List → Send to Controllers Fix Create/confirm the PnP Connect controller profile (vBond address + organization-name), make sure the device's serial is associated to it, then re-trigger PnP with 'pnpa service discovery stop/start' (or reload). Ensure the WAN Edge list is pushed to controllers. Verify On the cEdge: show sdwan control connections shows vbond, vmanage and vsmart all in state 'up'; show sdwan control connections-history no longer logs the rejection. Quick check · Q3 of 10 Meera at HCL must onboard a vEdge at a site that has DHCP and Internet but is in a customer's air-gapped enclave that can't reach the public Cisco cloud. What's the cleanest method? a) Public PnP via devicehelper.cisco.com b) An on-prem ZTP server the edge resolves ztp.viptela.com to c) Nothing — air-gapped sites can't run SD-WAN d) Manually edit the vSmart certificate Correct: b. A vEdge uses ZTP, and ZTP works air-gapped if you stand up an on-prem ZTP server and make the edge resolve ztp.viptela.com to it. Public PnP needs the public Cisco cloud (devicehelper) which the enclave can't reach. SD-WAN absolutely runs air-gapped; editing the vSmart cert is unrelated. Pause & Predict Predict: a remote site has NO DHCP and the install happens before any WAN circuit is live. Which method must you use, and what file/field makes it work? Type your guess. Reveal answer Answer: Bootstrap (or fully manual). With no DHCP and no reachability, ZTP/PnP can't phone home. You generate a bootstrap config in vManage and place ciscosdwan.cfg (or ciscosdwan_cloud_init.cfg) on a USB/flash; the edge reads its vBond IP, org-name and system-IP from the file on boot. Manual console config of the system block does the same job. ## ④ 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. ### ▶ One edge climbing the join ladder Step through power-on to full overlay membership, then break it to see the classic failure. Press Play for the healthy path, then Break it to see the failure. ① vBond edge 10.0.1.1 opens DTLS to vBond 203.0.113.10 → cert + serial + org checked → introduced ▼ ② vManage edge forms control conn to vManage → pulls device template (full config) ▼ ③ vSmart edge connects to vSmart → OMP exchanges routes + TLOCs ▼ ④ Joined BFD tunnels form across MPLS + Internet → overlay member , traffic flows Press Play to step through the healthy path. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset 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. cEdge CLI — the first-look on a healthy edge show sdwan control connections Expected output 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 cEdge CLI — when it's down, read the history show sdwan control connections-history | include vbond|ERROR|CTORGNMMIS|CONACTREJ Expected output 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 Figure 4 — Onboarding ladder + show-command cheat-sheet A cheat sheet mapping the four onboarding rungs to their verification command. Rung one transport up, verify with show sdwan control local-properties. Rung two authenticate to vBond, verify with show sdwan control connections looking for vbond in state up. Rung three pull template from vManage, verify with show sdwan control connections for vmanage up. Rung four OMP to vSmart, verify with show sdwan omp peers. A side panel lists the common control connection error codes and the DTLS port 12346. The onboarding ladder — one show command per rung ① Transport up (VPN 0, default route, DHCP/static) show sdwan control local-properties ② Authenticate to vBond · Validator show sdwan control connections (vbond up) ③ Pull template from vManage · Manager show sdwan control connections (vmanage up) ④ OMP to vSmart · Controller → fabric joined show sdwan omp peers · show sdwan bfd sessions control-connection error codes CTORGNMMIS org-name mismatch CRTVERFL cert verify failed CONACTREJ serial not in list DCONFAIL DTLS blocked (FW/NAT) NOACTVBMS no active vBond VM_TMO vManage timeout SYSIPCHNG system-IP changed DTLS = UDP 12346 (port-hops 12346–13156) read connections-history Local/Remote Error first First-look rule: "control connections down" → read the HISTORY error code, don't guess show sdwan control connections-history | match the code above underlay/untrusted overlay/trusted control/policy key insight allowed/joined Your one-card reference: each rung of the join with the command that proves it, plus the error-code table and the DTLS port. Keep it open during your first onboarding and before any ENSDWI question. Pro tip — the two-question onboarding model For any onboarding task ask: (1) which platform? vEdge → ZTP/TPM/ztp.viptela.com · cEdge → PnP/SUDI/devicehelper.cisco.com · no cloud → bootstrap (ciscosdwan.cfg). (2) which rung failed? read show sdwan control connections-history and map the code: org-name (CTORGNMMIS), serial sync (CONACTREJ), firewall (DCONFAIL), cert (CRTVERFL), vBond reachability (NOACTVBMS). Almost every onboarding ticket lands on that grid. Prove you've got the onboarding model Take a real ask — "a new branch cEdge won't join; reachability is fine" — and walk it cold: platform → method (PnP, Smart Account controller profile), trust (cert + serial on the pushed WAN Edge list + matching org-name), the ladder (vBond→vManage→vSmart), and the first command ( show sdwan control connections-history to read the code). If you can do that without notes, you're ready for the SOC floor and the 300-415 Router-Deployment domain. Next: OMP — the Overlay Management Protocol Back: Cisco SD-WAN Controllers Deep-Dive Quick check · Q4 of 10 An onboarded edge shows vbond UP but vmanage and vsmart stuck in 'connect', and history logs VM_TMO. Reachability to all controller IPs is confirmed. What's the most likely first-look conclusion? a) The org-name is wrong — that would be CTORGNMMIS, fix it b) OMP is misconfigured on vSmart c) vBond authenticated the edge, but the control session to vManage is timing out — check firewall/port 12346 and vManage health/load toward the edge d) The certificate is invalid — reinstall it Correct: c. vbond UP means the trust gate (cert + serial + org) passed — so org-name and certificate are fine, ruling out CTORGNMMIS/CRTVERFL. VM_TMO with confirmed IP reachability points at the control session itself: a firewall dropping the DTLS port to vManage, or vManage being overloaded/unreachable on the control plane. OMP comes later (rung 3), so it isn't the first-look cause. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What actually decides vEdge vs cEdge? Why does one typo in org-name kill the whole join? I uploaded the WAN Edge list — why won't the edge join? When do I use bootstrap instead of ZTP/PnP? What's the very first command when control connections are down? What does vBond actually do during onboarding? Pre-curated from Cisco SD-WAN docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which controller does a brand-new WAN Edge authenticate to FIRST during onboarding? a) vSmart (Controller) b) vManage (Manager) c) vBond (Validator) d) Another WAN Edge Correct: c. vBond (the Validator) is the first controller a new edge meets: it authenticates the device (cert + serial + org-name) and introduces vManage and vSmart. vManage pushes the template and vSmart runs OMP — both later rungs. An edge never onboards via another edge. Q6 · Apply You're onboarding a Catalyst 8300 running IOS-XE SD-WAN at a site with DHCP and Internet, true zero-touch. Which method and cloud endpoint? a) PnP via devicehelper.cisco.com, with a Smart Account controller profile b) ZTP via ztp.viptela.com c) Bootstrap with ciscosdwan.cfg on USB d) Manual console config only Correct: a. IOS-XE SD-WAN = cEdge, and cEdge zero-touch is Plug-and-Play via devicehelper.cisco.com, which relies on a Cisco Smart Account controller profile. ZTP/ztp.viptela.com is the vEdge path; bootstrap and manual are for air-gapped/no-DHCP sites, not this zero-touch scenario. Q7 · Apply A new edge's cert is valid and its serial is in the WAN Edge list shown in vManage, but it gets CONACTREJ from vBond. What's the fix? a) Reinstall the device certificate b) Change the system-IP c) Open TCP 830 on the firewall d) Click 'Send to Controllers' so vBond/vSmart get the whitelist, then clear control connections Correct: d. CONACTREJ = vBond rejected the device, typically because the serial isn't on the controllers' whitelist yet. Uploading to vManage isn't enough — you must 'Send to Controllers' so vBond/vSmart learn the serial, then clear control connections. The cert is already valid, system-IP is unrelated, and 830 isn't the control-plane gate here. Q8 · Analyze An edge shows control connections down to ALL three controllers; history logs DCONFAIL on every peer. Org-name and certificate are confirmed correct. Most likely root cause? a) The organization-name is mismatched b) A firewall/NAT is blocking the DTLS control port (UDP 12346), so no control session can form c) OMP is misconfigured on vSmart d) The WAN Edge list wasn't pushed Correct: b. DCONFAIL = the DTLS connection itself failed to establish — classic firewall/NAT blocking UDP 12346 (and its hop range). It hits all peers equally because the transport, not identity, is broken. A mismatched org would be CTORGNMMIS; an unpushed list would be CONACTREJ; OMP is a later rung and wouldn't down vBond. Q9 · Analyze After onboarding, vbond shows 'up' but vmanage and vsmart sit in 'connect' with VM_TMO/VS_TMO in history. Controller IPs are pingable from the edge. What does this tell you? a) The trust gate (cert/serial/org) failed b) The device certificate is invalid c) The site-ID is duplicated d) vBond authenticated the edge, but the control sessions to vManage/vSmart are timing out — suspect the DTLS port to those controllers or controller load, not identity Correct: d. vbond 'up' proves the identity checks passed (cert + serial + org all good), so it isn't CTORGNMMIS/CRTVERFL. VM_TMO/VS_TMO with reachable IPs means the control sessions to those controllers time out — a port/firewall issue toward vManage/vSmart or controller overload. A bad cert or org would have stopped you at vBond. Q10 · Evaluate Two onboarding plans for a 200-site greenfield cEdge rollout: (A) ship boxes and bootstrap each one by USB on-site; (B) pre-register serials to a Smart Account controller profile and use PnP zero-touch, with the WAN Edge list pushed to controllers. Which is stronger and why? a) B — PnP zero-touch scales to 200 sites with no on-site typing; bootstrap forces a manual USB visit per site, slower and error-prone, and offers no real security gain when trust is still cert+serial+org b) A — USB bootstrap is more secure because it avoids the cloud c) A — bootstrap is the only method that works for cEdge d) Identical — pick by personal preference Correct: a. For a large cEdge rollout with cloud reachability, PnP zero-touch is the right call: register serials once, push the WAN Edge list, and boxes self-provision with no on-site config. Bootstrap means a USB visit per site (200 manual touches) with more chances for typos. Both rely on the same trust model, so bootstrap isn't 'more secure' — it's just slower; and bootstrap is a fallback, not the only cEdge method. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: In one line, why can a WAN Edge have perfect IP reachability to all controllers and still never join the fabric? Then compare to the expert version. Compare with expert answer Expert version: Because onboarding is a trust handshake, not routing — if the serial isn't on the synced whitelist (CONACTREJ), the org-name is off by a character (CTORGNMMIS), or the cert isn't trusted (CRTVERFL), vBond rejects the edge before OMP ever starts, no matter how clean the ping. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Onboarding (ZTP/PnP) at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary vEdge (Viptela OS) Original Viptela router running Viptela OS; cert in a TPM chip; onboards via ZTP. cEdge (IOS-XE SD-WAN) Cisco ISR/ASR/Catalyst-8000 on IOS-XE SD-WAN; cert in a SUDI chip; onboards via PnP. The default for new builds. system-IP / site-ID system-IP = unique /32 naming the device in the overlay (never reused); site-ID = number grouping all devices at one location. organization-name Text string naming the overlay; must be byte-identical on every controller and edge or you get CTORGNMMIS. WAN Edge list Signed file of chassis+serial numbers from PnP Connect, uploaded to vManage and pushed to vBond/vSmart as the whitelist. vBond (Validator) First controller a new edge meets; authenticates the device and introduces vManage + vSmart; reachable across NAT. ZTP Zero-Touch Provisioning for vEdge: DHCP + resolve ztp.viptela.com to learn vBond IP, org-name and root cert. PnP (Plug-and-Play) cEdge onboarding via devicehelper.cisco.com; a Cisco Smart Account controller profile maps the serial to your vBond/org. Bootstrap config Offline onboarding: vManage-generated ciscosdwan.cfg (or ciscosdwan_cloud_init.cfg) on USB/flash for air-gapped or no-DHCP sites. CTORGNMMIS Control-connection error: organization-name on the edge doesn't match the controllers. CONACTREJ Control-connection error: vBond actively rejected the edge — usually the serial isn't on the synced whitelist. DTLS / UDP 12346 The encrypted control transport SD-WAN uses; default UDP 12346, port-hops 12346–13156. #### 📚 Sources Cisco — “Cisco SD-WAN: WAN Edge Onboarding (Prescriptive Deployment Guide)” / WAN Edge Onboarding Deploy Guide (ZTP, PnP, bootstrap; ciscosdwan.cfg / ciscosdwan_cloud_init.cfg; TPM vs SUDI; WAN Edge list). cisco.com/c/dam/en/us/td/docs/solutions/CVD/SDWAN/sdwan-wan-edge-onboarding-deploy-guide-2020nov.pdf - Cisco — “Onboard New vEdge Device by SD-WAN ZTP Process” (Doc ID 220445): DHCP, resolve ztp.viptela.com, serial in PnP portal, attach config in vManage. cisco.com/c/en/us/support/docs/routers/vedge-router/220445-onboard-new-vedge-device-by-sd-wan-ztp-p.html - Cisco — “Troubleshoot SD-WAN Control Connections” (Doc ID 214509): show sdwan control connections / connections-history / local-properties; error codes CTORGNMMIS, DCONFAIL, CRTVERFL, CONACTREJ; Local/Remote Error columns; DTLS UDP 12346. cisco.com/c/en/us/support/docs/routers/sd-wan/214509-troubleshoot-control-connections.html - Cisco Community — “SD-WAN Routers: Troubleshoot Control Connections” & “Migrating from vEdge (Viptela OS) to cEdge (IOS-XE) and vice versa”: practitioner walkthrough of org-name/serial/whitelist failures and platform migration. community.cisco.com/t5/networking-knowledge-base/sd-wan-routers-troubleshoot-control-connections/ta-p/3813237 - Cisco — Catalyst SD-WAN Control Components Release 20.15.x (Jun 2026) & Cisco IOS XE Catalyst SD-WAN 17.15.x (Nov 2025) release notes; from Manager 20.18 ISR1100 defaults to IOS-XE — recent confirmation Cisco standardises on cEdge/IOS-XE. cisco.com/c/en/us/support/routers/sd-wan/products-release-notes-list.html - Cisco Learning Network — “300-415 ENSDWI Exam Topics” (Router Deployment ~20%: onboard WAN Edge via ZTP vs PnP vs bootstrap; controller deployment + certificate management). learningnetwork.cisco.com/s/ensdwi-exam-topics - The Network DNA (2026) — “Step-by-Step Troubleshooting for Control Connections on Cisco SD-WAN Routers”: state values (up/connect/challenge/tear_down), error-code mapping, clear sdwan control connections. thenetworkdna.com/2026/04/step-by-step-troubleshooting-for.html ### What's next? Your edge is now a fabric member talking to vSmart — but what is it actually saying? Next we open OMP, the BGP-like protocol that distributes every route, TLOC and service across the overlay. Next · OMP: the Overlay Management Protocol → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt