2

I am trying to understand Linux bridging.

Lets say I have a Linux bridge with two veth interfaces and a vNic.

Bridge: br0 Interfaces: veth1, veth2, and eth1

Now, if I do brctl showmacs br0, it shows me a list of port no#s/ MAC address etc. Like:

 $ brctl showmacs br0
 port no mac addr                is local?       ageing timer 

   1     00:50:56:8f:96:e5       yes                0.00

   2     f2:2b:f5:fa:17:9c       yes                0.00

   3     0e:fd:9d:0a:2c:4f       yes                0.00

Question1: How is the above table constructed? I assume its called the forwarding database?

Frame Bridging

Now if a frame gets generated at veth1 with destination MAC address of veth2. It will just go to the bridge, the bridge will look up its forwarding database and it will be sent to the veth2's port on the bridge. Simple.

Question 2: But if a frame gets generated at veth1 with a destination MAC address that's not a bridge port then how does the bridging works? I assume the bridge floods all the ports with this frame. But then what? IF a port accepts the flooding frame, does it notify the bridge that I have this MAC address? If no port on the bridge is the receiver, how does the bridge know what's the uplink port or the port to which it should sent the frame to, in this event where no of bridge ports are the intended receivers?

  • I think you are confusing layer-2 (bridging/switching frames) with layer-3 (routing packets). Switches (bridges) flood unicast frames with unknown MAC addresses, broadcasts, and multicasts. Routers don't flood packets. Switches will learn which MAC addresses are on which ports from the frames coming into that port, then send unicast frames to only the port where the MAC address is connected. Routers forward packets based on the routing table. – Ron Maupin Mar 25 '16 at 16:50
  • sorry for the misunderstanding. I have changed s/routing/bridging/. I am not talking about L3 at all over here. Just L2 on a linux bridge and how the packets are bridged. – user35704 Mar 25 '16 at 16:53
4

The way switches (bridges) work is that a switch builds a MAC address table which relates MAC addresses to the port(s) where the MAC addresses are connected. When a frame comes into a switch port, the switch will update its MAC address table to show that the source MAC address in the frame is connected to that port. Each port can have multiple MAC addresses associated with it, but there is only one port for each MAC address.

When a frame comes into a switch, the switch will update its MAC address table with the source MAC address in the frame, and it will look to see if the destination MAC address is in its MAC address table. If the destination MAC address is in the table, the frame will be switched to the corresponding port. If the destination MAC address is not in the MAC address table, or the destination MAC address is the broadcast address or a multicast address, the frame will be flooded to all switch ports.

  • Thanks! That answers how the table is constructed ie Question1. However Question 2 is still unanswered. I wanted to know what happens after the frame is flooded to all switch ports? There could be two cases: 1. A particular port has that mac address and therefore accepts the frame. In this case does the port notify the bridge that it accepted the packet, which can help the bridge update it's port/mac table? 2. What if none of the flooded ports have that mac address? What happens then? – user35704 Mar 25 '16 at 17:26
  • When the frames are flooded to the switch ports, the ports merely send the frame out the ports. That's it. Switches are simple and transparent since speed is of the essence in switching. – Ron Maupin Mar 25 '16 at 17:31
  • So the situation where the bridge receives a packet with destination mac address not matching any of the ports on the bridge never arises? – user35704 Mar 25 '16 at 17:41
  • That is the bridge. The function of a bridge is to switch frames as quickly as possible. A compromise chosen for that is flooding. Flooding wastes bandwidth, but alternatives unacceptably slow the switching. Also, switches don't have large buffers, and ethernet has no facility for error correction or retransmission. It's better to drop data sooner so that the upper-layer protocols notice it sooner and can remediate it (ask for the data to be transmitted again) if necessary. – Ron Maupin Mar 25 '16 at 17:53
2

How is the above table constructed?

The table is constructed from the source MAC addresses of frames passing through the bridge.

Question 2: But if a frame gets generated at veth1 with a destination MAC address that's not a bridge port then how does the bridging works? I assume the bridge floods all the ports with this frame.

Correct

But then what? IF a port accepts the flooding frame, does it notify the bridge that I have this MAC address?

It doesn't explicitly notify the bridge.

But typically a request will provoke a response. Typically that response will tell the bridge where the MAC address is located.

Also except in cases where a bridge was rebooted without rebooting the connected devices this is unlikely to happen in the first place. Normally when hosts start to communicate they will send arp broadcasts (or for IPv6 ND "multicast") before they start sending unicast traffic.

If no port on the bridge is the receiver, how does the bridge know what's the uplink port

It doesn't, there is no concept of "uplink port" in Ethernet bridging. Just a list of ports each with a list of associated MAC addresses.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.