View Single Post
  #8  
Old 30th November 2009, 10:26 PM
PilotJLR Offline
Registered User
 
Join Date: Nov 2005
Location: flying a cubicle
Posts: 465
Quote:
Originally Posted by David Becker View Post
Did you just edit the file or did you edit the file and then restart networking or the machine?

Maybe you should do a traceroute from one guest to the other? Possibly while you're running 'tcpdump -i br0' on the host.

David
I did an "echo 1 > /proc/sys/net/ipv4/ip_forward" to turn on IP forwarding.

I will try doing the traceroute and tcpdump. I might not be able to do this until late afternoon / evening (central US), but I will report back!
Beaker - likewise, I will give that a shot and report back.

---------- Post added at 01:19 PM CST ---------- Previous post was at 11:27 AM CST ----------

Some more info...

I ran both a ping and a tracert (the guests are windows 2003 with no firewall) between 2 guests while running tcpdump on the host.
In each case, tcpdump DID list an ARP request from the guest initiating the ping. In each case, the ping target did not respond to the ARP (and did not send anything at all back).

Despite this, "brctl showmacs br0" does correctly list the MAC address of each guest.

---------- Post added at 02:16 PM CST ---------- Previous post was at 01:19 PM CST ----------

AH HA! It's not fixed, but it's getting closer.

If I manually add static ARP entries into EACH virtual machine, then they are able to communicate. I do not think this is due to blocking the ARP broadcast, because only 1 static entry (the ping source) was not successful. Once the ping ingresses to the destination, it's address should be learned... but it was not (or it was incorrect).

Which leads me to this question... why does the bridge show multiple MAC's per port?
Code:
# brctl showmacs br0
port no	mac addr		is local?	ageing timer
  1	00:15:af:75:9d:bb	no		  91.15
  1	00:19:d1:31:e9:e3	yes		   0.00
  1	00:22:6b:5f:1f:3d	no		   0.00
  1	00:23:32:c9:e9:f8	no		  63.07
  1	00:30:18:a9:b2:76	no		   0.39
  3	52:54:00:07:ca:6b	no		  62.55
  2	52:54:00:4c:c4:e0	no		  62.55
  3	ee:f2:a5:a1:58:33	yes		   0.00
  2	f6:32:32:3e:47:d8	yes		   0.00
The entries with "local" set to "no" are the correct ones, as shown inside the guest and in virt-manager.

The local "yes" entries are for vmnet0 and vmnet1... I'm not sure what these are!

---------- Post added at 03:26 PM CST ---------- Previous post was at 02:16 PM CST ----------

Problem Solved!

Thanks for the input, guys! Here is what it was.

Since I was using Windows Server 2003 guests, I chose to use a Intel e1000 virtual NIC, since that driver is included in 2003 by default and works well (oh physical hardware, at least).

I solved these problems by removing the e1000 NIC and adding a Realtek 8139 NIC using virt-manager. I created a CD ISO with the drivers from realtek's website and gave it to the guest. Once the 2003 guest had the driver, the network worked and inter-guest communication worked.

The tip off was when I kept watching "arp -a" inside a Windows Server guest. I noticed that pings received from the other guest (WITH a static arp entry) all came in as "00-00-00-00-00 invalid". After this, I installed Wireshark in the guest sending the pings and watched. Wireshark listed each source MAC as being from a Realtek NIC. I assume that the e1000 NIC was given an automatically generated Realtek address. I don't know if this is supposed to be kosher or not, but it certainly did not work. The problem was either the Realtek MAC + e1000 OR the problem was in the e1000 emulation itself.

I still think this is a bug, and I'll be updating the bugzilla entry with this info.

Last edited by PilotJLR; 30th November 2009 at 10:32 PM.
Reply With Quote