From ecfb73f4841fc5c905a25841e5ef96aa6ee08f99 Mon Sep 17 00:00:00 2001 From: medusa Date: Mon, 28 Jul 2025 14:38:44 -0500 Subject: [PATCH] Update tech_docs/networking/sdwan.md --- tech_docs/networking/sdwan.md | 97 +++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) diff --git a/tech_docs/networking/sdwan.md b/tech_docs/networking/sdwan.md index 6f89059..4c6c07b 100644 --- a/tech_docs/networking/sdwan.md +++ b/tech_docs/networking/sdwan.md @@ -95,6 +95,103 @@ Would you like a **sample config snippet** for any of these sections? --- +To **bring up an SD-WAN fabric**, you need to configure key components correctly. Below is a **concise, step-by-step breakdown** of the essentials, along with **critical design considerations**. + +--- + +### **1. Underlay Network (VPN 0 - Transport VPN)** +- **Purpose**: Handles **control-plane traffic** (OMP, DTLS/TLS tunnels between devices). +- **Key Configurations**: + - **Interfaces**: Assign WAN interfaces (e.g., MPLS, Internet, LTE) to VPN 0. + - **Routing**: + - Static routes (for simple setups). + - BGP/OSPF (for dynamic underlay routing in larger deployments). + - **TLOC Extensions**: Define public/private IPs for tunnel endpoints. +- **Design Considerations**: + - **Dual Underlay**: Use at least **two transport types** (e.g., MPLS + Internet) for redundancy. + - **TLOC Preference**: Prioritize cheaper/faster links (e.g., MPLS over LTE). + +--- + +### **2. Overlay Network (OMP Routing)** +- **Purpose**: Distributes routes and policies across the fabric. +- **Key Configurations**: + - **OMP (Overlay Management Protocol)**: Advertises routes between vSmart controllers and edges. + - **Route Policies**: Control which prefixes are shared (e.g., only corporate LAN routes). +- **Design Considerations**: + - **Route Aggregation**: Minimize prefixes advertised to vSmart (e.g., summarize branch LANs). + - **TLOC Redundancy**: Assign multiple TLOCs per route for failover. + +--- + +### **3. Service VPNs (VPN 1-511)** +- **Purpose**: Segments user/data traffic (e.g., VoIP, guest Wi-Fi). +- **Key Configurations**: + - **VRF Creation**: Define VPNs (e.g., `vpn 10` for corporate LAN). + - **Interface Assignment**: Assign LAN interfaces to the correct VPN. + - **Route Leaking**: If needed, allow controlled traffic flow between VPNs (via centralized policies). +- **Design Considerations**: + - **QoS Tagging**: Apply DSCP markings per VPN (e.g., EF for VoIP in `vpn 20`). + - **Security Policies**: Restrict inter-VPN communication (e.g., guest Wi-Fi in `vpn 30` can’t reach `vpn 10`). + +--- + +### **4. Internet Breakout (VPN 512)** +- **Purpose**: Local internet access (DIA) from branches. +- **Key Configurations**: + - **NAT & Firewall**: Enable NAT overload (PAT) for private→public IP translation. + - **PBR (Policy-Based Routing)**: Steer specific traffic (e.g., Zoom) to VPN 512. +- **Design Considerations**: + - **Security**: Apply **umbrella/ZTNA** for secure internet access. + - **Backup Path**: If VPN 512 fails, fall back to centralized internet via VPN 0. + +--- + +### **5. Management & Control Plane (VPN 0)** +- **Purpose**: Connects vEdges to controllers (vManage, vSmart, vBond). +- **Key Configurations**: + - **Controller IPs**: Ensure vEdges can reach vManage/vSmart/vBond over VPN 0. + - **Certificate Auth**: Use device certificates for secure onboarding. +- **Design Considerations**: + - **Out-of-Band (OOB) Management**: Use a separate OOB network for high availability. + - **Geo-Redundancy**: Deploy controllers in multiple regions. + +--- + +### **6. Security Policies** +- **Purpose**: Enforce traffic rules (e.g., blocking, inspection). +- **Key Configurations**: + - **Zone-Based Firewall**: Assign interfaces to zones (e.g., "inside," "outside"). + - **Application-Aware Policies**: Block high-risk apps (e.g., Tor, Netflix). +- **Design Considerations**: + - **Default-Deny**: Start with "deny all," then allow only needed traffic. + - **IPS/IDS**: Enable for internet-bound traffic (VPN 512). + +--- + +### **7. High Availability (HA)** +- **Design Considerations**: + - **Dual vSmarts**: Avoid single points of failure. + - **Active/Standby Edges**: Use VRRP for LAN-side HA. + - **Cloud Gateway Redundancy**: For cloud-onramp (e.g., AWS/Azure). + +--- + +### **Summary Checklist** +| **Step** | **Action** | **Critical Design Tip** | +|----------|-----------|-------------------------| +| **1. Underlay** | Configure VPN 0 interfaces & routing | Dual transports (MPLS + Internet) | +| **2. Overlay** | Set up OMP & route policies | Summarize routes to reduce overhead | +| **3. Service VPNs** | Define VPNs 1-511 & assign interfaces | Use QoS for VoIP/VC traffic | +| **4. Internet** | Configure VPN 512 for DIA | Add ZTNA/umbrella for security | +| **5. Management** | Ensure controllers are reachable via VPN 0 | OOB management for resiliency | +| **6. Security** | Apply firewall/IPS policies | Default-deny approach | +| **7. HA** | Deploy redundant controllers/edges | Active/standby for critical sites | + +Would you like a **sample config snippet** for any of these sections? + +--- + Yes, you're absolutely correct. In Cisco SD-WAN (formerly Viptela), **VPN 0** is indeed referred to as the **"front-door VRF" (FD-VRF)**. This is a critical concept in the architecture. Let me break down why it's special and how to properly configure it. ---