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

Ishimoto, Ryu ryu at midokura.com
Sun Feb 24 05:08:10 UTC 2013


my comments inline:

On Fri, Feb 22, 2013 at 4:21 PM, Dave Cahill <dcahill at midokura.com> wrote:
>
>
> *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?
>
>
I think Dave is raising a really interesting point here.  Having a cloud
orchestration do pre-seeding of port/mac/ip creates duplicate data (DHCP,
ARP, Bridge MAC table).  Even if we leave DHCP as a separate service, are
there problems to construct both bridge mac table and ARP cache from the
current port configs in ZK?  A port config already has IP address and MAC
address fields.  I still think it's worth having a separate ARP cache API
but only for doing proxy ARP, as Dave mentioned;  The mapping in this table
set via REST API would simply override the implicit ARP cache created from
the port ZK configs, and they're always permanent entries.  This idea
probably has already been discussed and dismissed but I would love to hear
some explanation from the core team as I am most likely missing something.



> *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?
>
>
It's probably acceptable not to handle this case from the cloud integration
point of view, as it's the same with EC2, and it hasn't seem to cause
issues.  Can midolman handle this case without any explicit API calls right
now?

Ryu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20130224/ca5244bc/attachment.html>


More information about the MidoNet-dev mailing list