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. [0]). 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
> [1], 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 dynamically,
using
ARP.
* Ratelimiting.
From casual observation, Linux appears to generate at most one ARP per
second per destination.
This might be supported by adding a new OVN logical action for
rate-limiting.
* Tracking queries
It's probably best to only record in the database responses to queries
actually issued by an L3 logical router, so somehow they have to be
tracked, probably by putting a tentative binding without a MAC address
into the database.
* Renewal and expiration.
Something needs to make sure that bindings remain valid and expire those
that become stale.
One way to do this might be to add some support for time to the database
server itself.
* Table size limiting.
The table of MAC bindings must not be allowed to grow unreasonably
large.
* 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.
The owner could also occasionally revalidate the binding.
Any thoughts?
Thanks,
Ben.
_______________________________________________
discuss mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
