[Network Virtualization] Bridge

The bridge is a virtual network device, so it has the characteristics of a virtual network device and can be configured with IP, MAC address, etc. Unlike other virtual network devices, the bridge is a virtual switch and has similar functions to a physical switch. Unlike other virtual network devices, bridge is a virtual switch with similar functions as a physical switch. bridge is connected to a protocol stack at one end and has multiple ports at the other end, and data is forwarded between the ports based on MAC addresses.

The bridge can work at layer 2 (link layer) or layer 3 (IP network layer). By default it works at layer 2. By default, it works at layer 2 and can forward Ethernet messages between different hosts within the same subnet; when an IP address is assigned to a bridge, it also enables the bridge’s layer 3 mode of operation. Under Linux, you can manage the bridge with the command iproute2 or brctl.

Creating a bridge is similar to creating other virtual network devices, you just need to make the type bridge.

1
2

# ip link add br0 type bridge
# ip link set br0 up

But the bridge created in this way has the protocol stack connected at one end and nothing connected to the other ports, so we need to connect other devices to that bridge to have actual functionality.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# ip link add veth0 type veth peer name veth1
# ip addr add 20.1.0.10/24 dev veth0
# ip addr add 20.1.0.11/24 dev veth1
# ip link set veth0 up
# ip link set veth1 up
# 将veth0连接到br0
# ip link set dev veth0 master br0
# 通过 bridge link 命令可以看到bridge上连接了哪些设备
# bridge link
6: veth0 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2

In fact, once br0 and veth0 are connected, they become bidirectional channels, but the kernel stack and veth0 become a single channel between them. The stack can send data to veth0, but the data veth0 receives from outside will not be forwarded to the stack, and the MAC address of br0 becomes the MAC address of veth0. We can verify this.

1
2
3
4
5
6

# ping -c 1 -I veth0 20.1.0.11
PING 20.1.0.11 (20.1.0.11) from 20.1.0.10 veth0: 56(84) bytes of data.
From 20.1.0.10 icmp_seq=1 Destination Host Unreachable

--- 20.1.0.11 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

If we use tcpdump to grab a packet on br0 we will see that:

1
2
3
4

# tcpdump -n -i br0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
21:45:48.225459 ARP, Reply 20.1.0.10 is-at a2:85:26:b3:72:6c, length 28

You can see that veth0 receives the answer packet and does not give it to the stack, but forwards it directly to br0, so that the stack does not get the mac address of veth1 and thus the ping is not possible. br0 intercepts the packet between veth0 and the stack. But what happens if we configure the IP for br?

1
2

# ip addr del 20.1.0.10/24 dev veth0
# ip addr add 20.1.0.10/24 dev br0

Thus, the network structure becomes the following.

At this time, ping veth1 through br0 again, you will find that the result can be passed.

1
2
3
4
5
6
7

# ping -c 1 -I br0 20.1.0.11
PING 20.1.0.11 (20.1.0.11) from 20.1.0.10 br0: 56(84) bytes of data.
64 bytes from 20.1.0.11: icmp_seq=1 ttl=64 time=0.121 ms

--- 20.1.0.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.121/0.121/0.121/0.000 ms

In fact, when the IP address of veth0 is removed and the IP is configured for br0, the protocol stack will not send packets to veth0 when routing, and to express it more intuitively, the connection line between our protocol stack and veth0 is removed, and this time veth0 is equivalent to a network cable.

In reality, bridge is commonly used in the following scenarios.

• Virtual Machine

  A typical VM network implementation is to connect the NIC in the VM to the host’s br0 via TUN/TAP, at which point br0 and the physical switch have similar effects, with packets sent from the VM first reaching br0 and then being handed over by br0 to eth0 to be sent out, so that the packets do not need to go through the host machine’s stack and run very efficiently.

  

• Containers

  As for container networks, each container’s network device is in a separate network namespace, so it is good to have different container protocol stacks, and we further discuss the different container implementations in the next notes.

  

Reference https://houmin.cc/posts/df8d4746/