EVPN/VXLAN Monitoring Checklist: Find Fabric Problems Before Users Do

EVPN/VXLAN monitoring should answer one operational question quickly: is the problem in the transport underlay, the EVPN overlay, or the tenant service? Without that separation, a single application complaint can turn into a long hunt through BGP sessions, NVE state, MAC tables, firewall policy and endpoint behavior.

This practical guide builds a small but useful monitoring checklist for leaf-spine fabrics. It is aimed at network engineers running data center fabrics, AI/GPU pods, lab environments or SMB private clouds where a full commercial observability platform may not be available yet. For related design topics, see the Data Center hub, the AI Infrastructure page and the Start Here networking topics page.

X Follow @ipexptobe

Generic diagram derived from anonymized lab and operations notes; no customer identifiers or real addressing.

The problem: green devices, broken tenant traffic

A fabric can look healthy at the device level while a tenant still has broken east-west or north-south connectivity. Common examples include:

• All leaf-spine interfaces are up, but one VNI is missing on a leaf.
• BGP underlay is established, but EVPN route targets are not imported correctly.
• The anycast gateway answers ARP/ND locally, but the remote MAC/IP route is absent.
• Traffic reaches the border leaf, then fails because of firewall policy, route leaking or asymmetric return paths.
• A GPU or storage workload is reachable with small packets but fails with larger frames because the effective MTU is wrong.

The monitoring goal is not to collect every possible counter. The goal is to collect enough signals to locate the fault domain before users, application teams or backup jobs create noisy tickets.

Design: monitor the fabric in three layers

1. Underlay transport health

The underlay is the foundation. If the transport is unstable, overlay symptoms will be misleading. Track at least:

• Routing adjacency state between every leaf and spine.
• Expected ECMP path count per leaf.
• Interface errors, CRCs, discards, pause frames and queue drops.
• Optical power and transceiver alarms for critical uplinks.
• MTU probes between VTEP loopbacks, not only between directly connected interfaces.

A useful underlay alert says what changed: leaf-03 has 3 of 4 spine paths is better than BGP neighbor down. The first alert points to lost redundancy and possible hashing impact; the second forces the engineer to reconstruct context.

2. EVPN overlay control plane

EVPN adds another control-plane layer. Monitor it explicitly instead of assuming it is healthy because the underlay BGP session is up:

• EVPN peer state and remote VTEP discovery.
• VNI-to-VRF and VNI-to-VLAN mappings on every leaf that hosts the tenant.
• Route-target import/export consistency.
• EVPN route type counts: MAC/IP routes, IMET routes and prefix routes if using symmetric IRB.
• Duplicate MAC/IP events and MAC move rate per VNI.

For routing-heavy environments, it is also natural to connect this view with broader BGP monitoring. The BGP Table Watch page is a useful companion for thinking about routing-table trends and control-plane change visibility.

3. Tenant service checks

Control-plane checks are necessary but not sufficient. Add synthetic service probes from the same places where real traffic enters the fabric:

• Ping and TCP checks inside important VRFs.
• HTTP or API checks for management and automation platforms.
• DNS, NTP and authentication reachability for server segments.
• Jumbo-frame checks for storage, backup and AI training paths where MTU matters.
• North-south tests through firewalls or border leaves, including return-path validation.

Generic telemetry workflow derived from sanitized networking materials and lab notes.

Implementation workflow: start small, label everything

A good first implementation can be simple: SNMP or streaming telemetry for counters, syslog for events, API/CLI collection for EVPN state, and a small probe host per VRF or per fabric zone. The important part is consistent labeling.

# Example labels to normalize in your monitoring system
site="dc-lab"
fabric="fabric-a"
role="leaf"
device="leaf-01"
vrf="tenant-a"
vni="10100"
link_role="leaf-spine"

With labels in place, dashboards can answer operational questions instead of only showing device graphs:

• Which tenants are present on this leaf?
• Which VNIs lost a remote VTEP in the last hour?
• Did packet loss start before or after the MAC move burst?
• Is the issue limited to one VRF, one leaf pair, or the whole fabric?

Minimal collector checklist

Signal	Why it matters	Example alert
Underlay neighbor count	Detects lost fabric paths.	Leaf has fewer spine adjacencies than expected.
VTEP peer count	Detects overlay isolation.	Remote VTEP missing for tenant VNI.
MAC move rate	Finds loops, active/active issues or endpoint instability.	MAC moves exceed baseline for VNI 10100.
Tenant synthetic probe	Proves real service reachability.	VRF probe fails while underlay is green.
MTU probe	Finds hidden fragmentation or black-hole issues.	VTEP jumbo probe fails after change.

Verification and troubleshooting flow

When an alert fires, avoid jumping directly into endpoint debugging. Walk down the stack in a fixed order:

1. Confirm the tenant symptom. Which VRF, VNI, application or segment is affected?
2. Check underlay first. Neighbor count, ECMP count, interface errors, optics and MTU.
3. Check overlay second. VTEP peer, VNI mapping, route targets, EVPN route presence and MAC/IP learning.
4. Check service policy last. VRF routes, route leaking, ACLs, firewalls, NAT and endpoint gateways.
5. Compare with change history. A monitoring alert is much more useful when correlated with a fabric change, optic replacement or firewall policy update.

Generic troubleshooting flow derived from anonymized EVPN/VXLAN operational notes.

Practical takeaways

• Monitor EVPN/VXLAN as underlay, overlay and service layers; do not rely on interface-up status alone.
• Use synthetic tenant probes so you can detect broken user traffic even when the fabric control plane looks healthy.
• Normalize labels early: site, fabric, role, VRF, VNI and link role make dashboards far more useful.
• Alert on actionable deltas: missing VTEP, lower ECMP path count, MAC move spike or failed MTU probe.
• Keep dashboards boring and repeatable. The best monitoring view is the one an on-call engineer can use at 02:00 without guessing.

For more references and study links, see the Useful Networking, BGP and AI Resources page.

Follow Network freak for more networking notes, diagrams and troubleshooting tips.

X @ipexptobe on X