EVPN/VXLAN Lab First: Build a Cisco IOS XE Fabric Before Touching Production
Tech GuruYes, but the lab should rehearse the production failure modes, not just prove that a sample config pastes cleanly. Build a small spine-leaf topology, validate underlay reachability, bring up BGP EVPN, map VLANs to VNIs, test integrated routing and bridging, break links intentionally, and document the checks that must pass before production.
Operating principle: Prove the underlay first, inspect EVPN routes rather than neighbor state alone, and treat virtual CAT 9000v results as control-plane evidence rather than hardware performance evidence.
The Short Version
- EVPN/VXLAN has two networks to understand: the underlay that moves IP packets and the overlay that carries tenant segments.
- Cisco CML and virtual images are useful for control-plane learning, but do not use virtual throughput as a production performance claim.
- A good lab validates route types, VTEP reachability, MAC/IP learning, anycast gateway behavior, and external handoff.
The Reader Question
Can I test EVPN/VXLAN safely before deploying it in production?
This guide is for engineers who understand VLANs, IP routing, and BGP but have not operated an Ethernet VPN (EVPN) and Virtual Extensible LAN (VXLAN) fabric. You need legal access to supported Cisco software, enough compute for the chosen images, test hosts, an addressing/VNI plan, and a hardware pilot for forwarding and scale. The outcome is a repeatable verification and rollback runbook, not a paste-ready universal configuration.
Before You Start: Safe Defaults
- Choose the intended Catalyst platform first and read its exact IOS XE feature restrictions, scale tables, release notes, licensing, and recommended release guidance.
- Use only images you are entitled to run. Cisco's CML CAT 9000v image is beta and its documented tested-feature list does not establish EVPN/VXLAN support.
- Use a topology that mirrors the production roles: spines, leaves, border, tenants, route reflectors if any, and external routing.
- Separate underlay, EVPN control plane, VXLAN data plane, tenant policy, and external handoff checks.
- Back up lab definitions and production candidates, and keep out-of-band access plus known-good device configurations for the hardware pilot.
- Test failure before production: leaf uplink loss, spine loss, VTEP reachability loss, wrong VNI/route-target mapping, and border-policy error.
Reference Model
The model below puts prerequisites in the correct order: stable underlay, reachable VTEP loopbacks, EVPN exchange, tenant mappings, forwarding, failure, then production evidence. Open each step and attach the matching commands and expected outputs for your exact platform and release.
Decision Matrix
| Choice | Best Fit | Watch Point |
|---|---|---|
| Two leaf/two spine lab | Concept validation and command practice | Limited scale and feature coverage. |
| CML virtual fabric | Repeatable control-plane learning | Virtual dataplane limits; not throughput evidence. |
| Hardware pilot | ASIC, TCAM, optics, and real cabling behavior | Cost and change risk. |
| Production rollout without lab | Almost never justified | Troubleshooting starts after users are affected. |
Underlay Before Overlay
If loopbacks cannot reach each other reliably, stop. Validate routed underlay adjacency, equal-cost multipath (ECMP), failure convergence, maximum transmission unit (MTU), and every VTEP loopback from every leaf before adding the overlay. Check both directions and with a payload that exposes an undersized path; a small ping is not an MTU test.
The overlay carries tenant segments through VXLAN Network Identifiers (VNIs). VXLAN uses a 24-bit VNI field and the IANA-assigned UDP destination port 4789. EVPN carries reachability in BGP: for a basic rehearsal, inspect MAC/IP Advertisement routes (Route Type 2), Inclusive Multicast Ethernet Tag routes (Route Type 3), and IP Prefix routes (Route Type 5) where the design uses them. Record each VLAN, bridge domain, VRF, Layer 2 VNI, Layer 3 VNI, route distinguisher, and import/export route target in one table.
What to Verify
A production rehearsal should include platform-appropriate show commands for BGP EVPN neighbors and address-family state, route types, MAC/IP learning, VTEP reachability, Network Virtualization Edge (NVE) peers, VLAN/VNI and VRF mappings, anycast-gateway state, and external route exchange. Save parsed or timestamped known-good output so the production window has a baseline.
- Underlay routes and path MTU to every VTEP loopback through each expected ECMP path.
- EVPN neighbors established with the correct address family and expected Route Type 2/3/5 entries.
- Tenant hosts learn local and remote MAC/IP entries without unresolved duplicates or unexplained moves.
- Same-subnet bridging and routed inter-subnet traffic work from local and remote leaves.
- Anycast gateway identity is consistent on every participating leaf.
- Unknown-unicast/BUM handling matches the chosen ingress-replication or multicast design.
- External handoff imports and advertises only intended prefixes and cannot leak one tenant into another.
Production Readiness
As of this fact check, Cisco publishes Catalyst 9300 EVPN/VXLAN guidance for IOS XE 17.18.x and release notes through 17.18.3. That is article context, not a blanket recommendation. Before production, confirm your exact model, ASIC, TCAM profile, supported/recommended release, caveats, feature interactions, scale, multicast or ingress-replication choice, MTU, redundancy, monitoring, and rollback. The 17.18 guide itself documents feature-specific restrictions, including integrated routing and bridging constraints that differ by gateway design.
A Practical Pilot Scenario
Build two spines, two leaves, one border or external router, and two test hosts. If the available virtual image does not document the required EVPN/VXLAN feature, use a supported alternative or move that test to hardware; do not infer support because the CLI accepts part of the configuration. Use one VRF, one routed subnet, and one bridged subnet before adding multitenancy.
The pilot passes when every layer has positive and negative evidence: underlay survives one path loss, expected EVPN routes appear and an incorrect route target is caught, hosts communicate only as policy allows, a border filter blocks an unauthorized prefix, and the known-good state can be restored. Measure convergence for comparison, but do not turn virtual timing into a production service-level claim.
Implementation Details
Build and validate one layer at a time. Save a checkpoint after the underlay, another after EVPN adjacency, and another after the first tenant. When a check fails, return to the last checkpoint instead of changing multiple route targets, VNIs, and policies at once.
- Record exact platform, image, release, license, feature-support, resource, and topology assumptions.
- Build two spines, two leaves, a border/external router, and host-facing links with unique underlay and loopback addresses.
- Validate adjacency, loopback routing, ECMP, path MTU, failure convergence, and management access.
- Enable the EVPN address family and confirm neighbor capabilities plus expected Route Type 3 exchange before attaching hosts.
- Map one VLAN/VRF/Layer 2 VNI/Layer 3 VNI set and verify route distinguishers and route targets.
- Verify local and remote MAC/IP learning, same-subnet bridging, anycast gateway, routed tenant traffic, and negative isolation tests.
- Attach the external handoff and prove import/export policy with an intentionally unauthorized test route.
- Fail each uplink and one node role, record control-plane and service effects, then restore the known-good checkpoint.
- Repeat forwarding, optics, scale, and platform-specific tests on representative hardware before production approval.
Evidence and Testing Method
- Status: documentation-backed. TechGeeks reviewed Cisco IOS XE 17.18 Catalyst 9300 guidance, 17.18.3 release notes, Cisco CML CAT 9000v limitations, and the relevant IETF RFCs. No original EVPN/VXLAN lab or hardware throughput test was performed for this draft.
- Capture the topology, addressing/VNI matrix, configurations, software/image identifiers, resource allocation, feature-support references, and command-output timestamps.
- Save underlay routes, EVPN summaries and route tables, NVE peers, MAC/IP tables, VRF routes, packet/path tests, and external policy results before and after each failure.
- Use test hosts on different leaves, test both permitted and denied paths, and distinguish control-plane convergence from application recovery.
- For hardware acceptance, add interface counters, optics, queue drops, CPU/memory, TCAM/scale usage, and traffic-generator results appropriate to the service objective.
Security and Recovery Boundaries
A wrong route target, route-map, or external redistribution policy can cross tenant boundaries or leak infrastructure routes. Limit management-plane access, authenticate routing sessions where supported and operationally appropriate, protect configuration artifacts, and test denied paths as first-class requirements. The fabric does not replace host firewalls, identity controls, or application encryption.
For a hardware pilot, stage the previous configuration, console/OOB access, and a rollback trigger before enabling an overlay or external handoff. Roll back in reverse dependency order: stop new external advertisements, detach or disable the pilot tenant, restore route policies and VNI mappings, and return to the known-good underlay. If management reachability is lost, use console recovery rather than adding speculative overlay changes.
Validation Checklist
- Every VTEP loopback is reachable through the underlay.
- EVPN neighbors are established and route tables contain expected entries.
- Hosts in the same tenant communicate across leaves.
- Inter-VRF or external routing works only where intended.
- Failure tests are documented with before/after command output.
Maintenance Cadence
- Per change: compare the addressing/VNI/route-target matrix to rendered configuration and run positive plus negative path tests.
- Monthly: review neighbor resets, MAC moves, NVE peer changes, route-target drift, interface errors, and capacity trends.
- Quarterly: fail one redundant path in a controlled window and verify the alert, convergence, service impact, and rollback procedure.
- Before upgrades: recheck platform release notes, restrictions, caveats, licensing, ROMMON/compatibility requirements, and lab-image parity.
Troubleshooting
| Symptom | Likely Cause | First Check |
|---|---|---|
| EVPN neighbor down | Underlay reachability, ASN, update-source, or policy mismatch | Check loopback reachability and BGP neighbor details. |
| Host cannot reach remote leaf | VLAN/VNI/VRF mapping or MAC learning issue | Check NVE peers, MAC/IP routes, and VLAN membership. |
| External routing leaks too much | Route-target, redistribution, or policy error | Inspect VRF route tables and outbound policy. |
Common Mistakes
- Configuring overlay before underlay reachability is boring and proven.
- Assuming virtual lab throughput predicts hardware performance.
- Forgetting MTU and platform scale limits.
- Using the same VNI for different meanings across sites.
- Skipping external route and security-policy validation.
Useful Gear And Buyer Notes
Do not buy a switch because its family name appears in an EVPN guide. Verify the exact PID, ASIC, licenses, TCAM/scale, software release, optics, airflow, power, and support status. Cables and console access can help a hardware pilot, but only Cisco's compatibility and feature documentation can establish platform support.
Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.
- Amazon search: Cisco serial console cable
- Amazon search: 10GbE SFP DAC cable
- Amazon search: rack lab switch
- Amazon search: network cable labels
- Amazon search: UPS rackmount
Related TechGeeks Reading
- Networking Field Notes: Start Here
- My Ubiquiti UniFi Home Network: Business-Grade Networking at Home
- Homelab VLAN Design: Simple Network Segmentation That Works
What This Evidence Does Not Prove
The cited documentation establishes protocol behavior, current Cisco guidance, and stated virtual-image limits. It does not prove that CAT 9000v supports the EVPN/VXLAN features your lab needs, that a virtual fabric forwards at production rates, or that a Catalyst 9300 configuration transfers unchanged to another Catalyst family or release.
A green BGP neighbor does not prove correct route targets, MAC mobility, tenant isolation, MTU, external policy, hardware scale, optics, queues, or failure recovery. Those need explicit route inspection, positive and negative traffic tests, and a representative hardware pilot.
Practical FAQ
Is EVPN/VXLAN only for data centers?
No. Campus fabric designs also use EVPN/VXLAN patterns, but the operations model must fit the team.
Can I use CML only?
Use CML for control-plane learning, then validate hardware-specific scale, ASIC, optics, and cabling separately.
What should the first lab prove?
It should prove underlay stability, EVPN route exchange, tenant reachability, and failure handling.
References
- Cisco IOS XE 17.18 Catalyst 9300 BGP EVPN VXLAN overview
- Cisco Catalyst 9300 IOS XE 17.18.x release notes
- Cisco IOS XE 17.18 Catalyst 9300 EVPN/VXLAN configuration guide and restrictions
- Cisco CML CAT 9000v requirements and beta limitations
- RFC 7348: VXLAN
- RFC 7432: BGP MPLS-based EVPN control plane
- RFC 8365: EVPN network virtualization overlays including VXLAN
Final Thought
An EVPN/VXLAN lab is useful when it produces a production checklist, not when it produces a screenshot of a green neighbor state.
