ExtremeCloud SD-WAN cheat sheet

Underlay vs overlay: the underlay is any IP transport (MPLS, internet, LTE/5G); the overlay is the encrypted tunnel mesh that carries policy-selected traffic independent of transport type.

Control plane vs data plane: a centralized controller/management plane distributes configuration and policy; forwarding of user traffic stays local at the branch appliance unless traffic is explicitly steered to a hub or gateway.

Key architecture roles: orchestration/management (configuration, templates, zero-touch), control (topology, path and policy distribution), and data forwarding (branch devices, hub/concentrator, cloud gateway).

Tunnel topology patterns: full mesh (direct branch-to-branch), hub-and-spoke (all branch traffic via hub), and partial mesh (per-policy direct paths plus hub for shared services) - topology is a policy outcome, not a fixed design.

Path selection depends on continuous link quality measurement (latency, jitter, packet loss, and often MOS/quality scores) per tunnel; SLA thresholds per application class drive forwarding decisions.

Encryption model: tunnels are secured with standards-based IPsec/DTLS-style encryption; keys and certificates are managed centrally, so adding a site does not require per-site crypto design.

Zero-touch provisioning relies on device identity: a serial number or hardware ID is pre-registered to a tenant/site, so the device authenticates to the orchestrator on first boot and pulls its configuration.

Segmentation: VRFs/segments (or equivalent tenant partitions) isolate address space and routing per business unit or guest network; policies and tunnels are scoped per segment.

Solution fit: SD-WAN replaces or augments hybrid WAN by using multiple cheap transports with per-application steering, while retaining centralized policy and visibility - not by simply bonding links.

Zero-touch flow: register device identity (serial/hardware key) in the orchestrator → assign to tenant and site → attach a template/stack → device boots, gets DHCP/DNS, reaches the controller over HTTPS → downloads config → tunnels form.

Prerequisites checklist before shipping hardware: site record created, WAN circuits and IP addressing (DHCP/static/PPPoE) documented, firewall/NAT allowing outbound management and tunnel ports, DNS resolvable, and time sync available.

Templates and device stacks: a stack bundles network, routing, and policy objects applied at site or device level; inheritance flows top-down, and local overrides must be used sparingly to keep audits simple.

Interface roles matter: a WAN interface carries underlay connectivity and tunnel endpoints; a LAN interface serves local subnets; a management interface may be separate to keep control traffic off the data path.

High availability options: dual-CPE at a site with VRRP/VRRP-like LAN gateway redundancy, and dual links per CPE for path diversity; verify failover timers and preemption behavior explicitly.

Cloud/hub gateways: deploy a virtual or hosted gateway in a region, peer it to the needed VPC/VNet, and confirm route propagation both directions before steering branch traffic to it.

Change safety: stage configuration in a template, preview the diff, apply to a lab or pilot site first, and keep a rollback plan (previous template version or config archive) per change window.

Licensing and capacity: confirm subscription tier covers the device model, throughput, and features (e.g., advanced security, cloud gateway) before cutover; mismatched licensing blocks features silently.

Cutover sequence: bring up new overlay in parallel, verify tunnels and path quality, migrate non-critical subnets first, then move default route and retire legacy circuits after monitoring period.

Route sources: static routes, connected subnets, dynamic routing (BGP/OSPF) over tunnels or LAN, and overlay-learned prefixes; longest-prefix match applies before policy steering decisions.

BGP over overlay: use per-transport or per-tunnel neighbors with distinct AS numbers to influence best-path selection; prefer overlay-learned routes over underlay defaults to keep traffic in policy scope.

Policy evaluation is ordered: match criteria (application, source/destination, segment, user/group, DSCP) are evaluated top-down, first match wins, so place specific rules above broad catch-alls and keep an explicit default rule.

Application identification: use signature/DPI-based app definitions plus IP/port and domain-based matching; verify the app is recognized on the deployed firmware before relying on it for steering.

Path selection actions: per-application SLA classes choose the best qualifying path, with fallback order (e.g., primary broadband → secondary broadband → LTE) and optional remediation such as FEC or replication for loss-sensitive traffic.

Breakout choices: local internet breakout for SaaS/cloud (low latency, less hub load) vs backhaul to hub for inspected or legacy-datacenter traffic; decide per application, not per site.

QoS pipeline: classify (app/DSCP) → mark → queue/schedule per tunnel; shaping must account for actual uplink bandwidth or queues will misbehave; verify DSCP preservation across the underlay.

Business policy vs network policy: business intent (app class + SLA) is translated into network rules; if intent and rule conflict, the explicit rule wins - document which layer owns each decision.

Verification: after policy changes, confirm flow matches expected rule ID, egress tunnel, and measured SLA; a rule that never matches usually indicates ordering or match-criteria error.

Dashboards to watch: per-site tunnel status and uptime, per-application SLA compliance, top talkers by application/segment, and path quality (latency/jitter/loss) per WAN link.

Alarm triage order: tunnel down → underlay reachability (ping/traceroute to peer public IP) → NAT/firewall port blocking → certificate/clock issues → policy or routing change.

Path-quality troubleshooting: compare measured latency/jitter/loss per link against the SLA class; if a link fails SLA, confirm the policy has a viable fallback and that the fallback tunnel is actually up.

Flow-level debugging: use flow tables/logs to confirm the matched policy, chosen path, NAT translation, and drop reason; absence of a flow entry often means routing, not policy, is at fault.

Common causes of tunnel flaps: ISP instability, MTU/fragmentation issues (test with large pings), asymmetric routing, duplicate public IPs behind NAT, and overloaded device CPU.

Logging and export: enable syslog/flow export to a collector for retention beyond the orchestrator's window; correlate timestamps across device, controller, and collector before drawing conclusions.

Change correlation: most incidents follow a change - check recent template, policy, or firmware pushes first, and compare current config against the last known-good archive.

Firmware management: read release notes for fixed defects affecting your features, upgrade pilot sites first, and confirm rollback image availability before fleet-wide upgrades.

Escalation data to collect: device serial, firmware, site, affected app/segment, timestamps, tunnel peer, flow details, and traceroutes from both ends - this shortens vendor triage substantially.