Lines Matching refs:VLAN
173 FDB entry is the {port, MAC, VLAN} tuple forwarding destination.
180 - VLAN flooding of multicast/broadcast and unknown unicast packets
221 Note: by default, the bridge does not filter on VLAN and only bridges untagged
222 traffic. To enable VLAN support, turn on VLAN filtering::
229 The switch device will learn/forget source MAC address/VLAN on ingress packets
310 For a given L2 VLAN domain, the switch device should flood multicast/broadcast
427 use per-port VLAN identifiers unless a better mechanism is available
432 appropriate filters for VLAN, multicast, unicast etc. The underlying device
440 of a VLAN-aware bridge doing ingress VID checking). See below for details.
442 If the device implements e.g.: VLAN filtering, putting the interface in
443 promiscuous mode should allow the reception of all VLAN tags (including those
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
462 data path will process all Ethernet frames as if they are VLAN-untagged.
463 The bridge VLAN database can still be modified, but the modifications should
464 have no effect while VLAN filtering is turned off. Frames ingressing the
465 device with a VID that is not programmed into the bridge/switch's VLAN table
466 must be forwarded and may be processed using a VLAN device (see below).
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
472 When there is a VLAN device (e.g: sw0p1.100) configured on top of a switchdev
477 - with VLAN filtering turned off, the bridge will process all ingress traffic
478 for the port, except for the traffic tagged with a VLAN ID destined for a
479 VLAN upper. The VLAN upper interface (which consumes the VLAN tag) can even
482 belonging to the VLAN upper interfaces are managed properly:
484 * If forwarding destinations can be managed per VLAN, the hardware could be
486 belonging to a VLAN upper interface, to an internal VID corresponding to
487 untagged packets. This internal VID spans all ports of the VLAN-unaware
488 bridge. The VID corresponding to the VLAN upper interface spans the
489 physical port of that VLAN interface, as well as the other ports that
491 * Treat bridge ports with VLAN upper interfaces as standalone, and let
494 - with VLAN filtering turned on, these VLAN devices can be created as long as
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
502 should indicate to the network stack that VLAN filtering is required by setting
505 Because VLAN filtering can be turned on/off at runtime, the switchdev driver
508 switchdev driver can also refuse to support dynamic toggling of the VLAN
510 creation of new bridge device(s) with a different VLAN filtering value to
511 ensure VLAN awareness is pushed down to the hardware.
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
526 When the bridge has VLAN filtering enabled and a PVID is not configured on the
528 has VLAN filtering enabled and a PVID exists on the ingress port, untagged and
530 bridge's port membership of the PVID VLAN. When the bridge has VLAN filtering