<!DOCTYPE html>
<html lang="en" data-content_root="../">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Ethernet Bridging — The Linux Kernel documentation</title>
<link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="../_static/alabaster.css?v=3918102e" />
<script src="../_static/documentation_options.js?v=5929fcd5"></script>
<script src="../_static/doctools.js?v=9bcbadda"></script>
<script src="../_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="SNMP counter" href="snmp_counter.html" />
<link rel="prev" title="IP-Aliasing" href="alias.html" />
<link rel="stylesheet" href="../_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/logo.svg" alt="Logo of The Linux Kernel"/>
</a></p>
<h1 class="logo"><a href="../index.html">The Linux Kernel</a></h1>
<p class="blurb">6.18.50</p>
<search id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="../search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script>
<p>
<h3 class="kernel-toc-contents">Contents</h3>
<input type="checkbox" class="kernel-toc-toggle" id = "kernel-toc-toggle" checked>
<label class="kernel-toc-title" for="kernel-toc-toggle"></label>
<div class="kerneltoc" id="kerneltoc">
<ul>
<li class="toctree-l1"><a class="reference internal" href="../process/development-process.html">Development process</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/submitting-patches.html">Submitting patches</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/code-of-conduct.html">Code of conduct</a></li>
<li class="toctree-l1"><a class="reference internal" href="../maintainer/index.html">Maintainer handbook</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/index.html">All development-process docs</a></li>
</ul>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../core-api/index.html">Core API</a></li>
<li class="toctree-l1"><a class="reference internal" href="../driver-api/index.html">Driver APIs</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="../subsystem-apis.html">Subsystems</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#core-subsystems">Core subsystems</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#human-interfaces">Human interfaces</a></li>
<li class="toctree-l2 current"><a class="reference internal" href="../subsystem-apis.html#networking-interfaces">Networking interfaces</a><ul class="current">
<li class="toctree-l3 current"><a class="reference internal" href="index.html">Networking</a></li>
<li class="toctree-l3"><a class="reference internal" href="../netlabel/index.html">NetLabel</a></li>
<li class="toctree-l3"><a class="reference internal" href="../infiniband/index.html">InfiniBand</a></li>
<li class="toctree-l3"><a class="reference internal" href="../isdn/index.html">ISDN</a></li>
<li class="toctree-l3"><a class="reference internal" href="../mhi/index.html">MHI</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#storage-interfaces">Storage interfaces</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#other-subsystems">Other subsystems</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../locking/index.html">Locking</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../process/license-rules.html">Licensing rules</a></li>
<li class="toctree-l1"><a class="reference internal" href="../doc-guide/index.html">Writing documentation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/index.html">Development tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/testing-overview.html">Testing guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kernel-hacking/index.html">Hacking guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../trace/index.html">Tracing</a></li>
<li class="toctree-l1"><a class="reference internal" href="../fault-injection/index.html">Fault injection</a></li>
<li class="toctree-l1"><a class="reference internal" href="../livepatch/index.html">Livepatching</a></li>
<li class="toctree-l1"><a class="reference internal" href="../rust/index.html">Rust</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/index.html">Administration</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kbuild/index.html">Build system</a></li>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/reporting-issues.html">Reporting issues</a></li>
<li class="toctree-l1"><a class="reference internal" href="../tools/index.html">Userspace tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../userspace-api/index.html">Userspace API</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../firmware-guide/index.html">Firmware</a></li>
<li class="toctree-l1"><a class="reference internal" href="../devicetree/index.html">Firmware and Devicetree</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../arch/index.html">CPU architectures</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../staging/index.html">Unsorted documentation</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../translations/index.html">Translations</a></li>
</ul>
</div>
<script type="text/javascript"> <!--
var sbar = document.getElementsByClassName("sphinxsidebar")[0];
let currents = document.getElementsByClassName("current")
if (currents.length) {
sbar.scrollTop = currents[currents.length - 1].offsetTop;
}
--> </script>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/networking/bridge.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="ethernet-bridging">
<h1>Ethernet Bridging<a class="headerlink" href="#ethernet-bridging" title="Link to this heading">¶</a></h1>
<section id="introduction">
<h2>Introduction<a class="headerlink" href="#introduction" title="Link to this heading">¶</a></h2>
<p>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.</p>
</section>
<section id="bridge-kapi">
<h2>Bridge kAPI<a class="headerlink" href="#bridge-kapi" title="Link to this heading">¶</a></h2>
<p>Here are some core structures of bridge code. Note that the kAPI is <em>unstable</em>,
and can be changed at any time.</p>
<dl class="c struct">
<dt class="sig sig-object c" id="c.net_bridge_vlan">
<span class="k"><span class="pre">struct</span></span><span class="w"> </span><span class="sig-name descname"><span class="n"><span class="pre">net_bridge_vlan</span></span></span><a class="headerlink" href="#c.net_bridge_vlan" title="Link to this definition">¶</a><br /></dt>
<dd><p>per-vlan entry</p>
</dd></dl>
<div class="kernelindent docutils container">
<p><strong>Definition</strong>:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>struct net_bridge_vlan {
struct rhash_head vnode;
struct rhash_head tnode;
u16 vid;
u16 flags;
u16 priv_flags;
u8 state;
struct pcpu_sw_netstats __percpu *stats;
union {
struct net_bridge *br;
struct net_bridge_port *port;
};
union {
refcount_t refcnt;
struct net_bridge_vlan *brvlan;
};
struct br_tunnel_info tinfo;
union {
struct net_bridge_mcast br_mcast_ctx;
struct net_bridge_mcast_port port_mcast_ctx;
};
u16 msti;
struct list_head vlist;
struct rcu_head rcu;
};
</pre></div>
</div>
<p><strong>Members</strong></p>
<dl class="simple">
<dt><code class="docutils literal notranslate"><span class="pre">vnode</span></code></dt><dd><p>rhashtable member</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">tnode</span></code></dt><dd><p>rhashtable member</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">vid</span></code></dt><dd><p>VLAN id</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">flags</span></code></dt><dd><p>bridge vlan flags</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">priv_flags</span></code></dt><dd><p>private (in-kernel) bridge vlan flags</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">state</span></code></dt><dd><p>STP state (e.g. blocking, learning, forwarding)</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">stats</span></code></dt><dd><p>per-cpu VLAN statistics</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">{unnamed_union}</span></code></dt><dd><p>anonymous</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">br</span></code></dt><dd><p>if MASTER flag set, this points to a bridge struct</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">port</span></code></dt><dd><p>if MASTER flag unset, this points to a port struct</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">{unnamed_union}</span></code></dt><dd><p>anonymous</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">refcnt</span></code></dt><dd><p>if MASTER flag set, this is bumped for each port referencing it</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">brvlan</span></code></dt><dd><p>if MASTER flag unset, this points to the global per-VLAN context
for this VLAN entry</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">tinfo</span></code></dt><dd><p>bridge tunnel info</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">{unnamed_union}</span></code></dt><dd><p>anonymous</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">br_mcast_ctx</span></code></dt><dd><p>if MASTER flag set, this is the global vlan multicast context</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">port_mcast_ctx</span></code></dt><dd><p>if MASTER flag unset, this is the per-port/vlan multicast
context</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">msti</span></code></dt><dd><p>if MASTER flag set, this holds the VLANs MST instance</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">vlist</span></code></dt><dd><p>sorted list of VLAN entries</p>
</dd>
<dt><code class="docutils literal notranslate"><span class="pre">rcu</span></code></dt><dd><p>used for entry destruction</p>
</dd>
</dl>
</div>
<p><strong>Description</strong></p>
<p>This structure is shared between the global per-VLAN entries contained in
the bridge rhashtable and the local per-port per-VLAN entries contained in
the port’s rhashtable. The <code class="xref c c-union broken_xref docutils literal notranslate"><span class="pre">union</span> <span class="pre">entries</span></code> should be interpreted depending on
the entry flags that are set.</p>
</section>
<section id="bridge-uapi">
<h2>Bridge uAPI<a class="headerlink" href="#bridge-uapi" title="Link to this heading">¶</a></h2>
<p>Modern Linux bridge uAPI is accessed via Netlink interface. You can find
below files where the bridge and bridge port netlink attributes are defined.</p>
<section id="bridge-netlink-attributes">
<h3>Bridge netlink attributes<a class="headerlink" href="#bridge-netlink-attributes" title="Link to this heading">¶</a></h3>
<p>Please <em>note</em> that the timer values in the following section are expected
in clock_t format, which is seconds multiplied by USER_HZ (generally
defined as 100).</p>
<dl>
<dt><strong>IFLA_BR_FORWARD_DELAY</strong></dt><dd><p>The bridge forwarding delay is the time spent in LISTENING state
(before moving to LEARNING) and in LEARNING state (before moving
to FORWARDING). Only relevant if STP is enabled.</p>
<p>The valid values are between (2 * USER_HZ) and (30 * USER_HZ).
The default value is (15 * USER_HZ).</p>
</dd>
<dt><strong>IFLA_BR_HELLO_TIME</strong></dt><dd><p>The time between hello packets sent by the bridge, when it is a root
bridge or a designated bridge. Only relevant if STP is enabled.</p>
<p>The valid values are between (1 * USER_HZ) and (10 * USER_HZ).
The default value is (2 * USER_HZ).</p>
</dd>
<dt><strong>IFLA_BR_MAX_AGE</strong></dt><dd><p>The hello packet timeout is the time until another bridge in the
spanning tree is assumed to be dead, after reception of its last hello
message. Only relevant if STP is enabled.</p>
<p>The valid values are between (6 * USER_HZ) and (40 * USER_HZ).
The default value is (20 * USER_HZ).</p>
</dd>
<dt><strong>IFLA_BR_AGEING_TIME</strong></dt><dd><p>Configure the bridge’s FDB entries aging time. It is the time a MAC
address will be kept in the FDB after a packet has been received from
that address. After this time has passed, entries are cleaned up.
Allow values outside the 802.1 standard specification for special cases:</p>
<blockquote>
<div><ul class="simple">
<li><p>0 - entry never ages (all permanent)</p></li>
<li><p>1 - entry disappears (no persistence)</p></li>
</ul>
</div></blockquote>
<p>The default value is (300 * USER_HZ).</p>
</dd>
<dt><strong>IFLA_BR_STP_STATE</strong></dt><dd><p>Turn spanning tree protocol on (<em>IFLA_BR_STP_STATE</em> > 0) or off
(<em>IFLA_BR_STP_STATE</em> == 0) for this bridge.</p>
<p>The default value is 0 (disabled).</p>
</dd>
<dt><strong>IFLA_BR_PRIORITY</strong></dt><dd><p>Set this bridge’s spanning tree priority, used during STP root bridge
election.</p>
<p>The valid values are between 0 and 65535.</p>
</dd>
<dt><strong>IFLA_BR_VLAN_FILTERING</strong></dt><dd><p>Turn VLAN filtering on (<em>IFLA_BR_VLAN_FILTERING</em> > 0) or off
(<em>IFLA_BR_VLAN_FILTERING</em> == 0). When disabled, the bridge will not
consider the VLAN tag when handling packets.</p>
<p>The default value is 0 (disabled).</p>
</dd>
<dt><strong>IFLA_BR_VLAN_PROTOCOL</strong></dt><dd><p>Set the protocol used for VLAN filtering.</p>
<p>The valid values are 0x8100(802.1Q) or 0x88A8(802.1AD). The default value
is 0x8100(802.1Q).</p>
</dd>
<dt><strong>IFLA_BR_GROUP_FWD_MASK</strong></dt><dd><p>The group forwarding mask. This is the bitmask that is applied to
decide whether to forward incoming frames destined to link-local
addresses (of the form 01:80:C2:00:00:0X).</p>
<p>The default value is 0, which means the bridge does not forward any
link-local frames coming on this port.</p>
</dd>
<dt><strong>IFLA_BR_ROOT_ID</strong></dt><dd><p>The bridge root id, read only.</p>
</dd>
<dt><strong>IFLA_BR_BRIDGE_ID</strong></dt><dd><p>The bridge id, read only.</p>
</dd>
<dt><strong>IFLA_BR_ROOT_PORT</strong></dt><dd><p>The bridge root port, read only.</p>
</dd>
<dt><strong>IFLA_BR_ROOT_PATH_COST</strong></dt><dd><p>The bridge root path cost, read only.</p>
</dd>
<dt><strong>IFLA_BR_TOPOLOGY_CHANGE</strong></dt><dd><p>The bridge topology change, read only.</p>
</dd>
<dt><strong>IFLA_BR_TOPOLOGY_CHANGE_DETECTED</strong></dt><dd><p>The bridge topology change detected, read only.</p>
</dd>
<dt><strong>IFLA_BR_HELLO_TIMER</strong></dt><dd><p>The bridge hello timer, read only.</p>
</dd>
<dt><strong>IFLA_BR_TCN_TIMER</strong></dt><dd><p>The bridge tcn timer, read only.</p>
</dd>
<dt><strong>IFLA_BR_TOPOLOGY_CHANGE_TIMER</strong></dt><dd><p>The bridge topology change timer, read only.</p>
</dd>
<dt><strong>IFLA_BR_GC_TIMER</strong></dt><dd><p>The bridge gc timer, read only.</p>
</dd>
<dt><strong>IFLA_BR_GROUP_ADDR</strong></dt><dd><p>Set the MAC address of the multicast group this bridge uses for STP.
The address must be a link-local address in standard Ethernet MAC address
format. It is an address of the form 01:80:C2:00:00:0X, with X in [0, 4..f].</p>
<p>The default value is 0.</p>
</dd>
<dt><strong>IFLA_BR_FDB_FLUSH</strong></dt><dd><p>Flush bridge’s fdb dynamic entries.</p>
</dd>
<dt><strong>IFLA_BR_MCAST_ROUTER</strong></dt><dd><p>Set bridge’s multicast router if IGMP snooping is enabled.
The valid values are:</p>
<blockquote>
<div><ul class="simple">
<li><p>0 - disabled.</p></li>
<li><p>1 - automatic (queried).</p></li>
<li><p>2 - permanently enabled.</p></li>
</ul>
</div></blockquote>
<p>The default value is 1.</p>
</dd>
<dt><strong>IFLA_BR_MCAST_SNOOPING</strong></dt><dd><p>Turn multicast snooping on (<em>IFLA_BR_MCAST_SNOOPING</em> > 0) or off
(<em>IFLA_BR_MCAST_SNOOPING</em> == 0).</p>
<p>The default value is 1.</p>
</dd>
<dt><strong>IFLA_BR_MCAST_QUERY_USE_IFADDR</strong></dt><dd><p>If enabled use the bridge’s own IP address as source address for IGMP
queries (<em>IFLA_BR_MCAST_QUERY_USE_IFADDR</em> > 0) or the default of 0.0.0.0
(<em>IFLA_BR_MCAST_QUERY_USE_IFADDR</em> == 0).</p>
<p>The default value is 0 (disabled).</p>
</dd>
<dt><strong>IFLA_BR_MCAST_QUERIER</strong></dt><dd><p>Enable (<em>IFLA_BR_MULTICAST_QUERIER</em> > 0) or disable
(<em>IFLA_BR_MULTICAST_QUERIER</em> == 0) IGMP querier, ie sending of multicast
queries by the bridge.</p>
<p>The default value is 0 (disabled).</p>
</dd>
<dt><strong>IFLA_BR_MCAST_HASH_ELASTICITY</strong></dt><dd><p>Set multicast database hash elasticity, It is the maximum chain length in
the multicast hash table. This attribute is <em>deprecated</em> and the value
is always 16.</p>
</dd>
<dt><strong>IFLA_BR_MCAST_HASH_MAX</strong></dt><dd><p>Set maximum size of the multicast hash table</p>
<p>The default value is 4096, the value must be a power of 2.</p>
</dd>
<dt><strong>IFLA_BR_MCAST_LAST_MEMBER_CNT</strong></dt><dd><p>The Last Member Query Count is the number of Group-Specific Queries
sent before the router assumes there are no local members. The Last
Member Query Count is also the number of Group-and-Source-Specific
Queries sent before the router assumes there are no listeners for a
particular source.</p>
<p>The default value is 2.</p>
</dd>
<dt><strong>IFLA_BR_MCAST_STARTUP_QUERY_CNT</strong></dt><dd><p>The Startup Query Count is the number of Queries sent out on startup,
separated by the Startup Query Interval.</p>
<p>The default value is 2.</p>
</dd>
<dt><strong>IFLA_BR_MCAST_LAST_MEMBER_INTVL</strong></dt><dd><p>The Last Member Query Interval is the Max Response Time inserted into
Group-Specific Queries sent in response to Leave Group messages, and
is also the amount of time between Group-Specific Query messages.</p>
<p>The default value is (1 * USER_HZ).</p>
</dd>
<dt><strong>IFLA_BR_MCAST_MEMBERSHIP_INTVL</strong></dt><dd><p>The interval after which the bridge will leave a group, if no membership
reports for this group are received.</p>
<p>The default value is (260 * USER_HZ).</p>
</dd>
<dt><strong>IFLA_BR_MCAST_QUERIER_INTVL</strong></dt><dd><p>The interval between queries sent by other routers. if no queries are
seen after this delay has passed, the bridge will start to send its own
queries (as if <em>IFLA_BR_MCAST_QUERIER_INTVL</em> was enabled).</p>
<p>The default value is (255 * USER_HZ).</p>
</dd>
<dt><strong>IFLA_BR_MCAST_QUERY_INTVL</strong></dt><dd><p>The Query Interval is the interval between General Queries sent by
the Querier.</p>
<p>The default value is (125 * USER_HZ). The minimum value is (1 * USER_HZ).</p>
</dd>
<dt><strong>IFLA_BR_MCAST_QUERY_RESPONSE_INTVL</strong></dt><dd><p>The Max Response Time used to calculate the Max Resp Code inserted
into the periodic General Queries.</p>
<p>The default value is (10 * USER_HZ).</p>
</dd>
<dt><strong>IFLA_BR_MCAST_STARTUP_QUERY_INTVL</strong></dt><dd><p>The interval between queries in the startup phase.</p>
<p>The default value is (125 * USER_HZ) / 4. The minimum value is (1 * USER_HZ).</p>
</dd>
<dt><strong>IFLA_BR_NF_CALL_IPTABLES</strong></dt><dd><p>Enable (<em>NF_CALL_IPTABLES</em> > 0) or disable (<em>NF_CALL_IPTABLES</em> == 0)
iptables hooks on the bridge.</p>
<p>The default value is 0 (disabled).</p>
</dd>
<dt><strong>IFLA_BR_NF_CALL_IP6TABLES</strong></dt><dd><p>Enable (<em>NF_CALL_IP6TABLES</em> > 0) or disable (<em>NF_CALL_IP6TABLES</em> == 0)
ip6tables hooks on the bridge.</p>
<p>The default value is 0 (disabled).</p>
</dd>
<dt><strong>IFLA_BR_NF_CALL_ARPTABLES</strong></dt><dd><p>Enable (<em>NF_CALL_ARPTABLES</em> > 0) or disable (<em>NF_CALL_ARPTABLES</em> == 0)
arptables hooks on the bridge.</p>
<p>The default value is 0 (disabled).</p>
</dd>
<dt><strong>IFLA_BR_VLAN_DEFAULT_PVID</strong></dt><dd><p>VLAN ID applied to untagged and priority-tagged incoming packets.</p>
<p>The default value is 1. Setting to the special value 0 makes all ports of
this bridge not have a PVID by default, which means that they will
not accept VLAN-untagged traffic.</p>
</dd>
<dt><strong>IFLA_BR_PAD</strong></dt><dd><p>Bridge attribute padding type for netlink message.</p>
</dd>
<dt><strong>IFLA_BR_VLAN_STATS_ENABLED</strong></dt><dd><p>Enable (<em>IFLA_BR_VLAN_STATS_ENABLED</em> == 1) or disable
(<em>IFLA_BR_VLAN_STATS_ENABLED</em> == 0) per-VLAN stats accounting.</p>
<p>The default value is 0 (disabled).</p>
</dd>
<dt><strong>IFLA_BR_MCAST_STATS_ENABLED</strong></dt><dd><p>Enable (<em>IFLA_BR_MCAST_STATS_ENABLED</em> > 0) or disable
(<em>IFLA_BR_MCAST_STATS_ENABLED</em> == 0) multicast (IGMP/MLD) stats
accounting.</p>
<p>The default value is 0 (disabled).</p>
</dd>
<dt><strong>IFLA_BR_MCAST_IGMP_VERSION</strong></dt><dd><p>Set the IGMP version.</p>
<p>The valid values are 2 and 3. The default value is 2.</p>
</dd>
<dt><strong>IFLA_BR_MCAST_MLD_VERSION</strong></dt><dd><p>Set the MLD version.</p>
<p>The valid values are 1 and 2. The default value is 1.</p>
</dd>
<dt><strong>IFLA_BR_VLAN_STATS_PER_PORT</strong></dt><dd><p>Enable (<em>IFLA_BR_VLAN_STATS_PER_PORT</em> == 1) or disable
(<em>IFLA_BR_VLAN_STATS_PER_PORT</em> == 0) per-VLAN per-port stats accounting.
Can be changed only when there are no port VLANs configured.</p>
<p>The default value is 0 (disabled).</p>
</dd>
<dt><strong>IFLA_BR_MULTI_BOOLOPT</strong></dt><dd><p>The multi_boolopt is used to control new boolean options to avoid adding
new netlink attributes. You can look at <code class="docutils literal notranslate"><span class="pre">enum</span> <span class="pre">br_boolopt_id</span></code> for those
options.</p>
</dd>
<dt><strong>IFLA_BR_MCAST_QUERIER_STATE</strong></dt><dd><p>Bridge mcast querier states, read only.</p>
</dd>
<dt><strong>IFLA_BR_FDB_N_LEARNED</strong></dt><dd><p>The number of dynamically learned FDB entries for the current bridge,
read only.</p>
</dd>
<dt><strong>IFLA_BR_FDB_MAX_LEARNED</strong></dt><dd><p>Set the number of max dynamically learned FDB entries for the current
bridge.</p>
</dd>
</dl>
</section>
<section id="bridge-port-netlink-attributes">
<h3>Bridge port netlink attributes<a class="headerlink" href="#bridge-port-netlink-attributes" title="Link to this heading">¶</a></h3>
<dl>
<dt><strong>IFLA_BRPORT_STATE</strong></dt><dd><p>The operation state of the port. Here are the valid values.</p>
<blockquote>
<div><ul class="simple">
<li><p>0 - port is in STP <em>DISABLED</em> state. Make this port completely
inactive for STP. This is also called BPDU filter and could be used
to disable STP on an untrusted port, like a leaf virtual device.
The traffic forwarding is also stopped on this port.</p></li>
<li><p>1 - port is in STP <em>LISTENING</em> state. Only valid if STP is enabled
on the bridge. In this state the port listens for STP BPDUs and
drops all other traffic frames.</p></li>
<li><p>2 - port is in STP <em>LEARNING</em> state. Only valid if STP is enabled on
the bridge. In this state the port will accept traffic only for the
purpose of updating MAC address tables.</p></li>
<li><p>3 - port is in STP <em>FORWARDING</em> state. Port is fully active.</p></li>
<li><p>4 - port is in STP <em>BLOCKING</em> state. Only valid if STP is enabled on
the bridge. This state is used during the STP election process.
In this state, port will only process STP BPDUs.</p></li>
</ul>
</div></blockquote>
</dd>
<dt><strong>IFLA_BRPORT_PRIORITY</strong></dt><dd><p>The STP port priority. The valid values are between 0 and 255.</p>
</dd>
<dt><strong>IFLA_BRPORT_COST</strong></dt><dd><p>The STP path cost of the port. The valid values are between 1 and 65535.</p>
</dd>
<dt><strong>IFLA_BRPORT_MODE</strong></dt><dd><p>Set the bridge port mode. See <em>BRIDGE_MODE_HAIRPIN</em> for more details.</p>
</dd>
<dt><strong>IFLA_BRPORT_GUARD</strong></dt><dd><p>Controls whether STP BPDUs will be processed by the bridge port. By
default, the flag is turned off to allow BPDU processing. Turning this
flag on will disable the bridge port if a STP BPDU packet is received.</p>
<p>If the bridge has Spanning Tree enabled, hostile devices on the network
may send BPDU on a port and cause network failure. Setting <em>guard on</em>
will detect and stop this by disabling the port. The port will be
restarted if the link is brought down, or removed and reattached.</p>
</dd>
<dt><strong>IFLA_BRPORT_PROTECT</strong></dt><dd><p>Controls whether a given port is allowed to become a root port or not.
Only used when STP is enabled on the bridge. By default the flag is off.</p>
<p>This feature is also called root port guard. If BPDU is received from a
leaf (edge) port, it should not be elected as root port. This could
be used if using STP on a bridge and the downstream bridges are not fully
trusted; this prevents a hostile guest from rerouting traffic.</p>
</dd>
<dt><strong>IFLA_BRPORT_FAST_LEAVE</strong></dt><dd><p>This flag allows the bridge to immediately stop multicast traffic
forwarding on a port that receives an IGMP Leave message. It is only used
when IGMP snooping is enabled on the bridge. By default the flag is off.</p>
</dd>
<dt><strong>IFLA_BRPORT_LEARNING</strong></dt><dd><p>Controls whether a given port will learn <em>source</em> MAC addresses from
received traffic or not. Also controls whether dynamic FDB entries
(which can also be added by software) will be refreshed by incoming
traffic. By default this flag is on.</p>
</dd>
<dt><strong>IFLA_BRPORT_UNICAST_FLOOD</strong></dt><dd><p>Controls whether unicast traffic for which there is no FDB entry will
be flooded towards this port. By default this flag is on.</p>
</dd>
<dt><strong>IFLA_BRPORT_PROXYARP</strong></dt><dd><p>Enable proxy ARP on this port.</p>
</dd>
<dt><strong>IFLA_BRPORT_LEARNING_SYNC</strong></dt><dd><p>Controls whether a given port will sync MAC addresses learned on device
port to bridge FDB.</p>
</dd>
<dt><strong>IFLA_BRPORT_PROXYARP_WIFI</strong></dt><dd><p>Enable proxy ARP on this port which meets extended requirements by
IEEE 802.11 and Hotspot 2.0 specifications.</p>
</dd>
</dl>
<p><strong>IFLA_BRPORT_ROOT_ID</strong></p>
<p><strong>IFLA_BRPORT_BRIDGE_ID</strong></p>
<p><strong>IFLA_BRPORT_DESIGNATED_PORT</strong></p>
<p><strong>IFLA_BRPORT_DESIGNATED_COST</strong></p>
<p><strong>IFLA_BRPORT_ID</strong></p>
<p><strong>IFLA_BRPORT_NO</strong></p>
<p><strong>IFLA_BRPORT_TOPOLOGY_CHANGE_ACK</strong></p>
<p><strong>IFLA_BRPORT_CONFIG_PENDING</strong></p>
<p><strong>IFLA_BRPORT_MESSAGE_AGE_TIMER</strong></p>
<p><strong>IFLA_BRPORT_FORWARD_DELAY_TIMER</strong></p>
<p><strong>IFLA_BRPORT_HOLD_TIMER</strong></p>
<dl>
<dt><strong>IFLA_BRPORT_FLUSH</strong></dt><dd><p>Flush bridge ports’ fdb dynamic entries.</p>
</dd>
<dt><strong>IFLA_BRPORT_MULTICAST_ROUTER</strong></dt><dd><p>Configure the port’s multicast router presence. A port with
a multicast router will receive all multicast traffic.
The valid values are:</p>
<blockquote>
<div><ul class="simple">
<li><p>0 disable multicast routers on this port</p></li>
<li><p>1 let the system detect the presence of routers (default)</p></li>
<li><p>2 permanently enable multicast traffic forwarding on this port</p></li>
<li><dl class="simple">
<dt>3 enable multicast routers temporarily on this port, not depending</dt><dd><p>on incoming queries.</p>
</dd>
</dl>
</li>
</ul>
</div></blockquote>
</dd>
</dl>
<p><strong>IFLA_BRPORT_PAD</strong></p>
<dl>
<dt><strong>IFLA_BRPORT_MCAST_FLOOD</strong></dt><dd><p>Controls whether a given port will flood multicast traffic for which
there is no MDB entry. By default this flag is on.</p>
</dd>
<dt><strong>IFLA_BRPORT_MCAST_TO_UCAST</strong></dt><dd><p>Controls whether a given port will replicate packets using unicast
instead of multicast. By default this flag is off.</p>
<p>This is done by copying the packet per host and changing the multicast
destination MAC to a unicast one accordingly.</p>
<p><em>mcast_to_unicast</em> works on top of the multicast snooping feature of the
bridge. Which means unicast copies are only delivered to hosts which
are interested in unicast and signaled this via IGMP/MLD reports previously.</p>
<p>This feature is intended for interface types which have a more reliable
and/or efficient way to deliver unicast packets than broadcast ones
(e.g. WiFi).</p>
<p>However, it should only be enabled on interfaces where no IGMPv2/MLDv1
report suppression takes place. IGMP/MLD report suppression issue is
usually overcome by the network daemon (supplicant) enabling AP isolation
and by that separating all STAs.</p>
<p>Delivery of STA-to-STA IP multicast is made possible again by enabling
and utilizing the bridge hairpin mode, which considers the incoming port
as a potential outgoing port, too (see <em>BRIDGE_MODE_HAIRPIN</em> option).
Hairpin mode is performed after multicast snooping, therefore leading
to only deliver reports to STAs running a multicast router.</p>
</dd>
<dt><strong>IFLA_BRPORT_VLAN_TUNNEL</strong></dt><dd><p>Controls whether vlan to tunnel mapping is enabled on the port.
By default this flag is off.</p>
</dd>
<dt><strong>IFLA_BRPORT_BCAST_FLOOD</strong></dt><dd><p>Controls flooding of broadcast traffic on the given port. By default
this flag is on.</p>
</dd>
<dt><strong>IFLA_BRPORT_GROUP_FWD_MASK</strong></dt><dd><p>Set the group forward mask. This is a bitmask that is applied to
decide whether to forward incoming frames destined to link-local
addresses. The addresses of the form are 01:80:C2:00:00:0X (defaults
to 0, which means the bridge does not forward any link-local frames
coming on this port).</p>
</dd>
<dt><strong>IFLA_BRPORT_NEIGH_SUPPRESS</strong></dt><dd><p>Controls whether neighbor discovery (arp and nd) proxy and suppression
is enabled on the port. By default this flag is off.</p>
</dd>
<dt><strong>IFLA_BRPORT_ISOLATED</strong></dt><dd><p>Controls whether a given port will be isolated, which means it will be
able to communicate with non-isolated ports only. By default this
flag is off.</p>
</dd>
<dt><strong>IFLA_BRPORT_BACKUP_PORT</strong></dt><dd><p>Set a backup port. If the port loses carrier all traffic will be
redirected to the configured backup port. Set the value to 0 to disable
it.</p>
</dd>
</dl>
<p><strong>IFLA_BRPORT_MRP_RING_OPEN</strong></p>
<p><strong>IFLA_BRPORT_MRP_IN_OPEN</strong></p>
<dl>
<dt><strong>IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT</strong></dt><dd><p>The number of per-port EHT hosts limit. The default value is 512.
Setting to 0 is not allowed.</p>
</dd>
<dt><strong>IFLA_BRPORT_MCAST_EHT_HOSTS_CNT</strong></dt><dd><p>The current number of tracked hosts, read only.</p>
</dd>
<dt><strong>IFLA_BRPORT_LOCKED</strong></dt><dd><p>Controls whether a port will be locked, meaning that hosts behind the
port will not be able to communicate through the port unless an FDB
entry with the unit’s MAC address is in the FDB. The common use case is
that hosts are allowed access through authentication with the IEEE 802.1X
protocol or based on whitelists. By default this flag is off.</p>
<p>Please note that secure 802.1X deployments should always use the
<em>BR_BOOLOPT_NO_LL_LEARN</em> flag, to not permit the bridge to populate its
FDB based on link-local (EAPOL) traffic received on the port.</p>
</dd>
<dt><strong>IFLA_BRPORT_MAB</strong></dt><dd><p>Controls whether a port will use MAC Authentication Bypass (MAB), a
technique through which select MAC addresses may be allowed on a locked
port, without using 802.1X authentication. Packets with an unknown source
MAC address generates a “locked” FDB entry on the incoming bridge port.
The common use case is for user space to react to these bridge FDB
notifications and optionally replace the locked FDB entry with a normal
one, allowing traffic to pass for whitelisted MAC addresses.</p>
<p>Setting this flag also requires <em>IFLA_BRPORT_LOCKED</em> and
<em>IFLA_BRPORT_LEARNING</em>. <em>IFLA_BRPORT_LOCKED</em> ensures that unauthorized
data packets are dropped, and <em>IFLA_BRPORT_LEARNING</em> allows the dynamic
FDB entries installed by user space (as replacements for the locked FDB
entries) to be refreshed and/or aged out.</p>
</dd>
</dl>
<p><strong>IFLA_BRPORT_MCAST_N_GROUPS</strong></p>
<dl>
<dt><strong>IFLA_BRPORT_MCAST_MAX_GROUPS</strong></dt><dd><p>Sets the maximum number of MDB entries that can be registered for a
given port. Attempts to register more MDB entries at the port than this
limit allows will be rejected, whether they are done through netlink
(e.g. the bridge tool), or IGMP or MLD membership reports. Setting a
limit of 0 disables the limit. The default value is 0.</p>
</dd>
<dt><strong>IFLA_BRPORT_NEIGH_VLAN_SUPPRESS</strong></dt><dd><p>Controls whether neighbor discovery (arp and nd) proxy and suppression is
enabled for a given port. By default this flag is off.</p>
<p>Note that this option only takes effect when <em>IFLA_BRPORT_NEIGH_SUPPRESS</em>
is enabled for a given port.</p>
</dd>
<dt><strong>IFLA_BRPORT_BACKUP_NHID</strong></dt><dd><p>The FDB nexthop object ID to attach to packets being redirected to a
backup port that has VLAN tunnel mapping enabled (via the
<em>IFLA_BRPORT_VLAN_TUNNEL</em> option). Setting a value of 0 (default) has
the effect of not attaching any ID.</p>
</dd>
</dl>
</section>
<section id="bridge-sysfs">
<h3>Bridge sysfs<a class="headerlink" href="#bridge-sysfs" title="Link to this heading">¶</a></h3>
<p>The sysfs interface is deprecated and should not be extended if new
options are added.</p>
</section>
</section>
<section id="stp">
<h2>STP<a class="headerlink" href="#stp" title="Link to this heading">¶</a></h2>
<p>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.</p>
<p>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
<a class="reference external" href="https://lore.kernel.org/netdev/20220316150857.2442916-1-tobias@waldekranz.com/">Multiple Spanning Tree Protocol (MSTP)</a>.</p>
<p>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.</p>
<section id="bridge-ports-and-stp-states">
<h3>Bridge Ports and STP States<a class="headerlink" href="#bridge-ports-and-stp-states" title="Link to this heading">¶</a></h3>
<dl class="simple">
<dt>In the context of STP, bridge ports can be in one of the following states:</dt><dd><ul class="simple">
<li><p>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.</p></li>
<li><p>Listening: The port begins to participate in the STP process and listens
for BPDUs.</p></li>
<li><p>Learning: The port continues to listen for BPDUs and begins to learn MAC
addresses from incoming frames but does not forward data frames.</p></li>
<li><p>Forwarding: The port is fully operational and forwards both BPDUs and
data frames.</p></li>
<li><p>Disabled: The port is administratively disabled and does not participate
in the STP process. The data frames forwarding are also disabled.</p></li>
</ul>
</dd>
</dl>
</section>
<section id="root-bridge-and-convergence">
<h3>Root Bridge and Convergence<a class="headerlink" href="#root-bridge-and-convergence" title="Link to this heading">¶</a></h3>
<p>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.</p>
<dl class="simple">
<dt>Here’s how the STP works and root bridge is chosen:</dt><dd><ol class="arabic simple">
<li><p>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).</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ol>
</dd>
</dl>
<p>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.</p>
<p>Proper configuration of STP parameters, such as the bridge priority, can
influence network performance, path selection and which bridge becomes the
Root Bridge.</p>
</section>
<section id="user-space-stp-helper">
<h3>User space STP helper<a class="headerlink" href="#user-space-stp-helper" title="Link to this heading">¶</a></h3>
<p>The user space STP helper <em>bridge-stp</em> is a program to control whether to use
user mode spanning tree. The <code class="docutils literal notranslate"><span class="pre">/sbin/bridge-stp</span> <span class="pre"><bridge></span> <span class="pre"><start|stop></span></code> is
called by the kernel when STP is enabled/disabled on a bridge
(via <code class="docutils literal notranslate"><span class="pre">brctl</span> <span class="pre">stp</span> <span class="pre"><bridge></span> <span class="pre"><on|off></span></code> or <code class="docutils literal notranslate"><span class="pre">ip</span> <span class="pre">link</span> <span class="pre">set</span> <span class="pre"><bridge></span> <span class="pre">type</span> <span class="pre">bridge</span>
<span class="pre">stp_state</span> <span class="pre"><0|1></span></code>). The kernel enables user_stp mode if that command returns
0, or enables kernel_stp mode if that command returns any other value.</p>
</section>
</section>
<section id="vlan">
<h2>VLAN<a class="headerlink" href="#vlan" title="Link to this heading">¶</a></h2>
<p>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).</p>
<p>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.</p>
<p>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 <em>VLAN-tagged frames</em>. 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 <a class="reference external" href="https://lore.kernel.org/netdev/1402401565-15423-1-git-send-email-makita.toshiaki@lab.ntt.co.jp/">802.1AD</a>
protocol for VLAN tagging.</p>
<p><a class="reference external" href="https://lore.kernel.org/netdev/1360792820-14116-1-git-send-email-vyasevic@redhat.com/">VLAN filtering</a>
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).</p>
</section>
<section id="multicast">
<h2>Multicast<a class="headerlink" href="#multicast" title="Link to this heading">¶</a></h2>
<p>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.</p>
<section id="multicast-snooping">
<h3>Multicast snooping<a class="headerlink" href="#multicast-snooping" title="Link to this heading">¶</a></h3>
<p>Multicast snooping is a networking technology that allows network switches
to intelligently manage multicast traffic within a local area network (LAN).</p>
<p>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.</p>
<p>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.</p>
</section>
<section id="igmpv3-mldv2-eht-support">
<h3>IGMPv3/MLDv2 EHT support<a class="headerlink" href="#igmpv3-mldv2-eht-support" title="Link to this heading">¶</a></h3>
<p>The Linux bridge supports IGMPv3/MLDv2 EHT (Explicit Host Tracking), which
was added by <a class="reference external" href="https://lore.kernel.org/netdev/20210120145203.1109140-1-razor@blackwall.org/">474ddb37fa3a (“net: bridge: multicast: add EHT allow/block handling”)</a></p>
<p>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.</p>
<p>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.</p>
</section>
<section id="other-multicast-features">
<h3>Other multicast features<a class="headerlink" href="#other-multicast-features" title="Link to this heading">¶</a></h3>
<p>The Linux bridge also supports <a class="reference external" href="https://lore.kernel.org/netdev/20210719170637.435541-1-razor@blackwall.org/">per-VLAN multicast snooping</a>,
which is disabled by default but can be enabled. And <a class="reference external" href="https://lore.kernel.org/netdev/20190121062628.2710-1-linus.luessing@c0d3.blue/">Multicast Router Discovery</a>,
which help identify the location of multicast routers.</p>
</section>
</section>
<section id="switchdev">
<h2>Switchdev<a class="headerlink" href="#switchdev" title="Link to this heading">¶</a></h2>
<p>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.</p>
<p>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.</p>
<p>Please see the <a class="reference internal" href="switchdev.html#switchdev"><span class="std std-ref">Ethernet switch device driver model (switchdev)</span></a> document for more details.</p>
</section>
<section id="netfilter">
<h2>Netfilter<a class="headerlink" href="#netfilter" title="Link to this heading">¶</a></h2>
<p>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.</p>
<p>The older ebtables tool is more feature-limited compared to nftables, but
just like nftables it doesn’t need this module either to function.</p>
<p>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.</p>
<p>br_netfilter is also the reason for the iptables <em>physdev</em> match:
This match is the only way to reliably tell routed and bridged packets
apart in an iptables ruleset.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
</section>
<section id="other-features">
<h2>Other Features<a class="headerlink" href="#other-features" title="Link to this heading">¶</a></h2>
<p>The Linux bridge also supports <a class="reference external" href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=958501163ddd6ea22a98f94fa0e7ce6d4734e5c4">IEEE 802.11 Proxy ARP</a>,
<a class="reference external" href="https://lore.kernel.org/netdev/20200426132208.3232-1-horatiu.vultur@microchip.com/">Media Redundancy Protocol (MRP)</a>,
<a class="reference external" href="https://lore.kernel.org/r/20201124082525.273820-1-horatiu.vultur@microchip.com">Media Redundancy Protocol (MRP) LC mode</a>,
<a class="reference external" href="https://lore.kernel.org/netdev/20220218155148.2329797-1-schultz.hans+netdev@gmail.com/">IEEE 802.1X port authentication</a>,
and <a class="reference external" href="https://lore.kernel.org/netdev/20221101193922.2125323-2-idosch@nvidia.com/">MAC Authentication Bypass (MAB)</a>.</p>
</section>
<section id="faq">
<h2>FAQ<a class="headerlink" href="#faq" title="Link to this heading">¶</a></h2>
<section id="what-does-a-bridge-do">
<h3>What does a bridge do?<a class="headerlink" href="#what-does-a-bridge-do" title="Link to this heading">¶</a></h3>
<p>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.</p>
</section>
<section id="is-it-l3-protocol-independent">
<h3>Is it L3 protocol independent?<a class="headerlink" href="#is-it-l3-protocol-independent" title="Link to this heading">¶</a></h3>
<p>Yes. The bridge sees all frames, but it <em>uses</em> only L2 headers/information.
As such, the bridging functionality is protocol independent, and there should
be no trouble forwarding IPX, NetBEUI, IP, IPv6, etc.</p>
</section>
</section>
<section id="contact-info">
<h2>Contact Info<a class="headerlink" href="#contact-info" title="Link to this heading">¶</a></h2>
<p>The code is currently maintained by Roopa Prabhu <<a class="reference external" href="mailto:roopa%40nvidia.com">roopa<span>@</span>nvidia<span>.</span>com</a>> and
Nikolay Aleksandrov <<a class="reference external" href="mailto:razor%40blackwall.org">razor<span>@</span>blackwall<span>.</span>org</a>>. Bridge bugs and enhancements
are discussed on the linux-netdev mailing list <a class="reference external" href="mailto:netdev%40vger.kernel.org">netdev<span>@</span>vger<span>.</span>kernel<span>.</span>org</a> and
<a class="reference external" href="mailto:bridge%40lists.linux.dev">bridge<span>@</span>lists<span>.</span>linux<span>.</span>dev</a>.</p>
<p>The list is open to anyone interested: <a class="reference external" href="http://vger.kernel.org/vger-lists.html#netdev">http://vger.kernel.org/vger-lists.html#netdev</a></p>
</section>
<section id="external-links">
<h2>External Links<a class="headerlink" href="#external-links" title="Link to this heading">¶</a></h2>
<p>The old Documentation for Linux bridging is on:
<a class="reference external" href="https://wiki.linuxfoundation.org/networking/bridge">https://wiki.linuxfoundation.org/networking/bridge</a></p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
©The kernel development community.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 8.1.3</a>
& <a href="https://alabaster.readthedocs.io">Alabaster 0.7.16</a>
|
<a href="../_sources/networking/bridge.rst.txt"
rel="nofollow">Page source</a>
</div>
</body>
</html>