Open vSwitch on an Auto-Sense port

[Raul_Carbonari]

Hi,

I am trying to use the OVS service on a Debian 12 installation.

According to the documentation, OVS does not support HMAC authentication for Auto-Attach. If I configure the switch port as FA without authentication, it works; however, when I set it to Auto-Sense, I receive authentication error messages on the port.

While NAC could handle this authentication dynamically, I am trying to set up a scenario where NAC is not required and Auto-Sense itself allows me to automate specific clients (Linux, in this case).

I found the command `auto-sense fa ovs eapol status authorized`; it is supposed to bypass authentication, but it doesn't seem to work.

I am connecting to a 5420 switch running firmware 9.3.2, and there is NAC on the network.

Is this a bug? Has anyone else tried using OVS on Auto-Sense ports?

Raúl Carbonari

[iDavidHere]

Hey, this behavior usually happens because Auto-Sense still tries to trigger EAPOL handling even if OVS is set to bypass auth, especially on 5420 running 9.3.x. So it’s not fully a bug, more like a limitation in how Auto-Sense interacts with FA/OVS mode. If NAC is present in the network, it can also interfere and force auth attempts on the port. You may want to explicitly disable NAC enforcement on that VLAN/port or stick with FA mode for OVS use cases.

[Raul_Carbonari]

Hi David,

I think a big part of the issue was assuming that "Auto" in "Auto-Sense" meant complete automation where every single connection scenario would be handled out of the box—and that’s not quite the case.

It handles devices with native Fabric Attach (FA) exceptionally well (Extreme switches, Extreme APs, certain IP cameras, and VoIP phones), but for everything else, it’s pretty much best-effort.

OVS (Open vSwitch) isn't a full-blown FA client; it just offers some basic FA compatibility, and that’s about it. There is no dedicated FA client developed for Linux, Windows, or macOS. While that would certainly be an interesting feature, I’m not going to fall into the Feature Request trap when I already know what the answer would be.

That said, the FAClient.py project has already allowed me to "play pretend" and simulate a client so I can use it however I want.

To achieve full automation, a NAC is still required, and I hope EP1 Security can deliver on that front as well. From a business perspective, this is the economically viable path for Extreme, and that’s perfectly fine.

At least I’m still having some fun under the hood trying to figure out how everything works underneath! 😉

Raúl

[MarkusNikulski]

Hi Raúl,

FYI, I created an FA test tool you can use against both physical and virtualised Fabric Engine (aka VOSS).  http://www.nikulski.net/vfad/
Please note that message authentication prevents unwanted VLAN/I-SID assignment, but it still exposes FA client details to the FA server/Proxy. It means that there is always an ability to recognise the client. If EAPoL is used, the FA client details can be shared with the Radius server by carrying the FA attributes in the request.
Yes, we are still improving the solution that has become more flexible. in each release. Your input is valid, and we have similar ideas too.

Best regards
Markus

[Raul_Carbonari]

Thanks for the follow-up, Markus.

I used vFAD to gain a deeper understanding of FA; it was really useful.

Raúl