Update tech_docs/networking/sdwan_extras.md
This commit is contained in:
@@ -1,3 +1,122 @@
|
||||
### **Deep Dive: The vBond Orchestrator in Cisco SD-WAN**
|
||||
The **vBond** is the **gatekeeper** and **orchestration brain** of Cisco SD-WAN (Viptela). It’s often misunderstood as "just another controller," but its role is critical for:
|
||||
1. **Initial authentication** (who gets into the overlay).
|
||||
2. **Control/management plane orchestration** (how devices talk to vSmart/vManage).
|
||||
3. **NAT traversal** (solving the "hidden behind a firewall" problem).
|
||||
|
||||
Let’s break it down **without vendor fluff**.
|
||||
|
||||
---
|
||||
|
||||
## **1. vBond’s Core Functions**
|
||||
### **A. First Point of Authentication**
|
||||
- **Think of it like a bouncer at a club**:
|
||||
- Every new WAN edge router (or controller) must **check in with vBond first**.
|
||||
- Validates:
|
||||
- Device certificate (is this a trusted router?).
|
||||
- Serial/chassis number (is it authorized by vManage?).
|
||||
- Only after passing checks can the device join the overlay.
|
||||
|
||||
**Key Command:**
|
||||
```bash
|
||||
show control connections # Verify vBond DTLS connection
|
||||
```
|
||||
|
||||
### **B. Orchestrating Control/Management Plane**
|
||||
- vBond **tells devices where to connect**:
|
||||
- "Here’s the list of vSmart controllers you need to talk to."
|
||||
- "Here’s the vManage’s address for policy/config."
|
||||
- Once devices connect to vSmart/vManage, the vBond steps back (its job is done).
|
||||
|
||||
**Why this matters:**
|
||||
- Without vBond, devices wouldn’t know **who to trust** or **where to get policies**.
|
||||
|
||||
---
|
||||
|
||||
## **2. vBond as a NAT Traversal Enabler (STUN Server)**
|
||||
### **The Problem:**
|
||||
- WAN edges behind NAT/firewalls **can’t see each other’s real IPs**.
|
||||
- BFD/data-plane connections **fail** because peers send traffic to private IPs (e.g., `10.10.10.1`) instead of public NAT IPs (e.g., `64.10.10.1`).
|
||||
|
||||
### **The Solution: vBond as a STUN Server**
|
||||
- **STUN** = Session Traversal Utilities for NAT.
|
||||
- vBond **discovers both private and public IPs** for each device.
|
||||
- How it works:
|
||||
1. Edge router behind NAT connects to vBond.
|
||||
2. vBond sees:
|
||||
- Private IP (e.g., `10.10.10.1`).
|
||||
- Public IP (e.g., `64.10.10.1`).
|
||||
3. vBond shares this mapping with **vSmart**, which distributes it to other edges.
|
||||
4. Now, peers know to send BFD/data traffic to the **public IP**.
|
||||
|
||||
**Key Command:**
|
||||
```bash
|
||||
show sdwan tloc | include NAT # Check NAT translations
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **3. vBond vs. Other Controllers**
|
||||
| **Controller** | **Role** | **Persistent Connection?** |
|
||||
|----------------|---------|----------------------------|
|
||||
| **vBond** | Authentication + NAT discovery | No (edges drop after setup) |
|
||||
| **vSmart** | OMP route reflection | Yes |
|
||||
| **vManage** | Policy/config | Yes |
|
||||
|
||||
**Critical Note:**
|
||||
- vBond **does not handle routing (OMP)** or **policy enforcement**—that’s vSmart/vManage’s job.
|
||||
- Its role is **temporary but essential** (like a network midwife).
|
||||
|
||||
---
|
||||
|
||||
## **4. Troubleshooting vBond Issues**
|
||||
### **Common Problems**
|
||||
1. **vBond DTLS Fails**
|
||||
- Cause: Certificate mismatch, firewall blocking UDP/12346.
|
||||
- Fix:
|
||||
```bash
|
||||
debug dtls events # Check handshake failures
|
||||
show control connections # Verify vBond reachability
|
||||
```
|
||||
|
||||
2. **NAT Traversal Broken**
|
||||
- Cause: vBond can’t see public IP (asymmetric NAT).
|
||||
- Fix:
|
||||
- Use `tloc-extension public-ip` (manual override).
|
||||
- Check STUN with `show sdwan stun translations`.
|
||||
|
||||
3. **vBond Not Syncing with vManage**
|
||||
- Cause: vManage hasn’t pushed device list to vBond.
|
||||
- Fix:
|
||||
```bash
|
||||
request vbond sync install # Force re-sync
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **5. Why vBond is Non-Negotiable**
|
||||
- **No vBond = No Overlay**: Devices can’t bootstrap.
|
||||
- **No STUN = No NAT Traversal**: Branch-to-branch tunnels fail.
|
||||
- **Scalability**: vBond lets you add controllers dynamically (no static configs).
|
||||
|
||||
**Pro Tip:** In small deployments, vBond can run on the same hardware as vSmart/vManage—but it’s still a **separate service**.
|
||||
|
||||
---
|
||||
|
||||
## **Final Verdict**
|
||||
The vBond is the **unsung hero** of Cisco SD-WAN:
|
||||
✅ **Gatekeeper**: Only authorized devices join.
|
||||
✅ **Orchestrator**: Tells devices where to go.
|
||||
✅ **NAT Whisperer**: Makes sure BFD/data flows work.
|
||||
|
||||
**If you ignore vBond, your overlay will fail.**
|
||||
|
||||
*(And yes, Cisco TAC will ask for `show tech vbond` first.)*
|
||||
|
||||
**Question for you:** Ever seen a vBond STUN failure break an entire deployment? How’d you fix it? 🕵️♂️
|
||||
|
||||
---
|
||||
|
||||
Great follow-up! You're absolutely right—**traffic is traffic**, and if you can classify it (VoIP, O365, CRM, etc.), why does the SD-WAN platform matter? Why move from something simple like **Meraki Auto-VPN** to a more complex solution like **Viptela (Cisco SD-WAN)**?
|
||||
|
||||
The answer lies in **granularity of control, scalability, and architectural fit**—not just traffic classification. Let’s break it down critically.
|
||||
|
||||
Reference in New Issue
Block a user