Creating a bridge

Creating a bridge
Prev	Chapter 5. Bridging: In practice	Next

The following sets up a bridge, a tun device and attaches the device to the bridge. We must do this before we start our UML sessions. The steps are explained in detail below and it is recommended you read through the descriptions before trying it out.

 1 - # ifconfig eth0 0.0.0.0 promisc up

 2 - # brctl addbr uml-bridge
 3 - # brctl setfd uml-bridge 0
 4 - # brctl sethello uml-bridge 0
 5 - # brctl stp uml-bridge off
 6 - # ifconfig uml-bridge 192.168.0.100 netmask 255.255.255.0 up

 7 - # brctl addif uml-bridge eth0

 8 - # tunctl -u umluser -t uml-conn0
 9 - # ifconfig uml-conn0 0.0.0.0 promisc up

10 - # brctl addif uml-bridge uml-conn0

First we configure what was our external interface to have an IP of 0.0.0.0, to be promiscuous and to be up. Devices that are attached to bridges need to have an IP address of 0.0.0.0.

	Warning
	Please remember that if you configure your external interface with the IP address `0.0.0.0` you will loose connectivity with it.

Now we make our bridge and call it uml-bridge. This creates a bridge with nothing connected to it.
This sets the forwarding delay, the time the bridge spends in the "listening" and "learning" states, to zero seconds.
How often we send out STP "hello" packets with information on the bridged topology. This isn't strictly necessary, due to (5).
Turn off STP, the "spanning tree protocol". We only have one bridge and therefore don't need this on. See the Linux-Bridge-STP howto for more information on it.
Set the IP and netmask of the bridge. This is really the IP that we want the host machine to have as (unmanaged) transparent devices don't have IPs. The bridge should now appear in the output of ifconfig.
Add the eth0 device to the bridge. Provided you set the IP of the bridge in step (6) you should now see network connectivity back on the host. Test this by attempting to ping another device on the network, connecting to something (etc).
Create a tun device, owned by the user umluser and called "uml-conn0". The user umluser has to exist on the host.
Configure the tun device to have the IP 0.0.0.0. We do not set the desired IP for the UML here, that is done inside the UML itself. As with the bridge, the tun device should appear in the output of ifconfig once we've finished.
Add the tun device to the bridge.

This gives us a bridge and a tun device. We connect eth0 to the bridge so that the host has networking too. If we wanted to run more than one UML session on the host we would repeat steps 8 to 10, changing the name of the tun device to something unique each time.

The following (appalling ASCII art) diagram should hopefully give a clearer picture of what we now have.

Outside world  --> [      BRIDGE       ]
                   [ Port 0: eth0      ] -->  Networking on the host
                   [ Port 1: uml-conn0 ] -->  Our UML session
                   [ ...               ]
                   [ Port X: uml-connX ] -->  More UML sessions

At this stage there is nothing actually connected to the "other end" of the tun device that's on port 1 (uml-conn0). Imagine it as a piece of wire, we've plugged one end into the bridge and the other end gets "plugged in" to the UML when we start it up.