[MidoNet-dev] API proposal - Optional Bridge ARP Cache
Pino de Candia
gdecandia at midokura.com
Tue Feb 12 23:11:49 UTC 2013
On Tuesday, February 12, 2013 at 6:49 PM, Guillermo Ontañón wrote:
> On Tue, Feb 12, 2013 at 3:09 PM, Navarro, Galo <galo at midokura.com (mailto:galo at midokura.com)> wrote:
> > 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?
> Good point, I don't think it's necessary, it would work as the ArpTable in the router does: the node that writes the entry is in charge of expiration. If the node shuts down, the entry is automatically removed by zookeeper (it's an ephemeral node).
> BTW, this just made think, would it make sense to expose other pieces of state such as the router's ArpTable or the bridge's MacLearningTable through the REST API?
Rossella recently wrote a proposal to extend the API to read/write the Bridge's MAC table.
It seems that if we're adding an ArpTable to the bridge, and exposing it via the API it should be easy to extend the Router's ArpTable and use the code for both.
That would leave the router's RoutingTable, which is in a single ZK directory, but it's not exposed via the API. Definitely worth doing though.
> -- Guillermo Ontañón
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MidoNet-dev