Hi Eelco, Mike,
Sorry I had already responded to your email, but due to my Outlook and
HTML messages I think they are not coming across correctly. Also,
Outlook web seems to lack ability to reply nicely inline, so I've
switched my mail client. Please see inline.
On 9/21/26 6:29 AM, Eelco Chaudron wrote:
External email: Use caution opening links or attachments
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.
My first attempt at this (with the help of AI) was to create a real
proactive ARP requester. I'm not an expert in OVS codebase and AI warned
me that this was going to be a huge code change to add this kind of
functionality. Instead I went with this intermediary solution that was
less code, and achieved most of what we cared about. I'm wondering if we
can compromise by adding a time based component and still use the packet
event mechanism as the trigger to send the ARP requests. Something like
this:
1. An unused entry may remain STALE.
2. First use forwards with the stale MAC and starts probing.
3. A timer sends the remaining probes without requiring more traffic.
Retransmission time of 1s, which matches kernel.
4. A reply restores REACHABLE; otherwise the entry is removed after
the retry limit.
This is pretty close the relevant kernel behavior. I can also reduce the
entry limit to 1024. Thoughts? If it is off base and you think it will
be less or equivalent codewise to use an active ARP requester then I can
try to go down that path and we can compare the 2 implementations.
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
