[ovs-discuss] [OVN] Aging mechanism for MAC_Binding table

Ben Pfaff 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
guess.


More information about the discuss mailing list