Linux Ethernet Bridging - Oct 2008 - [Bridge] pinging other side (normal bridge ok, anonymous bridge not ok)

Hi, if I set up a bridge, assign an IP address to it, remove the
IP from a real interface (in my case dummy0, but the same situation
might apply to an physically unconnected eth1 NIC), plumb that real
interface into the bridge and plumb one end of a virtual cross-over
cable (tap0 <-> eth0-in-a-VM) into the bridge too, like this:

	brctl addbr br0 
	ifconfig br0 192.168.1.42 up
	ifconfig dummy0 0.0.0.0
	brctl addif br0 dummy0
	brctl addif br0 tap0

then I can now ping the other side, from both sides. Good.

Actually, dummy0 is superfluous; I might just as well not use it
in the above lines.

However, purely because I want my bridge to behave like a physical
bridge/hub/switch which I am used to not having an IP address, I would
like to use an *anonymous* bridge instead based on a command sequence 
like this:

brctl addbr br0
ifconfig dummy0 192.168.1.42 up
brctl addif br0 dummy0
brctl addif br0 tap0

But all attempts to do this have fail: I cannot ping the other side
from either side.

What is odd is than a tcpdump on the physical host shows that packets
are arriving on br0 but not on dummy0, also both sides ARP tables
contain the IP of the other side. It's almost like the bridge is saying
"I'll let ARP traffic through but not IP!"

I googled that this might be an iptables issue, so I flushed all
rules from all tables and set policy to ACCEPT. No dice.

Also, and please correct me if I am wrong in this assumption, I assume
that forwarding is not needed in this scenario; the bridge does not
behave as a computer and actually *require* forwarding to be turned on.
(Sure, if I wanted the VM to be able to reach something *beyond* the
physical machine then I would need to tell the physical machine to
do forwarding and maybe masquerading.)

I've also echoed '1' onto various things under /proc as per googled
docs. All to no avail.

Finally, I wanted to plumb dummy0 into an anonymous br0 to be analogous
with real hardware, but is there an advantage to doing it the usual
bridge-with-an-ip-address way? (Other than that it seems to work
whereas the anonymous way doesn't - for me.)

Many thanks for any assistance you can offer!

Alexis

Hi,

Adding a dummy device to a bridge doesn't do much for you. The dummy
device never has any incoming packets, and any outgoing packets are
discarded.

The veth driver might be more useful for you. If you have the veth
module buillt (CONFIG_VETH), you can create an interface pair using:
$ ip link add name veth0 type veth peer name veth1
This gives you a pair of ethernet devices (veth0 and veth1) set up so
that a packet sent out on any one is received on the other. With this,
you can make one of these a bridge port and give the other end the IP
address.

One page describing how to use veth for network namespace is:
http://lxc.sourceforge.net/network/configuration.php

On Tue, Oct 14, 2008 at 1:58 AM, Alexis Huxley <ahuxley at gmx.net>
wrote:
> Hi, if I set up a bridge, assign an IP address to it, remove the
> IP from a real interface (in my case dummy0, but the same situation
> might apply to an physically unconnected eth1 NIC), plumb that real
> interface into the bridge and plumb one end of a virtual cross-over
> cable (tap0 <-> eth0-in-a-VM) into the bridge too, like this:
>
>        brctl addbr br0
>        ifconfig br0 192.168.1.42 up
>        ifconfig dummy0 0.0.0.0
>        brctl addif br0 dummy0
>        brctl addif br0 tap0
>
> then I can now ping the other side, from both sides. Good.
>
> Actually, dummy0 is superfluous; I might just as well not use it
> in the above lines.
>
> However, purely because I want my bridge to behave like a physical
> bridge/hub/switch which I am used to not having an IP address, I would
> like to use an *anonymous* bridge instead based on a command sequence
> like this:
>
> brctl addbr br0
> ifconfig dummy0 192.168.1.42 up
> brctl addif br0 dummy0
> brctl addif br0 tap0
>
> But all attempts to do this have fail: I cannot ping the other side
> from either side.