[Openstack] Duplicate ICMP due to public interface bridge being placed in promiscus mode

Brian Haley brian.haley at hp.com
Fri Oct 14 18:37:23 UTC 2011


On 10/14/2011 08:59 AM, Shyam Kaushik wrote:
> *Hi Vish,* 
> 
> In our openstack deployment we observe this:
> 
> Since linux_net.py/initialize_gateway_device()
> <http://linux_net.py/initialize_gateway_device()> does this
> 
>     # NOTE(vish): If the public interface is the same as the
>     #             bridge, then the bridge has to be in promiscuous
>     #             to forward packets properly.
> 
>     if(FLAGS.public_interface == dev):
>         _execute('ip', 'link', 'set',
>                      'dev', dev, 'promisc', 'on', run_as_root=True)
> 
> 
> Any VM spawned on the cloud controller node if it sends an ICMP ping to an
> external network gets duplicate replies (i.e. there are 2 replies for the same
> ICMP request). For VM’s spawned on any other non-cloud controller this doesn’t
> happen.
> 
> If we turn of promiscus mode on the bridge, the VM on cloud controller doesn’t
> see the duplicate replies, but VM’s on non-cloud controller cannot reach
> external network.
> 
> Question to you is, is this duplicate ICMP replies expected for VM’s running on
> cloud controller due to above logic?

I've seen duplicate packets in one of our configs, if I explain how maybe it
will help here.

1. Create a bridge, and set the MAC with /sbin/ip, for example:

	'ip link set dev br123 address 00:00:00:00:11:11'

2. Start a VM and attach it to that bridge.  Try to communicate with it, but you
can't, since the MAC of the bridge doesn't match the MAC of any device attached
to it.

3. Set the bridge in promiscuous mode - 'ip link set dev br123 promisc on'.
Things work, but the side-effect is duplicated packets.

There's a RHEL but against libvirt that talks about it, and I believe there's a
patch upstream that fixes it by adding a dummy tap device (so the bridge and one
device share the same MAC), which lets you turn-off promisc.

https://bugzilla.redhat.com/show_bug.cgi?id=609463

So I think the answer is that if you want a stable MAC on a bridge that doesn't
match an existing tap device, turning-on promisc is a bad idea to make things work.

Hope that helps,

-Brian




More information about the Openstack mailing list