On Sat, Feb 27, 2021 at 02:18:20PM +0100, Michael Walle wrote:
Am 2021-02-27 01:16, schrieb Vladimir Oltean:
> On Fri, Feb 26, 2021 at 03:49:22PM -0800, Jakub Kicinski wrote:
> > On Sat, 27 Feb 2021 01:42:44 +0200 Vladimir Oltean wrote:
> > > On Fri, Feb 26, 2021 at 03:28:36PM -0800, Jakub Kicinski wrote:
> > > > I don't understand what you're fixing tho.
> > > >
> > > > Are we trying to establish vlan-filter-on as the expected behavior?
> > >
> > > What I'm fixing is unexpected behavior, according to the applicable
> > > standards I could find.
In the referenced thread you quoted from the IEEE802.3 about the
promisc
mode.
The MAC sublayer may also provide the capability of operating in the
promiscuous receive mode. In this mode of operation, the MAC
sublayer
recognizes and accepts all valid frames, regardless of their
Destination
Address field values.
Your argument was that the standard just talks about disabling the
DMAC
filter. But was that really the _intention_ of the standard? Does the
standard even mention a possible vlan tag? What I mean is: maybe the
standard just mention the DMAC because it is the only filtering
mechanism
in this standard and it's enough to disable it to "accept all valid
frames".
I was biten by "the NIC drops frames with an unknown VLAN" even if
promisc mode was enabled. And IMHO it was quite suprising for me.
In short, promiscuity is a function of the MAC sublayer, which is the
lower portion of the Data Link Layer (the higher portion being the
Logical Link Control layer - LLC). The MAC sublayer is governed by IEEE
802.3, and IEEE 802.1Q does not change anything related to promiscuity,
so everything still applies.
The MAC sublayer provides its services to the MAC client through
something called the MAC service, which uses the following primitives:
MA_DATA.request(
destination_address,
source_address,
mac_service_data_unit,
frame_check_sequence)
to send a frame, and
MA_DATA.indication(
destination_address,
source_address,
mac_service_data_unit,
frame_check_sequence,
ReceiveStatus)
to receive a frame.
One particular component of the MAC sublayer seems to be called the
Internal Sublayer Service (ISS), and this one is defined in IEEE
802.1AC-2016. To be frank, I don't quite grok why there needs to exist
this extra layering, but nonetheless, the ISS has some similar service
primitives to the MAC sublayer as well, and these are:
M_UNITDATA.indication(
destination_address,
source_address,
mac_service_data_unit,
priority,
drop_eligible,
frame_check_sequence,
service_access_point_identifier,
connection_identifier)
M_UNITDATA.request(
destination_address,
source_address,
mac_service_data_unit,
priority,
drop_eligible,
frame_check_sequence,
service_access_point_identifier,
connection_identifier)
where a "unit of data" is basically just very pompous speak for
"a frame", I guess.
Promiscuity is defined in IEEE 802.3 clause 4A.2.9 Frame reception,
which _in_context_ talks about the interface between the MAC client and
the MAC sublayer, so that means about the M_UNITDATA.indication or the
MA_DATA.indication.
Whereas VLAN filtering, as well as adding and removing VLAN tags, is
governed by IEEE 802.1Q, as a function of the Enhanced Internal
Sublayer
Service (EISS), i.e. clause 6.8. In fact, the EISS is just an ISS
enhanced for VLAN filtering, as the naming and definition implies.
Of course (why not), the EISS has its own service primitives towards
its
higher-level clients for transmitting and receiving a frame. These are:
EM_UNITDATA.request(
destination_address,
source_address,
mac_service_data_unit,
priority,
drop_eligible,
vlan_identifier,
frame_check_sequence,
service_access_point_identifier,
connection_identifier,
flow_hash,
time_to_live)
EM_UNITDATA.indication(
destination_address,
source_address,
mac_service_data_unit,
priority,
drop_eligible,
vlan_identifier,
frame_check_sequence,
service_access_point_identifier,
connection_identifier,
flow_hash,
time_to_live)
There's a big note in IEEE 802.1Q that says:
The destination_address, source_address, mac_service_data_unit,
priority, drop_eligible, service_access_point_identifier,
connection_identifier, and frame_check_sequence parameters are as
defined for the ISS.
So basically, although the EISS extends the ISS, it has not changed the
aspects of it regarding what constitutes a destination_address. So
there
is nothing that redefines the promiscuity concept to extend it with the
vlan_identifier.
Additionally, the 802.1Q spec talks about this EISS Multiplex Entity
thing, which can be used by a VLAN-aware end station to provide a SAP
(Service Access Point, in context it means an instance of the Internal
Sublayer Service), one per VID of interest, to separate MAC clients.
That is to say, the EISS Multiplex Entity provides multiple
M_UNITDATA.indication and M_UNITDATA.request services to multiple MAC
clients, one per VLAN. Each individual service can be in "promiscuous"
mode. This is similar to how in Linux, each 8021q upper of a physical
interface can be promiscuous or not.
