ExtremeCloud SD-WAN flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Underlay network

The physical or virtual IP transport paths - MPLS, broadband internet, LTE/5G - that carry encrypted overlay tunnels. SD-WAN policy operates on top of whatever underlay links exist at a site.

Overlay tunnel

An encrypted logical connection between SD-WAN devices that runs over one or more underlay links. It carries policy-selected traffic and hides transport differences from applications and routing.

Full mesh topology

A tunnel design where every site can reach every other site directly. It minimizes branch-to-branch latency but requires each device to maintain many tunnels and scale accordingly.

Hub-and-spoke topology

All branch traffic is forwarded through a central hub device. Useful for centralized inspection and legacy services, but adds latency and concentrates bandwidth demand at the hub.

Path quality metrics

Continuous measurements of latency, jitter, and packet loss per WAN link, often combined into a quality or MOS score. These metrics drive per-application path selection decisions.

Zero-touch provisioning

A deployment model where a pre-registered device authenticates to the orchestrator on first boot and downloads its full configuration automatically, requiring no on-site CLI work.

Device stack

A layered bundle of network, routing, and policy configuration applied to a device or site. Higher layers inherit downward, and local overrides should be limited for auditability.

Site record

The orchestrator object representing a physical location, holding address, contact, WAN circuit details, and device assignments. It must exist before hardware can be claimed and configured.

Dual-CPE high availability

Two appliances at one site sharing a LAN gateway via a redundancy protocol such as VRRP. If one fails, the peer assumes the gateway address and keeps tunnels available.

Cloud gateway

A virtual or hosted SD-WAN endpoint in a cloud region that terminates branch tunnels and peers with the cloud network. It enables local breakout to cloud workloads without hub backhaul.

Configuration rollback

Restoring a previously known-good template version or archived configuration after a failed change. Confirm the rollback path exists before applying changes to production sites.

Cutover parallel run

Bringing up the new overlay alongside legacy circuits, validating tunnels and path quality, then migrating subnets and default routes gradually before retiring old links.

Licensing capacity check

Verifying the subscription tier supports the device model, required throughput, and features such as advanced security or cloud gateways. Mismatches can silently disable capabilities.

First-match policy evaluation

Policies are evaluated top-down and the first matching rule wins. Specific rules must precede broad catch-alls, and an explicit default rule should always exist.

Application identification

Matching traffic to an application using signatures, IP/port, or domain information. Confirm the application is recognized on the deployed firmware before steering depends on it.

SLA class

A named set of latency, jitter, and loss thresholds assigned to an application category. Path selection picks links that satisfy the class and falls back when none qualify.

Local internet breakout

Sending SaaS and cloud-bound traffic directly out a branch internet link instead of backhauling to a hub. It reduces latency and hub load but may bypass centralized inspection.

BGP over overlay

Running BGP peering across SD-WAN tunnels, often with per-tunnel neighbors and distinct AS numbers, to advertise prefixes and influence best-path selection between sites.

QoS marking and queuing

Classifying traffic, setting DSCP, and scheduling it into queues per tunnel. Shaping must reflect real uplink bandwidth, and DSCP should be preserved across the underlay.

Business intent policy

A high-level statement pairing an application category with required SLA and preferred paths. It is translated into concrete network rules, with explicit rules taking precedence on conflict.

Path fallback order

The ranked list of links a policy tries when the preferred path fails its SLA, such as primary broadband, then secondary broadband, then LTE. Each fallback must have a live tunnel.

Segment or VRF isolation

Logical partitioning of address space and routing per business unit, guest, or tenant. Policies and tunnels are scoped to a segment so traffic cannot leak across partitions.

Tunnel status dashboard

A view showing per-site tunnel up/down state and uptime. It is the first check when users report connectivity issues, quickly separating overlay from underlay faults.

Underlay reachability test

Pinging and tracing to the peer's public IP to prove the transport path works before investigating tunnel or policy causes. Failure here points to ISP or firewall issues.

Flow table inspection

Examining per-flow entries for matched policy, chosen egress path, NAT translation, and drop reason. Missing entries usually indicate a routing problem rather than a policy problem.

MTU and fragmentation

Oversized packets plus tunnel encapsulation can cause silent drops and flapping tunnels. Test with large, don't-fragment pings and adjust interface or tunnel MTU accordingly.

SLA compliance report

A per-application view comparing measured latency, jitter, and loss against the assigned SLA class. It shows whether steering decisions and fallbacks are working as designed.

Change correlation

Checking recent template, policy, or firmware pushes first when an incident appears, since most outages follow a change. Compare current configuration with the last known-good archive.

Syslog and flow export

Sending device logs and flow records to an external collector for retention beyond the orchestrator window. Align timestamps across sources before correlating events.

Firmware upgrade sequencing

Reading release notes for relevant fixes, upgrading pilot sites first, and confirming a rollback image is available before pushing firmware to the wider fleet.

Tunnel flap causes

Recurring tunnel drops commonly stem from ISP instability, MTU or fragmentation problems, asymmetric routing, duplicate public IPs behind NAT, or device CPU overload.

Escalation evidence bundle

Device serial, firmware, site, affected application and segment, timestamps, tunnel peer, flow details, and traceroutes from both ends. Complete evidence shortens vendor triage considerably.