<div dir="ltr">Hi,<div><br></div><div style>I made a PoC to the proxy ARP proposed solution.</div><div style>I made it on Folsom release with OVS+GRE driver.</div><div style>This PoC removing broadcast and multicast traffic on the l2. Only DHCP is authorized. The ARP traffic is DNATed to ARP proxy.</div>
<div style><br></div><div style>To do that, I add this openflow rules to the egress traffic of all port (in priority order):</div><div style>- Authorize BOOTP broadcast packets</div><div style>- MAC DNAT to the MAC ARP proxy for all ARP broadcast traffic</div>
<div style>- Drop all multicast and broadcast traffic</div><div style>- Drop all other traffic aren't having the MAC address of the proxy ARP as destination</div><div><br></div><div style>I'm working to edit a blueprint for this.</div>
<div style>I think it could be optional for l2 network and interesting to enable it to isolated ports on public network, for example.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Édouard.<br><br><div class="gmail_quote">
On Mon, Mar 18, 2013 at 10:53 AM, Rohon Mathieu <span dir="ltr"><<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
hi all,<br>
<br>
I don't know if removing l2 communication is a good point, since it's<br>
a potential regression, some application may need it.<br>
<br>
But I agree that mac learning could be prevented since<br>
Openstack/quantum already know about VM Mac/IP and placement.<br>
Mac table/Flow tables could be populated by a controller, you can<br>
adapt an openflow controller like ryu, floodlight or other to do so.<br>
But this functionnality should be used directly within OVS and LB<br>
plugin.<br>
Instead of populating mac tables, we could also use a proxy ARP, as a<br>
proxy-arp agent which would be populated by the Quantum-server.<br>
We could use the quantum scheduler to have multiple proxy-arp-agent.<br>
<div class=""><div class="h5"><br>
On Fri, Mar 15, 2013 at 11:54 PM, Tomasz Paszkowski <<a href="mailto:ss7pro@gmail.com">ss7pro@gmail.com</a>> wrote:<br>
> Connecting non broadcast network solution with LISP will also<br>
> eliminate need to build virtual mesh between compute hosts.<br>
><br>
> On Fri, Mar 15, 2013 at 11:50 PM, Tomasz Paszkowski <<a href="mailto:ss7pro@gmail.com">ss7pro@gmail.com</a>> wrote:<br>
>> I'am thinking about completely removing broadcast traffic from gre<br>
>> networks and ignore l2 addressing. It could be achieved by introducing<br>
>> openflow controller, which can make all the forwarding decisions<br>
>> (direct traffic to appropriate tunnels and interfaces on compute<br>
>> hosts). For IP/DHCP/ARP traffic this is very easy as we already know<br>
>> ip addresses of all vms , dhcp-agents, l3-agents. Questions is which<br>
>> openflow controller implementation to take and if we would like to<br>
>> build a central controller or a distributed one.<br>
>><br>
>> What do you think about this ?<br>
>><br>
>><br>
>> On Thu, Mar 14, 2013 at 9:59 AM, Rohon Mathieu <<a href="mailto:mathieu.rohon@gmail.com">mathieu.rohon@gmail.com</a>> wrote:<br>
>>> hi all,<br>
>>><br>
>>> I just wanted to share about a BP to limit broadcasting in every<br>
>>> tunnel while using OVS and GRE. This could also be used for VXLan<br>
>>> tunneling.<br>
>>><br>
>>> <a href="https://blueprints.launchpad.net/quantum/+spec/ovs-tunnel-partial-mesh" target="_blank">https://blueprints.launchpad.net/quantum/+spec/ovs-tunnel-partial-mesh</a><br>
>>><br>
>>> the specification show a call flow for the port creation.<br>
>>><br>
>>> Does anyone see something wrong in my architecture?<br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> --<br>
>> Tomasz Paszkowski<br>
>> SS7, Asterisk, SAN, Datacenter, Cloud Computing<br>
>> <a href="tel:%2B48500166299" value="+48500166299">+48500166299</a><br>
><br>
><br>
><br>
> --<br>
> Tomasz Paszkowski<br>
> SS7, Asterisk, SAN, Datacenter, Cloud Computing<br>
> <a href="tel:%2B48500166299" value="+48500166299">+48500166299</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>