medusa/the_information_nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
56d7284c9f0cb2e5b15500dd9514c07b663c1cbe
the_information_nexus/tech_docs/networking/sdwan.md

20 KiB
Raw Blame History

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.

Key Characteristics of VPN 0 (Front-Door VRF)

  1. Transport-Only VPN:

    • Exclusively handles control-plane traffic (vBond, vSmart, vManage connections).
    • Carries encrypted data-plane traffic (IPsec/GRE tunnels between edges).
    • Does not carry user traffic (that goes in VPN 1, VPN 2, etc.).

  2. Mandatory for SD-WAN Operation:

    • Every SD-WAN router must have VPN 0 configured.
    • If VPN 0 fails, the device loses connectivity to controllers and other edges.

  3. Uses Physical/Tunnel Interfaces:

    • Physical WAN interfaces (e.g., Gig0/1) are assigned to VPN 0.
    • Tunnel interfaces (e.g., Tunnel1) are also part of VPN 0 for overlay traffic.

CLI Configuration Deep Dive (VPN 0)

Let’s expand on your earlier config with more details:

1. Physical Interface in VPN 0

vpn 0
 interface GigabitEthernet0/1
  ip address 192.168.1.2/24     # Branch 1 (Primary WAN)
  tunnel-interface              # Marks this as an SD-WAN transport
   color private1               # Used for QoS/policy matching (e.g., MPLS)
   allow-service all            # Permits control traffic (DTLS, IPsec)
  exit
 exit

Explanation:

  • color private1 (or biz-internet, metro-ethernet, etc.) defines the WAN type for policies.
  • allow-service all permits vBond/vSmart/vManage connections (critical!).

2. Tunnel Interface (Overlay) in VPN 0

vpn 0
 interface Tunnel1
  tunnel-interface
   encapsulation ipsec          # Mandatory for secure overlay
   color private1               # Must match physical interface color
   no shutdown
  exit
 exit

Why Tunnel in VPN 0?

  • The tunnel carries control traffic (DTLS to controllers) and data-plane traffic (IPsec to other edges).
  • No user data passes here—only SD-WAN-encapsulated packets.

3. Static Route (For Controller Reachability)

router static
 vpn 0
  0.0.0.0/0 192.168.1.1        # Default route (WAN gateway)
  # Optional: Static route for controllers if not using default
  203.0.113.1/32 192.168.1.1   # vBond controller
 exit

Critical Checks:

  • Can the router ping the vBond IP? (ping vpn 0 203.0.113.1)
  • Is the route present? (show sdwan control local-properties)

4. Verification Commands

show sdwan control connections      # Are vSmart/vBond connections UP?
show sdwan tunnel                   # Are IPsec tunnels established?
show interface Tunnel1              # Is the tunnel operational?
show route vpn 0                    # Are WAN routes correct?

Common Mistakes in VPN 0 Setup

  1. Missing allow-service: Blocks control traffic (device won’t onboard).
  2. Wrong color: Policies won’t match (e.g., private1 vs mpls).
  3. No route to vBond: Device can’t join the overlay.
  4. Firewall blocking UDP/12346 (DTLS): SD-WAN control won’t establish.

Next Steps

Once VPN 0 is working (controller connectivity is UP), we can move to:

  • VPN 1 (Data VRF): Where user traffic lives.
  • Policies: Centralized rules for traffic steering, QoS, etc.

Would you like to dive deeper into any of these areas?

Absolutely! Let’s break down SD-WAN’s three planes in detail—covering protocols, traffic flows, security, and real-world deployment considerations.

1. SD-WAN Management Plane

Purpose:

  • Centralized device provisioning, monitoring, and policy enforcement.
  • Handles initial bootstrap, config push, telemetry, and analytics.

Key Components:

Component Protocol Port Description
vManage HTTPS (WebUI) TCP/443 GUI/API for centralized control.
vBond DTLS UDP/23456 Orchestrator for device authentication and tunnel setup.
Zero-Touch Provisioning (ZTP) DHCP/HTTPS - Auto-configures devices out-of-the-box.

Traffic Flow:

  1. Onboarding:
    • Device contacts vBond (DTLS) → gets redirected to vManage.
    • Downloads config/CSR via HTTPS.
  2. Ongoing Management:
    • Devices send telemetry (metrics, logs) to vManage.
    • Policies (security, routing) are pushed from vManage.

Security Considerations:

✔ Always use FVRF (isolate management traffic).
✔ Mutual TLS (mTLS) for device-vManage communication.
✔ Role-Based Access Control (RBAC) in vManage.

2. SD-WAN Control Plane

Purpose:

  • Distributes reachability info (routes, policies, topology) between devices.
  • Decides path selection (based on SLA, jitter, loss).

Key Protocols:

Protocol Function Port
OMP (Overlay Management Protocol) Advertises routes, TLOCs, policies. DTLS/UDP/40322
BGP (optional) Legacy WAN integration. TCP/179
TLOC Extension Maps physical WAN links to logical tunnels. -

How OMP Works:

  1. vSmart controllers act as route reflectors for OMP.
  2. Edge devices (vEdges) send:
    • Routes (prefixes learned from LAN/WAN).
    • TLOCs (tunnel endpoints, e.g., public-IP:color).
    • Policies (e.g., "prefer MPLS for VoIP").
  3. vSmart redistributes this info to all edges.

Example OMP Route Advertisement:

vEdge# show omp routes  
RECEIVED ROUTES:  
Prefix       TLOC IP         Color       Preference  
10.1.1.0/24  203.0.113.1     mpls        100  
10.1.1.0/24  198.51.100.1    biz-internet 50

(MPLS is preferred over Internet due to higher preference.)

Security Considerations:

✔ DTLS encryption for OMP (no cleartext control traffic!).
✔ Control-plane policing (CoPP) to prevent floods.
✔ Private WAN links (MPLS) for critical control traffic.

3. SD-WAN Data Plane

Purpose:

  • Forwards actual user traffic (VoIP, video, web) over optimal paths.

Key Technologies:

Technology Role
IPsec/GRE Encrypted tunnels between edges.
TLOC (Transport Locator) Logical tunnel endpoint (e.g., public-IP:color).
Application-Aware Routing (AAR) Dynamically switches paths based on SLA.

Data Flow Example:

  1. Traffic arrives at vEdge:
    • Classified via DPI (Deep Packet Inspection).
    • Tagged with QoS markings (DSCP).
  2. Path Selection:
    • Checks OMP-learned TLOCs and SLA metrics.
    • Chooses best path (e.g., MPLS for VoIP, Internet for web).
  3. Encapsulation:
    • Wrapped in IPsec (ESP/AH) or GRE.
    • Sent to peer vEdge via WAN (MPLS/Internet/5G).

Packet Walkthrough:

  1. Original Packet: 
    SRC: 10.1.1.100 (LAN) | DST: 8.8.8.8 (Internet)
  2. After SD-WAN Processing: 
    [IPsec][GRE][SD-WAN Header][Original Packet]  
SRC: 203.0.113.1 (vEdge Public IP)  
DST: 198.51.100.2 (Peer vEdge Public IP)

Security Considerations:

✔ IPsec (AES-256-GCM, IKEv2) for all tunnels.
✔ Zone-Based Firewall on vEdges.
✔ SLA-based DDoS protection (drop jitter/lossy links).

Summary Table: SD-WAN Planes Compared

Plane Components Protocols Security Measures
Management vManage, vBond HTTPS, DTLS FVRF, mTLS, RBAC
Control vSmart, OMP DTLS/OMP, BGP CoPP, DTLS, Private WAN
Data vEdges, TLOCs IPsec, GRE IPsec, AAR, QoS

Key Takeaways

  1. Management Plane = “The brain” (vManage pushes configs).
  2. Control Plane = “The nervous system” (OMP shares routes/policies).
  3. Data Plane = “The muscle” (IPsec tunnels move packets).

Critical Best Practices:

  • Isolate management (FVRF + private network).
  • Encrypt control traffic (OMP over DTLS).
  • Monitor SLA metrics for dynamic failover.

Would you like a deep dive into troubleshooting OMP routes or IPsec tunnel debugging? Let me know! 🔍

Yes! You're absolutely right to categorize them this way. In modern networking (especially with overlay technologies like VXLAN, SD-WAN, and MPLS), we deal with three distinct planes, each serving a critical role:

1. Management Plane

  • Purpose: Controls device access and monitoring (SSH, SNMP, HTTPS, syslog, etc.).
  • Key Traits:
    • Should be isolated (FVRF, OOB management like iLO/DRAC).
    • Often runs over dedicated interfaces or VRFs.
    • Example: 
      vrf definition MGMT  
 rd 65000:999  
!  
interface GigabitEthernet0/0  
 vrf forwarding MGMT  
 ip address 192.168.1.1 255.255.255.0
      (FVRF ensures management traffic never mixes with data/control planes.)

2. Control Plane

  • Purpose: Handles protocols that build network intelligence (BGP, OSPF, VXLAN EVPN, SD-WAN OMP, STP, LACP, etc.).
  • Key Traits:
    • Distributes reachability info (routes, tunnels, topology).
    • Runs on the CPU (software-based) and is vulnerable to floods (e.g., BGP attacks).
    • Can be placed in a separate VRF (but not FVRF!).
    • Example: 
      vrf definition CONTROL_PLANE  
 rd 65000:100  
!  
router bgp 65000  
 address-family ipv4 vrf CONTROL_PLANE  
  neighbor 10.0.0.2 remote-as 65000
      (BGP in a VRF—keeps control traffic logically isolated.)

3. Data Plane (Forwarding Plane)

  • Purpose: Moves user traffic (packets/frames) at line rate (hardware-accelerated).
  • Key Traits:
    • ASIC/switch-chip driven (not CPU).
    • Doesn’t care about routes/tunnels—just forwards based on FIB/TCAM.
    • Examples:
      • VXLAN data traffic (UDP 4789).
      • MPLS-labeled packets.
      • SD-WAN data flows.

Why This Separation Matters

Plane Runs On Isolation Needed? Risks if Compromised
Management CPU Yes (FVRF/OOB) Total device takeover
Control CPU Yes (VRF/CoPP) Network meltdown (BGP hijacks, loops)
Data ASIC No (but ACLs help) Performance drops (DDoS), but no config access

Common Misconceptions

  1. "Control Plane = Management Plane" → No!

    • Control Plane: BGP, OSPF, VXLAN EVPN.
    • Management Plane: SSH, SNMP.
    • (They’re both CPU-based but serve different purposes.)

  2. "FVRF Can Carry BGP/VXLAN" → No!

    • FVRF is only for management (per Cisco’s design).
    • BGP/VXLAN go in normal VRFs (or a dedicated control-plane VRF).

  3. "Data Plane Needs a VRF" → Usually No.

    • Data traffic follows the FIB (built by the control plane).
    • VRFs for data are tenant isolation (MPLS VPNs, multi-tenancy).

Real-World Use Cases

  1. SD-WAN

    • Management: vManage (HTTPS).
    • Control: OMP (Overlay Management Protocol).
    • Data: Encrypted tunnels (IPsec/GRE).

  2. VXLAN EVPN

    • Management: SSH to switches.
    • Control: BGP EVPN (MAC/IP routing).
    • Data: VXLAN-encapsulated traffic.

  3. Service Provider MPLS

    • Management: TACACS+ for routers.
    • Control: LDP/RSVP (label distribution).
    • Data: Label-switched packets.

Key Takeaways

  1. Management Plane = Your remote admin access (FVRF/OOB).
  2. Control Plane = Protocols that build the network (BGP, EVPN, OSPF).
  3. Data Plane = Raw packet forwarding (ASIC-driven, no intelligence).

Final Thought

The industry’s failure to physically separate all three planes (like servers do with iLO) is a security flaw. But until vendors fix it:

  • Use FVRF for management.
  • Use VRFs/CoPP for control-plane isolation.
  • Trust ASICs for the data plane.

Would you like a deep dive into protecting the control plane (CoPP, BGP hardening, etc.)? I can break it down. 🔐

Front-Door VRF (FVRF) Explained (Using Cisco Gear)

Front-Door VRF (FVRF) is a Cisco feature that enhances security by separating the management plane from the data plane in network devices (routers, switches, firewalls). It achieves this by placing the management interface (SSH, SNMP, HTTPS, etc.) in a separate Virtual Routing and Forwarding (VRF) instance, isolating it from the default routing table.

Why Use Front-Door VRF?

  1. Security: Prevents unauthorized access to management interfaces via data-plane attacks.
  2. Isolation: Ensures management traffic doesn’t mix with production traffic.
  3. Multi-Tenancy: Useful in service provider environments where management traffic must be segregated per customer.
  4. Simplified Routing: Avoids route conflicts between management and data networks.

How FVRF Works

  • The management interface (Mgmt0/0) is assigned to a dedicated VRF (e.g., MGMT-VRF).
  • All management traffic (SSH, SNMP, etc.) must go through this VRF.
  • The data plane (regular traffic) uses the default global routing table or other VRFs.

Configuration Example (Cisco IOS-XE / IOS)

1. Create the Management VRF

configure terminal
vrf definition MGMT-VRF
 rd 100:1  ! Route Distinguisher (for uniqueness)
 address-family ipv4
 exit-address-family
exit

2. Assign the Management Interface to the VRF

interface GigabitEthernet0/0
 description Management Interface
 vrf forwarding MGMT-VRF
 ip address 192.168.1.1 255.255.255.0
 no shutdown
exit

3. Configure a Default Route for Management Traffic

ip route vrf MGMT-VRF 0.0.0.0 0.0.0.0 192.168.1.254

(Where 192.168.1.254 is the gateway for management traffic.)

4. Enable VRF-Aware Services

ip http server
ip http vrf MGMT-VRF  ! Ensures HTTP/HTTPS uses the MGMT-VRF

line vty 0 4
 transport input ssh
 vrf-alias MGMT-VRF enable  ! Ensures SSH uses the MGMT-VRF
exit

Verification

  • Check VRF routing table: 
    show ip route vrf MGMT-VRF
  • Verify interface assignment: 
    show vrf brief
  • Test connectivity: 
    ping vrf MGMT-VRF 192.168.1.254

Key Considerations

  • NTP & DNS: If management relies on NTP/DNS, ensure they are reachable via the FVRF.
  • Backup Access: Always maintain an alternative access method (console) in case of misconfiguration.
  • Compatibility: Some older Cisco devices may not support all VRF-aware services.

Conclusion

Front-Door VRF is a best practice for securing management traffic in Cisco environments. By isolating management interfaces in a separate VRF, you reduce attack surfaces and prevent unauthorized access through data-plane vulnerabilities.

Would you like a more advanced example (e.g., with NAT or ACLs)? Let me know!