Virtual interfaces are entering/leaving promiscuous mode

[aaronjwood]

For some containers that are launched and stopped or killed (due to errors with what's running inside of them) I'm seeing logs that the virtual interfaces are entering and leaving promiscuous mode. These containers are running with the normal bridge networking mode. Example:

device veth0bb1f1f entered promiscuous mode
device veth0bb1f1f left promiscuous mode

Most of the containers aren't running with any special privileges or capabilities. There is one that runs with --privileged but it exhibits the same behavior as all the others. Another thing to note is that none of the other interfaces on the host are in promiscuous mode.

What could be causing this. It doesn't seem to be consistent and I have been unable to reproduce it on a Ubuntu machine with the same Docker version. Here's some info about the environment it's happening in:

docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef-dirty
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef-dirty

docker info
Containers: 14
Images: 271
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Kernel Version: 3.19.3
Operating System: CoreOS 647.0.0
CPUs: 40
Total Memory: 125.9 GiB

uname -a
Linux 3.19.3 #2 SMP Thu Apr 9 01:47:33 UTC 2015 x86_64 Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz GenuineIntel GNU/Linux

[GordonTheTurtle]

Hi!

Please read this important information about creating issues.

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.

If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.

This is an automated, informational response.

Thank you.

For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

---

BUG REPORT INFORMATION

Use the commands below to provide key information from your environment:

docker version:
docker info:
uname -a:

Provide additional environment details (AWS, VirtualBox, physical, etc.):

List the steps to reproduce the issue:
1.
2.
3.

Describe the results you received:

Describe the results you expected:

Provide additional info you think is important:

----------END REPORT ---------

#ENEEDMOREINFO

[cpuguy83]

Seems like something on the host may be doing this...
But in any case, the latest release of docker, 1.7, includes a complete rewrite of Docker's networking code.
It would be good to upgrade to 1.7 so we can troubleshoot against the existing code base.

[aaronjwood]

Thanks. That's on our roadmap but we won't be getting to it until maybe a month or two from now.
I'll do some testing on a pristine CoreOS VM and see if it's specific to CoreOS (though I doubt that's the issue)

[aaronjwood]

Surprise, surprise. This does seem to be the default behavior on CoreOS. Closing this as invalid :)

EDIT: in case anyone is interested all I did was setup a fresh CoreOS VM using https://coreos.com/os/docs/latest/booting-on-vagrant.html and started/stopped a Ubuntu container a bunch of times. I found the same messages about the virtual interfaces being in promiscuous mode with sudo journalctl | grep promiscuous

EDIT: @mrjana is correct. I was not looking in the right place on the other Linux variants that I was testing this on. These messages are there, just run dmesg

[mrjana]

@aaronjwood This is how things work when you connect a particular interface to a bridge. In this case the host end of the veth pair is getting connected to the bridge and when you are a bridge port you cannot only receive packets for your own mac address. You need to receive packets destined to any mac address so that the bridge can forward the packet out of the appropriate outgoing interface or flood it on every interface part of the bridge. So all of this is intentional

[aaronjwood]

@mrjana you're right. I wasn't looking in the right place on the other non-CoreOS variants. Thanks for the explanation.

[mansurali901]

I was able to fix this by using turning to privileged to off

administrator@gitlabrunner-prod01:~$ docker run --rm --privileged -t -d -p 23:22 --name ubuntu ubuntu