[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
non-overwriteable...

--Pino

> 
> I will copy these improvements to the wiki, thanks!
> /g
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20130215/dd005ce8/attachment.html>


More information about the MidoNet-dev mailing list