[MidoNet-dev] API proposal - Optional Bridge ARP Cache
galo at midokura.com
Tue Feb 12 14:09:07 UTC 2013
Thanks for the comments Guillermo, replies inline:
On 12 February 2013 11:14, Guillermo Ontañón <guillermo at midokura.jp> wrote:
> Hi Galo,
> Looks good, just one comment below,
> On Wed, Feb 6, 2013 at 2:02 PM, Navarro, Galo <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
>> 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:
> 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
Yes, all entries regardless of source. I agree that it'd be desirable
to have a type. Re. TTL I'd probably put an expiration time when the
entry is added since we'll probably have expiration also for
non-snooped entries. If the TTL varies based on type, the ARP cache
impl can set different values when adding the entry. This is more of
an implementation detail but should we worry about hosts running
midonet having significant time differences?
The DtoArpCacheEntry would be thus:
- IPv4 (identifier)
- MAC mac
- ArpCacheEntry.Type Type
- long? Expiration
> 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.
More information about the MidoNet-dev