[ovs-discuss] [OVN] Aging mechanism for MAC_Binding table
blp at ovn.org
Wed Aug 21 16:46:19 UTC 2019
On Tue, Aug 20, 2019 at 06:11:12PM -0700, Han Zhou wrote:
> On Tue, Aug 20, 2019 at 4:57 PM Ben Pfaff <blp at ovn.org> 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
More information about the discuss