On Tue, Aug 20, 2019 at 06:11:12PM -0700, Han Zhou wrote: > On Tue, Aug 20, 2019 at 4:57 PM Ben Pfaff <[email protected]> wrote: > > > > Let me see if I'm following this correctly. This is what currently > > happens: > > > > - HV1 needs a MAC address for an IP so it broadcasts an ARP request. > > > > - The port with the IP address, on HV2, causes the MAC_Binding to be > > inserted. > > > > - Every ovn-controller inserts an OF flow for the binding. HV1 and > > perhaps other ovn-controllers use this flow to populate the MAC > > address for subsequent packets destined to the IP address in question. > > > > This proposal augments that with: > > > > - After a while, the binding goes idle and isn't used. The > > ovn-controllers gradually notice this and delete their OF flows for > > it. > > > > - HV3 eventually needs the binding again. It broadcasts an ARP request. > > > > - The port with the IP address causes the MAC_Binding to be inserted. > > This might still be on HV2 if the port hasn't moved, or it might be on > > HV4 if it has. > > > > Is that what you mean? It might work OK. > > > > Please do update the lifetime description in ovn-sb(5) under the > > MAC_Binding table regardless of what you implement. > > > > Thanks, > > > > Ben. > > > > On Tue, Aug 20, 2019 at 09:03:57AM +0200, Daniel Alvarez Sanchez wrote: > > > Hi folks, > > > > > > Reviving this thread as we're seeing this more and more problematic. > > > Combining the ideas mentioned up thread, Dumitru, Numan, Lucas and I > > > had some internal discussion where we came up with a possible approach > > > and we'd love to get feedback from you: > > > > > > - Local ovn-controller will always insert an OF rule per MAC_Binding > > > entry to match on src_ip + src_mac that will be sampled with a meter > > > to ovn-controller. > > > - When ovn-controller sees that one entry has not been hit "for a > > > while", it'll delete the OpenFlow rule in table 65 that fills the > > > eth.dst field with the MAC_Binding info. > > I assume the rules in table 65 can be "extended" for this purpose, instead > of adding extra rules for this. > > > > - This will result in further ARP requests from the instance(s) that > > > will refresh the MAC_Binding entries in the database. > > > > > > This could make troubleshooting a bit harder so at some point it'll be > > > great to have a mechanism in OVS where we could disable a flow instead > > > of deleting it. This way, one can tell that the flows in table 65 have > > > been disabled due to the aging mechanism in the local node. > > Sorry that I didn't understand this. Why do you want the flow being > disabled instead of deleted? I think if we want to avoid stale entries, we > do want to delete them, so that the stale data doesn't occupy the space in > flow table, neither in SB DB. It may be ok to add debug log for deleting a > aged entry in ovn-controller, for trouble shooting purpose? > > > > > > > Thoughts? Is there any performance consideration regarding the extra > > > flows and meters? > > Are you proposing shared meters or one meter per mac-binding? If it is per > mac-binding, I would be worried about the scalability considering that we > may have >10k of mac-bindings. Or should I be worried? Maybe Justin and Ben > can comment on the meter scalability. If it is a concern, I would suggest > the feature be configurable (i.e. enable/disable), so that it can be > enabled in environments where aging is required but number of mac-bindings > are not very high.
That *is* a lot of meters. I'd suggest at least testing to make sure that it scales. I don't recall enough about the implementation to guess. _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
