Sorry, Han, for messing up the indents, looks like my outlook browser client is either set correctly, or doesn’t work well.
Let me try from the app and see if it is any better.. From: ovn-kuberne...@googlegroups.com <ovn-kuberne...@googlegroups.com> On Behalf Of Han Zhou Sent: Friday, May 22, 2020 1:51 PM To: Venugopal Iyer <venugop...@nvidia.com> Cc: Girish Moodalbail <gmoodalb...@gmail.com>; Tim Rozet <tro...@redhat.com>; Dumitru Ceara <dce...@redhat.com>; Han Zhou <hz...@ovn.org>; Dan Winship <danwins...@redhat.com>; ovs-discuss <ovs-discuss@openvswitch.org>; ovn-kuberne...@googlegroups.com; Michael Cambria <mcamb...@redhat.com> Subject: Re: [ovs-discuss] [OVN] flow explosion in lr_in_arp_resolve table External email: Use caution opening links or attachments On Fri, May 22, 2020 at 8:39 AM Venugopal Iyer <venugop...@nvidia.com<mailto:venugop...@nvidia.com>> wrote: A couple of comments below: <vi> I suppose the use of GARP as a reply v/s response is not very clear; [1], Section 3 seems to offer a concise summary of this. If the application sends GARP as <vi> a reply we are covered, but the question is if the GARP is a request (which is allowed) then what our response should be. Tim is right, we can't ignore <vi> the request (more so, since aging is not supported currently), however "arp_accept" ignores the request for creating a new cache entry, not updating <vi> an existing one (see last para below) [2] arp_accept - BOOLEAN Define behavior for gratuitous ARP frames who's IP is not already present in the ARP table: 0 - don't create new entries in the ARP table 1 - create new entries in the ARP table Both replies and requests type gratuitous arp will trigger the ARP table to be updated, if this setting is on. If the ARP table already contains the IP address of the gratuitous arp frame, the arp table will be updated regardless if this setting is on or off. <vi> if we lookup and get a hit, we should still process the GARP; only if we don't have a hit, we should ignore (instead of <vi> creating an entry). BTW, do we update today? if I understand the use of reg9[2] / REGBIT_LOOKUP_NEIGHBOR_RESULT (assuming lookup_arp <vi> returns 1 if entry exists), I am not sure it does? maybe I missed it .. thanks, -venu [1]https://www.ietf.org/rfc/rfc5227.txt (Not sure why the indent format of your reply is not correct at least on my client - it mixes all previous replies together so one cannot tell which part was from whom, so I truncated all of them.) Thanks Venu. I think this would work: we can add an option similar but different from arp_accept (because it is not easy to OVN to tell if it is GARP on the ingress pipeline). The option can be named like: learn_from_arp_request. When ARP request is received, always check if an old entry existed for the SPA. If existed and MAC is different, then update the mac-binding entry. If the entry doesn't exist, check the option setting: "true" - add a new entry. "false" - if the TPA is on the router, add a new entry (it means the remote wants to communicate with this node, so it makes sense to learn the remote as well). Otherwise, ignore it and no new entry added. [vi> ] yes, I believe that should work. Do you think this works? Regarding your question on lookup_arp(), today it looks up for the same IP-MAC binding, just avoid unnecessary updating if the pair already existed and not changed. thanks, -venu Thanks, Han -- You received this message because you are subscribed to the Google Groups "ovn-kubernetes" group. To unsubscribe from this group and stop receiving emails from it, send an email to ovn-kubernetes+unsubscr...@googlegroups.com<mailto:ovn-kubernetes+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/ovn-kubernetes/CADtzDCk%3DeqsrifyfSuBcLFUNdbtFOESdeqg-M%2BZch%2BiQNiJTiA%40mail.gmail.com<https://groups.google.com/d/msgid/ovn-kubernetes/CADtzDCk%3DeqsrifyfSuBcLFUNdbtFOESdeqg-M%2BZch%2BiQNiJTiA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
