Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters
Hi Mathieu, please see my comments below. On Wed, 2014-08-27 at 16:13 +0200, Mathieu Rohon wrote: hi irena, in the proposal of andreas you want to enforce the non-promisc mode per l2-agent? yes, kind of. We're currently not yet sure how to figure out the right interface for the registration. In the worst case it would be another config parameter saying register macs on ethx. But maybe there's a better automated way. We need to have a closer look at this. so every port managed by this agent will have to be in a non-promisc state? at a first read of the mail, I understood that you want to manage that per port with an extension. I guess you came to that conclusion as I was mentioning only in vlan and flat networking, right? This applies at least for my use case, but I do not yet have full insight into the sriov use case of Irena. But if it's also only for vlan and flat networking, an extension might be a good option. But we need a better understanding of the problem and of the extension framework first! Thanks for your hint! By using an extension, an agent could host promisc and non-promisc net-adapters, and other MD could potentially leverage this info (at least LB MD). On Wed, Aug 27, 2014 at 3:45 PM, Irena Berezovsky ire...@mellanox.com wrote: Hi Mathieu, We had a short discussion with Andreas about the use case stated below and also considered the SR-IOV related use case. It seems that all required changes can be encapsulated in the L2 OVS agent, since it requires to add fdb mac registration on adapted interface. What was your idea related to extension manager in ML2? Thanks, Irena -Original Message- From: Mathieu Rohon [mailto:] Sent: Wednesday, August 27, 2014 3:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters you probably should consider using the future extension manager in ML2 : https://review.openstack.org/#/c/89211/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters
you probably should consider using the future extension manager in ML2 : https://review.openstack.org/#/c/89211/ On Mon, Aug 25, 2014 at 12:54 PM, Irena Berezovsky ire...@mellanox.com wrote: Hi Andreas, We can definitely set some time to discuss this. I am usually available from 5 to 14:00 UTC. Let's follow up on IRC (irenab). BR, Irena -Original Message- From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] Sent: Monday, August 25, 2014 11:00 AM To: Irena Berezovsky Cc: OpenStack Development Mailing List (not for usage questions) Subject: RE: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters Hi Irena, thanks for your reply. Yes sure, collaboration would be great. Do you already have a blueprint out there? Maybe wen can synchup this week to discuss more details? Cause I would like to understand what exactly you're looking for. Normally I'm available form 7 UTC to 16 utc (today only until 13 utc). My irc name is scheuran. Maybe we can get in contact this week! You also where talking about sriov. I saw some blueprint mentioning sriov macvtap. Do you have any insights into this one, too? What we also would like to do is to introduce macvtap as network virtualization option. Macvtap also registers mac addresses to network adapters... Thanks, Andreas On Sun, 2014-08-24 at 08:51 +, Irena Berezovsky wrote: Hi Andreas, Thank you for this initiative. We were looking on similar problem for mixing OVS and SR-IOV on same network adapter, which also requires mac addresses registration of OVS ports. Please let me know if you would like to collaborate on this effort. BR, Irena -Original Message- From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] Sent: Friday, August 22, 2014 11:16 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters Thanks for your feedback. No, I do not yet have code for it. Just wanted to get a feeling if such a feature would get acceptance in the community. But if that helps I can sit down and start some prototyping while I'm preparing a blueprint spec in parallel. The main part of the implementation I wanted to do on my own to get more familiar with the code base and to get more in touch with the community. But of course advice and feedback of experienced neutron developers is essential! So I will proceed like this - Create a blueprint - Commit first pieces of code to get early feedback (e.g. ask via the mailing list or irc) - Upload a spec (as soon as the repo is available for K) Does that make sense for you? Thanks, Andreas On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote: I think this sounds reasonable. Do you have code for this already, or are you looking for a developer to help implement it? On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring scheu...@linux.vnet.ibm.com wrote: Hi, last week I started discussing an extension to the existing neutron openvswitch agent to support network adapters that are not in promiscuous mode. Now I would like to enhance the round to get feedback from a broader audience via the mailing list. The Problem When driving vlan or flat networking, openvswitch requires an network adapter in promiscuous mode. Why not having promiscuous mode in your adapter? - Admins like to have full control over their environment and which network packets enter the system. - The network adapter just does not have support for it. What to do? Linux net-dev driver offer an interface to manually register additional mac addresses (also called secondary unicast addresses). Exploiting this one can register additional mac addresses to the network adapter. This also works via a well known ip user space tool. `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0` What to do in openstack? As neutron is aware of all the mac addresses that are in use it's the perfect candidate for doing the mac registrations. The idea is to modify the neutron openvswitch agent that it does the registration on port add and port remove via the bridge command. There would be a new optional configuration parameter, something like 'non-promisc-mode' that is by default set to false. Only when set to true, macs get manually registered. Otherwise the agent behaves like it does today. So I guess only very little changes to the agent code are required. From my current point of view we do not need any changes to the ml2 plug
Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters
hi irena, in the proposal of andreas you want to enforce the non-promisc mode per l2-agent? so every port managed by this agent will have to be in a non-promisc state? at a first read of the mail, I understood that you want to manage that per port with an extension. By using an extension, an agent could host promisc and non-promisc net-adapters, and other MD could potentially leverage this info (at least LB MD). On Wed, Aug 27, 2014 at 3:45 PM, Irena Berezovsky ire...@mellanox.com wrote: Hi Mathieu, We had a short discussion with Andreas about the use case stated below and also considered the SR-IOV related use case. It seems that all required changes can be encapsulated in the L2 OVS agent, since it requires to add fdb mac registration on adapted interface. What was your idea related to extension manager in ML2? Thanks, Irena -Original Message- From: Mathieu Rohon [mailto:] Sent: Wednesday, August 27, 2014 3:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters you probably should consider using the future extension manager in ML2 : https://review.openstack.org/#/c/89211/ On Mon, Aug 25, 2014 at 12:54 PM, Irena Berezovsky ire...@mellanox.com wrote: Hi Andreas, We can definitely set some time to discuss this. I am usually available from 5 to 14:00 UTC. Let's follow up on IRC (irenab). BR, Irena -Original Message- From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] Sent: Monday, August 25, 2014 11:00 AM To: Irena Berezovsky Cc: OpenStack Development Mailing List (not for usage questions) Subject: RE: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters Hi Irena, thanks for your reply. Yes sure, collaboration would be great. Do you already have a blueprint out there? Maybe wen can synchup this week to discuss more details? Cause I would like to understand what exactly you're looking for. Normally I'm available form 7 UTC to 16 utc (today only until 13 utc). My irc name is scheuran. Maybe we can get in contact this week! You also where talking about sriov. I saw some blueprint mentioning sriov macvtap. Do you have any insights into this one, too? What we also would like to do is to introduce macvtap as network virtualization option. Macvtap also registers mac addresses to network adapters... Thanks, Andreas On Sun, 2014-08-24 at 08:51 +, Irena Berezovsky wrote: Hi Andreas, Thank you for this initiative. We were looking on similar problem for mixing OVS and SR-IOV on same network adapter, which also requires mac addresses registration of OVS ports. Please let me know if you would like to collaborate on this effort. BR, Irena -Original Message- From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] Sent: Friday, August 22, 2014 11:16 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters Thanks for your feedback. No, I do not yet have code for it. Just wanted to get a feeling if such a feature would get acceptance in the community. But if that helps I can sit down and start some prototyping while I'm preparing a blueprint spec in parallel. The main part of the implementation I wanted to do on my own to get more familiar with the code base and to get more in touch with the community. But of course advice and feedback of experienced neutron developers is essential! So I will proceed like this - Create a blueprint - Commit first pieces of code to get early feedback (e.g. ask via the mailing list or irc) - Upload a spec (as soon as the repo is available for K) Does that make sense for you? Thanks, Andreas On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote: I think this sounds reasonable. Do you have code for this already, or are you looking for a developer to help implement it? On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring scheu...@linux.vnet.ibm.com wrote: Hi, last week I started discussing an extension to the existing neutron openvswitch agent to support network adapters that are not in promiscuous mode. Now I would like to enhance the round to get feedback from a broader audience via the mailing list. The Problem When driving vlan or flat networking, openvswitch requires an network adapter in promiscuous mode. Why not having promiscuous mode in your adapter? - Admins like to have full control over their environment and which network packets enter the system. - The network adapter just does not have support for it. What to do? Linux net-dev driver offer an interface to manually register additional
Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters
Hi Irena, thanks for your reply. Yes sure, collaboration would be great. Do you already have a blueprint out there? Maybe wen can synchup this week to discuss more details? Cause I would like to understand what exactly you're looking for. Normally I'm available form 7 UTC to 16 utc (today only until 13 utc). My irc name is scheuran. Maybe we can get in contact this week! You also where talking about sriov. I saw some blueprint mentioning sriov macvtap. Do you have any insights into this one, too? What we also would like to do is to introduce macvtap as network virtualization option. Macvtap also registers mac addresses to network adapters... Thanks, Andreas On Sun, 2014-08-24 at 08:51 +, Irena Berezovsky wrote: Hi Andreas, Thank you for this initiative. We were looking on similar problem for mixing OVS and SR-IOV on same network adapter, which also requires mac addresses registration of OVS ports. Please let me know if you would like to collaborate on this effort. BR, Irena -Original Message- From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] Sent: Friday, August 22, 2014 11:16 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters Thanks for your feedback. No, I do not yet have code for it. Just wanted to get a feeling if such a feature would get acceptance in the community. But if that helps I can sit down and start some prototyping while I'm preparing a blueprint spec in parallel. The main part of the implementation I wanted to do on my own to get more familiar with the code base and to get more in touch with the community. But of course advice and feedback of experienced neutron developers is essential! So I will proceed like this - Create a blueprint - Commit first pieces of code to get early feedback (e.g. ask via the mailing list or irc) - Upload a spec (as soon as the repo is available for K) Does that make sense for you? Thanks, Andreas On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote: I think this sounds reasonable. Do you have code for this already, or are you looking for a developer to help implement it? On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring scheu...@linux.vnet.ibm.com wrote: Hi, last week I started discussing an extension to the existing neutron openvswitch agent to support network adapters that are not in promiscuous mode. Now I would like to enhance the round to get feedback from a broader audience via the mailing list. The Problem When driving vlan or flat networking, openvswitch requires an network adapter in promiscuous mode. Why not having promiscuous mode in your adapter? - Admins like to have full control over their environment and which network packets enter the system. - The network adapter just does not have support for it. What to do? Linux net-dev driver offer an interface to manually register additional mac addresses (also called secondary unicast addresses). Exploiting this one can register additional mac addresses to the network adapter. This also works via a well known ip user space tool. `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0` What to do in openstack? As neutron is aware of all the mac addresses that are in use it's the perfect candidate for doing the mac registrations. The idea is to modify the neutron openvswitch agent that it does the registration on port add and port remove via the bridge command. There would be a new optional configuration parameter, something like 'non-promisc-mode' that is by default set to false. Only when set to true, macs get manually registered. Otherwise the agent behaves like it does today. So I guess only very little changes to the agent code are required. From my current point of view we do not need any changes to the ml2 plug-in. Blueprint or a bug? I guess it's a blueprint. What's the timeframe? K would be great. I would be thankful for any feedback on this! Feel free to contact me anytime. Thanks in advance! Regards, Andreas (irc: scheuran) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org
Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters
Hi Andreas, We can definitely set some time to discuss this. I am usually available from 5 to 14:00 UTC. Let's follow up on IRC (irenab). BR, Irena -Original Message- From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] Sent: Monday, August 25, 2014 11:00 AM To: Irena Berezovsky Cc: OpenStack Development Mailing List (not for usage questions) Subject: RE: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters Hi Irena, thanks for your reply. Yes sure, collaboration would be great. Do you already have a blueprint out there? Maybe wen can synchup this week to discuss more details? Cause I would like to understand what exactly you're looking for. Normally I'm available form 7 UTC to 16 utc (today only until 13 utc). My irc name is scheuran. Maybe we can get in contact this week! You also where talking about sriov. I saw some blueprint mentioning sriov macvtap. Do you have any insights into this one, too? What we also would like to do is to introduce macvtap as network virtualization option. Macvtap also registers mac addresses to network adapters... Thanks, Andreas On Sun, 2014-08-24 at 08:51 +, Irena Berezovsky wrote: Hi Andreas, Thank you for this initiative. We were looking on similar problem for mixing OVS and SR-IOV on same network adapter, which also requires mac addresses registration of OVS ports. Please let me know if you would like to collaborate on this effort. BR, Irena -Original Message- From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] Sent: Friday, August 22, 2014 11:16 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters Thanks for your feedback. No, I do not yet have code for it. Just wanted to get a feeling if such a feature would get acceptance in the community. But if that helps I can sit down and start some prototyping while I'm preparing a blueprint spec in parallel. The main part of the implementation I wanted to do on my own to get more familiar with the code base and to get more in touch with the community. But of course advice and feedback of experienced neutron developers is essential! So I will proceed like this - Create a blueprint - Commit first pieces of code to get early feedback (e.g. ask via the mailing list or irc) - Upload a spec (as soon as the repo is available for K) Does that make sense for you? Thanks, Andreas On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote: I think this sounds reasonable. Do you have code for this already, or are you looking for a developer to help implement it? On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring scheu...@linux.vnet.ibm.com wrote: Hi, last week I started discussing an extension to the existing neutron openvswitch agent to support network adapters that are not in promiscuous mode. Now I would like to enhance the round to get feedback from a broader audience via the mailing list. The Problem When driving vlan or flat networking, openvswitch requires an network adapter in promiscuous mode. Why not having promiscuous mode in your adapter? - Admins like to have full control over their environment and which network packets enter the system. - The network adapter just does not have support for it. What to do? Linux net-dev driver offer an interface to manually register additional mac addresses (also called secondary unicast addresses). Exploiting this one can register additional mac addresses to the network adapter. This also works via a well known ip user space tool. `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0` What to do in openstack? As neutron is aware of all the mac addresses that are in use it's the perfect candidate for doing the mac registrations. The idea is to modify the neutron openvswitch agent that it does the registration on port add and port remove via the bridge command. There would be a new optional configuration parameter, something like 'non-promisc-mode' that is by default set to false. Only when set to true, macs get manually registered. Otherwise the agent behaves like it does today. So I guess only very little changes to the agent code are required. From my current point of view we do not need any changes to the ml2 plug-in. Blueprint or a bug? I guess it's a blueprint
Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters
Hi Andreas, Thank you for this initiative. We were looking on similar problem for mixing OVS and SR-IOV on same network adapter, which also requires mac addresses registration of OVS ports. Please let me know if you would like to collaborate on this effort. BR, Irena -Original Message- From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] Sent: Friday, August 22, 2014 11:16 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters Thanks for your feedback. No, I do not yet have code for it. Just wanted to get a feeling if such a feature would get acceptance in the community. But if that helps I can sit down and start some prototyping while I'm preparing a blueprint spec in parallel. The main part of the implementation I wanted to do on my own to get more familiar with the code base and to get more in touch with the community. But of course advice and feedback of experienced neutron developers is essential! So I will proceed like this - Create a blueprint - Commit first pieces of code to get early feedback (e.g. ask via the mailing list or irc) - Upload a spec (as soon as the repo is available for K) Does that make sense for you? Thanks, Andreas On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote: I think this sounds reasonable. Do you have code for this already, or are you looking for a developer to help implement it? On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring scheu...@linux.vnet.ibm.com wrote: Hi, last week I started discussing an extension to the existing neutron openvswitch agent to support network adapters that are not in promiscuous mode. Now I would like to enhance the round to get feedback from a broader audience via the mailing list. The Problem When driving vlan or flat networking, openvswitch requires an network adapter in promiscuous mode. Why not having promiscuous mode in your adapter? - Admins like to have full control over their environment and which network packets enter the system. - The network adapter just does not have support for it. What to do? Linux net-dev driver offer an interface to manually register additional mac addresses (also called secondary unicast addresses). Exploiting this one can register additional mac addresses to the network adapter. This also works via a well known ip user space tool. `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0` What to do in openstack? As neutron is aware of all the mac addresses that are in use it's the perfect candidate for doing the mac registrations. The idea is to modify the neutron openvswitch agent that it does the registration on port add and port remove via the bridge command. There would be a new optional configuration parameter, something like 'non-promisc-mode' that is by default set to false. Only when set to true, macs get manually registered. Otherwise the agent behaves like it does today. So I guess only very little changes to the agent code are required. From my current point of view we do not need any changes to the ml2 plug-in. Blueprint or a bug? I guess it's a blueprint. What's the timeframe? K would be great. I would be thankful for any feedback on this! Feel free to contact me anytime. Thanks in advance! Regards, Andreas (irc: scheuran) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters
Thanks for your feedback. No, I do not yet have code for it. Just wanted to get a feeling if such a feature would get acceptance in the community. But if that helps I can sit down and start some prototyping while I'm preparing a blueprint spec in parallel. The main part of the implementation I wanted to do on my own to get more familiar with the code base and to get more in touch with the community. But of course advice and feedback of experienced neutron developers is essential! So I will proceed like this - Create a blueprint - Commit first pieces of code to get early feedback (e.g. ask via the mailing list or irc) - Upload a spec (as soon as the repo is available for K) Does that make sense for you? Thanks, Andreas On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote: I think this sounds reasonable. Do you have code for this already, or are you looking for a developer to help implement it? On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring scheu...@linux.vnet.ibm.com wrote: Hi, last week I started discussing an extension to the existing neutron openvswitch agent to support network adapters that are not in promiscuous mode. Now I would like to enhance the round to get feedback from a broader audience via the mailing list. The Problem When driving vlan or flat networking, openvswitch requires an network adapter in promiscuous mode. Why not having promiscuous mode in your adapter? - Admins like to have full control over their environment and which network packets enter the system. - The network adapter just does not have support for it. What to do? Linux net-dev driver offer an interface to manually register additional mac addresses (also called secondary unicast addresses). Exploiting this one can register additional mac addresses to the network adapter. This also works via a well known ip user space tool. `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0` What to do in openstack? As neutron is aware of all the mac addresses that are in use it's the perfect candidate for doing the mac registrations. The idea is to modify the neutron openvswitch agent that it does the registration on port add and port remove via the bridge command. There would be a new optional configuration parameter, something like 'non-promisc-mode' that is by default set to false. Only when set to true, macs get manually registered. Otherwise the agent behaves like it does today. So I guess only very little changes to the agent code are required. From my current point of view we do not need any changes to the ml2 plug-in. Blueprint or a bug? I guess it's a blueprint. What's the timeframe? K would be great. I would be thankful for any feedback on this! Feel free to contact me anytime. Thanks in advance! Regards, Andreas (irc: scheuran) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters
Hi, last week I started discussing an extension to the existing neutron openvswitch agent to support network adapters that are not in promiscuous mode. Now I would like to enhance the round to get feedback from a broader audience via the mailing list. The Problem When driving vlan or flat networking, openvswitch requires an network adapter in promiscuous mode. Why not having promiscuous mode in your adapter? - Admins like to have full control over their environment and which network packets enter the system. - The network adapter just does not have support for it. What to do? Linux net-dev driver offer an interface to manually register additional mac addresses (also called secondary unicast addresses). Exploiting this one can register additional mac addresses to the network adapter. This also works via a well known ip user space tool. `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0` What to do in openstack? As neutron is aware of all the mac addresses that are in use it's the perfect candidate for doing the mac registrations. The idea is to modify the neutron openvswitch agent that it does the registration on port add and port remove via the bridge command. There would be a new optional configuration parameter, something like 'non-promisc-mode' that is by default set to false. Only when set to true, macs get manually registered. Otherwise the agent behaves like it does today. So I guess only very little changes to the agent code are required. From my current point of view we do not need any changes to the ml2 plug-in. Blueprint or a bug? I guess it's a blueprint. What's the timeframe? K would be great. I would be thankful for any feedback on this! Feel free to contact me anytime. Thanks in advance! Regards, Andreas (irc: scheuran) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters
I think this sounds reasonable. Do you have code for this already, or are you looking for a developer to help implement it? On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring scheu...@linux.vnet.ibm.com wrote: Hi, last week I started discussing an extension to the existing neutron openvswitch agent to support network adapters that are not in promiscuous mode. Now I would like to enhance the round to get feedback from a broader audience via the mailing list. The Problem When driving vlan or flat networking, openvswitch requires an network adapter in promiscuous mode. Why not having promiscuous mode in your adapter? - Admins like to have full control over their environment and which network packets enter the system. - The network adapter just does not have support for it. What to do? Linux net-dev driver offer an interface to manually register additional mac addresses (also called secondary unicast addresses). Exploiting this one can register additional mac addresses to the network adapter. This also works via a well known ip user space tool. `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0` What to do in openstack? As neutron is aware of all the mac addresses that are in use it's the perfect candidate for doing the mac registrations. The idea is to modify the neutron openvswitch agent that it does the registration on port add and port remove via the bridge command. There would be a new optional configuration parameter, something like 'non-promisc-mode' that is by default set to false. Only when set to true, macs get manually registered. Otherwise the agent behaves like it does today. So I guess only very little changes to the agent code are required. From my current point of view we do not need any changes to the ml2 plug-in. Blueprint or a bug? I guess it's a blueprint. What's the timeframe? K would be great. I would be thankful for any feedback on this! Feel free to contact me anytime. Thanks in advance! Regards, Andreas (irc: scheuran) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
