What is Bridge?
By definition, bridge is action taken by network equipment (can be router, switch, or even our machine) to allow two or more communicative networks, or two or more network segments to create an aggregate network. It is different from routing which allows the networks to communicate independently as separate networks. A bridge is a network device that connects more than one network segment and acts in the first two layers of OSI (physical and datalink).
Bridging Concept for QEMU
In this case, bridging is not something specific for QEMU and actually the bridge functionality is provided by LInux kernel, not QEMU.
QEMU supports tap device (“-net tap” instead of “-net user” when starting QEMU). TUN/TAP devices is a “virtual ethernet driver”. On the official document of tuntap.txt, it is said that: “TUN/TAP provides packet reception and transmission for user space programs. It can be seen as a simple Point-to-Point or Ethernet device, which, instead or receiving packets from physical media, receives them from user space program and instead of sending packets via physical media writes them to the user space program.”
In basically QEMU runs on our machine as a program and have capability to write packets to the TAP devices. Thus, QEMU can simply write all the virtual computer generated packets to the TAP device and forward packets to the virtual computer. But is only sufficient if our virtual computer wants to talk to the real computer it runs on ONLY. Once the packets from the virtual computer reaches the TAP device Linux doesn’t know where to send the packets as it is not part of TAP device functionality.
So, here bridge play the role.
The bridge is (sort of) the most reliable way of connecting your virtual computer to the real network. There is no need to configure IP for TAP device for the bridge to work. No IP forwarding involved but routing instead. In this sytem, packets are forwarded at Ethernet level (layer 2 / datalink on OSI layer), bridge does not even care about IP.
Now let’s see the real implementation. Suppose we have 2 (or more) NIC (Network Interface Card), one NIC connected to one Ethernet and the other to the second Ethernet. The bridge then joins the Ethernets together to become one. The good use of bridge for example is connecting a 1GBps Ethernet with a 10MBps Ethernet. Bridge keep them separate but connect them with a with one tunnel so they can talk to each other while not bother each other that much.
Note that once the bridge started, we cannot manipulate eth0 or whatever real NIC device in our machine anymore. Since the bridge is at level 2, it needs to be able to tell where a packet is going by the MAC address in the packet. If we manipulate the eth0 device, the packet is going out to the real network directly and the bridge will not have access to the packet. Hence, it breaks the bridge.
Let’s get back to our example of 1GBps network and 10MBps network. If we request a DHCP IP address on our eth0 – which is our 1GBps network – the DHCP server has to be on the 1GBps network or it won’t be able to get an IP address. In this situation, we will have to have two DHCP servers, one on 1GBps and other on 10MBps. We will either create two segments of dynamic IPs or find a way to synchronize two DHCP servers leases.
Since the IP layer is on Layer 3 of OSI (network layer), it is built on top of the bridge which runs on datalink layer and we will have to start our IP stack on top of the bridge instead of our real NIC.
Start Bridging Step
Before we did bridging of course we need to create the TAP device. The creation
First release IP address assigned to real NIC. Then rename eth0 to reth0 (means RealETH0) and then create bridge with name “eth0”.
Create a bridge, add two NIC (one is the real NIC and the other is the TAP device).
Re-acquire a DHCP lease with the bridge interface (which is eth0 now).
Here is the complete commands:
# 1st, release all DHCP address and remove all IP address associated with the original eth0 /sbin/dhcpcd -k /sbin/ip addr flush eth0 # then take the interface down so we can rename it /sbin/ip link set eth0 down # now rename the original eth0 to reth0 (Real ETH0) /sbin/nameif -r reth0 eth0 # OK, bring the interface back up /sbin/ip link set reth0 up # 2nd let's create a bridge called eth0 so other programs think they are talking to the same old interface /sbin/brctl addbr eth0 # then add both original eth0 and tap1 device to the bridge /sbin/brctl addif eth0 tap1 /sbin/brctl addif eth0 reth0 /sbin/brctl showmacs eth0 # 3rd, we need to bring the newly created bridge UP /sbin/ip link set eth0 up # 4th, renew the DHCP address if possible /sbin/dhcpcd -n /sbin/ip addr show
Please note, there are other ways of connecting your virtual computer to the real network with TAP device: you can configure routing on your real computer (I don’t see a reason why I want to do that – if you use NAT, why don’t you use the “-net user” instead which is much simpler; if you use real world IP, why don’t you use bridge? To configure routing for the TAP, you need to start IP stack on the TAP device and start ip forwarding on the real Linux – unnecessarily complex for my environment).
Another good option is VDE (Virtual Distributed Ethernet). It is a very good solution, in some case, it maybe better than bridge. The best feature is you don’t need the brief down time as the bridge solution. I found the description of VDE is much better than bridge and hence I will skip this part.bridge, network, qemu