Update tech_docs/networking/sdwan.md
This commit is contained in:
@@ -1,3 +1,100 @@
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
Reference in New Issue
Block a user