This can be done using "ebtables", a URL for this is available at the end of the document. In newer 2.6 kernels, iptables can also accomplish this.

Often this is caused by UML instances having the same MAC address. Please see the next question.

This could due to the way interfaces are brought up. If an interface is brought up using ifconfig eth0 up before it is given an address, the interface will receive a "default" MAC address. Differences between scripts on various distributions cause this error to surface. You can either edit the scripts on your distribution to bring up interfaces correctly, or see the following question.

A unique MAC address can be assigned by specifying it as part of the network interface argument, like so: eth0=tuntap,uml-conn0,FE:FD:00:00:00:01.

The daemons will (normally) bind to any IP that isn't 0.0.0.0. This means they wont bind to addresses in use by your UML sessions, just the IP used by the bridge, localhost and any other network adapters you happen to have.

Of course, bridges are designed for this. Simply repeat steps (1) and (7) in Chapter 2, The host kernel.

Simply add aliases to the bridge interface in the same way you would any other interface.

This happens if you don't have bridging support compiled into your kernel, or the module isn't loaded. Read the section about the host kernel.

Most likely you don't have tuntap compiled into your kernel, or the module isn't loaded. Read Chapter 2, The host kernel.

If your host kernel uses devfs, the TUN device can also be /dev/misc/net/tun.  Add the following lines to /etc/devfsd.conf:

REGISTER       misc         MKOLDCOMPAT

# Create correct /dev/net/tun symlink
REGISTER       ^misc/net/tun$  CFUNCTION GLOBAL unlink   net/tun
REGISTER       ^misc/net/tun$  CFUNCTION GLOBAL symlink  /dev/$devname
net/tun

and comment out the old UNREGISTER for misc if it exists:

#UNREGISTER     misc         RMOLDCOMPAT

then send a HUP signal to the devfsd process to force it to read the modified configuration file. This will create a symlink /dev/net/tun pointing to your actual TUN device /dev/misc/net/tun.

Most likely, permissions on /dev/net/tun on the host are incorrect. If you are not running UML as root, add group permissions to /dev/net/tun and put the user who runs UML into the appropriate group.

If you are running UML inside a chroot, you will need to bind mount /dev/net/tun on the host into the chroot filesystem. Using mknod to create a device with the same major/minor number is not sufficient, the correct command is mount --bind /dev/net/tun <chroot path>/dev/net/tun.

Check that you assigned the bridge an IP address and that it is up. The output of ifconfig will help here.

Setting up the bridge may remove your default route, in which case you need to issue the command route add default gw <ip> on the host, where <ip> is the IP address of your gateway.

Yes, ARP will travel across bridges, this is necessary in order for ethernet to work as it should. If you are not seeing ARP pass your bridge interface this may be an indication of a problem.

DHCP is fully compatible with bridging as described in this HOWTO. Setup a DHCP server somewhere on the network and use dhclient or dhcpcd in the UML.

Configuring a Samba server on your LAN to act as a WINS replicator fixes these issues in many cases. See this page at the Samba site for more information on WINS.