<div dir="ltr">I think this sounds reasonable. Do you have code for this already, or are you looking for a developer to help implement it?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring <span dir="ltr"><<a href="mailto:scheuran@linux.vnet.ibm.com" target="_blank">scheuran@linux.vnet.ibm.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
last week I started discussing an extension to the existing neutron<br>
openvswitch agent to support network adapters that are not in<br>
promiscuous mode. Now I would like to enhance the round to get feedback<br>
from a broader audience via the mailing list.<br>
<br>
<br>
The Problem<br>
When driving vlan or flat networking, openvswitch requires an network<br>
adapter in promiscuous mode.<br>
<br>
<br>
Why not having promiscuous mode in your adapter?<br>
- Admins like to have full control over their environment and which<br>
network packets enter the system.<br>
- The network adapter just does not have support for it.<br>
<br>
<br>
What to do?<br>
Linux net-dev driver offer an interface to manually register additional<br>
mac addresses (also called secondary unicast addresses). Exploiting this<br>
one can register additional mac addresses to the network adapter. This<br>
also works via a well known ip user space tool.<br>
<br>
`bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`<br>
<br>
<br>
What to do in openstack?<br>
As neutron is aware of all the mac addresses that are in use it's the<br>
perfect candidate for doing the mac registrations. The idea is to modify<br>
the neutron openvswitch agent that it does the registration on "port<br>
add" and "port remove" via the bridge command.<br>
There would be a new optional configuration parameter, something like<br>
'non-promisc-mode' that is by default set to false. Only when set to<br>
true, macs get manually registered. Otherwise the agent behaves like it<br>
does today. So I guess only very little changes to the agent code are<br>
required. From my current point of view we do not need any changes to<br>
the ml2 plug-in.<br>
<br>
<br>
Blueprint or a bug?<br>
I guess it's a blueprint.<br>
<br>
What's the timeframe?<br>
K would be great.<br>
<br>
<br>
<br>
I would be thankful for any feedback on this! Feel free to contact me<br>
anytime. Thanks in advance!<br>
<br>
Regards,<br>
Andreas<br>
<br>
(irc: scheuran)<br>
<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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>