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

Jacob Mandelson jlm at midokura.com
Wed Feb 13 21:53:11 UTC 2013

On Tue, Feb 12, 2013 at 3:11 PM, Pino de Candia <gdecandia at midokura.com>wrote:

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

Agreed.  If we're to support static, pre-set entries in the MLT, the ARP
caches, and the routing table (and why shouldn't we?), it makes perfect
sense to me to have these tables which are most of the devices' state
exposed by the API.  Might help network operators debug issues with the net
if they can see all this stuff easily, too.

      -- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20130213/2425d829/attachment.html>

More information about the MidoNet-dev mailing list