Map an Untagged Access Port into the Right EVPN VNI

An untagged host frame is classified by the access port, then carried by the VTEP as a VNI. Check ingress, egress, and the service model separately.

An ordinary Ethernet host sends untagged frames, and the EVPN fabric still has to carry them in the right tenant service. The access port classifies the frame into a local segment, the VTEP maps that segment to a VNI, and the remote attachment presents the frame the way its host expects. The VLAN and the VNI identify different parts of that path and need not share a number. Work the runbook below in order, because a mistake at any step produces the same symptom: a host that transmits and receives nothing.

Follow one frame through the fabric

For a simple VLAN-based service, an illustrative path looks like this:

Host A: untagged frame
  to access port: local VLAN 110
  to VTEP A: L2VNI 50110
  to VTEP B: corresponding local service
  to access port: untagged frame to Host B

The VLAN and VNI numbers are examples, not a rule. The local VLAN is an ingress classification that exists on one switch; the L2VNI is the overlay service identifier that both VTEPs understand. The overlay specification RFC 8365 keeps the service identifier separate from how a host is attached, and it names three shapes: VLAN-based, bundled and VLAN-aware.

Configure ingress classification

The host has an address and reaches nothing, while the port itself shows up. Decide which attachment mode the port is really in, an access port that carries untagged frames or a trunk with a native VLAN, and set that one explicitly. An untagged frame still leaves the port inside a named local segment, and that segment is a decision rather than a side effect of the platform. Open the port's running configuration and read the classification it has instead of trusting a vendor default you never set.

On a typical switch the sequence is a mode change and an access VLAN assignment, followed by a check that the port is actually up and in that state. If the port is a trunk, the native VLAN handles untagged frames, and that is a different configuration with different failure modes. Record both the mode and the VLAN before you move on.

show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan brief

Configure the VTEP and VNI mapping

The VTEP adds the VXLAN encapsulation and the VNI. The host does not generate that header, and it does not need to know that the service exists.

Map the local VLAN to the L2VNI with the platform's supported command form, and keep that mapping consistent on both ends of the service. A tenant L2VNI and the L3VNI used for inter-subnet routing are different objects, and mixing their numbers breaks routing without touching the L2 path, and remember that a working underlay route to the remote VTEP belongs to yet another layer of the setup.

If the mapping is wrong, the frame still enters the fabric and simply lands in the wrong service. That is why the check is a service check, not a link check.

Configure egress presentation

At the far end the received service has to be turned back into whatever the host expects: bare Ethernet on an access port, a specific tag on a trunk you control, and inner-tag handling that matches the service model you chose. Check the trunk allowed VLAN list before you blame the overlay, because a tag the egress trunk does not permit is dropped after the overlay has already done its job. Confirm the remote host expects the presentation it receives rather than the one your diagram assumed.

Whether an inner tag survives is a property of the service model you chose, so no article can promise strip or preserve in general. A design that assumes one behavior and a platform that implements the other will pass a link test and fail the application.

Read local MAC learning, the EVPN service route and the remote attachment mapping together, and drive the neighbour discovery the application needs rather than only a ping. A MAC address learned in a different bridge domain can be perfectly valid there and still point at the wrong service.

Verify with one host pair

Bring up one host pair and prove the full path before adding a second pair. Then read the state on both VTEPs and confirm that the same service identifier appears at both ends.

show mac address-table vlan 110
show bgp l2vpn evpn
show nve peers

For each end write down four values: port presentation, local segment, L2VNI, and the reverse presentation on egress. That record lets the next engineer see why the host has a simple untagged connection while the fabric carries a tenant service. If a change fails, revert the port to its previous VLAN and re-test the same pair, so the rollback is a known state rather than a guess.

Inyandiko zihuye