On Thu, Jul 21, 2022 at 1:45 PM Vladimir Oltean olteanv@gmail.com wrote:
Why is it "not really so nice" to "trigger MAB" (in fact only to learn a locked entry on a locked port) when initiating the 802.1X session?
The consideration is mostly to limit (not eliminate) double actrivation, e.g. activation of 802.1X and MAB at roughly the same time, so that the daemons will have more to do coordinating which has the session.
You can disable link-local learning via the bridge option if you're
The issue here is that you can only disable it bridge wide and not per port.
really bothered by that. When you have MAB enabled on an 802.1X port, I think it's reasonable to expect that there will be some locked entries which user space won't ever unlock via MAB. If those entries happen to be created as a side effect of the normal EAPOL authentication process, I don't exactly see where is the functional problem. This shouldn't block EAPOL from proceeding any further, because this protocol uses link-local packets which are classified as control traffic, and that isn't subject to FDB lookups but rather always trapped to CPU, so locked or not, it should still be received.
I'm only pointing out the obvious here, we need an opt in for MAB, and the implemented behavior I've seen here kind of points to mapping this to "+learning +locked", where the learning process creates locked FDB entries.
If we need an opt in for MAB, you are right. Only then I think that we need to solve the link-local learning issue so that it is disabled per port?