topic Re: ZTP+ Fabric with NAC on edge ports not working (auto-sense enabled) in ExtremeSwitching (VSP/Fabric Engine)

ZTP+ Fabric with NAC on edge ports not working (auto-sense enabled)

JPavel — Wed, 17 Jun 2026 10:20:30 GMT

Hello community,

we are looking to set up ZTP+ Fabric, including Extreme Control (NAC), for one of our customers.

In this case, the customer wants to minimize the need for CLI-based switch configuration as much as possible.

In principle, the onboarding of the fabric switches via the workflow is working as intended.

However, we are having trouble getting NAC to work on the end-device ports.

The customer wishes to continue using their legacy Control configuration to pass the VLAN to the switch via RADIUS attributes (using the "Extreme VOSS" RADIUS template).

The rule set and mapping within Control appear to be correct, as the end-system logs clearly show the correct VLAN attributes being returned:

However, we observe that the switch port ignores the VLAN attribute, meaning the port is not authorized for the target VLAN.

Consequently, the port remains stuck in the onboarding VLAN (4048):

To check if the issue might be related to the legacy VLAN configuration, we also ran tests using the "Extreme VOSS - Fabric Attach" and "Extreme VOSS - Per-User-ACL" RADIUS templates, defining the corresponding policy roles in the policy domain.

The behavior, however, was exactly the same. The end-system logs showed that the correct policy role value was forwarded to the switch (FilterID=<Policy-Role>), but the switch ignored it, and the port remained stuck in the onboarding VLAN (4048).

To get NAC working, we had to enable "auto-sense" on the ports and configure eapol for the interfaces:

(Because we did a simple tests with MAC authentication we had to add the guest-vlan here)

Once that was done, the switch correctly recognized the RADIUS VLAN attribute and successfully moved the port into the appropriate VLAN:

I am now wondering whether it is even possible to get NAC working when "auto-sense" is enabled on the end-device ports.

I tried setting the "auto-sense wait-interval" to 2 seconds to rule out potential timeout issues, but that didn't help.

Can anyone assist me with this?

Best regards,

Joerg

Re: ZTP+ Fabric with NAC on edge ports not working (auto-sense enabled)

Ludovico — Wed, 17 Jun 2026 15:44:28 GMT

The Tunnel-Private-Group-Id attribute (Template Extreme VOSS) is not designed to work on auto-sense / flex-uni access ports. It will only work if there is already a platform VLAN object on the switch.

Auto-sense is what you want to keep on access ports, and NAC uses flex-uni on auto-sense ports, which can be added to any I-SID (without any need for platform VLANs on the switch).

The correct RADIUS template is Extreme VOSS - Fabric Attach" if not using XIQ-SE Policy, or "Extreme VOSS - Per-User-ACL" if using XIQ-SE Policy.

There is a Sandbox that Extreme partners can reserve to understand how to deploy a fully zero-touch automated Fabric Edge with NAC; ask your Extreme sales rep to reserve it for you.

Re: ZTP+ Fabric with NAC on edge ports not working (auto-sense enabled)

JPavel — Fri, 19 Jun 2026 09:00:48 GMT

Hi Ludovico,

first of all, thanks for your feedback.

I actually manually created the corresponding platform VLAN on the test switch in our lab, so—in my opinion—the "Extreme VOSS" template should have worked.

Nevertheless, I also ran the same tests in our lab using the "Extreme VOSS - Fabric Attach" and "Extreme VOSS - Per-User-ACL" RADIUS templates which is illustrated in the “NAC in Campus Fabric Edge.pdf“ document.

The result was always the same. I never see the end-device port being pushed untagged into the correct C-VLAN (VLAN 10 in our case) after authentication; it always remains in the onboarding VLAN 4048.

Here the Control Rule Definition and the corresponding Radius Attribute Policy Mapping preview:

And the corresponding switch outputs:

But I probably just have a misunderstanding here, since I come from the EXOS world and am currently getting up to speed on Fabric Connect 😉

I would have expected the end-device port to be untagged in VLAN 10 at this point.

Regards, Joerg

Re: ZTP+ Fabric with NAC on edge ports not working (auto-sense enabled)

JPavel — Fri, 19 Jun 2026 09:02:29 GMT

Hi Ludovico,

first of all, thanks for your feedback.

I actually manually created the corresponding platform VLAN on the test switch in our lab, so—in my opinion—the "Extreme VOSS" template should have worked.

Here the Control Rule Definition and the corresponding Radius Attribute Policy Mapping preview:

And the corresponding switch outputs:

But I probably just have a misunderstanding here, since I come from the EXOS world and am currently getting up to speed on Fabric Connect 😉

I would have expected the end-device port to be untagged in VLAN 10 at this point.

Regards, Joerg

Re: ZTP+ Fabric with NAC on edge ports not working (auto-sense enabled)

Ludovico — Mon, 22 Jun 2026 10:43:58 GMT

Hi Joerg

You have it working there; RADIUS returned 0:2000100 and you have I-SID 2000100 untagged on port 1/10.

Yes you also have Onboarding I-SID 15999999 untagged on same port, but keep in mind that any I-SID applied by RADIUS gets applied internally as a MAC-based-VLAN, so on your port 1/10, any untagged frame generated by your authenticated MAC address will always land untagged in I-SID 2000100; and if you happened to have some other non-authenticated devices on the same port they would go into the untagged Onboarding I-SID

Best regards

Ludovico

Re: ZTP+ Fabric with NAC on edge ports not working (auto-sense enabled)

JPavel — Mon, 22 Jun 2026 17:23:04 GMT

Hi Lodovico,

I understand that we have an I-SID untagged on port 1/10.
But what I am missing is the binding from that I-SID to vlan 10 at this point.
There is no vlan configured on the switch and I also cannot see any cli output which shows that port 1/10 is untagged in vlan10.
The "show int gig i-sid 1/10" shows no vlan (N/A) under the line "VLANID" .

Shouldn´t the Radius Attribute also return the VLAN ID besides the I-SID if there is no mapping Vlan-to-I-SID mapping at all on the switch?
Do I miss something here or do I simply do not understand what´s going on here.

Sorry that I do not get it 😞

Regards, Joerg

Re: ZTP+ Fabric with NAC on edge ports not working (auto-sense enabled)

Ludovico — Tue, 23 Jun 2026 16:04:49 GMT

Hi Joerg

Welcome to our Fabric. We don't need VLANs, we have I-SIDs!

The I-SID is applied untagged on the port 1/10 where your device is. Your device is sending untagged packets.

In our fabric, a L2 broadcast domain, is a L2VSN and it only needs an I-SID to exist. The switch has auto-sense on the access ports, which uses flex-uni mode and in that mode a VLAN-id is only really needed if you need to hand it off to a device which wants it q-tagged with a particular VLAN-id.

Why would we need a VLAN ?

If your switch is just a L2 access switch, you normally don't need a VLAN object; the packets from your client will get MACinMAC encapsualted to the destination using the I-SID to identify the L2VSN service.

Now, there are some exceptions where you might need a VLAN object on the switch anyway, for certain functionality, like if you wanted that switch to bind an IP interface to IP route traffic to/from that L2VSN; or if you needed IP Multicast to work on that segment, or if you wanted the L2VSN to be of type Private-VLAN, or if you wanted to use DHCP-Snooping to work on it, etc...

Now, if for those reasons you really wanted to have a VLAN object created at the same time via RADIUS, you need to use a different VSA:

Extreme-Dynamic-Client-Assignments=[create vlan|pvlan|none, pv=Primary VLANID, [sv=secondary VLANID]], vni=ISID, ev=EGRESS-VLAN-tag, [vn=vlan-name], [vnin=isid-name], [mvni=L3ISID], [igmpqaddr=IPv4addr]

You will find that on slide 16 of the document I attached to my first reply.

Best regards

Ludovico

Re: ZTP+ Fabric with NAC on edge ports not working (auto-sense enabled)

JPavel — Wed, 24 Jun 2026 18:49:19 GMT

I’ve finally got it now 🙂 I just successfully got the setup running in my lab and will implement it at our customer's site tomorrow. Thanks for your patience with me. Regards, Joerg