Ask Your Question

Neutron: Solution without promiscuous mode

asked 2015-01-28 08:53:46 -0500

Herr-Herner gravatar image

updated 2015-01-28 10:04:36 -0500

We are trying to install OpenStack Juno in our Bladecenter. Unfortunately, we cannot activate the promiscuous mode for our external network interface for Neutron. Is there any solution possible (in the sense of Layer 2 NAT), that works without the promiscuous mode.

The problem is that there are other non-OpenStack VMs running in the Bladecenter. The IT says that the activation of the promiscuous mode gives us the capability to see the traffic of the other VMs running in the Bladecenter. Our security policies do not allow this.

I would guess that the promiscuous mode is required for Neutron. Under these circumstances, is there any configuration possible to get Neutron running (VLANs, ...)?


The problem is caused by ESX/ESXi and how the promiscuous mode works at the virtual switch and portgroup levels.

edit retag flag offensive close merge delete


What is the issue activating promiscuous mode on the external network interface on openstack blades? I presume the interface is br-ex or similar.

mickt gravatar imagemickt ( 2015-01-28 09:26:23 -0500 )edit

Our IT refers to this problem: (How promiscuous mode works at the vSwitch)

It seems to be not a problem of the bladecenter. It causes a security breach in VMware (ESX/ESXi) environments

Herr-Herner gravatar imageHerr-Herner ( 2015-01-28 09:46:00 -0500 )edit

I cannot access the link. So IT will not permit you to configure promiscuous mode on your openstack blades? Would doing so affect other non-openstack blades in the blade centre?

mickt gravatar imagemickt ( 2015-01-28 09:55:49 -0500 )edit

Right... They say that the VMware vSwitch would forward all L2 segments it has received to the interface running in promiscuous mode. A vSwitch is not a "normal" (learning) switch. We would receive even segments which are addressed to other VMs connected to the vSwitch.

Herr-Herner gravatar imageHerr-Herner ( 2015-01-28 09:59:10 -0500 )edit

I think this would not help. As far as I understood Neutron, L2 segments pass the external interface which do not carry the source mac address of this interface.

Herr-Herner gravatar imageHerr-Herner ( 2015-01-28 15:11:38 -0500 )edit

1 answer

Sort by ยป oldest newest most voted

answered 2015-01-28 13:12:34 -0500

darragh-oreilly gravatar image

updated 2015-01-28 13:12:48 -0500

I wonder could you do something like clone the neutron gateway mac onto the vmware port.

edit flag offensive delete link more


Sorry, but I do not understand how this should solve the problem. Could you please give me more details? Which Mac must be put to which interfaces? Our external network interface is connected to a vSwitch provided by ESX.

Herr-Herner gravatar imageHerr-Herner ( 2015-02-04 03:54:00 -0500 )edit

My idea is to change the vmware port to have the same mac address as the neutron router external gateway port.

darragh-oreilly gravatar imagedarragh-oreilly ( 2015-02-04 13:29:05 -0500 )edit

I have tried it, but it is only working with exactly one tenant, otherwise multiple gateway interfaces have the same mac address and packages are not forwarded to the requestors.

Herr-Herner gravatar imageHerr-Herner ( 2015-02-11 01:15:18 -0500 )edit

I don't know - maybe use a distinct vmware port for each gateway.

darragh-oreilly gravatar imagedarragh-oreilly ( 2015-02-11 07:26:49 -0500 )edit

That would be possible, but then we loose the ability to define your own network topology at runtime by the customer. Setting up gateways will not work until the provider "hacks" the mac address in the Neutron database.

Herr-Herner gravatar imageHerr-Herner ( 2015-02-16 03:15:12 -0500 )edit

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2015-01-28 08:53:46 -0500

Seen: 1,771 times

Last updated: Jan 28 '15