EVPN is up but the service is not: four checkpoints

Reaching the remote VTEP address proves the underlay carries packets, and that is all it proves. The tenant service needs a BGP EVPN session with the right address family, a local VNI attached and operational, an originated route, and an import at the far end. Those are four separate checkpoints, each with a different repair. Treating a green underlay as service readiness is the most common way an EVPN bring-up stalls.

Read them in order and stop at the first one that is not what the design expects. Later checkpoints cannot compensate for an earlier failure.

Checkpoint 1: transport to the VTEP

Start with reachability between the loopback addresses used as VTEP sources. The route has to exist in the underlay, the path has to be permitted including any encapsulation requirement, and the return path has to work. A route that exists but is filtered in one direction produces an asymmetric failure that looks intermittent. Confirm both directions before moving on.

Record the source and destination addresses you checked. A later step that resolves a next hop over a different address is a different test, and treating them as one is how a resolved next hop gets blamed for a transport fault.

Checkpoint 2: the EVPN family, not the session count

An established BGP session does not mean the EVPN address family was negotiated. Look at the family-specific state for the neighbor: whether the family is enabled, whether it was negotiated with the peer, and whether the session carries it at all. A session that is up for IPv4 unicast and never negotiated EVPN shows nothing wrong in a general neighbor summary, and the EVPN overlay specification treats service and control procedures as separate concerns from transport.

Check the session's source address too. A peering built from an address that is not the VTEP source is a design mismatch waiting to explain a forwarding failure.

Checkpoint 3: the local service is attached

The local VNI must be attached to the bridge or VRF that represents the tenant, and the platform must report it as operational. Membership state used by the replication model can matter before any host MAC is learned, so an empty endpoint table is not evidence that the service is down.

Then confirm what the device actually originates: the local route for that VNI with the route targets the design specifies. A VNI that is attached but not advertised produces a service that exists locally and nowhere else.

Checkpoint 4: import at the receiver

At the receiving device, compare exported and imported route targets rather than numeric VNIs. A matching VNI number does not prove that the receiving instance imports the advertisement, and a mismatched route target is invisible in a VNI listing. Resolve the advertised next hop through the underlay before trusting the forwarding entry. Then read the overlay forwarding state for the service rather than for the device as a whole.

A peer table may also reflect implementation-specific dataplane or membership learning. Read its origin and service context alongside the EVPN route instead of treating a row count as proof.

One record that walks the path

Keep one record per service: local VNI state, the EVPN neighbor and family, the originated route, and the received and imported result. Walk that record from origin to installation. When something fails, the record says which of four checkpoints to repair rather than which command to try.

Attach timestamps while you do it. An import that appears minutes after the advertisement is a policy or convergence question, while one that never appears is a configuration question, and that difference is only visible if you wrote down when you looked.

When static VXLAN is the right answer

A statically configured VXLAN data path can work with manually supplied peers while the EVPN table stays empty. That is not a broken EVPN deployment, it is a different control model. Decide which one the design intends before diagnosing an empty table as a fault.

An underlay IGP neighbor supplies transport and nothing more. The overlay's service state is a separate thing to build and a separate thing to verify.