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).