diff --git a/tech_docs/networking/sdwan_extras.md b/tech_docs/networking/sdwan_extras.md
index 906dc21..6dea162 100644
--- a/tech_docs/networking/sdwan_extras.md
+++ b/tech_docs/networking/sdwan_extras.md
@@ -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.