EVPN quiet host never resolves: follow the ARP to the binding

The endpoint is attached, its port is up, and the monitoring host still cannot reach it. Someone runs a ping from the far side and it starts working, which makes the problem look intermittent and the fabric look innocent. That pattern is the signature of a quiet host: it rarely transmits, so the fabric's discovery and refresh behaviour matters more than its attachment state. Start with one intended IP, MAC and bridge domain and follow the next resolution exchange.

Follow the next ARP or ND exchange

For IPv4, watch the requesting host's ARP exchange; for IPv6, follow the Neighbor Solicitation and Advertisement. Confirm the request enters the intended local segment and the intended VNI, because a request that never reaches the right bridge domain cannot be answered by any proxy.

Then look at what the fabric knows about the target. A MAC-only route can identify a Layer 2 destination while the proxy still has no IP-to-MAC binding for it. Those are separate records, and checking one tells you nothing about the other.

If a valid binding exists, the proxy can answer according to its policy, but the MAC in that binding still needs an active forwarding path. If the binding is absent, the request has to reach the endpoint's attachment through the flooding or replication path before anything can learn from the reply.

Two records that must agree

The MAC route answers where the Ethernet address lives. The proxy table answers which IP maps to which MAC. A host that has not spoken recently can have a perfectly good MAC route and no usable proxy entry, which is exactly the state that produces a resolution failure on a healthy attachment.

At the remote attachment, check whether the endpoint actually receives and answers the exchange. Its reply refreshes local learning and the corresponding EVPN advertisement, which is why the manual ping appears to fix things: you generated the traffic the fabric was waiting for. That also explains why the fix does not last: once the refreshed entry ages out, the endpoint goes quiet again. A scheduled ping treats the symptom and hides the design gap.

After the reply, follow the selected route and the installed forwarding state back toward the requester. Resolution succeeding and forwarding succeeding are two separate events, and a ticket that conflates them sends you to the wrong layer.

What the standard actually assumes

RFC 9161 describes dynamic proxy learning and the default flooding of unknown ARP and ND requests. Complete suppression of that flooding is limited to deployments whose learning or provisioning assumptions make it safe, which is a narrower condition than most configuration guides imply.

A fabric that expects newly discovered endpoints needs a working path for those requests. If someone disabled unknown-request flooding to reduce BUM traffic, quiet hosts are the population that pays for it, and the symptom arrives weeks later as an intermittent reachability complaint.

Read the suppression setting as a statement about what the fabric promises to know. If nothing provisions the bindings, the promise is not true for infrequent senders. Compare the configured suppression against the provisioning system that is supposed to feed it. When those two disagree, the fabric is behaving exactly as configured and the expectation is what needs fixing.

Refresh, aging and the static alternative

The standard describes supported refresh probes before dynamic entries age out. Responses refresh the relevant bridge and proxy state; absent responses can legitimately lead to removal and route withdrawal. That is not a bug to be suppressed by stretching every timer.

Extending aging timers indefinitely trades a visible failure for a stale one: the fabric keeps advertising a location the host has left. Use the implementation's documented controls and pick a lifetime that matches how often the endpoint can reasonably be expected to speak.

For known, managed endpoints, a static or controller-provisioned binding is a legitimate second model. It needs an owner who handles replacement and movement, because a provisioned record does not update itself when the host moves to another port.

What to record before the next ticket

Keep the binding's source, last refresh time, current location and any withdrawal event next to the MAC route. That record answers the question the ticket is really asking: is the application waiting for discovery, relying on stale state, or failing to forward after successful resolution?

Then decide which of the three you are willing to operate. Discovery with flooding, refresh with a realistic lifetime, or provisioning with an owner are all defensible. A fabric configured for one and expected to behave like another is where quiet hosts disappear.