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

Dumitru Ceara dceara at redhat.com
Thu Aug 22 07:16:32 UTC 2019


On Wed, Aug 21, 2019 at 6:47 PM Ben Pfaff <blp at ovn.org> wrote:
>
> 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.

I guess sharing meters is an option if we're worried about scaling
issues. We could implement something similar to what Han suggested for
ARP packets [1]. That could potentially trigger more ARP requests from
ovn-controller and more load on ovn-controller so we should probably
allow the user to configure the way meters are created for these flows
(e.g., meter per flow or meter bucket size).

Thanks,
Dumitru

[1] https://mail.openvswitch.org/pipermail/ovs-dev/2019-August/361482.html

> _______________________________________________
> discuss mailing list
> discuss at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


More information about the discuss mailing list