-
Notifications
You must be signed in to change notification settings - Fork 39
Bridge
- VLAN-aware and VLAN-unaware Bridges
- Bridge Device Configuration
- VLAN Devices
- Bridge Membership
- Bridge Port Configuration
- Forwarding Database Configuration
- Multicast Database Configuration
- Spanning Tree Protocol Configuration
- Q-in-Q
- Further Resources
| Kernel Version | |
|---|---|
| 4.4 | VLAN-aware bridge offload |
| 4.5 | VLAN-unaware bridge offload |
| 5.11 | Q-in-Q bridge offload |
The IEEE 802.1Q standard defines two types of bridges:
- VLAN-unaware bridge – a bridge that does not recognize VLAN-tagged frames
- VLAN-aware bridge – a bridge that recognizes frames with a VLAN tag and can insert or remove tag headers
The Linux bridge is by default a VLAN-unaware bridge, but that can be changed as described in the VLAN-aware Configuration section.
A bridge may be created by running:
$ ip link add name br0 type bridge
By default, the bridge is VLAN-unaware (indicated by vlan_filtering being set
to 0):
$ ip -d link show dev br0
69: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 2a:35:40:96:db:d8 brd ff:ff:ff:ff:ff:ff promiscuity 0
bridge forward_delay 1500 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32768 vlan_filtering 0 vlan_protocol 802.1Q addrgenmode eui64
The default aging time is 300 seconds. To change the aging time to 10 seconds, run:
$ ip link set dev br0 type bridge ageing_time 1000
Aging time range: 10-1,000,000 hundredth of a seconds.
Note: The aging time in seconds is the value entered divided by 100. Therefore, in the example above 1000/100=10 seconds.
To delete a bridge device, run:
$ ip link del dev br0
The following command makes br0 VLAN-aware:
$ ip link set dev br0 type bridge vlan_filtering 1
VLAN devices are soft interfaces that can be set up on top of front panel ports. Any traffic going in through the port with the VLAN device's VLAN is directed to the VLAN device instead of the port netdev. Similarly, any packet transmitted through the VLAN device carries the appropriate VLAN tag.
To configure a VLAN device on top of a front panel port, run:
$ ip link add link sw1p5 name sw1p5.10 type vlan id 10
The VLAN device can only go up if the administrative state of the underlying device (the real device) is up:
$ ip link set dev sw1p5.10 up
RTNETLINK answers: Network is down
$ ip link set dev sw1p5 up
$ ip link set dev sw1p5.10 up
To delete a VLAN device, run:
$ ip link del dev sw1p5.10
To add a net device to a bridge (enslaving), run:
$ ip link set dev DEV master BRDEV
Similarly, to remove a net device from a bridge, run:
$ ip link set dev DEV nomaster
And to make the bridge functional, run:
$ ip link set dev BRDEV up
To enslave sw1p5 and sw1p6 to a VLAN-aware br0, run:
$ ip link set dev br0 type bridge vlan_filtering 1
$ ip link set dev sw1p5 master br0
$ ip link set dev sw1p6 master br0
Trying to set vlan_filtering to 0 while port netdevs are
enslaved to it generates an error:
$ ip link set dev br0 type bridge vlan_filtering 0
RTNETLINK answers: Invalid argument
The mlxsw_spectrum driver currently supports only one VLAN-aware bridge.
Trying to enslave sw1p7 to a different bridge is forbidden.
$ ip link add name br1 type bridge
$ ip link set dev br1 type bridge vlan_filtering 1
$ ip link set dev sw1p7 master br1
RTNETLINK answers: Operation not permitted
Note: Adding a non-switch port (e.g. management port) to a bridge with switch ports is not supported.
By default only the port VID (PVID) is allowed to ingress through any bridge port.
$ bridge vlan show dev sw1p5
port vlan ids
sw1p5 1 PVID Egress Untagged
The PVID flag indicates that VLAN 1 is the PVID VLAN, which means that any
untagged packet coming through this bridge port gets tagged with VID 1.
Similarly, the Egress Untagged flag causes packets going out of the bridge
port with VID 1 to be untagged at egress.
To allow another VLAN (VID 20) to ingress the bridge through sw1p5, run:
$ bridge vlan add vid 20 dev sw1p5
$ bridge vlan show dev sw1p5
port vlan ids
sw1p5 1 PVID Egress Untagged
20
To allow packets with VID 20 to be bridged between sw1p5 and sw1p6, VID
20 needs to be configured on sw1p6 as well. Run:
$ bridge vlan add vid 20 dev sw1p6 untagged
The above command also specifies the untagged flag which sets the
Egress Untagged flag for VID 20. To toggle it off, run:
$ bridge vlan add vid 20 dev sw1p6
To change the PVID, the flag pvid may be used.
$ bridge vlan add vid 20 dev sw1p5 pvid
$ bridge vlan show dev sw1p5
port vlan ids
sw1p5 1 Egress Untagged
20 PVID
The PVID flag is removed from VID 1, as there can only be one PVID per
bridge port.
Removing the PVID flag entirely from the bridge port prevents untagged
packets from entering the bridge through the port.
$ bridge vlan add vid 20 dev sw1p5
$ bridge vlan show dev sw1p5
port vlan ids
sw1p5 1 Egress Untagged
20
Unlike the VLAN-aware bridge, it is possible to create multiple VLAN-unaware bridges and use them to bridge VLAN devices. This can be used, for example, to bridge two VLAN devices with different VIDs.
$ ip link add link sw1p5 name sw1p5.30 type vlan id 30
$ ip link add link sw1p6 name sw1p6.40 type vlan id 40
$ ip link add name br1 type bridge
$ ip link set dev sw1p5.30 master br1
$ ip link set dev sw1p6.40 master br1
Note: Configuring two VLAN devices on the same physical port to be members in the same bridge is forbidden and will fail.
Note: Despite the fact that multiple bridges can be configured, only one aging time can be configured in the ASIC. The last one configured is used.
The following bridge port attributes can be configured regardless of the bridge
device's vlan_filtering value (taken from man bridge):
- Learning – controls whether a given port learns MAC addresses from received traffic or not. By default this flag is on.
- Flooding – controls whether a given port floods unicast traffic for which there is no FDB entry. By default this flag is on.
To toggle off all of the aforementioned attributes, run:
$ bridge link set dev sw1p5 learning off flood off
Assume we have the following configuration:
sw1p7 1 PVID Egress Untagged sw1p8 1 PVID Egress Untagged
br0
+------+
+----------------+switch+-----------------+
| +------+ |
| |
| |
| |
| |
| |
| |
+------------------------+ +------------------------+
| HostA | | HostB |
| MAC: e4:1d:2d:a5:f0:4a | | MAC: e4:1d:2d:a5:f1:7e |
+------------------------+ +------------------------+
And that both hosts are communicating using both of the configured VLANs. To dump the FDB per port, run:
$ bridge fdb show brport sw1p8
e4:1d:2d:46:13:f3 vlan 1 master br0 permanent
e4:1d:2d:a5:f1:7e vlan 1 extern_learn offload master br0
e4:1d:2d:46:13:f3 master br0 permanent
33:33:00:00:00:01 self permanent
33:33:00:00:00:02 self permanent
01:00:5e:00:00:01 self permanent
33:33:ff:46:13:f3 self permanent
33:33:ff:00:00:00 self permanent
Or per bridge, run:
$ bridge fdb show br br0
e4:1d:2d:a5:f0:4a dev sw1p7 vlan 1 extern_learn offload master br0
e4:1d:2d:46:13:f1 dev sw1p7 master br0 permanent
e4:1d:2d:46:13:f1 dev sw1p7 vlan 1 master br0 permanent
33:33:00:00:00:01 dev sw1p7 self permanent
33:33:00:00:00:02 dev sw1p7 self permanent
01:00:5e:00:00:01 dev sw1p7 self permanent
33:33:ff:46:13:f1 dev sw1p7 self permanent
33:33:ff:00:00:00 dev sw1p7 self permanent
e4:1d:2d:46:13:f3 dev sw1p8 vlan 1 master br0 permanent
e4:1d:2d:a5:f1:7e dev sw1p8 vlan 1 extern_learn offload master br0
e4:1d:2d:46:13:f3 dev sw1p8 master br0 permanent
33:33:00:00:00:01 dev sw1p8 self permanent
33:33:00:00:00:02 dev sw1p8 self permanent
01:00:5e:00:00:01 dev sw1p8 self permanent
33:33:ff:46:13:f3 dev sw1p8 self permanent
33:33:ff:00:00:00 dev sw1p8 self permanent
33:33:00:00:00:01 dev br0 self permanent
33:33:00:00:00:02 dev br0 self permanent
01:00:5e:00:00:01 dev br0 self permanent
33:33:ff:46:13:f1 dev br0 self permanent
33:33:ff:00:00:00 dev br0 self permanent
Entries marked with the offload flag are present in the ASIC's
FDB. Entries marked with the extern_learn flag were learned by an
external entity such as the ASIC, as opposed to those learned by the
bridge driver.
According to the configured aging time, the entries become aged-out and removed from the FDB.
To manually add a static FDB entry, run:
$ bridge fdb add aa:bb:cc:dd:ee:ff dev sw1p7 master static vlan 1
And to delete it, run:
$ bridge fdb del aa:bb:cc:dd:ee:ff dev sw1p7 master static vlan 1
On each host connected to the switch, you may add a new route for multicast traffic. Run:
hostA$ ip route add 224.0.0.0/4 dev <dev>
hostB$ ip route add 224.0.0.0/4 dev <dev>
Multicast traffic may be tested using iperf. Run:
hostA$ iperf -s -B 239.255.1.3 -u -f m -i 1
------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 239.255.1.3
Joining multicast group 239.255.1.3
Receiving 1470 byte datagrams
UDP buffer size: 0.20 MByte (default)
------------------------------------------------------------
hostB$ iperf -c 239.255.1.3 -u -f m -i 1 -b <speed>
To dump the MDB on the switch, run:
$ bridge mdb show
dev br0 port sw1p6 grp 239.255.1.3 temp vid 1
Multicast bridging is enabled by default. To disable it, run:
$ ip link set dev <brdev> type bridge mcast_snooping 0
To change the maximum number of supported MDB entries, run:
$ ip link set dev <brdev> type bridge mcast_hash_max 8192
Note: The max hash value must be a power of 2 (e.g. 128, 256), with the maximum being 8192.
Note: mlxsw has a hard limit of at most 6992 offloaded MDB entries.
As explained in the previous section, multicast is enabled in the Linux bridge by default. It is therefore important for a multicast querier to be present on the network.
If a querier is not available on the network, it is possible to configure the Linux bridge to act as a multicast querier:
$ ip link set dev <brdev> type bridge mcast_querier 1
IGMP queries are sent with the source IP 0.0.0.0 by default, but it is possible to send queries using the bridge's IP address instead. To do so, run:
$ ip link set dev <brdev> type bridge mcast_query_use_ifaddr 1
In IPv6 environments, it is especially important to have a querier present on the network where MLD snooping is performed. If MLD queries are not sent, MDB records for Solicited-Node multicast addresses expire and neighbour discovery fails.
Note: If the bridge is VLAN-aware, only untagged general queries are sent.
In order to activate STP on a bridge, run:
$ ip link set dev BRDEV type bridge stp_state 1
Note: STP is disabled by default. STP must be enabled before enabling the bridge netdev.
802.1ad, also known as QinQ, is an extension to the 802.1q standard, which is concerned with passing possibly 802.1q-tagged packets through another VLAN-like tunnel. The format of 802.1ad tag is the same as 802.1q, except it uses the EtherType of 0x88a8, unlike 802.1q's 0x8100.
To configure 802.1ad bridge, run:
ip link add dev br0 type bridge vlan_filtering 1 vlan_protocol 802.1ad
The following conditions are not allowed:
-
802.1ad VLAN netdevices, whether they are on top of a front-panel port netdevice, a bridge port or a LAG
-
802.1q VLAN netdevices on top of an 802.1ad bridge
-
VLAN netdevices on top of 802.1ad bridge ports
-
Enslavement of netdevices that already have a VLAN netdevice to an 802.1ad bridge
-
Addition of IP address to an 802.1ad bridge
-
Changing bridge protocol
-
Creating more than one VLAN-aware bridge (regardless of protocol)
- man bridge
- man ip
General information
System Maintenance
Network Interface Configuration
- Switch Port Configuration
- Netdevice Statistics
- Persistent Configuration
- Quality of Service
- Queues Management
- How To Configure Lossless RoCE
- Port Mirroring
- ACLs
- OVS
- Resource Management
- Precision Time Protocol (PTP)
Layer 2
Network Virtualization
Layer 3
- Static Routing
- Virtual Routing and Forwarding (VRF)
- Tunneling
- Multicast Routing
- Virtual Router Redundancy Protocol (VRRP)
Debugging