Open Stack

On Thu, Apr 11, 2013 at 11:41 AM, Eleouet Francois <f.eleouet at gmail.com>wrote:

> Hi,
>

Hi,

>  Great! It opens new perspectives for Linuxbridge plugin!
>
> I was actually also trying to implement a VXLAN LinuxBridge extension
> leveraging the integrated proxy-ARP capabilities (this feature is supported
> in 3.8 kernel, which should be included in havana's timeline distributions).
>

Yes I have already seen this :-) I'm already working on this feature for
linuxbridge plugin :-) I'm still wondering what should be the behavior if
we detect that feature is not supported by the kernel but
agent is configured to use it. I don't know if I should just raise an
exception and exit agent or just produce error message. Do you have any
thoughts on that ?



>  It could be and alternative to dataplane-based learning, that may raise
> some scalability issues (see
> https://blueprints.launchpad.net/quantum/+spec/ovs-tunnel-partial-meshthat tries to solve generalized broadcast scalability issue on OVS pluging)
>
> It's pretty hard to figure out how to distribute [mac, IP, VNID, agent_ip]
> among agents to populate the proxy-arp, there are lots of alternatives... I
> was expecting to discuss about them during the summit (
> http://summit.openstack.org/cfp/details/263 should be a good place for
> that talk)
>

As i wrote some time ago on this ml, i believe that for most of the
enviroments we could go with non-broadcast,l3-switching-based addressing
ethernet networks and just forward all dhcp and arp packets to appropriate
nodes (when running with openvswitch module). But as you mentioned it's a
very difficult task to distribute appropriate data to the agents and update
flow tables. Do you already have some ideas you can share ?

Anyway, if two alternatives could merge peacefully, it seems to be is a
> small issue in your proposal: as you explained in linuxbridge_config.ini,
> VNIDs are globals in VXLAN module, putting them in NetworkState DB makes
> them allocatable on a per-physicalNetwork basis. It could raise (netlink)
> errors if several PhysicalNetworks are declared, wouldn't it be better to
> use a separate DB as OVS plugin does in TunnelAllocation? Or maybe
> modular-L2 should be revisited (
> https://blueprints.launchpad.net/quantum/+spec/modular-l2)?
>
I believe it's better to stay with mapping VNI to physical_networks as this
allows to bound VNIs range to a specific interface (this is not possible
within OVS plugin). The only thing I need to implement is simple check to
avoid overlapping VNI between different physical networks (this will be
done during quantum-server startup).


-- 
Tomasz Paszkowski
SS7, Asterisk, SAN, Datacenter, Cloud Computing
+48500166299
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130411/928543a4/attachment.html>