Bug 696730

Summary:	virtio on guest, connected to bridged physical interface can't get full data from tcpdump
Product:	Red Hat Enterprise Linux 5	Reporter:	Jay Rishel <jay>
Component:	kvm	Assignee:	Amos Kong <akong>
Status:	CLOSED WORKSFORME	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	5.5	CC:	ailan, akong, gcosta, juzhang, mkenneth, roland.friedwagner, virt-maint, xfu
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-08-09 02:15:00 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	580948

Description Jay Rishel 2011-04-14 18:05:10 UTC

Description of problem:
needed to run a RHEL4.8 instance on newer, unsupported hardware, decided to virtualize it.  Set up a RHEL5.5 KVM hypervisor host, setup up two bridge devices, br0 connected to eth0, for regular tcp/ip access to the system, and br1 connected to eth3 to allow the guest to do network sniffing.  The hardware was an HP ProLiant DL385 G7 with Broadcom network cards, using the bnx2 driver. 

Guest was installed and configured to use the virtio-net for both bridged connections. Tcpdump on the monitor connection (br1) did not return expected traffic, only a few mcast packets.

tried virtualbox, using same bridge connections and was able to get tcpdump packets as expected.

tried the kvm guest again with the e1000 driver, didn't work.  tried again with the ne2k_pci driver and were able to get correct tcpdump data.

Version-Release number of selected component (if applicable):
RHEL5.5

How reproducible:
everytime

Steps to Reproduce:
1. install a RHEL5.5 with KVM as hypervisor
2. setup up two bridged connections, one without an IP address
3. install a RHEL4.8 guest, using two virtio net connections.
4. try and sniff traffic on the un-IP assigned port.  not all packets will be seen.
5. switching the second connection to ne2k_pci hardware allows tcpdump to connect accurate packets.

  
Actual results:


Expected results:


Additional info:

Comment 1 juzhang 2011-04-15 01:54:43 UTC

Hi,Jay

   Would you please provide kvm version via "rpm -qa | grep kvm"?
   
   Thanks

Comment 2 Jay Rishel 2011-04-15 12:30:33 UTC

version is 83-164.el5

Comment 3 Jay Rishel 2011-04-15 17:35:04 UTC

update on this issue, the ne2k_pci driver is better, but still only seeing about half the packets we see on the raw interface, or what is seen in virtualbox.

Comment 5 Michael S. Tsirkin 2011-05-16 21:55:52 UTC

I think tcpdump on the bridge is not what you want.
Since you say br1, is this what you do?
I think this only dumps packets destined at the bridge.

tcpdump should be done on the tap interface.
If what you do is tcpdump -i <bridge>
I'm surprised ne2k_pci somehow makes a difference.

Could you pls supply
-command line for qemu with ne2k_pci and with e1000
-ifconfig -a; brctl show; brctl showmacs br0; brctl showmacs br1 on host
-ifconfig -a on guest in both cases

Thanks!

Comment 6 Michael S. Tsirkin 2011-05-16 21:56:58 UTC

correction to prev post: virtio-net, not e1000 as that
is what the question is about.

Comment 7 Jay Rishel 2011-05-17 12:18:30 UTC

unfortunately, I don't have access to the system to run further tests, as we went into production with the virtualbox solution. I'll try and see if I can get some time on the qual system reconfigure to test. but some clarifications:

we run tcpdump inside the virtual guest, which shows up as eth1, but on the hypervisor is eth3 bridged as br1.

ne2k_pci and virtio were configured via virt-manager, where should I look for the qemu commandline?

Comment 8 Glauber Costa 2011-06-01 23:14:37 UTC

qemu command line can be found at /var/log/libvirt/qemu/

Comment 9 Michael S. Tsirkin 2011-06-14 15:15:17 UTC

to Comment 7:
ps -elf will give you the command line

Comment 10 Michael S. Tsirkin 2011-06-14 15:19:34 UTC

Sorry confused
tcpdump in *guest* does not give you any data?
but networking works, right?
it just doesn't show up in tcpdump?

Comment 11 Amos Kong 2011-08-06 03:16:17 UTC

Hi juzhang,

Could you help to check if this bug can be reproduced with the latest kvm in your localhost? Please try to answer the questions in Comment #10. Thanks

Comment 12 FuXiangChun 2011-08-08 10:38:51 UTC

this bug cann't be reproduced with e1000 and ne2k_pci nics.

host info:
 # uname -r
2.6.18-274.el5
# rpm -qa|grep kvm
kvm-83-164.el5

guest info:
 rhel4.8(x86_64)

tested steps:

1. use two physical Nics to create two bridges(switch switch1) devices in host and don't assign ip address to bridge switch1

2. start guest with e1000 or ne2k_pci 
/usr/libexec/qemu-kvm -M rhel5.5.0 -m 4096 -smp 4,sockets=4,cores=1,threads=1 -name RHEL5u7 -uuid 13bd47ff-7458-a214-9c43-d311ed5ca5a3 -monitor stdio -no-kvm-pit-reinjection -boot c -drive file=test,if=virtio,format=qcow2,cache=none,boot=on -net nic,macaddr=54:52:00:52:ed:62,vlan=0,model=e1000 -net tap,script=/etc/qemu-ifup,downscript=no,vlan=0 -net nic,macaddr=00:1B:21:66:2A:63,vlan=1,model=e1000 -net tap,script=/etc/qemu-ifup1,downscript=no,vlan=1 -vnc :1 -balloon none -notify all -no-hpet -soundhw ac97

3. execute command "ping -I eth0 getway-ip" from guest and "tcpdump -i switch" from host
   actual result:
   bridge switch can get ICMP pachage from guest.
   IP 10.66.11.123 > 10.66.11.254: ICMP echo request, id 25627, seq 19, length 64

4. execute command "ping -I eth1 getway-ip" from guest and "tcpdump -i switch1" from host
   actual result:
   bridge switch1 can get ICMP package from guest too.
   IP 10.66.11.234 > 10.66.11.254: ICMP echo request, id 25883, seq 20, length 64 

notes: 1.if use ne2k_pci Nic to start guest, it will get the same result
       2.bridge switch and switch1 info
switch    Link encap:Ethernet  HWaddr 00:24:21:7F:B7:F9  
          inet addr:10.66.9.97  Bcast:10.66.11.255  Mask:255.255.252.0
          inet6 addr: fe80::224:21ff:fe7f:b7f9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:778338 errors:0 dropped:0 overruns:0 frame:0
          TX packets:984733 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:48241888 (46.0 MiB)  TX bytes:700105641 (667.6 MiB)

switch1   Link encap:Ethernet  HWaddr 00:1B:21:66:2A:ED  
          inet6 addr: fe80::21b:21ff:fe66:2aed/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:124814 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:6516501 (6.2 MiB)  TX bytes:3500 (3.4 KiB)

Comment 13 Amos Kong 2011-08-09 02:15:00 UTC

Confirmed with FuXiangChun, this bz also could not reproduce with virtio nic. I also got the same result as comment #12. so close this bug as WORKSFORME.