qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kenton Cabiness <kenton.cabiness@alcatel-lucent.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Guest NIC interfaces always operate in promiscuous mode?
Date: Fri, 14 Oct 2011 14:05:49 -0500	[thread overview]
Message-ID: <4E98880D.4020201@alcatel-lucent.com> (raw)


We have been seeing some unexpected behavior in our guests 
(configuration details below).  We have a configuration where we have 
redundant networks configured in our guests and use IPM to control the 
network routing over these networks (this is a port of a redundant high 
availability Linux configuration onto virtualized HW platform).  This 
IPM process works by binding to raw TCP sockets and sending directed ARP 
messages to monitor condition of the network access of the guest.

Our networks are configured using bridges.  Our understanding is that 
bridges run in promiscuous mode by the nature of their operation.  Our 
guest NIC interfaces have promiscuous mode turned off (by looking at 
ifconfig output and looking in the device files), but the IPM process is 
receiving ARP messages that are directed to other MAC addresses (i.e. 
the NICs seem to be operating as if they have promiscuous mode turned 
on).  The only way we have been able to prevent this is by setting up 
network filters using the libvirt network filters to drop the unexpected 
messages (which seems to work OK).

Is this expected behavior?  We have searched and can't find any 
references to anyone having similar problems.  Our theory is that the 
bridge is operating in promiscuous mode and passing everything to the 
guest, and since there isn't any actual hardware to do the MAC 
filtering, the raw guest socket is getting everything passed by the bridge.

Is there any other way around this issue?  We are seeing some problems 
that seem like intermittent connectivity problems so we don't know if it 
is a performance issue with the filters or not, so we would like to be 
able to remove the filters if we could find a way to block these 
unwanted messages.

Thanks,
Kenton
===================================================
Specifics:
===========
Host OS:
     - RHEL 6.1 x64: (2.6.32-131.6.1.el6.x86_64)
     - qemu-kvm: qemu-kvm-0.12.1.2-2.160.el6_1.2.x86_64.rpm
     - libvirt: libvirt-0.8.7-18.el6.x86_64.rpm

Guest OS:
     - RHEL 5.6: (2.6.18-238.19.1.el5)

VM details:
     - 1 VM/guest on the host
     - VM size is 32GB ram and 10 cores (host has
         36GB and 12 cores total)
         - virtual disk drive is a local file on a RAID 1 disk
         - cpu pinning set to force each virtual core to
         a unique core (hyperthreading is turned on)
         - virtio for storage and network devices
     - have 16 ethernet devices tied to 16 bridges
       mapped to 2 NICS on the host
     - Use of iPXE and SGA bios for VM.

                 reply	other threads:[~2011-10-14 19:05 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E98880D.4020201@alcatel-lucent.com \
    --to=kenton.cabiness@alcatel-lucent.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).