Why a QFX MAC Shows in EVPN but Not in the Forwarding Table

Finding a MAC in the EVPN database proves that it was advertised or received as a route, and nothing beyond that. The forwarding table is a different structure, programmed later, so the same MAC can appear in one and be missing from the other while every protocol behaves correctly. Treating those two outputs as copies of each other sends engineers after a BGP fault when the actual gap is an import policy or an unresolved next hop. The question worth asking is not whether the fabric knows the MAC, but which stage stopped passing it along.

Two tables that answer different questions

On Junos EVPN the database lists MAC addresses per instance together with how each one arrived: learned from an access port, received in a Type 2 route, or flagged as part of a multihoming group. Juniper's show evpn database reference covers the per-MAC and per-instance filters that make the view readable. It is a control-plane summary keyed by instance and MAC, not the table the hardware switches frames with.

The switching table is that forwarding state. Both outputs list MACs beside VLAN or VNI context, which is exactly why they get compared line by line, and exactly why the comparison misleads. An entry in the database says the route exists and was accepted into the instance; it says nothing about whether the platform installed it for forwarding.

A Type 2 route carries the MAC, an optional IP, a label or VNI, a route distinguisher and a next hop naming the remote VTEP. Four things can break between the wire and that route: the host is never learned, the route is never advertised, it is rejected on import, or its next hop fails to resolve. Each failure leaves a different set of tables populated, which is the reason the sequence can be diagnosed at all.

Local learning still happens first

The common assumption is that EVPN takes over MAC learning, so an empty database must mean an overlay problem. Local learning still runs on the access side, exactly as it did before VXLAN existed: the switch learns the source MAC of a permitted frame in the correct VLAN and service, and only then originates a Type 2 for it. A host that has sent no relevant frame has nothing to advertise. A host whose frames are discarded by VLAN membership, a filter, or a down member of an aggregate looks identical from the overlay's point of view.

Start at the attachment and work forward with read-only commands. The goal is to prove that a frame from the host crossed in the intended service, because nothing downstream compensates for a frame that never arrived.

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

Selected LACP members matter more than the bundle being up, since an aggregate can be up on one member while the host's traffic hashes to a link that is down or blocked. Interface counters separate a silent host from a dropping one, because a host that never transmits and a host whose frames are discarded by classification leave the same empty table behind.

Where a remote MAC gets lost

A remote MAC fails in the opposite direction, and quietly. The Type 2 route arrives, but it only enters an instance when its route target and VNI match the local configuration, and it only becomes usable when the next hop resolves to a reachable VTEP. A route-target mismatch leaves a valid route in the BGP table that no instance ever asks for.

Read the three views in order: route presence, database entry, forwarding entry. The commands below query the same MAC at each stage, and the sample address keeps the outputs comparable.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

Those outputs answer three separate questions. A route in bgp.evpn.0 with no database entry points at import policy, route-target or instance configuration. A database entry with no forwarding entry points at platform programming, which belongs to a different escalation path. An active route whose next hop will not resolve is a transport or label problem, and no amount of MAC debugging repairs it.

A reboot that fixed it proves very little

When a restart makes the symptom vanish, the tempting conclusion is that the configuration must be sound. A reboot reprograms every table from scratch, so it also hides the case where a stale entry was shadowing a policy error; the fault tends to return at the next churn, link flap or route withdrawal.

Before any maintenance window, capture what the restart will erase. These three commands are enough to compare before and after, and they change nothing on the device.

show evpn database instance blue
show route table bgp.evpn.0
show version

File those outputs with the date and the software build beside them. A later report that the same restart worked before is a lead rather than evidence, and the difference only becomes visible when someone kept the earlier output.

Four observations that settle most cases

Four observations carry almost every case: the attachment and its service, the MAC as an example value, the state of the route and database, and the build in use. Choose a MAC that is obviously a sample so nobody mistakes it for a production address: a first octet of 02 marks a locally administered unicast address, the remaining octets are free, and 02:00:00:00:00:5c is therefore a safe placeholder.

Then let the answers point at the stage that failed. No attachment learning means the access side; a route without a database entry means import; a database entry without forwarding state means programming. Whichever it turns out to be, hand over the collected outputs together with the host, interface, service and build, so the next engineer can reproduce the path instead of repeating the query.