[MidoNet-dev] API proposal - Optional Bridge ARP Cache
Pino de Candia
gdecandia at midokura.com
Fri Feb 15 17:02:05 UTC 2013
> > 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'm not sure I see the value of this, and dislike the added complexity.
Aside, we're only snooping on ARP request/reply, not other packet types, right?
Regarding the snooped entry... the moment you've seen it, the MAC must have been
added to the MacLearningTable, unless it conflicted with an existing non-over-writeable
Mac table entry. But in that case the corresponding ARP cache entry should also be
> I will copy these improvements to the wiki, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MidoNet-dev