Open Stack

Hi,

2013/4/11 Tomasz Paszkowski <ss7pro at gmail.com>

>
> 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's a good question which doesn't only concerns proxy-arp feature but also
VXLAN support...I suppose the agent could exit as it would be an incoherent
configuration, but the plugin should also check if VXLAN is enabled
globally in order to prevent provider network allocation if VXLAN is not
supported.

>  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 ?
>
> For now, 3 different alternatives were coming to my mind:
-A centralized approach where plugin distributes [mac, IP, VNID, agent_ip]
tuples to the agents (rpc distribution of these tuples could be triggered
by update_device_up/down) in this case plugin would need an additionnal DB
to track port to agents mappings, as well as agent_ips
-A distributed one where agent fanout_casts [mac, IP, VNID, agent_ip] to
other agents when a port becomes up. Agents having ports on the same
networks should answer with the properties of the ports they handle. To
achieve this agents should maintin a list of their ports.
-We could also think to use an external control plane: BGP may land in
quantum for VPNaaS, it could also be a good candidate to propagate VXLAN
neighbors infomations (see
http://tools.ietf.org/html/draft-boutros-l2vpn-vxlan-evpn-01)

> 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).
>
> Yes, but it'll remain an issue with provider networks: if several
physicalNetworks are declared, the same VNI could still be reserved on
different physicalNetworks...

> --
> Tomasz Paszkowski
> SS7, Asterisk, SAN, Datacenter, Cloud Computing
> +48500166299
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130411/6cb92e85/attachment.html>