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. > 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. >> >>> 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
