Traditional VLANs were designed for Layer 2 segmentation inside relatively bounded switched networks.<\/p>\n
Modern data centers often need much larger logical networks that span Layer 3 infrastructure.<\/p>\n
VXLAN solves that problem by building a Layer 2 overlay on top of a Layer 3 underlay<\/strong>.<\/p>\n A VXLAN tunnel can be configured correctly while traffic still fails because the routed underlay cannot reach a remote VTEP; conversely, the underlay may be healthy while overlay mapping or endpoint policy prevents delivery. When interpreting N10-009 network-architecture practice<\/a> evidence, check underlay reachability and MTU separately from tunnel membership and controller policy. A successful ping to a VTEP proves neither that the intended MAC\/IP endpoint was learned nor that the application flow is permitted.<\/p>\n A VXLAN fabric still needs a working routed network underneath it.<\/p>\n That routed network is the underlay<\/strong>.<\/p>\n The underlay’s job is to provide IP connectivity between VXLAN tunnel endpoints.<\/p>\n It can use ordinary routing technologies and redundant data-center design.<\/p>\n The underlay does not need to know every tenant MAC address.<\/p>\n It needs to know how to route IP packets between the devices that participate in the overlay.<\/p>\n If the underlay is unstable, the VXLAN overlay will be unstable too.<\/p>\n Troubleshoot underlay reachability before blaming encapsulation.<\/p>\n VXLAN creates logical Layer 2 networks over that IP underlay.<\/p>\n A frame from a tenant or application network is encapsulated for transport across the routed fabric.<\/p>\n At the remote endpoint, the encapsulation is removed and the original Layer 2 frame is delivered into the correct logical segment.<\/p>\n This lets workloads in different racks or routed portions of a data center participate in the same overlay network without extending one physical Layer 2 switching domain everywhere.<\/p>\n The overlay therefore separates the logical tenant topology from the physical routed topology.<\/p>\n A VXLAN Tunnel Endpoint, or VTEP, is responsible for encapsulating and decapsulating VXLAN traffic.<\/p>\n A VTEP can be implemented in:<\/p>\n The VTEP has an IP presence in the underlay.<\/p>\n When it needs to send an Ethernet frame across the VXLAN network, it encapsulates that frame in VXLAN over UDP\/IP and sends it toward another VTEP.<\/p>\n RFC 7348 defines UDP port 4789<\/strong> as the default VXLAN destination port.<\/p>\n The VNI identifies the logical overlay segment<\/strong><\/p>\n A VXLAN Network Identifier, or VNI, identifies a VXLAN segment.<\/p>\n The VNI is 24 bits.<\/p>\n That creates a far larger logical segmentation space than the 12-bit VLAN ID field used by traditional 802.1Q VLANs.<\/p>\n This is one of the reasons VXLAN became attractive in multi-tenant data centers.<\/p>\n The architect can create many logical overlay segments without being limited to the traditional VLAN-ID scale.<\/p>\n A VNI is not the same thing as a VLAN ID.<\/p>\n VLAN-to-VNI mapping can exist at the edge, but the identifiers belong to different encapsulation systems.<\/p>\n Conceptually, VXLAN carries:<\/p>\n outer Ethernet \u2192 outer IP \u2192 UDP \u2192 VXLAN header \u2192 original Ethernet frame<\/strong><\/p>\n The outer IP header belongs to the underlay.<\/p>\n The original Ethernet frame belongs to the overlay tenant segment.<\/p>\n This separation is the core architectural idea.<\/p>\n The routed network transports the VXLAN packet.<\/p>\n The tenant’s Layer 2 frame remains inside the encapsulation until it reaches the remote VTEP.<\/p>\n Overlays reduce the need for one large physical spanning-tree domain<\/strong><\/p>\n Traditional Layer 2 extension across a data center can create large broadcast and spanning-tree domains.<\/p>\n VXLAN allows the physical fabric to remain routed.<\/p>\n That provides benefits such as:<\/p>\n The overlay still presents Layer 2 semantics where applications need them.<\/p>\n This is why VXLAN commonly appears with leaf-spine routed fabrics.<\/p>\n The physical topology is optimized for IP routing.<\/p>\n The virtual topology is optimized for workload segmentation.<\/p>\n Early VXLAN designs could rely heavily on flood-and-learn behavior.<\/p>\n Modern data-center fabrics commonly use a control plane such as EVPN to distribute MAC and IP reachability information between VTEPs.<\/p>\n That reduces the need for flooding and improves scale.<\/p>\n Network+ may not require the depth of a data-center specialist exam, but understanding this distinction helps:<\/p>\n Do not treat VXLAN and EVPN as synonyms.<\/p>\n Modern VXLAN fabrics often use EVPN as the control plane because the data plane alone does not tell every VTEP where remote endpoints live. With BGP EVPN, reachability information can be advertised between VTEPs instead of relying only on flood-and-learn behavior. That lets the fabric scale better and gives the operator a control-plane table to inspect when an endpoint exists locally but is not reachable remotely.<\/p>\n Broadcast, unknown-unicast, and multicast traffic still need handling inside an overlay. Depending on the design, the fabric can use multicast in the underlay or ingress replication to deliver BUM traffic to the VTEPs that participate in a segment. A failure in that mechanism can create symptoms that look inconsistent: known unicast might work while ARP, Neighbor Discovery, or other broadcast-dependent behavior fails.<\/p>\n The underlay also has performance responsibilities. Equal-cost multipath is common in leaf-spine fabrics, so multiple routed paths may carry VXLAN packets between VTEPs. If one path has MTU, loss, or routing problems, failures can appear intermittent because different flows hash across different underlay links. That is another reason to test VTEP-to-VTEP reachability and path health before editing VLAN or VNI mappings.<\/p>\n Operationally, separate three identities during troubleshooting: the endpoint VLAN or local segment, the VNI that identifies the overlay segment, and the VTEP IP address used by the underlay. A mistake at any one of those layers can break communication, but the evidence will be different. Local MAC learning can be correct while the remote EVPN route is missing; the EVPN route can be correct while the underlay cannot reach the remote VTEP; and the underlay can be healthy while a VLAN maps to the wrong VNI.<\/p>\n VXLAN adds headers.<\/p>\n That increases the packet size carried by the underlay.<\/p>\n If the underlay MTU is too small, the network may experience:<\/p>\n Data-center VXLAN designs commonly use a larger underlay MTU to account for encapsulation overhead.<\/p>\n When small pings succeed but larger application traffic fails, MTU is a useful troubleshooting candidate.<\/p>\n If two endpoints should share one logical overlay but are placed in different VNIs, they will not share the expected Layer 2 segment.<\/p>\n Symptoms can include:<\/p>\n Check:<\/p>\n Do not troubleshoot only the access VLAN when the segmentation error may be in the overlay identifier.<\/p>\n VXLAN is a network encapsulation technology.<\/p>\n VXLAN uses encapsulation to carry an overlay segment across an IP underlay. A configured VNI is not proof that remote endpoints can exchange frames: compare VTEP reachability, the advertised endpoint mapping and the route taken by the outer packet. The encapsulation adds a transport dependency, so a perfectly configured local VLAN can still fail when the routed fabric cannot carry the tunneled traffic.<\/p>\n VXLAN can be part of an SDN solution.<\/p>\n It can also exist in designs where the important concept is simply an overlay carried over a routed fabric.<\/p>\nThe underlay provides IP reachability<\/h2>\n
The overlay carries Layer 2 segments<\/h2>\n
VTEPs perform VXLAN encapsulation<\/h2>\n
\n
Encapsulation keeps tenant Ethernet separate from the routed underlay<\/h2>\n
\n
Control-plane learning matters<\/h2>\n
\n
MTU must account for encapsulation<\/h2>\n
\n
VNI mismatch can look like a VLAN problem<\/h2>\n
\n
\n
VXLAN can participate in SDN fabrics without being SDN itself<\/h2>\n