Listen to this Post
Introduction:
Virtual Extensible LAN (VXLAN) has become the cornerstone of modern network overlays, enabling massive scale and flexibility in data center designs. While BGP EVPN is the industry standard for dynamic control plane learning, understanding the fundamentals of static VXLAN configuration provides invaluable insight into the underlying data plane mechanics. This article deconstructs a manual VXLAN implementation using Juniper hardware, breaking down the traffic flow for both Layer 2 and Layer 3 communication across a spine-leaf architecture.
Learning Objectives:
- Differentiate between the VXLAN underlay and overlay networks.
- Understand the role of VTEPs and how static tunnels are established.
- Analyze East-West and North-South traffic flows within a static VXLAN environment.
You Should Know:
1. The Architectural Blueprint: Spine-Leaf and VTEPs
The foundation of this VXLAN design is a classic spine-leaf topology. The spine layer, composed of MX Series routers, provides high-speed IP fabric for the underlay and acts as the centralized Layer 3 gateway for VXLAN segments. The leaf layer, built with QFX5120 switches, functions as the VXLAN Tunnel Endpoints (VTEPs), which are the workhorses responsible for encapsulating and decapsulating tenant traffic.
In this specific setup, VTEPs are logically grouped:
VTEP 1: Leaf1 and Leaf2 (likely configured as a MLAG pair for redundancy).
VTEP 2: Leaf3 and Leaf4 (another redundant pair).
The underlay network, represented by the gray lines connecting leaves to spines, uses an IGP like OSPF or IS-IS to provide pure IP reachability between the VTEPs’ loopback addresses. This IP connectivity is essential for transporting the encapsulated VXLAN packets.
2. Manual VXLAN Tunnel Configuration
Unlike dynamic BGP EVPN, this setup relies on static VXLAN configurations. This means the network administrator must manually define the remote VTEP peers for each VXLAN Network Identifier (VNI). The “orange static VXLAN tunnel line” in the diagram symbolizes this manual mapping.
On a Juniper QFX switch, the configuration for a static VXLAN tunnel would look similar to this:
Configure the VXLAN tunnel interface and bind it to a VNI set interfaces vxlan vxlan-100 vni 100 set interfaces vxlan vxlan-100 source-ip 192.0.2.1 Local VTEP Loopback IP Statically define the remote VTEP for this VNI set interfaces vxlan vxlan-100 remote-ip 192.0.2.3 Remote VTEP Loopback IP Bridge the VXLAN interface to the physical access port set vlans vlan-100 vlan-id 100 set vlans vlan-100 l3-interface irb.100 For Layer 3 gateway (if on leaf) set interfaces et-0/0/10 unit 0 family ethernet-switching vlan members vlan-100 set interfaces vxlan-100 unit 0 family ethernet-switching vlan members vlan-100
This configuration explicitly tells VTEP1 (192.0.2.1) that for any traffic in VNI 100 destined for a host it doesn’t have a direct MAC entry for, it should encapsulate and send the packet to the remote VTEP at 192.0.2.3. There is no dynamic MAC-IP-VTEP learning via BGP.
3. Dissecting East-West (Layer 2) Traffic Flow
Let’s trace the journey of a packet from Host1 (VNI 100) to Host3 (VNI 100), which are on the same subnet but connected to different VTEPs.
- Frame Transmission: Host1 sends a standard Ethernet frame destined for Host3’s MAC address to its local switch, Leaf1 (part of VTEP1).
- MAC Lookup & Encapsulation: Leaf1 checks its MAC address table. In a static setup, if Host3’s MAC is not locally known, it will either flood the frame to all remote VTEPs configured for VNI 100 or use a static MAC entry. It then encapsulates the entire Ethernet frame with a VXLAN header (specifying VNI 100) and new outer IP and UDP headers.
Outer Source IP: VTEP1’s loopback IP (e.g., 192.0.2.1)
Outer Destination IP: VTEP2’s loopback IP (e.g., 192.0.2.3) - Underlay Transport: This new IP packet is routed through the underlay network, traversing the MX spine routers based on standard IP routing for the destination 192.0.2.3.
- Decapsulation & Delivery: VTEP2 (Leaf3/Leaf4) receives the packet, verifies the VNI, decapsulates it to retrieve the original Ethernet frame, and forwards it to Host3.
4. Analyzing North-South (Inter-VNI) Traffic Flow
When Host1 (VNI 100) needs to communicate with Host4 (VNI 200), the traffic must be routed. In this design, the MX spines act as the centralized Layer 3 gateway.
- Host Routing: Host1 sends a packet to Host4’s IP address. Recognizing it’s on a different subnet, Host1 sends the packet to its default gateway.
- Gateway Forwarding: The default gateway for VNI 100 is an Integrated Routing and Bridging (IRB) interface (e.g.,
irb.100) hosted on the spine routers. The leaf switch forwards the frame to the spine via the VXLAN overlay. - Inter-VNI Routing: The spine router receives the frame on
irb.100, performs a routing lookup, and determines the next hop is out of `irb.200` (the gateway for VNI 200). - Re-encapsulation: The spine router then re-encapsulates the packet into a new VXLAN frame, this time with VNI 200 in the header.
Outer Source IP: Spine’s VTEP IP (this could be its own loopback).
Outer Destination IP: VTEP2’s loopback IP (192.0.2.3).
- Final Delivery: The packet is sent across the underlay to VTEP2, which decapsulates it and delivers the original routed packet to Host4.
5. Simulating VTEP Connectivity in a Linux Environment
You can experiment with VXLAN basics on a Linux server, which can act as a software VTEP. The following commands create a VXLAN interface and statically point it to a remote VTEP, mirroring the manual concept from the article.
Create a VXLAN interface named 'vxlan100' with VNI 100 sudo ip link add vxlan100 type vxlan id 100 dev eth0 local 192.0.2.1 remote 192.0.2.3 dstport 4789 Bring the interface up sudo ip link set dev vxlan100 up Assign an IP address to the VXLAN interface sudo ip addr add 10.0.100.1/24 dev vxlan100
ip link add: Creates the virtual VXLAN interface.
`type vxlan id 100`: Defines the VNI.
`local 192.0.2.1`: Sets the source VTEP IP.
remote 192.0.2.3: The static remote VTEP IP—this is the key manual configuration.
`dstport 4789`: The standard VXLAN UDP port.
What Undercode Say:
- Foundational Knowledge is Power: Mastering static VXLAN provides a rock-solid understanding of encapsulation and data plane mechanics, which is crucial for troubleshooting more complex dynamic EVPN setups.
- Operational Overhead is a Trade-Off: While excellent for learning and small-scale labs, static VXLAN does not scale. Every MAC address move or new VTEP addition requires manual reconfiguration, which is prone to error and operationally intensive.
The analysis of this manual VXLAN setup reveals the critical value of the control plane. BGP EVPN was developed specifically to automate the distribution of MAC/VNI/VTEP mappings that are manually configured here. While this static approach works, it highlights the immense operational burden that EVPN eliminates. For any production environment requiring scale, agility, or efficient handling of Broadcast, Unknown Unicast, and Multicast (BUM) traffic, evolving towards a BGP EVPN design is not just recommended, it is essential. This exercise ultimately serves to appreciate the automation and scalability that dynamic protocols bring to modern networking.
Prediction:
The manual configuration of network overlays will continue to diminish in favor of fully automated, intent-driven systems. The future impact of understanding these low-level mechanics lies not in their manual deployment, but in empowering network engineers to build more robust automation and diagnostic scripts. As AI-driven network operations (AIOps) mature, the foundational knowledge of how VXLAN packets flow will be critical for developing and validating the AI models that will autonomously manage and secure these complex environments, making the skilled engineer who understands both the manual and dynamic worlds more valuable than ever.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Ah M – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
