Strange bridge behaviour, need suggestions

[capzulu]

I have this 3 machines with this setup:
VM1-----Internal Network-----VM with Ubuntu 12.04-----Internal Network------VM2

VM1 have IP 192.168.10.1 and VM2 have 192.168.10.10.
My VM with Ubuntu have 2 ethernet interfaces. I want to create a bridge in Ubuntu so VM1 and VM2 can talk to each other.

I have created a bridge in Ubuntu with

Code: Select all

sudo ifconfig eth0 0.0.0.0 down
sudo ifconfig eth1 0.0.0.0 down
sudo brctl addbr br0
sudo brctl addif br0 eth0
sudo brctl addif br0 eth1
sudo ifconfig br0 up
sudo ifconfig eth0 promisc up
sudo ifconfig eth1 promisc up

The command "brctl showstp br0" shows me that the state of eth0 and eth1 is forwarding. Then I start tshark in bridge with

Code: Select all

sudo tshark -i br0

If in VM2 I try to ping VM1 I get

Code: Select all

ARP 60 Who has 192.168.10.1? Tell 192.168.10.10

In the bridge I get the ARP Request from VM2 but I don't see ARP Reply from VM1

When I run the tshark at VM1 gets this

Code: Select all

ARP 60 Who has 192.168.10.1? Tell 192.168.10.10
ARP 42 192.168.10.1 is at XX:XX:XX:XX:XX:XX (mac hidden)

With this I see that ARP gets passed through the brige, Computer1 receives the ARP and sends the reply but that reply don't go through the bridge.

Any ideas???

Thanks

[mpack]

Why do you need a bridge? If the three VMs are already connected to the same virtual network (which would be the case with internal networking) then you don't need a bridge. Certainly, bridging a network to itself is probably not useful.

[capzulu]

Sorry, I forgot to say that the internal networks are different.

The setup is this

VM1 ---- Internal Network 1 ------- VM with Ubuntu --------- Internal Network 2 ------- VM2

[noteirak]

Am I right in understanding that the reply gets stuck in the "middle VM"?

[lfs]

I have exactly the same problem as capzulu. Three virtual machines with this setup:

VM1-----Internal Network 1 -----VM3, Ubuntu 12.04, as a bridge with brctl -----Internal Network 2------VM2

In VM2 I ping VM1. I capture the packets and I observe that ARP request (broadcast) packets do go through the bridge and reach VM1, VM1 responds ARP reply packets but the bridge doesn't forward them to VM2...

To avoid ARP requests I've filled manually the ARP table of VM1 and VM2 with the corresponding (IP address, MAC address) and I've repeated the ping. No ping packet get through the bridge. It means, then, that only broadcast packets (FFF....FF) are forwarded by the bridge.

Any ideas about what it is happening and how to solve it?

Thanks

[noteirak]

If you have different IP subnets, then you need a router configuration, not a bridge configuration.
Else the bridge interface must be aware that it has to act as a dumb switch.
Finally, check the firewall configuration.

Be aware that this has nothing to do with Virtualbox and is a networking issue - a network forum might be best in this case.

[lfs]

Thanks for the suggestion.

However, there are not two IP networks, it is a single IP network with 2 hosts and a bridge (a switch) joining them. For example, in my scenario the IP prefix is 10.0.0.0/24, with IP address for VM1 10.0.0.100 and for VM2 10.0.0.200 (VM3, the bridge, does not have assigned an IP address).

In a real scenario it should work... So the way I have configured VirtualBox or the use of the networking mode "internal" must have some relation to this problem.

[noteirak]

What about your fill up the ARP table of the VM3 with the IP & MAC of VM1 & VM2?

[lfs]

Thanks!

Filling up manually the ARP table of VM3 (bridge) doesn't work. I also filled manually the ARP table of VM1 and VM2 but nothing changes.

In these different tests I've captured the packets with Wireshark in a bridge interface, and I only see the brodcast packets (with destination address FF...FF, e.g, ARP request) and no unicast packets (ARP reply, ICMP echo request...). That is, only broadcast packets reach VM3, although they are sent by the other VMs.

On the other hand, it would be nice there was a networking mode "equal" to a cable (normal or crossover). It could be used in this type of scenarios where VMs are bridges or switches. Instead I am using the "internal networking" mode, which is like an "Ethernet switch" that connects all the VMs' adapters assigned to the same internal network rather than a simple cable

[noteirak]

I still can't figure out what use case would make a birdge VM useful....

[BillG]

I can't either. This whole thread is a mystery to me.

[capzulu]

I've found the solution to this problem.

I solved it by editing the network settings of the bridge VM and setting the "Promiscuous mode" to "Allow All".
The bridge VM need their interfaces to be in promiscuous mode to allow traffic forwarding. This setting is enforced by Virtual Box, thus you need to set "Promiscuous mode" to "Allow All" in the VM network settings.

[lfs]

Great capzulu! It works! Thanks!

Changing the "Promiscuous mode" from "Deny" to "Allow All" in all network adapters of the bridge VM is the solution (in fact it also works with "Allow VMs", which is a promiscuous mode "restricted" to the traffic of all VMs, without including the traffic of the host). The "Deny" option makes the adapter to be aware only of Ethernet packets directed to the adapter, which is consistent with the behaviour I observed (only broadcasts packets reached VM3...).

About the utility, well, besides virtualizing hosts, one may find useful to virtualize devices like bridges/switches, routers and similar, and build scenarios with these networking devices and hosts connected together, for studying how they behave, try new developments, etc.