http://events.linuxfoundation.org/sites/events/files/slides/LinuxConJapan2014_makita_0.pdf

Uses netlink interface to manage a bridge.

# ip link add br1 type bridge
# ip link set dev eth0 master br1

Creates bridge named br1 and adds eth0 interface as a slave to that bridge

# ip link set dev eth0 nomaster

Removes interface eth0 from a bridge it is part of

# ip link del dev br1

Removes bridge br1

Display enslaved interfaces

# bridge link
2: eth0 state DOWN : <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 master br1 state disabled priority 32 cost 100

Mapping of mac addresses and ports via which are these mac addresses reachable. This mapping is usually learned from source mac addresses of frames received via a specific port. Can be also statically configured. If no mapping for a destination mac address is found the received frame is flooded to all ports except for the one it was received from.

Show the kernel forwarding database

# bridge fdb
01:00:5e:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev wlan0 self permanent
33:33:00:00:00:02 dev wlan0 self permanent
33:33:00:00:00:01 dev wlan0 self permanent
33:33:ff:67:20:3a dev wlan0 self permanent
33:33:ff:00:00:00 dev wlan0 self permanent
00:26:9e:99:f3:ab dev eth0 vlan 0 master br1 permanent

Interfaces with master tag are part of the specified bridge (here br1). The rest are multicast ethernet addresses on other interfaces that we won't discuss here.

There are 3 types of entries in the forwarding database

• Permanent - these refer to mac addresses on local ports that will cause delivery to the local bridge interface. That means frames won't be sent out from these ports.
• Static - manually configured, also refered to as temp in the bridge tool
• Others - dynamically learned by watching source mac addresses of passing frames

brctl showmacs displays mac adresses and port numbers but brctl show doesn't show the port numbers. Sometimes the order of the interface isn't the same as the port number. This shows how to find out which is which.

#  brctl show br0
bridge name     bridge id               STP enabled     interfaces
br0             8000.364dfd60b415       no              eth5
                                                        tap-vpn2
                                                        tap-vpn1

# brctl showmacs br0
port no mac addr                is local?       ageing timer
...
  1     28:92:4a:cc:09:8e       no                 1.42
  1     28:92:4a:cc:09:95       no                 1.60
  1     28:92:4a:cc:09:e9       no                 1.03
  3     2c:44:fd:05:4e:5e       no                 2.87
  3     36:4d:fd:60:b4:15       yes                0.00
  2     62:54:77:42:48:3a       yes                0.00
...

The portnumber is specified in sysfs

# cat /sys/class/net/br0/brif/tap-vpn1/port_no
0x3

Bridge code has the ability to call iptables, ip6tables, arptables for bridged packets. This makes it possible to use these tools to filter traffic that passes only through the bridge. This also means that if using macvlan interfaces on a bridge interface, the various hooks get called twice or even more for each packet, usually with different in/out physical and logical interfaces. If there is no need to filter using ip, ipv6 or arp information beyond what ebtables can do, these hooks can be disabled.

bridge-nf-call-{arp,ip,ip6}tables (bool,1)

• set 1 to call the appropriate hooks, 0 to not call them

bridge-nf-filter-pppoe-tagged (bool,0)

• pass bridged pppoe ip/ip6 frames to {ip,ip6}tables

bridge-nf-filter-vlan-tagged (bool,0)

• pass bridged vlan-tagged arp/ip/ip6 frames to {arp,ip,ip6}tables

bridge-nf-pass-vlan-input-dev (bool,0)

• if set and the bridge has vlan interfaces on top of it, set the input device to the vlan interface (such as br0.24). if there is no such interface or this is set to 0, then the input device is the bridge itself (br0).

How ebtables interact with iptables

Multicast querier is a service that sends at regular intervals multicast queries into the local network to find multicast listeners (clients). Implements IGMP for ipv4 and MLD for ipv6. Configuration done through sysfs.

• multicast_querier - (default 0) send ipv4 and ipv6 multicast queries when set to 1
• multicast_query_interval - (default 10000) how often to send multicast queries (in 10ms units, 1000 = 10 seconds)
• multicast_query_response_interval - (default 1000) maximum interval in which the listener must respond. listeners use random timers so they won't overwhelm the switch with mld responses at the same time.
• multicast_querier_interval - (default 25500) how much time to wait for a query from the current multicast querier. there should be only a single multicast querier on the network. one querier is elected to be the active one, others become passive and only send if they don't hear a multicast query from the active one within this interval.

macvlan interface bound to a bridge interface with a different mac address then the bridge mac address (whole point of having a macvlan interface) won't have its mac address in the bridge forwarding table. That means an incoming frame with the destination mac address of the macvlan interface is actually an unknown unicast frame and will be flooded to all the other interfaces enslaved to the bridge.

Looks like new kernels add the macvlan mac address to the forwarding database. Tested briefly on v4.4.4.