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

Pino de Candia gdecandia at midokura.com
Fri Feb 15 14:47:07 UTC 2013


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.
>  
> 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?
>  
> 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

--Pino
>  
> cheers,
>  
> Rossella
>  
> On 2/12/13 11:14 AM, Guillermo Ontañón wrote:
> > Hi Galo,  
> >  
> > Looks good, just one comment below,  
> >  
> >  
> > On Wed, Feb 6, 2013 at 2:02 PM, Navarro, Galo <galo at midokura.com (mailto:galo at midokura.com)> wrote:
> > > Hello, below is an initial proposal for the API changes to support the
> > > optional Bridge ARP cache. You can see further details at
> > > https://trello.com/card/bridge-arp-cache/510b93ac787666573800291f/24
> > > but I'm copying the requirements below
> > >  
> > > * DTO changes:
> > >  
> > > DtoArpCacheEntry (new) to represent an IP-MAC assoc., has properties:
> > > - IPv4 IP
> > > - MAC mac
> > >  
> > > DtoBridge, add property to enable/disable the usage of the ARP cache.
> > > - boolean arpCacheEnabled
> > > - 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?
> > >  
> > > All new properties should also have the associated getters and setters.
> > >  
> > > * ZK path:
> > >  
> > > /bridges/[bridgeId]/arp_cache
> >  
> >  
> > Would snooped entries show up here too? If so, DtoArpCacheEntry may need field(s) to indicate the type of entry and the time-to-live for snooped ones.  
> >  
> > One more thing, under this directories, would entries have a uuid or be identified by the IP address. I'd go for the latter to eliminate the possibility of duplicates.  
> >  
> >   
> > >  
> > > * Operations:
> > >  
> > > GET all entries:
> > > - against /bridges/[bridgeId]/arp_cache
> > > - returns a Collection<DtoArpCacheEntry> that represents the entries
> > > of the ARP cache on the bridge with id bridgeId.
> > >  
> > > PUT an entry:
> > > - against /bridges/[bridgeId]/arp_cache, adds or replaces an entry
> > > - returns the new entry
> > >  
> > > DELETE an entry
> > > - against /bridges/[bridgeId]/arp_cache, removes the entry if exists.
> > >  
> > > Not sure if we also want:
> > >  
> > > DELETE all entries (if it's needed)
> > > - against /bridges/[bridgeId]/arp_cache, removes ALL the entries.
> > >  
> > >  
> > > ------------------------------------------------------------------------------------------------
> > >  
> > > * Feature description
> > >  
> > > The Virtual Bridge implements an (optional) ARP cache.
> > > NOTE: IPv4 only.
> > >  
> > > When the bridge detects an ARP request, if the reply can be generated
> > > from its ARP cache, it does so and sends it as a unicast to the source
> > > of the request. Otherwise, the request is forwarded according to
> > > normal bridging rules.
> > >  
> > > Population of the ARP cache may be accomplished via:
> > > - the REST API (high priority)
> > > - snooping on ARP replies (low priority)
> > >  
> > > * Core team responsibilities
> > > - Propose REST API changes to enable/disable the ARP cache, view its
> > > contents, manipulate its contents.
> > > - Design the ZK schema changes (should be backwards compatible)
> > > - Implement the feature in the API server and Midolman.
> > >  
> > > * Integration team responsibilities
> > > - Collaborate with Core team on API design.
> > > - Design/Implement ARP cache pre-seeding using OpenStack port/mac/ip
> > > information.
> > >  
> > > * GUI/management team responsibilities
> > > - What frames/pages need to change?
> > > - What new pages? One to display the ARP cache contents?
> > >  
> > > * Q/A team responsibilities
> > >  
> > > - Normal vetting of the software. No new tests needed because this is
> > > an optimization that should not be noticed at a user/functional level
> > > in OpenStack.
> > >  
> > > * Schedule
> > > - Agree on API changes by Feb. 11
> > > - Core team delivers untested implementation by Feb 18
> > > - Core team completes tests by Feb. 25
> > > - Integration team completes integration changes (Diyari/Grizzly) by Feb. 25
> > > - QA vets release by Mar. 1
> > >  
> > >  
> > > Thanks!
> > > Galo
> >  
> >  
> >  
> > --  
> > -- Guillermo Ontañón  

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


More information about the MidoNet-dev mailing list