Lines Matching refs:VLAN

172 FDB entry is the {port, MAC, VLAN} tuple forwarding destination.
179 - VLAN flooding of multicast/broadcast and unknown unicast packets
220 Note: by default, the bridge does not filter on VLAN and only bridges untagged
221 traffic. To enable VLAN support, turn on VLAN filtering::
228 The switch device will learn/forget source MAC address/VLAN on ingress packets
309 For a given L2 VLAN domain, the switch device should flood multicast/broadcast
426 use per-port VLAN identifiers unless a better mechanism is available
431 appropriate filters for VLAN, multicast, unicast etc. The underlying device
439 of a VLAN-aware bridge doing ingress VID checking). See below for details.
441 If the device implements e.g.: VLAN filtering, putting the interface in
442 promiscuous mode should allow the reception of all VLAN tags (including those
453 Bridge VLAN filtering
456 The Linux bridge allows the configuration of a VLAN filtering mode (statically,
460 - with VLAN filtering turned off: the bridge is strictly VLAN unaware and its
461 data path will process all Ethernet frames as if they are VLAN-untagged.
462 The bridge VLAN database can still be modified, but the modifications should
463 have no effect while VLAN filtering is turned off. Frames ingressing the
464 device with a VID that is not programmed into the bridge/switch's VLAN table
465 must be forwarded and may be processed using a VLAN device (see below).
467 - with VLAN filtering turned on: the bridge is VLAN-aware and frames ingressing
468 the device with a VID that is not programmed into the bridges/switch's VLAN
471 When there is a VLAN device (e.g: sw0p1.100) configured on top of a switchdev
476 - with VLAN filtering turned off, the bridge will process all ingress traffic
477 for the port, except for the traffic tagged with a VLAN ID destined for a
478 VLAN upper. The VLAN upper interface (which consumes the VLAN tag) can even
481 belonging to the VLAN upper interfaces are managed properly:
483 * If forwarding destinations can be managed per VLAN, the hardware could be
485 belonging to a VLAN upper interface, to an internal VID corresponding to
486 untagged packets. This internal VID spans all ports of the VLAN-unaware
487 bridge. The VID corresponding to the VLAN upper interface spans the
488 physical port of that VLAN interface, as well as the other ports that
490 * Treat bridge ports with VLAN upper interfaces as standalone, and let
493 - with VLAN filtering turned on, these VLAN devices can be created as long as
494 the bridge does not have an existing VLAN entry with the same VID on any
495 bridge port. These VLAN devices cannot be enslaved into the bridge since they
496 duplicate functionality/use case with the bridge's VLAN data path processing.
499 way by the enabling of VLAN filtering on the bridge device(s). If the VLAN
501 should indicate to the network stack that VLAN filtering is required by setting
504 Because VLAN filtering can be turned on/off at runtime, the switchdev driver
507 switchdev driver can also refuse to support dynamic toggling of the VLAN
509 creation of new bridge device(s) with a different VLAN filtering value to
510 ensure VLAN awareness is pushed down to the hardware.
512 Even when VLAN filtering in the bridge is turned off, the underlying switch
513 hardware and driver may still configure itself in a VLAN-aware mode provided
516 The VLAN protocol of the bridge plays a role in deciding whether a packet is
518 VLAN-untagged packets, as well as packets tagged with 802.1Q headers, as
525 When the bridge has VLAN filtering enabled and a PVID is not configured on the
527 has VLAN filtering enabled and a PVID exists on the ingress port, untagged and
529 bridge's port membership of the PVID VLAN. When the bridge has VLAN filtering