요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
=================
Ethernet Bridging
=================
Introduction
============
The IEEE 802.1Q-2022 (Bridges and Bridged Networks) standard defines the
operation of bridges in computer networks. A bridge, in the context of this
standard, is a device that connects two or more network segments and operates
at the data link layer (Layer 2) of the OSI (Open Systems Interconnection)
model. The purpose of a bridge is to filter and forward frames between
different segments based on the destination MAC (Media Access Control) address.
Bridge kAPI
===========
Here are some core structures of bridge code. Note that the kAPI is *unstable*,
and can be changed at any time.
.. kernel-doc:: net/bridge/br_private.h
:identifiers: net_bridge_vlan
Bridge uAPI
===========
Modern Linux bridge uAPI is accessed via Netlink interface. You can find
below files where the bridge and bridge port netlink attributes are defined.
Bridge netlink attributes
-------------------------
.. kernel-doc:: include/uapi/linux/if_link.h
:doc: Bridge enum definition
Bridge port netlink attributes
------------------------------
.. kernel-doc:: include/uapi/linux/if_link.h
:doc: Bridge port enum definition
Bridge sysfs
------------
The sysfs interface is deprecated and should not be extended if new
options are added.
STP
===
The STP (Spanning Tree Protocol) implementation in the Linux bridge driver
is a critical feature that helps prevent loops and broadcast storms in
Ethernet networks by identifying and disabling redundant links. In a Linux
bridge context, STP is crucial for network stability and availability.
STP is a Layer 2 protocol that operates at the Data Link Layer of the OSI
model. It was originally developed as IEEE 802.1D and has since evolved into
multiple versions, including Rapid Spanning Tree Protocol (RSTP) and
`Multiple Spanning Tree Protocol (MSTP)
<https://lore.kernel.org/netdev/20220316150857.2442916-1-tobias@waldekranz.com/>`_.
The 802.1D-2004 removed the original Spanning Tree Protocol, instead
incorporating the Rapid Spanning Tree Protocol (RSTP). By 2014, all the
functionality defined by IEEE 802.1D has been incorporated into either
IEEE 802.1Q (Bridges and Bridged Networks) or IEEE 802.1AC (MAC Service
Definition). 802.1D has been officially withdrawn in 2022.
Bridge Ports and STP States
---------------------------
In the context of STP, bridge ports can be in one of the following states:
* Blocking: The port is disabled for data traffic and only listens for
BPDUs (Bridge Protocol Data Units) from other devices to determine the
network topology.
* Listening: The port begins to participate in the STP process and listens
for BPDUs.
* Learning: The port continues to listen for BPDUs and begins to learn MAC
addresses from incoming frames but does not forward data frames.
* Forwarding: The port is fully operational and forwards both BPDUs and
data frames.
* Disabled: The port is administratively disabled and does not participate
in the STP process. The data frames forwarding are also disabled.
Root Bridge and Convergence
---------------------------
In the context of networking and Ethernet bridging in Linux, the root bridge
is a designated switch in a bridged network that serves as a reference point
for the spanning tree algorithm to create a loop-free topology.
Here's how the STP works and root bridge is chosen:
1. Bridge Priority: Each bridge running a spanning tree protocol, has a
configurable Bridge Priority value. The lower the value, the higher the
priority. By default, the Bridge Priority is set to a standard value
(e.g., 32768).
2. Bridge ID: The Bridge ID is composed of two components: Bridge Priority
and the MAC address of the bridge. It uniquely identifies each bridge
in the network. The Bridge ID is used to compare the priorities of
different bridges.
3. Bridge Election: When the network starts, all bridges initially assume
that they are the root bridge. They start advertising Bridge Protocol
Data Units (BPDU) to their neighbors, containing their Bridge ID and
other information.
4. BPDU Comparison: Bridges exchange BPDUs to determine the root bridge.
Each bridge examines the received BPDUs, including the Bridge Priority
and Bridge ID, to determine if it should adjust its own priorities.
The bridge with the lowest Bridge ID will become the root bridge.
5. Root Bridge Announcement: Once the root bridge is determined, it sends
BPDUs with information about the root bridge to all other bridges in the
network. This information is used by other bridges to calculate the
shortest path to the root bridge and, in doing so, create a loop-free
topology.
6. Forwarding Ports: After the root bridge is selected and the spanning tree
topology is established, each bridge determines which of its ports should
be in the forwarding state (used for data traffic) and which should be in
the blocking state (used to prevent loops). The root bridge's ports are
all in the forwarding state. while other bridges have some ports in the
blocking state to avoid loops.
7. Root Ports: After the root bridge is selected and the spanning tree
topology is established, each non-root bridge processes incoming
BPDUs and determines which of its ports provides the shortest path to the
root bridge based on the information in the received BPDUs. This port is
designated as the root port. And it is in the Forwarding state, allowing
it to actively forward network traffic.
8. Designated ports: A designated port is the port through which the non-root
bridge will forward traffic towards the designated segment. Designated ports
are placed in the Forwarding state. All other ports on the non-root
bridge that are not designated for specific segments are placed in the
Blocking state to prevent network loops.
STP ensures network convergence by calculating the shortest path and disabling
redundant links. When network topology changes occur (e.g., a link failure),
STP recalculates the network topology to restore connectivity while avoiding loops.
Proper configuration of STP parameters, such as the bridge priority, can
influence network performance, path selection and which bridge becomes the
Root Bridge.
User space STP helper
---------------------
The user space STP helper *bridge-stp* is a program to control whether to use
user mode spanning tree. The ``/sbin/bridge-stp <bridge> <start|stop>`` is
called by the kernel when STP is enabled/disabled on a bridge
(via ``brctl stp <bridge> <on|off>`` or ``ip link set <bridge> type bridge
stp_state <0|1>``). The kernel enables user_stp mode if that command returns
0, or enables kernel_stp mode if that command returns any other value.
VLAN
====
A LAN (Local Area Network) is a network that covers a small geographic area,
typically within a single building or a campus. LANs are used to connect
computers, servers, printers, and other networked devices within a localized
area. LANs can be wired (using Ethernet cables) or wireless (using Wi-Fi).
A VLAN (Virtual Local Area Network) is a logical segmentation of a physical
network into multiple isolated broadcast domains. VLANs are used to divide
a single physical LAN into multiple virtual LANs, allowing different groups of
devices to communicate as if they were on separate physical networks.
Typically there are two VLAN implementations, IEEE 802.1Q and IEEE 802.1ad
(also known as QinQ). IEEE 802.1Q is a standard for VLAN tagging in Ethernet
networks. It allows network administrators to create logical VLANs on a
physical network and tag Ethernet frames with VLAN information, which is
called *VLAN-tagged frames*. IEEE 802.1ad, commonly known as QinQ or Double
VLAN, is an extension of the IEEE 802.1Q standard. QinQ allows for the
stacking of multiple VLAN tags within a single Ethernet frame. The Linux
bridge supports both the IEEE 802.1Q and `802.1AD
<https://lore.kernel.org/netdev/1402401565-15423-1-git-send-email-makita.toshiaki@lab.ntt.co.jp/>`_
protocol for VLAN tagging.
`VLAN filtering <https://lore.kernel.org/netdev/1360792820-14116-1-git-send-email-vyasevic@redhat.com/>`_
on a bridge is disabled by default. After enabling VLAN filtering on a bridge,
it will start forwarding frames to appropriate destinations based on their
destination MAC address and VLAN tag (both must match).
Multicast
=========
The Linux bridge driver has multicast support allowing it to process Internet
Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD)
messages, and to efficiently forward multicast data packets. The bridge
driver supports IGMPv2/IGMPv3 and MLDv1/MLDv2.
Multicast snooping
------------------
Multicast snooping is a networking technology that allows network switches
to intelligently manage multicast traffic within a local area network (LAN).
The switch maintains a multicast group table, which records the association
between multicast group addresses and the ports where hosts have joined these
groups. The group table is dynamically updated based on the IGMP/MLD messages
received. With the multicast group information gathered through snooping, the
switch optimizes the forwarding of multicast traffic. Instead of blindly
broadcasting the multicast traffic to all ports, it sends the multicast
traffic based on the destination MAC address only to ports which have
subscribed the respective destination multicast group.
When created, the Linux bridge devices have multicast snooping enabled by
default. It maintains a Multicast forwarding database (MDB) which keeps track
of port and group relationships.
IGMPv3/MLDv2 EHT support
------------------------
The Linux bridge supports IGMPv3/MLDv2 EHT (Explicit Host Tracking), which
was added by `474ddb37fa3a ("net: bridge: multicast: add EHT allow/block handling")
<https://lore.kernel.org/netdev/20210120145203.1109140-1-razor@blackwall.org/>`_
The explicit host tracking enables the device to keep track of each
individual host that is joined to a particular group or channel. The main
benefit of the explicit host tracking in IGMP is to allow minimal leave
latencies when a host leaves a multicast group or channel.
The length of time between a host wanting to leave and a device stopping
traffic forwarding is called the IGMP leave latency. A device configured
with IGMPv3 or MLDv2 and explicit tracking can immediately stop forwarding
traffic if the last host to request to receive traffic from the device
indicates that it no longer wants to receive traffic. The leave latency
is thus bound only by the packet transmission latencies in the multiaccess
network and the processing time in the device.
Other multicast features
------------------------
The Linux bridge also supports `per-VLAN multicast snooping
<https://lore.kernel.org/netdev/20210719170637.435541-1-razor@blackwall.org/>`_,
which is disabled by default but can be enabled. And `Multicast Router Discovery
<https://lore.kernel.org/netdev/20190121062628.2710-1-linus.luessing@c0d3.blue/>`_,
which help identify the location of multicast routers.
Switchdev
=========
Linux Bridge Switchdev is a feature in the Linux kernel that extends the
capabilities of the traditional Linux bridge to work more efficiently with
hardware switches that support switchdev. With Linux Bridge Switchdev, certain
networking functions like forwarding, filtering, and learning of Ethernet
frames can be offloaded to a hardware switch. This offloading reduces the
burden on the Linux kernel and CPU, leading to improved network performance
and lower latency.
To use Linux Bridge Switchdev, you need hardware switches that support the
switchdev interface. This means that the switch hardware needs to have the
necessary drivers and functionality to work in conjunction with the Linux
kernel.
Please see the :ref:`switchdev` document for more details.
Netfilter
=========
The bridge netfilter module is a legacy feature that allows to filter bridged
packets with iptables and ip6tables. Its use is discouraged. Users should
consider using nftables for packet filtering.
The older ebtables tool is more feature-limited compared to nftables, but
just like nftables it doesn't need this module either to function.
The br_netfilter module intercepts packets entering the bridge, performs
minimal sanity tests on ipv4 and ipv6 packets and then pretends that
these packets are being routed, not bridged. br_netfilter then calls
the ip and ipv6 netfilter hooks from the bridge layer, i.e. ip(6)tables
rulesets will also see these packets.
br_netfilter is also the reason for the iptables *physdev* match:
This match is the only way to reliably tell routed and bridged packets
apart in an iptables ruleset.
Note that ebtables and nftables will work fine without the br_netfilter module.
iptables/ip6tables/arptables do not work for bridged traffic because they
plug in the routing stack. nftables rules in ip/ip6/inet/arp families won't
see traffic that is forwarded by a bridge either, but that's very much how it
should be.
Historically the feature set of ebtables was very limited (it still is),
this module was added to pretend packets are routed and invoke the ipv4/ipv6
netfilter hooks from the bridge so users had access to the more feature-rich
iptables matching capabilities (including conntrack). nftables doesn't have
this limitation, pretty much all features work regardless of the protocol family.
So, br_netfilter is only needed if users, for some reason, need to use
ip(6)tables to filter packets forwarded by the bridge, or NAT bridged
traffic. For pure link layer filtering, this module isn't needed.
Other Features
==============
The Linux bridge also supports `IEEE 802.11 Proxy ARP
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=958501163ddd6ea22a98f94fa0e7ce6d4734e5c4>`_,
`Media Redundancy Protocol (MRP)
<https://lore.kernel.org/netdev/20200426132208.3232-1-horatiu.vultur@microchip.com/>`_,
`Media Redundancy Protocol (MRP) LC mode
<https://lore.kernel.org/r/20201124082525.273820-1-horatiu.vultur@microchip.com>`_,
`IEEE 802.1X port authentication
<https://lore.kernel.org/netdev/20220218155148.2329797-1-schultz.hans+netdev@gmail.com/>`_,
and `MAC Authentication Bypass (MAB)
<https://lore.kernel.org/netdev/20221101193922.2125323-2-idosch@nvidia.com/>`_.
FAQ
===
What does a bridge do?
----------------------
A bridge transparently forwards traffic between multiple network interfaces.
In plain English this means that a bridge connects two or more physical
Ethernet networks, to form one larger (logical) Ethernet network.
Is it L3 protocol independent?
------------------------------
Yes. The bridge sees all frames, but it *uses* only L2 headers/information.
As such, the bridging functionality is protocol independent, and there should
be no trouble forwarding IPX, NetBEUI, IP, IPv6, etc.
Contact Info
============
The code is currently maintained by Roopa Prabhu <roopa@nvidia.com> and
Nikolay Aleksandrov <razor@blackwall.org>. Bridge bugs and enhancements
are discussed on the linux-netdev mailing list netdev@vger.kernel.org and
bridge@lists.linux.dev.
The list is open to anyone interested: http://vger.kernel.org/vger-lists.html#netdev
External Links
==============
The old Documentation for Linux bridging is on:
https://wiki.linuxfoundation.org/networking/bridge
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Ethernet bridge 개요와 API
1-49`.. SPDX-License-Identifier: GPL-2.0`
Ethernet 브리징
소개
IEEE 802.1Q-2022(Bridges and Bridged Networks) 표준은 컴퓨터 네트워크에서 bridge가 동작하는 방식을 정의합니다. 이 표준에서 bridge는 둘 이상의 network segment를 연결하며 OSI(Open Systems Interconnection) 모델의 data link layer(Layer 2)에서 동작하는 장치입니다. Bridge의 목적은 destination MAC(Media Access Control) address를 기준으로 서로 다른 segment 사이의 frame을 filtering하고 forwarding하는 것입니다.
Bridge kAPI
다음은 bridge code의 핵심 structure 일부입니다. 이 kAPI는 *unstable*하며 언제든 변경될 수 있다는 점에 유의하십시오.
.. kernel-doc:: net/bridge/br_private.h
:identifiers: net_bridge_vlanBridge uAPI
현대 Linux bridge uAPI는 Netlink interface를 통해 접근합니다. Bridge와 bridge port의 netlink attribute가 정의된 파일은 아래와 같습니다.
Bridge netlink attribute
.. kernel-doc:: include/uapi/linux/if_link.h
:doc: Bridge enum definitionBridge port netlink attribute
.. kernel-doc:: include/uapi/linux/if_link.h
:doc: Bridge port enum definitionBridge sysfs
sysfs interface는 deprecated 상태이므로 새 option을 추가할 때 이 interface를 확장해서는 안 됩니다.
.. SPDX-License-Identifier: GPL-2.0
=================
Ethernet Bridging
=================
Introduction
============
The IEEE 802.1Q-2022 (Bridges and Bridged Networks) standard defines the
operation of bridges in computer networks. A bridge, in the context of this
standard, is a device that connects two or more network segments and operates
at the data link layer (Layer 2) of the OSI (Open Systems Interconnection)
model. The purpose of a bridge is to filter and forward frames between
different segments based on the destination MAC (Media Access Control) address.
Bridge kAPI
===========
Here are some core structures of bridge code. Note that the kAPI is *unstable*,
and can be changed at any time.
.. kernel-doc:: net/bridge/br_private.h
:identifiers: net_bridge_vlan
Bridge uAPI
===========
Modern Linux bridge uAPI is accessed via Netlink interface. You can find
below files where the bridge and bridge port netlink attributes are defined.
Bridge netlink attributes
-------------------------
.. kernel-doc:: include/uapi/linux/if_link.h
:doc: Bridge enum definition
Bridge port netlink attributes
------------------------------
.. kernel-doc:: include/uapi/linux/if_link.h
:doc: Bridge port enum definition
Bridge sysfs
------------
The sysfs interface is deprecated and should not be extended if new
options are added.
STP와 bridge port 상태
50-85STP
Linux bridge driver의 STP(Spanning Tree Protocol) 구현은 중복 link를 식별하고 비활성화하여 Ethernet network의 loop와 broadcast storm을 방지하는 핵심 기능입니다. Linux bridge 환경에서 STP는 network 안정성과 가용성을 유지하는 데 중요합니다.
STP는 OSI 모델의 Data Link Layer에서 동작하는 Layer 2 protocol입니다. 처음에는 IEEE 802.1D로 개발되었으며, 이후 Rapid Spanning Tree Protocol(RSTP)과 `Multiple Spanning Tree Protocol(MSTP) <https://lore.kernel.org/netdev/20220316150857.2442916-1-tobias@waldekranz.com/>`_을 포함한 여러 version으로 발전했습니다.
802.1D-2004는 원래 Spanning Tree Protocol을 제거하고 그 대신 Rapid Spanning Tree Protocol(RSTP)을 포함했습니다. 2014년에는 IEEE 802.1D가 정의하던 모든 기능이 IEEE 802.1Q(Bridges and Bridged Networks) 또는 IEEE 802.1AC(MAC Service Definition)에 편입되었습니다. 802.1D는 2022년에 공식 폐기되었습니다.
Bridge port와 STP 상태
STP 관점에서 bridge port는 다음 상태 가운데 하나에 있을 수 있습니다.
- Blocking: data traffic에 대해 port가 비활성화되며, network topology를 판단하기 위해 다른 장치가 보내는 BPDU(Bridge Protocol Data Unit)만 수신합니다.
- Listening: port가 STP 절차에 참여하기 시작하고 BPDU를 수신합니다.
- Learning: port가 계속 BPDU를 수신하면서 들어오는 frame의 MAC address를 학습하기 시작하지만 data frame은 forwarding하지 않습니다.
- Forwarding: port가 완전히 동작하며 BPDU와 data frame을 모두 forwarding합니다.
- Disabled: port가 관리 목적으로 비활성화되어 STP 절차에 참여하지 않으며 data frame forwarding도 비활성화됩니다.
STP
===
The STP (Spanning Tree Protocol) implementation in the Linux bridge driver
is a critical feature that helps prevent loops and broadcast storms in
Ethernet networks by identifying and disabling redundant links. In a Linux
bridge context, STP is crucial for network stability and availability.
STP is a Layer 2 protocol that operates at the Data Link Layer of the OSI
model. It was originally developed as IEEE 802.1D and has since evolved into
multiple versions, including Rapid Spanning Tree Protocol (RSTP) and
`Multiple Spanning Tree Protocol (MSTP)
<https://lore.kernel.org/netdev/20220316150857.2442916-1-tobias@waldekranz.com/>`_.
The 802.1D-2004 removed the original Spanning Tree Protocol, instead
incorporating the Rapid Spanning Tree Protocol (RSTP). By 2014, all the
functionality defined by IEEE 802.1D has been incorporated into either
IEEE 802.1Q (Bridges and Bridged Networks) or IEEE 802.1AC (MAC Service
Definition). 802.1D has been officially withdrawn in 2022.
Bridge Ports and STP States
---------------------------
In the context of STP, bridge ports can be in one of the following states:
* Blocking: The port is disabled for data traffic and only listens for
BPDUs (Bridge Protocol Data Units) from other devices to determine the
network topology.
* Listening: The port begins to participate in the STP process and listens
for BPDUs.
* Learning: The port continues to listen for BPDUs and begins to learn MAC
addresses from incoming frames but does not forward data frames.
* Forwarding: The port is fully operational and forwards both BPDUs and
data frames.
* Disabled: The port is administratively disabled and does not participate
in the STP process. The data frames forwarding are also disabled.
Root bridge 선출과 convergence
86-150Root bridge와 convergence
Linux networking과 Ethernet bridging에서 root bridge는 bridged network 안에서 지정된 switch이며, spanning tree algorithm이 loop 없는 topology를 만드는 기준점 역할을 합니다.
STP가 동작하고 root bridge가 선택되는 과정은 다음과 같습니다.
- 1. Bridge Priority: spanning tree protocol을 실행하는 각 bridge에는 설정 가능한 Bridge Priority 값이 있습니다. 값이 낮을수록 우선순위가 높습니다. 기본 Bridge Priority는 보통 32768 같은 표준값입니다.
- 2. Bridge ID: Bridge ID는 Bridge Priority와 bridge의 MAC address 두 요소로 구성되며 network의 각 bridge를 고유하게 식별합니다. 서로 다른 bridge의 우선순위를 비교할 때 Bridge ID를 사용합니다.
- 3. Bridge Election: network가 시작되면 모든 bridge는 처음에 자신이 root bridge라고 가정합니다. 각 bridge는 자신의 Bridge ID와 기타 정보를 담은 BPDU(Bridge Protocol Data Unit)를 neighbor에 알리기 시작합니다.
- 4. BPDU Comparison: bridge는 BPDU를 교환하여 root bridge를 결정합니다. 각 bridge는 수신한 BPDU의 Bridge Priority와 Bridge ID 등을 살펴 자신의 우선순위를 조정해야 하는지 판단합니다. Bridge ID가 가장 낮은 bridge가 root bridge가 됩니다.
- 5. Root Bridge Announcement: root bridge가 정해지면 해당 bridge는 root bridge 정보를 담은 BPDU를 network의 다른 모든 bridge에 보냅니다. 다른 bridge는 이 정보로 root bridge까지의 shortest path를 계산하고 loop 없는 topology를 만듭니다.
- 6. Forwarding Ports: root bridge가 선택되고 spanning tree topology가 확립되면 각 bridge는 어느 port를 data traffic용 Forwarding 상태로 둘지, 어느 port를 loop 방지용 Blocking 상태로 둘지 정합니다. Root bridge의 모든 port는 Forwarding 상태이고, 다른 bridge는 loop를 피하기 위해 일부 port를 Blocking 상태로 둡니다.
- 7. Root Ports: root bridge가 선택되고 spanning tree topology가 확립되면 각 non-root bridge는 수신 BPDU를 처리하여 그 정보에 따라 root bridge까지 가장 짧은 경로를 제공하는 port를 찾습니다. 이 port가 root port로 지정되며, network traffic을 능동적으로 forwarding할 수 있도록 Forwarding 상태가 됩니다.
- 8. Designated ports: designated port는 non-root bridge가 지정된 segment 쪽으로 traffic을 forwarding하는 port입니다. Designated port는 Forwarding 상태에 놓입니다. 특정 segment용 designated port가 아닌 non-root bridge의 나머지 port는 network loop를 막기 위해 Blocking 상태에 놓입니다.
STP는 shortest path를 계산하고 중복 link를 비활성화하여 network convergence를 보장합니다. Link failure 같은 network topology 변화가 발생하면 STP는 loop를 피하면서 연결을 복구하도록 network topology를 다시 계산합니다.
Bridge priority 같은 STP parameter를 적절히 설정하면 network 성능, path 선택, 어느 bridge가 Root Bridge가 되는지에 영향을 줄 수 있습니다.
User space STP helper
User space STP helper인 *bridge-stp*는 user mode spanning tree를 사용할지 제어하는 program입니다. Bridge에서 STP가 활성화되거나 비활성화될 때, 즉 `brctl stp <bridge> <on|off>` 또는 `ip link set <bridge> type bridge stp_state <0|1>`를 실행할 때 kernel은 `/sbin/bridge-stp <bridge> <start|stop>`을 호출합니다. 이 command가 0을 반환하면 kernel은 user_stp mode를 활성화하고, 다른 값을 반환하면 kernel_stp mode를 활성화합니다.
Root Bridge and Convergence
---------------------------
In the context of networking and Ethernet bridging in Linux, the root bridge
is a designated switch in a bridged network that serves as a reference point
for the spanning tree algorithm to create a loop-free topology.
Here's how the STP works and root bridge is chosen:
1. Bridge Priority: Each bridge running a spanning tree protocol, has a
configurable Bridge Priority value. The lower the value, the higher the
priority. By default, the Bridge Priority is set to a standard value
(e.g., 32768).
2. Bridge ID: The Bridge ID is composed of two components: Bridge Priority
and the MAC address of the bridge. It uniquely identifies each bridge
in the network. The Bridge ID is used to compare the priorities of
different bridges.
3. Bridge Election: When the network starts, all bridges initially assume
that they are the root bridge. They start advertising Bridge Protocol
Data Units (BPDU) to their neighbors, containing their Bridge ID and
other information.
4. BPDU Comparison: Bridges exchange BPDUs to determine the root bridge.
Each bridge examines the received BPDUs, including the Bridge Priority
and Bridge ID, to determine if it should adjust its own priorities.
The bridge with the lowest Bridge ID will become the root bridge.
5. Root Bridge Announcement: Once the root bridge is determined, it sends
BPDUs with information about the root bridge to all other bridges in the
network. This information is used by other bridges to calculate the
shortest path to the root bridge and, in doing so, create a loop-free
topology.
6. Forwarding Ports: After the root bridge is selected and the spanning tree
topology is established, each bridge determines which of its ports should
be in the forwarding state (used for data traffic) and which should be in
the blocking state (used to prevent loops). The root bridge's ports are
all in the forwarding state. while other bridges have some ports in the
blocking state to avoid loops.
7. Root Ports: After the root bridge is selected and the spanning tree
topology is established, each non-root bridge processes incoming
BPDUs and determines which of its ports provides the shortest path to the
root bridge based on the information in the received BPDUs. This port is
designated as the root port. And it is in the Forwarding state, allowing
it to actively forward network traffic.
8. Designated ports: A designated port is the port through which the non-root
bridge will forward traffic towards the designated segment. Designated ports
are placed in the Forwarding state. All other ports on the non-root
bridge that are not designated for specific segments are placed in the
Blocking state to prevent network loops.
STP ensures network convergence by calculating the shortest path and disabling
redundant links. When network topology changes occur (e.g., a link failure),
STP recalculates the network topology to restore connectivity while avoiding loops.
Proper configuration of STP parameters, such as the bridge priority, can
influence network performance, path selection and which bridge becomes the
Root Bridge.
User space STP helper
---------------------
The user space STP helper *bridge-stp* is a program to control whether to use
user mode spanning tree. The ``/sbin/bridge-stp <bridge> <start|stop>`` is
called by the kernel when STP is enabled/disabled on a bridge
(via ``brctl stp <bridge> <on|off>`` or ``ip link set <bridge> type bridge
stp_state <0|1>``). The kernel enables user_stp mode if that command returns
0, or enables kernel_stp mode if that command returns any other value.
VLAN과 VLAN filtering
151-179VLAN
LAN(Local Area Network)은 일반적으로 단일 건물이나 campus처럼 작은 지리적 영역을 포괄하는 network입니다. LAN은 제한된 영역 안의 computer, server, printer 및 기타 network 장치를 연결하는 데 쓰입니다. LAN은 Ethernet cable을 사용하는 유선 방식이나 Wi-Fi를 사용하는 무선 방식일 수 있습니다.
VLAN(Virtual Local Area Network)은 물리 network를 서로 격리된 여러 broadcast domain으로 논리적으로 분할한 것입니다. VLAN을 사용하면 하나의 물리 LAN을 여러 virtual LAN으로 나누어 서로 다른 장치 group이 별도의 물리 network에 있는 것처럼 통신할 수 있습니다.
대표적인 VLAN 구현은 IEEE 802.1Q와 IEEE 802.1ad(QinQ라고도 함) 두 가지입니다. IEEE 802.1Q는 Ethernet network의 VLAN tagging 표준입니다. Network 관리자는 물리 network에 논리 VLAN을 만들고 Ethernet frame에 VLAN 정보를 tag할 수 있으며, 이렇게 만든 frame을 *VLAN-tagged frame*이라 합니다. IEEE 802.1ad는 보통 QinQ 또는 Double VLAN이라 부르는 IEEE 802.1Q 확장입니다. QinQ는 하나의 Ethernet frame 안에 여러 VLAN tag를 쌓을 수 있게 합니다. Linux bridge는 VLAN tagging에 IEEE 802.1Q와 `802.1AD <https://lore.kernel.org/netdev/1402401565-15423-1-git-send-email-makita.toshiaki@lab.ntt.co.jp/>`_ protocol을 모두 지원합니다.
Bridge의 `VLAN filtering <https://lore.kernel.org/netdev/1360792820-14116-1-git-send-email-vyasevic@redhat.com/>`_은 기본적으로 비활성화되어 있습니다. VLAN filtering을 활성화하면 bridge는 destination MAC address와 VLAN tag가 모두 일치하는지에 따라 frame을 적절한 destination으로 forwarding하기 시작합니다.
VLAN
====
A LAN (Local Area Network) is a network that covers a small geographic area,
typically within a single building or a campus. LANs are used to connect
computers, servers, printers, and other networked devices within a localized
area. LANs can be wired (using Ethernet cables) or wireless (using Wi-Fi).
A VLAN (Virtual Local Area Network) is a logical segmentation of a physical
network into multiple isolated broadcast domains. VLANs are used to divide
a single physical LAN into multiple virtual LANs, allowing different groups of
devices to communicate as if they were on separate physical networks.
Typically there are two VLAN implementations, IEEE 802.1Q and IEEE 802.1ad
(also known as QinQ). IEEE 802.1Q is a standard for VLAN tagging in Ethernet
networks. It allows network administrators to create logical VLANs on a
physical network and tag Ethernet frames with VLAN information, which is
called *VLAN-tagged frames*. IEEE 802.1ad, commonly known as QinQ or Double
VLAN, is an extension of the IEEE 802.1Q standard. QinQ allows for the
stacking of multiple VLAN tags within a single Ethernet frame. The Linux
bridge supports both the IEEE 802.1Q and `802.1AD
<https://lore.kernel.org/netdev/1402401565-15423-1-git-send-email-makita.toshiaki@lab.ntt.co.jp/>`_
protocol for VLAN tagging.
`VLAN filtering <https://lore.kernel.org/netdev/1360792820-14116-1-git-send-email-vyasevic@redhat.com/>`_
on a bridge is disabled by default. After enabling VLAN filtering on a bridge,
it will start forwarding frames to appropriate destinations based on their
destination MAC address and VLAN tag (both must match).
Multicast snooping과 EHT
180-235Multicast
Linux bridge driver는 IGMP(Internet Group Management Protocol) 또는 MLD(Multicast Listener Discovery) message를 처리하고 multicast data packet을 효율적으로 forwarding할 수 있는 multicast 기능을 제공합니다. Bridge driver는 IGMPv2/IGMPv3와 MLDv1/MLDv2를 지원합니다.
Multicast snooping
Multicast snooping은 network switch가 LAN 안의 multicast traffic을 지능적으로 관리할 수 있게 하는 networking 기술입니다.
Switch는 multicast group address와 해당 group에 가입한 host가 있는 port 사이의 관계를 기록하는 multicast group table을 유지합니다. Group table은 수신한 IGMP/MLD message에 따라 동적으로 갱신됩니다. Switch는 snooping으로 수집한 multicast group 정보를 이용해 multicast traffic forwarding을 최적화합니다. 모든 port에 multicast traffic을 무작정 broadcast하는 대신, destination MAC address를 기준으로 해당 destination multicast group을 구독한 port에만 traffic을 보냅니다.
Linux bridge device를 만들면 multicast snooping이 기본적으로 활성화됩니다. Bridge는 port와 group의 관계를 추적하는 MDB(Multicast Forwarding Database)를 유지합니다.
IGMPv3/MLDv2 EHT 지원
Linux bridge는 IGMPv3/MLDv2 EHT(Explicit Host Tracking)를 지원합니다. 이 기능은 `474ddb37fa3a ("net: bridge: multicast: add EHT allow/block handling") <https://lore.kernel.org/netdev/20210120145203.1109140-1-razor@blackwall.org/>`_에서 추가되었습니다.
Explicit host tracking을 사용하면 특정 group 또는 channel에 가입한 각 host를 장치가 개별적으로 추적할 수 있습니다. IGMP에서 이 기능의 주된 이점은 host가 multicast group이나 channel을 떠날 때 leave latency를 최소화할 수 있다는 것입니다.
Host가 떠나려 한 시점부터 장치가 traffic forwarding을 중단할 때까지의 시간을 IGMP leave latency라 합니다. IGMPv3 또는 MLDv2와 explicit tracking을 설정한 장치는 마지막 수신 요청 host가 더 이상 traffic을 원하지 않는다고 표시하면 즉시 forwarding을 중단할 수 있습니다. 따라서 leave latency는 multiaccess network의 packet 전송 지연과 장치의 처리 시간만으로 제한됩니다.
기타 multicast 기능
Linux bridge는 기본적으로 비활성화되어 있지만 켤 수 있는 `per-VLAN multicast snooping <https://lore.kernel.org/netdev/20210719170637.435541-1-razor@blackwall.org/>`_도 지원합니다. 또한 multicast router의 위치를 식별하는 데 도움이 되는 `Multicast Router Discovery <https://lore.kernel.org/netdev/20190121062628.2710-1-linus.luessing@c0d3.blue/>`_도 지원합니다.
Multicast
=========
The Linux bridge driver has multicast support allowing it to process Internet
Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD)
messages, and to efficiently forward multicast data packets. The bridge
driver supports IGMPv2/IGMPv3 and MLDv1/MLDv2.
Multicast snooping
------------------
Multicast snooping is a networking technology that allows network switches
to intelligently manage multicast traffic within a local area network (LAN).
The switch maintains a multicast group table, which records the association
between multicast group addresses and the ports where hosts have joined these
groups. The group table is dynamically updated based on the IGMP/MLD messages
received. With the multicast group information gathered through snooping, the
switch optimizes the forwarding of multicast traffic. Instead of blindly
broadcasting the multicast traffic to all ports, it sends the multicast
traffic based on the destination MAC address only to ports which have
subscribed the respective destination multicast group.
When created, the Linux bridge devices have multicast snooping enabled by
default. It maintains a Multicast forwarding database (MDB) which keeps track
of port and group relationships.
IGMPv3/MLDv2 EHT support
------------------------
The Linux bridge supports IGMPv3/MLDv2 EHT (Explicit Host Tracking), which
was added by `474ddb37fa3a ("net: bridge: multicast: add EHT allow/block handling")
<https://lore.kernel.org/netdev/20210120145203.1109140-1-razor@blackwall.org/>`_
The explicit host tracking enables the device to keep track of each
individual host that is joined to a particular group or channel. The main
benefit of the explicit host tracking in IGMP is to allow minimal leave
latencies when a host leaves a multicast group or channel.
The length of time between a host wanting to leave and a device stopping
traffic forwarding is called the IGMP leave latency. A device configured
with IGMPv3 or MLDv2 and explicit tracking can immediately stop forwarding
traffic if the last host to request to receive traffic from the device
indicates that it no longer wants to receive traffic. The leave latency
is thus bound only by the packet transmission latencies in the multiaccess
network and the processing time in the device.
Other multicast features
------------------------
The Linux bridge also supports `per-VLAN multicast snooping
<https://lore.kernel.org/netdev/20210719170637.435541-1-razor@blackwall.org/>`_,
which is disabled by default but can be enabled. And `Multicast Router Discovery
<https://lore.kernel.org/netdev/20190121062628.2710-1-linus.luessing@c0d3.blue/>`_,
which help identify the location of multicast routers.
Switchdev offload와 Netfilter
236-289Switchdev
Linux Bridge Switchdev는 기존 Linux bridge가 switchdev를 지원하는 hardware switch와 더 효율적으로 동작하도록 기능을 확장한 Linux kernel 기능입니다. Linux Bridge Switchdev를 사용하면 Ethernet frame의 forwarding, filtering, learning 같은 일부 networking 기능을 hardware switch로 offload할 수 있습니다. Offload는 Linux kernel과 CPU의 부담을 줄여 network 성능을 높이고 latency를 낮춥니다.
Linux Bridge Switchdev를 사용하려면 switchdev interface를 지원하는 hardware switch가 필요합니다. 즉, switch hardware에 Linux kernel과 함께 동작하는 데 필요한 driver와 기능이 있어야 합니다.
자세한 내용은 :ref:`switchdev` 문서를 참조하십시오.
Netfilter
Bridge netfilter module은 bridged packet을 iptables와 ip6tables로 filtering할 수 있게 하는 legacy 기능입니다. 사용은 권장되지 않으며 packet filtering에는 nftables 사용을 고려해야 합니다.
오래된 ebtables 도구는 nftables보다 기능이 제한적이지만, nftables와 마찬가지로 동작에 이 module이 필요하지는 않습니다.
`br_netfilter` module은 bridge로 들어오는 packet을 가로채 IPv4와 IPv6 packet에 최소한의 sanity test를 수행한 뒤, 이 packet이 bridged된 것이 아니라 routed된 것처럼 처리합니다. 이어서 `br_netfilter`는 bridge layer에서 IP 및 IPv6 netfilter hook을 호출하므로 ip(6)tables ruleset에서도 이 packet을 보게 됩니다.
`br_netfilter`는 iptables의 *physdev* match가 존재하는 이유이기도 합니다. 이 match는 iptables ruleset에서 routed packet과 bridged packet을 확실히 구별하는 유일한 방법입니다.
`br_netfilter` module이 없어도 ebtables와 nftables는 정상 동작합니다. iptables/ip6tables/arptables는 routing stack에 연결되므로 bridged traffic에는 동작하지 않습니다. nftables의 ip/ip6/inet/arp family rule도 bridge가 forwarding하는 traffic을 보지 않는데, 이것이 정상 동작입니다.
역사적으로 ebtables의 기능은 매우 제한적이었고 지금도 그렇습니다. 이 module은 packet을 routed된 것처럼 가장하고 bridge에서 IPv4/IPv6 netfilter hook을 호출하여 사용자가 conntrack을 포함한 iptables의 더 풍부한 match 기능을 쓸 수 있도록 추가되었습니다. nftables에는 이 제약이 없으며 protocol family와 관계없이 거의 모든 기능이 동작합니다.
따라서 사용자가 특별한 이유로 bridge가 forwarding한 packet을 ip(6)tables로 filtering하거나 bridged traffic에 NAT를 적용해야 할 때만 `br_netfilter`가 필요합니다. 순수한 link layer filtering에는 이 module이 필요하지 않습니다.
Switchdev
=========
Linux Bridge Switchdev is a feature in the Linux kernel that extends the
capabilities of the traditional Linux bridge to work more efficiently with
hardware switches that support switchdev. With Linux Bridge Switchdev, certain
networking functions like forwarding, filtering, and learning of Ethernet
frames can be offloaded to a hardware switch. This offloading reduces the
burden on the Linux kernel and CPU, leading to improved network performance
and lower latency.
To use Linux Bridge Switchdev, you need hardware switches that support the
switchdev interface. This means that the switch hardware needs to have the
necessary drivers and functionality to work in conjunction with the Linux
kernel.
Please see the :ref:`switchdev` document for more details.
Netfilter
=========
The bridge netfilter module is a legacy feature that allows to filter bridged
packets with iptables and ip6tables. Its use is discouraged. Users should
consider using nftables for packet filtering.
The older ebtables tool is more feature-limited compared to nftables, but
just like nftables it doesn't need this module either to function.
The br_netfilter module intercepts packets entering the bridge, performs
minimal sanity tests on ipv4 and ipv6 packets and then pretends that
these packets are being routed, not bridged. br_netfilter then calls
the ip and ipv6 netfilter hooks from the bridge layer, i.e. ip(6)tables
rulesets will also see these packets.
br_netfilter is also the reason for the iptables *physdev* match:
This match is the only way to reliably tell routed and bridged packets
apart in an iptables ruleset.
Note that ebtables and nftables will work fine without the br_netfilter module.
iptables/ip6tables/arptables do not work for bridged traffic because they
plug in the routing stack. nftables rules in ip/ip6/inet/arp families won't
see traffic that is forwarded by a bridge either, but that's very much how it
should be.
Historically the feature set of ebtables was very limited (it still is),
this module was added to pretend packets are routed and invoke the ipv4/ipv6
netfilter hooks from the bridge so users had access to the more feature-rich
iptables matching capabilities (including conntrack). nftables doesn't have
this limitation, pretty much all features work regardless of the protocol family.
So, br_netfilter is only needed if users, for some reason, need to use
ip(6)tables to filter packets forwarded by the bridge, or NAT bridged
traffic. For pure link layer filtering, this module isn't needed.
기타 기능, FAQ와 연락처
290-335기타 기능
Linux bridge는 `IEEE 802.11 Proxy ARP <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=958501163ddd6ea22a98f94fa0e7ce6d4734e5c4>`_, `Media Redundancy Protocol (MRP) <https://lore.kernel.org/netdev/20200426132208.3232-1-horatiu.vultur@microchip.com/>`_, `Media Redundancy Protocol (MRP) LC mode <https://lore.kernel.org/r/20201124082525.273820-1-horatiu.vultur@microchip.com>`_, `IEEE 802.1X port authentication <https://lore.kernel.org/netdev/20220218155148.2329797-1-schultz.hans+netdev@gmail.com/>`_, `MAC Authentication Bypass (MAB) <https://lore.kernel.org/netdev/20221101193922.2125323-2-idosch@nvidia.com/>`_도 지원합니다.
FAQ
Bridge는 무엇을 합니까?
Bridge는 여러 network interface 사이에서 traffic을 투명하게 forwarding합니다. 쉽게 말하면 둘 이상의 물리 Ethernet network를 연결하여 하나의 더 큰 논리 Ethernet network를 만듭니다.
L3 protocol과 독립적입니까?
그렇습니다. Bridge는 모든 frame을 보지만 L2 header와 정보만 *사용*합니다. 따라서 bridging 기능은 protocol과 독립적이며 IPX, NetBEUI, IP, IPv6 등을 forwarding하는 데 문제가 없어야 합니다.
연락처
현재 code는 Roopa Prabhu <roopa@nvidia.com>와 Nikolay Aleksandrov <razor@blackwall.org>가 유지관리합니다. Bridge bug와 개선 사항은 linux-netdev mailing list인 netdev@vger.kernel.org와 bridge@lists.linux.dev에서 논의합니다.
관심 있는 누구나 list에 참여할 수 있습니다: http://vger.kernel.org/vger-lists.html#netdev
외부 link
Linux bridging의 이전 문서는 다음 위치에 있습니다: https://wiki.linuxfoundation.org/networking/bridge
Other Features
==============
The Linux bridge also supports `IEEE 802.11 Proxy ARP
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=958501163ddd6ea22a98f94fa0e7ce6d4734e5c4>`_,
`Media Redundancy Protocol (MRP)
<https://lore.kernel.org/netdev/20200426132208.3232-1-horatiu.vultur@microchip.com/>`_,
`Media Redundancy Protocol (MRP) LC mode
<https://lore.kernel.org/r/20201124082525.273820-1-horatiu.vultur@microchip.com>`_,
`IEEE 802.1X port authentication
<https://lore.kernel.org/netdev/20220218155148.2329797-1-schultz.hans+netdev@gmail.com/>`_,
and `MAC Authentication Bypass (MAB)
<https://lore.kernel.org/netdev/20221101193922.2125323-2-idosch@nvidia.com/>`_.
FAQ
===
What does a bridge do?
----------------------
A bridge transparently forwards traffic between multiple network interfaces.
In plain English this means that a bridge connects two or more physical
Ethernet networks, to form one larger (logical) Ethernet network.
Is it L3 protocol independent?
------------------------------
Yes. The bridge sees all frames, but it *uses* only L2 headers/information.
As such, the bridging functionality is protocol independent, and there should
be no trouble forwarding IPX, NetBEUI, IP, IPv6, etc.
Contact Info
============
The code is currently maintained by Roopa Prabhu <roopa@nvidia.com> and
Nikolay Aleksandrov <razor@blackwall.org>. Bridge bugs and enhancements
are discussed on the linux-netdev mailing list netdev@vger.kernel.org and
bridge@lists.linux.dev.
The list is open to anyone interested: http://vger.kernel.org/vger-lists.html#netdev
External Links
==============
The old Documentation for Linux bridging is on:
https://wiki.linuxfoundation.org/networking/bridge
요약·해설
bridge.rst:1-335Linux bridge는 여러 interface를 하나의 Layer 2 network로 묶고 destination MAC address를 기준으로 frame을 학습·filtering·forwarding합니다. 이 문서는 단순한 bridge 생성법보다 STP의 loop 방지, VLAN 격리, multicast 가입 추적, hardware offload, packet filtering 경계를 정확히 이해하는 데 초점을 둡니다.
기능마다 판단에 사용하는 정보와 핵심 목적이 다릅니다.
모든 bridge가 BPDU를 비교해 하나의 loop-free topology로 수렴합니다.
학습과 forwarding 허용 범위를 단계별로 구분합니다.
Bridge는 802.1Q와 802.1ad tagging을 모두 지원합니다.
IGMP/MLD 가입 정보를 MDB에 반영해 불필요한 flooding을 줄입니다.
새 구성은 nftables를 중심으로 판단하고 br_netfilter는 필요한 경우에만 사용합니다.
지원 hardware와 driver가 있으면 bridge의 일부 data-plane 기능을 switch로 넘깁니다.