[MidoNet-dev] API proposal - Optional Bridge ARP Cache
ryu at midokura.com
Tue Feb 26 02:08:29 UTC 2013
On Tue, Feb 26, 2013 at 1:27 AM, Pino de Candia <gdecandia at midokura.com>wrote:
> I don't understand this. BridgePorts don't have the MAC/IP information of
> the VM-nic
> that's going to be attached. The DHCP information can help you with the
> ARP cache's
> mac/ip entries, but you would have to make decisions for the client
> (permanent entries or
> expiring? can they be over-written if we snoop the mac on a different ip?).
> Somehow, I'm not so worried about duplicate information. After all, ARP,
> learning and DHCP are separate concerns and would be separate in a real
> If we expose the contents of those maps/functions, then it should be easy
> to debug
> inconsistencies, and the API will be cleaner.
Sorry I misspoke in my previous email. There is no MAC/IPs information on
the bridge port, but I was wondering if it makes sense to add them to port
config. What I was thinking was, there would be two kinds of entries: the
expiring (learned) and non-expiring (API), and nothing in between. I
didn't think of the case in which clients would create ephemeral ARP cache
entry via API. Because of that, I thought that non-expiring entries could
be constructed as part of port config when these ports are created/updated.
I was also thinking that it would be nice to have IPs and MAC assigned to
each bridge port (this is equivalent to Quantum db model - A GET on the
port would get this information). So when the port updates with new
MAC/IPs, ARP cache is updated as well accordingly, and they are always
non-expiring since API sets these values. Everything else is the ARP cache
table are expiring because they are learned. My proposal is to stress
that, from the client point of view, it would seem as though only in very
unique situations (proxy ARP) you'd use the ARP cache API to modify the
behavior. Otherwise, it is mostly implicit (I'm considering updating ports
with IPs and MAC as non-ARP related operation). But I'm not really sold on
my own case as I haven't spent enough time on this part of MidoNet, and
perhaps more difficult to implement, so if others agree with the current
proposal, count my vote in as well.
I agree that DHCP should be considered a separate concern.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MidoNet-dev