Hands-On Lab: Configuring VXLAN with a Static Unicast Head-End

This hands-on lab configures a basic VXLAN tunnel between two switches using static head-end replication, extending a single Layer 2 VLAN across an IP-routed underlay network without requiring the VLAN to be trunked hop-by-hop.

VXLAN ConfigurationVTEP Head-End ReplicationLayer 2 Extension Over Layer 3

~4 min read · Updated Sep 26, 2026

Lab Objective

Configure a VXLAN Network Identifier mapped to a local VLAN on two switches, establish a static VXLAN tunnel between their VTEP interfaces across a routed IP network, and verify hosts in the same VLAN on each switch can communicate as though directly connected at Layer 2.

Lab Purpose

Every VLAN extension covered earlier in this series relied on 802.1Q trunking, discussed extensively in this series, requiring the VLAN to be carried hop-by-hop across every intermediate switch. VXLAN instead encapsulates Layer 2 frames inside UDP/IP packets, allowing a VLAN to be extended across an entirely Layer 3-routed underlay network where intermediate devices need no VLAN awareness whatsoever.

Lab Topology

Switch1 (VTEP)              Switch2 (VTEP)
  Loopback0: 10.0.0.1/32      Loopback0: 10.0.0.2/32
  VLAN 100 (local)            VLAN 100 (local)
  Gi1/0/1 ---- HostA          Gi1/0/1 ---- HostB

Underlay: an IP-routed network already
providing reachability between the two
loopback addresses (details abstracted)

Goal: HostA and HostB, in VLAN 100 on their
respective switches, should communicate as
if on the same LAN segment

Task 1: Verify Underlay IP Reachability

Confirm the two switches' loopback addresses can already reach each other across the routed underlay.

Task 2: Create the VXLAN Interface Mapped to VLAN 100

Create a VXLAN interface on each switch, associating VNI 10100 with local VLAN 100.

Task 3: Configure the VTEP Source Interface

Configure each switch's VXLAN interface to source encapsulated traffic from its loopback address.

Task 4: Configure Static Head-End Replication

Configure each switch with a static peer list pointing to the other switch's VTEP address for this VNI.

Task 5: Verify Layer 2 Connectivity Across the VXLAN Tunnel

Confirm HostA and HostB can ping each other despite being separated by a routed IP network.

Solution and Verification

Switch1# ping 10.0.0.2 source loopback0

!!!!!
Success rate is 100 percent (5/5)
-- Underlay reachability confirmed before
-- attempting any VXLAN configuration

Switch1(config)# interface nve1
Switch1(config-if)# source-interface loopback0
Switch1(config-if)# member vni 10100 mcast-group static
Switch1(config-if)# member vni 10100 vlan-mapping 100

Switch2(config)# interface nve1
Switch2(config-if)# source-interface loopback0
Switch2(config-if)# member vni 10100 mcast-group static
Switch2(config-if)# member vni 10100 vlan-mapping 100

Switch1(config)# interface nve1
Switch1(config-if)# member vni 10100 ingress-replication protocol static
Switch1(config-if)# peer-ip 10.0.0.2

-- Static head-end replication explicitly
-- lists the peer VTEP -- no multicast or
-- dynamic control plane involved in this
-- basic configuration, unlike more advanced
-- VXLAN designs using BGP EVPN

Switch2(config)# interface nve1
Switch2(config-if)# member vni 10100 ingress-replication protocol static
Switch2(config-if)# peer-ip 10.0.0.1

HostA (VLAN 100)> ping HostB

!!!!!
Success rate is 100 percent (5/5)
-- HostA and HostB communicate successfully,
-- despite being separated by a routed
-- underlay network that has no awareness
-- of VLAN 100 at all

Switch1# show nve peers

Interface  Peer-IP    State
nve1       10.0.0.2   Up

Switch1# show nve vni

Interface  VNI     VLAN  State
nve1       10100   100   Up
-- Confirms the VXLAN tunnel is established
-- and actively mapping local VLAN 100
-- traffic into VNI 10100 for transport
-- across the underlay

Key Takeaway

VXLAN's VNI functions conceptually like a VLAN ID but with a vastly larger namespace (up to roughly 16 million values versus VLAN's 4094 limit, discussed earlier in this series regarding VLAN scale) and, critically, requires no trunking configuration on any device between the two VTEPs — the entire Layer 2 extension happens through IP-encapsulated tunneling, making the underlay network's own routing (not VLAN configuration) the only requirement for the overlay to function.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue