Lines Matching full:bridge
155 together to form a LAG. Two or more ports (or LAGs) can be bridged to bridge
158 tools such as the bridge driver, the bonding/team drivers, and netlink-based
163 bond will see its upper master change. If that bond is moved into a bridge,
172 to the switchdev device by mirroring bridge FDB entries down to the device. An
177 - Static FDB entries installed on a bridge port
187 static bridge FDB entry::
189 bridge fdb add dev DEV ADDRESS [vlan VID] [self] static
196 implementation of the ``DEV`` device itself. If ``DEV`` is a bridge port, this
197 will bypass the bridge and therefore leave the software database out of sync
202 bridge fdb add dev DEV ADDRESS [vlan VID] master static
206 This time, the bridge generates a ``SWITCHDEV_FDB_ADD_TO_DEVICE`` notification
211 Note: for new switchdev drivers that offload the Linux bridge, implementing the
212 ``ndo_fdb_add`` and ``ndo_fdb_del`` bridge bypass methods is strongly
213 discouraged: all static FDB entries should be added on a bridge port using the
221 Note: by default, the bridge does not filter on VLAN and only bridges untagged
224 echo 1 >/sys/class/net/<bridge>/bridge/vlan_filtering
231 in turn, will notify the bridge driver using the switchdev notifier call::
237 SWITCHDEV_FDB_ADD, the bridge driver will install the FDB entry into the
238 bridge's FDB and mark the entry as NTF_EXT_LEARNED. The iproute2 bridge
241 $ bridge fdb
256 Learning on the port should be disabled on the bridge using the bridge command::
258 bridge link set dev DEV learning off
262 bridge link set dev DEV learning on self
263 bridge link set dev DEV learning_sync on self
266 the bridge's FDB. It's possible, but not optimal, to enable learning on the
267 device port and on the bridge port, and disable learning_sync.
275 The bridge will skip ageing FDB entries marked with NTF_EXT_LEARNED and it is
278 driver which in turn will notify the bridge with SWITCHDEV_FDB_DEL. If the
281 notified to the bridge using SWITCHDEV_FDB_DEL. See rocker driver for
288 second. (The last-used time is visible using the bridge -s fdb option).
294 bridge driver maintains the STP state for ports, and will notify the switch
314 be sent to the port netdev for processing by the bridge driver. The
315 bridge should not reflood the packet to the same ports the device flooded,
319 forwarded by setting the skb->offload_fwd_mark bit. The bridge driver will mark
320 the skb using the ingress bridge port's mark and prevent it from being forwarded
321 through any bridge port with the same mark.
324 packets up to the bridge driver for flooding. This is not ideal as the number
334 In order to support IGMP snooping, the port netdevs should trap to the bridge
336 The bridge multicast module will notify port netdevs on every multicast group
440 of a VLAN-aware bridge doing ingress VID checking). See below for details.
449 When a switchdev enabled network device is added as a bridge member, it should
451 should continue to behave as normal network devices. Depending on the bridge
454 Bridge VLAN filtering
457 The Linux bridge allows the configuration of a VLAN filtering mode (statically,
461 - with VLAN filtering turned off: the bridge is strictly VLAN unaware and its
463 The bridge VLAN database can still be modified, but the modifications should
465 device with a VID that is not programmed into the bridge/switch's VLAN table
468 - with VLAN filtering turned on: the bridge is VLAN-aware and frames ingressing
473 network device which is a bridge port member, the behavior of the software
477 - with VLAN filtering turned off, the bridge will process all ingress traffic
480 be added to a second bridge, which includes other switch ports or software
488 bridge. The VID corresponding to the VLAN upper interface spans the
491 * Treat bridge ports with VLAN upper interfaces as standalone, and let
495 the bridge does not have an existing VLAN entry with the same VID on any
496 bridge port. These VLAN devices cannot be enslaved into the bridge since they
497 duplicate functionality/use case with the bridge's VLAN data path processing.
500 way by the enabling of VLAN filtering on the bridge device(s). If the VLAN
509 filtering knob at runtime and require a destruction of the bridge device(s) and
510 creation of new bridge device(s) with a different VLAN filtering value to
513 Even when VLAN filtering in the bridge is turned off, the underlying switch
517 The VLAN protocol of the bridge plays a role in deciding whether a packet is
518 treated as tagged or not: a bridge using the 802.1ad protocol must treat both
523 as untagged packets, since the bridge device does not allow the manipulation of
526 When the bridge has VLAN filtering enabled and a PVID is not configured on the
527 ingress port, untagged and 802.1p tagged packets must be dropped. When the bridge
530 bridge's port membership of the PVID VLAN. When the bridge has VLAN filtering
534 Bridge IGMP snooping
537 The Linux bridge allows the configuration of IGMP snooping (statically, at
542 ports within the same bridge that have mcast_flood=true. The CPU/management
555 since that is what the Linux bridge implementation does.
562 snooping knob at runtime and require the destruction of the bridge device(s)
563 and creation of a new bridge device(s) with a different multicast snooping