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

Dave Cahill dcahill at midokura.com
Fri Feb 22 07:21:51 UTC 2013


Hi all,

Joining the conversation in the hope that late is better than never - we'll
choose an integration team "feature reviewer" before the feedback deadline
passes next time. I've added myself on the wiki page as feature reviewer
for bridge ARP cache.

*Proxy ARP for free?*
There's a Trello card for proxy ARP [1] in the "M4 - Apr 1" release. Some
discussion of why the feature is useful in [2].

At first glance, I think we can support this using static bridge ARP cache
entries. For example, if IP A is reachable via the router, but we want
machines on the bridge to believe that IP A is local, we can set a static
entry of (IP A, router's MAC) on the bridge. Machines on the bridge should
then send packets for A direct to the router's MAC, and the router should
(I think) just route the packet to where it needs to go. I think this is
what Pino describes in Github issue #154 [3].

Does the bridge ARP cache feature give us proxy ARP for free? If it
doesn't, what am I missing? If it does, we should remove the other cardand
pat ourselves on the back for .

*Default behavior*
Is ARP cache enabled or disabled by default? If disabled by default, should
the integration code set it to enabled?

*Relation to DHCP*
One of the tasks listed for the integration team is "Design/Implement ARP
cache pre-seeding using OpenStack port/mac/ip information".

In integration code, we already set each new VM's IP / MAC in DHCP. We can
of course duplicate this info into the ARP cache, but:
Should the ARP cache just pull in DHCP entries instead?
If we do duplicate the info into the ARP cache, should we set these entries
as do-not-expire, or OK-to-overwrite?

*Physical bridge equivalent*
How does this ARP caching behavior compare to physical bridges? For
example, if I locally (e.g. using ifconfig on the machines) change VM A to
take VM B's IP, and VM B to take VM A's IP, I'd imagine a physical bridge
would realize that quickly and adapt. If we set ARP entries statically and
permanently, could that result in worse behavior (never adapts to the IP
address switch)? Or is changing your IP address statically / locally on the
VM just a weird case?

Thanks,
Dave.


[1] https://trello.com/card/proxy-arp/510b93ac787666573800291f/10
[2] https://github.com/midokura/midonet/issues/197
[3] https://github.com/midokura/midonet/issues/154

On Sat, Feb 16, 2013 at 2:02 AM, Pino de Candia <gdecandia at midokura.com>wrote:

> 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
>
>
> That seems like a good solution.
>
> I think also that sanitizing snooped entries as Rosella suggests would
> be desirable: for snooped entries, do not insert if MAC does not exist
> in MacLearningTable; when deleting MAC from MacLearningTable, remove
> cached entry.
>
> I'm not sure I see the value of this, and dislike the added complexity.
>
> Aside, we're only snooping on ARP request/reply, not other packet types,
> right?
>
> Regarding the snooped entry... the moment you've seen it, the MAC must
> have been
> added to the MacLearningTable, unless it conflicted with an existing
> non-over-writeable
> Mac table entry. But in that case the corresponding ARP cache entry should
> also be
> non-overwriteable...
>
> --Pino
>
>
> I will copy these improvements to the wiki, thanks!
> /g
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20130222/55f74194/attachment.html>


More information about the MidoNet-dev mailing list