[MidoNet-dev] API proposal - Optional Bridge ARP Cache

Navarro, Galo galo at midokura.com
Fri Feb 15 16:53:30 UTC 2013

Thanks for your feedback Rossella and Pino, some comments inline but
mainly agree on your proposals.

On 15 February 2013 15:47, Pino de Candia <gdecandia at midokura.com> wrote:
> On Friday, February 15, 2013 at 3:23 PM, Rossella Sblendido wrote:
> Hi Galo,
> thanks for the write up, here are my comments, I'll add them in the wiki.
> About your question:
> - Q: if ARP reply snooping is implemented, should disabling the arp
> cache also stop snooping on ARP replies? If so, should the cache be
> deleted or just be left to stale?
> In my option if the ARP cache is disabled the ARP snooping should also be
> disabled. The bridge will behave as a "normal" bridge and flood the arp
> requests.
> I think the cache should be deleted. It's not so big that means that it can
> be recreated fast. Most entries have time out so I don't see any value in
> occupying memory with out-dated entries.

I agree.

> What's the difference between snooped entries and entries that are injected
> using the REST API? I don't see the need of a type. In which way do they
> behave differently?
> The only thing I can imagine is that entries coming from the rest api don't
> expire. So why don't we use an infinite time out to distinguish those
> entries?

That's true. The only other case I can think where it'd be useful to
have the source is for debugging scenarios. Other than that I think
the parameter settings mentioned below are enough.

> What happens if an entry configured using the rest api conflicts with a
> snooped one or vice-versa?
> Do we need to do any health check on the entries inserted using the rest
> api? I think so. We shouldn't allow entries that mess up the system. An easy
> one would be if the MAC associated to the IP is not in the MacLearningTable
> we shouldn't accept the entry.
> What happens when the MAC gets deleted from the MacLearningTable? Shall we
> disable the corresponding arp cache entry?
> I propose the following:
> - an ARP cache entry that's added via the API should indicate explicitly:
> expiration-time (or never expires); over-writeable or not.
> - all ARP cache entries that are learned by snooping ARP requests and
> replies are over-writeable (if you see a different association) and
> expiring.
> This way the API client decides a-priori who's authoritative when the
> pre-seeded information contradicts what's seen on the wire:
> - trust the API client
> - trust the VMs

That seems like a good solution.

I think also that sanitizing snooped entries as Rosella suggests would
be desirable: for snooped entries, do not insert if MAC does not exist
in MacLearningTable; when deleting MAC from MacLearningTable, remove
cached entry.

I will copy these improvements to the wiki, thanks!

More information about the MidoNet-dev mailing list