[ovs-discuss] [OVN] Aging mechanism for MAC_Binding table
zhouhan at gmail.com
Tue Jul 9 01:19:23 UTC 2019
On Thu, Jun 27, 2019 at 6:44 AM Ben Pfaff <blp at ovn.org> wrote:
> On Tue, Jun 25, 2019 at 01:05:21PM +0200, Daniel Alvarez Sanchez wrote:
> > Lately we've been trying to solve certain issues related to stale
> > entries in the MAC_Binding table (e.g. ). On the other hand, for
> > the OpenStack + Octavia (Load Balancing service) use case, we see that
> > a reused VIP can be as well affected by stale entries in this table
> > due to the fact that it's never bound to a VIF so ovn-controller won't
> > claim it and send the GARPs to update the neighbors.
> > I'm not sure if other scenarios may suffer from this issue but seems
> > reasonable to have an aging mechanism (as we discussed at some point
> > in the past) that makes unused/old entries to expire. After talking to
> > Numan on IRC, since a new pinctrl thread has been introduced recently
> > , it'd be nice to implement this aging mechanism there.
> > At the same time we'd be also reducing the amount of entries for long
> > lived systems as it'd grow indefinitely.
> > Any thoughts?
> > Thanks!
> > Daniel
> > PS. With regards to the 'unused' vs 'old' entries I think it has to be
> > 'old' rather than 'unused' as I don't see a way to reset the TTL of a
> > MAC_Binding entry when we see packets coming. The implication is that
> > we'll be seeing ARPs sent out more often when perhaps they're not
> > needed. This also leads to the discussion of making the cache timeout
> > configurable.
> I've always considered the MAC_Binding implementation incomplete because
> of this issue and others. ovn/TODO.rst says:
> * Dynamic IP to MAC binding enhancements.
> OVN has basic support for establishing IP to MAC bindings
> * Ratelimiting.
> From casual observation, Linux appears to generate at most one
> second per destination.
> This might be supported by adding a new OVN logical action for
> * Tracking queries
> It's probably best to only record in the database responses to
> actually issued by an L3 logical router, so somehow they have to
> tracked, probably by putting a tentative binding without a MAC
> into the database.
> * Renewal and expiration.
> Something needs to make sure that bindings remain valid and
> that become stale.
> One way to do this might be to add some support for time to the
> server itself.
> * Table size limiting.
> The table of MAC bindings must not be allowed to grow
> * MTU handling (fragmentation on output)
> So, what do we do about it? First, I think that adding support for time
> to the database server is a terrible idea (even though I think I wrote
> the above originally). Let's not do that. The following is some
> "thinking out loud" on the subject.
> I think there's a challenge around which ovn-controller should take care
> of a given MAC_Binding. We don't want every ovn-controller expiring
> every binding. Ideally, we want exactly one ovn-controller expiring a
> binding. One way would be to add an owner column (but it would be
> better if we don't need it).
> If we want to keep track of "unused" bindings, I can imagine a
> statistical mechanism to do that. Any user of a binding occasionally
> and probabilistically changes a serial number column that we'd introduce
> into the MAC_Binding table (this could be optimized to not bother if it
> has changed recently). The owner checks the serial number every so
> often and if it hasn't changed then it deletes the row.
Thanks Ben for the advice. Since the user of a binding is simply a OpenFlow
rule matching, I guess we will need "controller" action to trigger the
serial number column update in ovn-controller, combined with a meter action
so that only small number of packets trigger the update. Is this what you
> The owner could also occasionally revalidate the binding.
> Any thoughts?
> discuss mailing list
> discuss at openvswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the discuss