On 9/23/26 10:34 AM, Eelco Chaudron wrote:
External email: Use caution opening links or attachments
On 23 Sep 2026, at 16:10, Tim Rozet wrote:
On 9/23/26 6:05 AM, Eelco Chaudron wrote:
External email: Use caution opening links or attachments
On 22 Sep 2026, at 17:31, Tim Rozet wrote:
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.
This is a problem, as it will never time out, and hence the system will keep
using the invalid MAC address.
No, because in step 3 it will start timing out if it does not receive an ARP
response in 3 seconds (3 attempts) and the entry will be removed in step 4.
Maybe I got it wrong. But if there is no first use, the entry will stay in
STALE state forever (will not be deleted), and existing flow entries will not
be deleted, which is currently the case after 15 minutes. So the existing
entries will use the wrong mac forever (and never timeout).
You are correct there. That was the intention of the patch. The entry
will stay STALE until the table is full and it is the oldest entry. That
was the way to passively avoid dropping packets after ARP expiry. The
proposed state machine I was referencing was not to change that
behavior, but to change the behavior after an entry has gone STALE, and
a packet triggers the ARP renewal. I was proposing an added timer there
to make sure the absence of an ARP response would not cause the entry to
stay STALE permanently.
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.
The current AI-generated code is already adding a lot of code for what I feel
can be done much simpler. I think all we really need is a re-check of the ARP
entry once it's about to expire, as Mike suggested. I'm currently rather busy,
but I can have a stab at it at a later time.
I think Mike suggested walking remote_ips, but we use flow based Geneve tunnels
with OVN. That would still require walking the neighbor entries, resolving the
route/output port and injecting ARP/ND in the bridge pipeline wouldn't it? I'm
not sure it will be less than hooking into the code that already exists for
generating the ARP message. I will try to explore it anyway.
I think Mike was talking about neighbour entries also, or at least that was
what I assumed.
I tried going this route and it seems fine to me. The code change is
around 400 lines are so, and it makes sense to me. I'll post a V3.
Thanks for the feedback.
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
