On 18 Sep 2026, at 19:03, Mike Pattrick via dev wrote:
> On Fri, Sep 11, 2026 at 2:05 PM Tim Rozet via dev <[email protected]> > wrote: > >> The native userspace tunnel neighbor cache removes a complete entry >> as soon as its aging timer expires. The next packet is treated as a >> cache miss and dropped while OVS sends an ARP or neighbor discovery >> request. >> >> A kernel neighbor entry can instead enter the stale state while still >> retaining a usable link-layer address. Traffic continues using that >> address while neighbor reachability is refreshed. >> >> Add reachable, stale, and incomplete states to the userspace cache. >> When a reachable entry expires, retain its MAC indefinitely and send >> traffic while issuing rate-limited refresh probes. Avoid caching >> translations made with a stale entry so that OVS can retry probes and >> promptly use a refreshed binding. >> >> Do not extend the reachable deadline when the cached MAC is merely >> used. Only ARP or neighbor discovery learning confirms reachability >> and renews the deadline. Thus, active tunnel traffic still makes an >> unconfirmed entry stale and triggers a refresh. >> >> Remove a stale entry after three unanswered probes and one retransmit >> interval. Limit retained stale entries to 4096 and evict the >> oldest-used entries when the limit is exceeded. >> >> This fixes the case where OVS previously learned the neighbor MAC but >> the entry became stale during an idle period. >> >> A genuinely cold entry—restart, flush, eviction, or never learned— >> still drops its triggering packet. That remains the future buffering >> case. >> >> Add IPv4 and IPv6 tests covering active-use aging, long-idle >> retention, stale MAC forwarding, rate-limited refresh probes, and >> removal after three unanswered probes. >> >> Assisted-by: GPT-5, OpenAI Codex >> Signed-off-by: Tim Rozet <[email protected]> >> --- > > > Instead of sending traffic to a stale address, could we preemptively send > ARP/ND packets just before the address of an in use tunnel expires? It > might make sense to integrate this as part of the bridge's main function, > periodic lookup's of each configured remote_ip when it's unknown or stale. > This would save us from dropping the first packet and remove the need to > retain a large number of stale entries indefinitely. I guess this is sort of what I suggested, with the preemptive period being the STALE state. But I do agree with you that adding an extra state seems like a lot of code for something that could be implemented more simply. > If not, I agree with Eelco that the restrictions and limits introduced by > this patch are too loose. And I agree that implementing this as a state > machine would both simplify and clarify the implementation. > > Cheers, > M > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
