From: Hangbin Liu <liuhangbin@gmail.com>
To: netdev@vger.kernel.org
Cc: "David S . Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Ido Schimmel <idosch@idosch.org>,
Nikolay Aleksandrov <razor@blackwall.org>,
Roopa Prabhu <roopa@nvidia.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Florian Westphal <fw@strlen.de>, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
Marc Muehlfeld <mmuehlfe@redhat.com>,
Hangbin Liu <liuhangbin@gmail.com>
Subject: [PATCH net-next 05/10] docs: bridge: add STP doc
Date: Fri, 17 Nov 2023 17:31:40 +0800 [thread overview]
Message-ID: <20231117093145.1563511-6-liuhangbin@gmail.com> (raw)
In-Reply-To: <20231117093145.1563511-1-liuhangbin@gmail.com>
Add STP part for bridge document.
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
Documentation/networking/bridge.rst | 85 +++++++++++++++++++++++++++++
1 file changed, 85 insertions(+)
diff --git a/Documentation/networking/bridge.rst b/Documentation/networking/bridge.rst
index 84aae94f6598..1fd339e48129 100644
--- a/Documentation/networking/bridge.rst
+++ b/Documentation/networking/bridge.rst
@@ -51,6 +51,91 @@ options are added.
.. kernel-doc:: net/bridge/br_sysfs_br.c
:doc: Bridge sysfs attributes
+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/>`_.
+
+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 which bridge becomes the Root Bridge. Careful configuration can
+optimize network performance and path selection.
+
FAQ
===
--
2.41.0
next prev parent reply other threads:[~2023-11-17 9:32 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-17 9:31 [PATCH net-next 00/10] Doc: update bridge doc Hangbin Liu
2023-11-17 9:31 ` [PATCH net-next 01/10] net: bridge: add document for IFLA_BR enum Hangbin Liu
2023-11-18 17:45 ` Jakub Kicinski
2023-11-21 3:28 ` Hangbin Liu
2023-11-21 16:21 ` Jakub Kicinski
2023-11-23 14:07 ` Hangbin Liu
2023-11-19 16:46 ` Vladimir Oltean
2023-11-19 18:21 ` Andrew Lunn
2023-11-21 3:10 ` Hangbin Liu
2023-11-21 3:06 ` Hangbin Liu
2023-11-17 9:31 ` [PATCH net-next 02/10] net: bridge: add document for IFLA_BRPORT enum Hangbin Liu
2023-11-20 11:31 ` Vladimir Oltean
2023-11-21 3:10 ` Hangbin Liu
2023-11-17 9:31 ` [PATCH net-next 03/10] net: bridge: add document for bridge sysfs attribute Hangbin Liu
2023-11-17 9:31 ` [PATCH net-next 04/10] docs: bridge: Add kAPI/uAPI fields Hangbin Liu
2023-11-17 9:31 ` Hangbin Liu [this message]
2023-11-20 11:39 ` [PATCH net-next 05/10] docs: bridge: add STP doc Vladimir Oltean
2023-11-21 3:02 ` Hangbin Liu
2023-11-24 13:18 ` Nikolay Aleksandrov
2023-11-24 14:01 ` Hangbin Liu
2023-12-03 20:12 ` Stephen Hemminger
2023-11-17 9:31 ` [PATCH net-next 06/10] docs: bridge: add VLAN doc Hangbin Liu
2023-11-17 9:31 ` [PATCH net-next 07/10] docs: bridge: add multicast doc Hangbin Liu
2023-11-17 9:31 ` [PATCH net-next 08/10] docs: bridge: add switchdev doc Hangbin Liu
2023-11-20 11:56 ` Vladimir Oltean
2023-11-17 9:31 ` [PATCH net-next 09/10] docs: bridge: add netfilter doc Hangbin Liu
2023-11-17 9:31 ` [PATCH net-next 10/10] docs: bridge: add other features Hangbin Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231117093145.1563511-6-liuhangbin@gmail.com \
--to=liuhangbin@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=fw@strlen.de \
--cc=idosch@idosch.org \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=mmuehlfe@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).