Using MAC table – Linux Bridge – WILT

In an earlier blog, I have talked about Linux bridge based virtual networking. Recently as part of a comment on my blog, I learnt how to view and interpret the MAC table of Linux bridge. In this installment of WILT (What I Learnt Today) series, I will share how MAC Table can be used for troubleshooting Linux bridges.

MAC Table - Background

Bridges and Switches forward packets by examining and learning MAC address from incoming packets. Linux bridges are no different from their hardware counterparts. And looking at the MAC table learnt by Linux bridges can provide useful insight into the flow of packets.

In cloud platforms like OpenStack, virtual machines (VMs) started by different tenants may get scheduled on the same hardware server. It follows that these VMs will share the resources on that server including the network ports. Let us consider a scenario where Linux bridge is used for virtual networking (as Mechanism driver in OpenStack). Now if there was a problem with one of the network ports on a server, it will be good to know which VMs are impacted by it.

Since multiple Linux bridges may be present, one of the best ways to find out the affected VMs for a given physical network port, is by looking at the MAC table of the Linux bridge that is bound to the failed network port.

Interpreting MAC Table - Step-by-Step guide

Step 1: If you have detected that eth0 interface is having a problem, then using brctl show command you can list all the bridges and identify the Linux bridge bound to eth0.

Step 2: Next execute the command brctl showmacs <bridge_name> with the bridge you identified in Step 1 to view the MAC table. In the output, each row represents MAC address learnt at each port of the Linux bridge. The important columns in the output are ‘is local?’, ‘port no’ and ‘mac addr’.

Step 3: When a row (or MAC address) has ‘is local’ as Y (means Yes), then it represents the MAC address of an interface directly on the Linux Bridge**. **You can confirm this with the MAC address of _eth0 _which is bound to the Linux bridge (myvirtbridge in the screenshot below). The other interfaces with ‘is local’ as Yes are the tap interfaces directly on the Linux bridge. Make a note of the ‘port no’ for these tap interface MAC addresses (where ‘is local’ is Yes).

In this example, Port Number 1 belongs to the eth0 interface. And Ports 2 and 3 represent the Tap interfaces on the Linux bridge (myvirtbridge).

Step 4: For each port number with a ‘is local’ as Yes, you will find another entry in the MAC table with the same port number but with ‘is local’ as No. These entries with ‘is local’ as No represents the MAC address _learnt _from the incoming packets. Since we are looking at Port number for tap interfaces, the remote entities that are sending these packets are basically the virtual interfaces inside virtual machines. In the picture below, for Local port 2, the non-local (remote) MAC address is ‘52:54:00:81:ad:5a’. This will be the MAC address of a virtual NIC of a VM. Similarly for local port 3.

Step 5: There are two ways to confirm that the remote MAC addresses belong to VMs.

1. You can use the _ps -ef _ command and grep for these remote MAC addresses.
2. Or you can login into the VMs and try the ifconfig command _inside _the VM.

Conclusion: As seen in the step by step guide, understanding MAC table output provides useful insights into the flow of packets in a Linux bridge. It can be a useful tool in troubleshooting networking problems (in addition to other tools).