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