Lines Matching +full:role +full:- +full:switch +full:- +full:default +full:- +full:mode
1 .. SPDX-License-Identifier: GPL-2.0
6 Ethernet switch device driver model (switchdev)
11 Copyright |copy| 2014-2015 Scott Feldman <sfeldma@gmail.com>
14 The Ethernet switch device driver model (switchdev) is an in-kernel driver
15 model for switch devices which offload the forwarding (data) plane from the
19 an example setup using a data-center-class switch ASIC chip. Other setups
20 with SR-IOV or soft switches, such as OVS, are possible.
25 User-space tools
28 +-------------------------------------------------------------------+
31 +--------------+-------------------------------+
35 +----------------------------------------------+
41 +--+----+----+----+----+----+---+ +-----+-----+
42 | Switch driver | | mgmt |
45 +--------------+----------------+ +-----------+
48 +-------------------------------------------------------------------+
50 +--------------+----------------+
51 | Switch device (sw1) |
52 | +----+ +--------+
55 +--|----|----+----+----+----+---+
60 front-panel ports
67 -------------
76 -------------
82 Switch Ports
83 ------------
86 struct net_device (using register_netdev()) for each enumerated physical switch
92 provide to the user access to the physical properties of the switch port such
95 There is (currently) no higher-level kernel object for the switch beyond the
98 A switch management port is outside the scope of the switchdev driver model.
103 Switch ID
108 each port of a switch. The ID must be unique between switches on the same
112 The switch ID is used to locate ports on a switch and to know if aggregated
113 ports belong to the same switch.
120 Hard-coding of kernel netdev names within the driver is discouraged; let the
121 kernel pick the default netdev name, and let udev set the final name based on a
125 useful for dynamically-named ports where the device names its ports based on
133 Suggested naming convention is "swXpYsZ", where X is the switch name or ID, Y
134 is the port name or ID, and Z is the sub-port name or ID. For example, sw1p1s0
135 would be sub-port 0 on port 1 on switch 1.
140 dev->netns_local
142 If the switchdev driver (and device) only supports offloading of the default
144 the port netdev from being moved out of the default netns. A netns-aware
152 The port netdevs representing the physical switch ports can be organized into
153 higher-level switching constructs. The default construct is a standalone
156 L2 networks. VLANs can be applied to sub-divide L2 networks. L2-over-L3
158 tools such as the bridge driver, the bonding/team drivers, and netlink-based
169 ---------------------
177 - Static FDB entries installed on a bridge port
178 - Notification of learned/forgotten src mac/vlans from device
179 - STP state changes on the port
180 - VLAN flooding of multicast/broadcast and unknown unicast packets
191 (the "static" keyword is non-optional: if not specified, the entry defaults to
194 The "self" keyword (optional because it is implicit) has the role of
221 Note: by default, the bridge does not filter on VLAN and only bridges untagged
229 The switch device will learn/forget source MAC address/VLAN on ingress packets
230 and notify the switch driver of the mac/vlan/port tuples. The switch driver,
286 notification will reset the FDB entry's last-used time to now. The driver
288 second. (The last-used time is visible using the bridge -s fdb option).
293 Internally or with a third-party STP protocol implementation (e.g. mstpd), the
294 bridge driver maintains the STP state for ports, and will notify the switch
298 State is one of BR_STATE_*. The switch driver can use STP state updates to
301 and other IEEE 01:80:c2:xx:xx:xx link-local multicast packets can pass.
310 For a given L2 VLAN domain, the switch device should flood multicast/broadcast
312 current STP state. The switch driver, knowing which ports are within which
313 vlan L2 domain, can program the switch device for flooding. The packet may
318 To avoid duplicate packets, the switch driver should mark a packet as already
319 forwarded by setting the skb->offload_fwd_mark bit. The bridge driver will mark
323 It is possible for the switch device to not handle flooding and push the
342 ------------------
381 default via 192.168.0.2 dev eth0
401 the switch device to forward the packet with the correct dst mac address, the
414 -------------------------------
419 Configuration-less state
425 from other network devices/ports (e.g.: as is frequent with a switch ASIC). How
427 use per-port VLAN identifiers unless a better mechanism is available
440 of a VLAN-aware bridge doing ingress VID checking). See below for details.
443 promiscuous mode should allow the reception of all VLAN tags (including those
446 Bridged switch ports
450 not disrupt any functionality of non-bridged network devices and they
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
462 data path will process all Ethernet frames as if they are VLAN-untagged.
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
469 the device with a VID that is not programmed into the bridges/switch's VLAN
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
487 untagged packets. This internal VID spans all ports of the VLAN-unaware
494 - with VLAN filtering turned on, these VLAN devices can be created as long as
499 Non-bridged network ports of the same switch fabric must not be disturbed in any
503 'rx-vlan-filter: on [fixed]' in the ethtool features.
513 Even when VLAN filtering in the bridge is turned off, the underlying switch
514 hardware and driver may still configure itself in a VLAN-aware mode provided
517 The VLAN protocol of the bridge plays a role in deciding whether a packet is
519 VLAN-untagged packets, as well as packets tagged with 802.1Q headers, as
529 priority-tagged packets must be accepted and forwarded according to the
541 - when IGMP snooping is turned off, multicast traffic must be flooded to all
549 - when IGMP snooping is turned on, multicast traffic must selectively flow
554 The switch must adhere to RFC 4541 and flood multicast traffic accordingly