cancel
Showing results for 
Search instead for 
Did you mean: 

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

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

JPavel
New Contributor II

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).

JPavel_0-1781691551235.png

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

JPavel_1-1781691551237.png

JPavel_2-1781691551238.png

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):

JPavel_3-1781691551238.png

JPavel_4-1781691551239.png

JPavel_5-1781691551239.png

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:

JPavel_6-1781691551239.png

(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:

JPavel_7-1781691551240.png

JPavel_8-1781691551240.png

JPavel_9-1781691551241.png

JPavel_10-1781691551241.png

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

 

 

1 ACCEPTED SOLUTION

JPavel
New Contributor II

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

View solution in original post

7 REPLIES 7

Ludovico
New Contributor II

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

JPavel
New Contributor II

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

Ludovico
New Contributor II

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. 

 

GTM-P2G8KFN