topic Re: Multi-auth and unmanaged switch in Network Access Control

Multi-auth and unmanaged switch

iores — Wed, 04 Jun 2025 22:17:11 GMT

Hi,

I have several devices on unmanaged switch that I need to authenticate via MAB. Unmanaged and upstream switch are connected via access port.

My idea is to configure MAB on a access port of upstream switch, and use multi-auth host-mode.

Would this work? Do I need to authorize the MAC of the switchport of unmanaged switch, as well? Can I use dynamic VLAN assigment in such a case?

Re: Multi-auth and unmanaged switch

Arne Bier — Wed, 04 Jun 2025 23:18:32 GMT

Multi-auth on upstream switch is the way to go - every device attached to the unmanaged switch will create a new session on the upstream switch and be subjected to Policy Auth. The assumption is that you use access vlan mode on the upstream and unmanaged switch - which means, your domain is using a single VLAN. The access-vlan is the same on upstream, as it is on the unmanaged switch. I don't believe that trunk mode (802.1Q) would work in this scenario.

There is another way - Cisco calls it NEAT - I have never used it - not sure what the current state is this method. It would seem the smarter way to go, is the "unmanaged" switch can act as a 802.1X supplicant and supports CISP. It also appears that NEAT functionality has been superseded by interface templates - the idea being, that you authenticate the SWITCH as a whole, and then it turns the access mode into a trunk. But what's never been clear to me, is whether or not you can then also authenticate and authorize the endpoints separately as they connect to the unmanaged switch.

Re: Multi-auth and unmanaged switch

paulwelchh — Thu, 05 Jun 2025 00:48:49 GMT

Thanks for the clear explanation, Arne. Just to confirm, with multi-auth on the upstream switch, each device behind the unmanaged switch will create its own MAB session and be individually authenticated. Has anyone seen dynamic VLAN assignment work reliably in this setup, given that the unmanaged switch simply forwards traffic without VLAN tagging? Would assigning different VLANs to endpoints cause issues since the unmanaged switch is not VLAN-aware? I’d appreciate any practical experiences from others using this approach.

Re: Multi-auth and unmanaged switch

Arne Bier — Thu, 05 Jun 2025 01:35:24 GMT

You're looking for the holy grail. An unmanaged switch is usually a dumb device that may or may not allow each interface to be configured with a different VLAN. Even if it could, how do you propose to dynamically change the VLAN of a switch that you can't manage (via RADIUS) ? The best hope you have, is to configure all the VLANs (if possible) on the unmanaged switch according to your needs, and then run a 802.1Q trunk to the NAC enabled switch - but ... NAC is typically used on access mode interfaces - not trunks - so every MAC address that gets learned by the managed switch would need to be multi-auth authenticated, including the unmanaged switch itself. And that might be possible, but you'd have to test it. I have a vague memory of trying this once and gave up because I got strange results.

The plan would be to configure an access-mode interface on managed switch, put the NAC config on it. In ISE, create a downloadable interface template that enables trunking mode when it sees the MAC address (of the unmanaged switch's uplink) - that should turn your managed switch's access port into a trunk. But NAC will still operate on that interface - and every MAC address learned should then be subject to NAC session management.

You should also consider that since the unmanaged switch is dumb, it won't tell you if a device disconnects (since you have no L1/L2 visibility) - therefore, you should enabled session-timeout to maintain the session table on the managed switch.

If you reboot the unmanaged switch, check that you are happy with the session table on the managed switch (does it clear all the sessions you expect?)

Re: Multi-auth and unmanaged switch

iores — Thu, 05 Jun 2025 18:23:49 GMT

@Arne Bier

Whole network is flat - one vlan, and I cannot change this. All devices are without supplicant, therefore, I am using only MAB.

At managed segment, all access ports are in blackhole VLAN which then gets overidden by dinamically assigned VLAN from ISE.

Only exception is this dumb switch which has mgmt IP, and nothing else. It is connected via access port to the uplink/managed switch.

So I was thinking to put the access port on the managed switch in blackhole VLAN, which will be overidden by ISE after unmanaged switch port gets authenticated.

Will then ISE put each other MAC address to dynamically assigned VLAN?

Does this mean that MAC address of the mgmt interface of the dumb switch will be subject of MAB, as well?

Re: Multi-auth and unmanaged switch

Arne Bier — Thu, 05 Jun 2025 22:10:47 GMT

One VLAN to rule them all! I like it.

The only interface's VLAN you need to dynamically set via RADIUS, is the interface on the managed switch that connects to the dumb switch. Forget doing anything on or to the dumb switch. Get the MAC address of the dumb switch and put that in an Endpoint Identity Group and write an ISE MAB Authorization Policy to return the appropriate VLAN when you see that MAC address.

As for the endpoints connecting to the dumb switch - get all those MAC addresses into ISE via whatever means you can, and then write a MAB Authorization Policy to just return an Access-Accept. There should be no need to set the VLAN each time an endpoint connects on the dumb switch, since the VLAN has already been set when the dumb switch's uplink sent an Ethernet frame (as a result of it sending some management traffic). However, I can imagine a scenario where this might be needed, in situations where the dumb switch's management traffic for some reason doesn't flow, and therefore the VLAN on the managed switch is not yet assigned, while the connected endpoints on the dumb switch are trying to send traffic and getting MAB'd, but not on the right VLAN. So, perhaps just return the VLAN in all cases to be sure.

You can also return a dACL if you like, which is applied to the individual access sessions at Layer 3.

Re: Multi-auth and unmanaged switch

iores — Thu, 05 Jun 2025 22:20:25 GMT

But if the dumb switch has MGMT SVI in the same VLAN, I need to add its MAC too to the Endpoint Identity Group, beside the MAC of the physical port, right?

Re: Multi-auth and unmanaged switch

Arne Bier — Thu, 05 Jun 2025 22:55:36 GMT

Yes - whatever the Ethernet MAC the dumb device uses to send traffic TO the managed switch, will be the trigger for ISE to authorize the interface and set the VLAN.

Re: Multi-auth and unmanaged switch

Arne Bier — Thu, 05 Jun 2025 23:44:46 GMT

I mocked this up in my CML 2.8 lab

rnolab-sw-ab-01#show access-session interface gi 1/0/3 Interface MAC Address Method Domain Status Fg Session ID -------------------------------------------------------------------------------------------- Gi1/0/3 5254.006c.6834 mab DATA Auth 208016AC0000000D426CCDA7 Gi1/0/3 aabb.cc00.0330 mab DATA Auth 208016AC0000000C426C7BDD Gi1/0/3 aabb.cc80.0300 mab DATA Auth 208016AC0000000E426ED118

5254.006c.6834 - Ubuntu client workstation on dumb switch
aabb.cc00.0330 - dumb switch Eth 0/3 (set to access vlan 100)
aabb.cc80.0300 - dumb switch interval vlan 100 (SVI)

Re: Multi-auth and unmanaged switch

sidshas03 — Fri, 06 Jun 2025 02:37:53 GMT

Hey,

If you’re planning to keep this setup long-term with unmanaged switches and multiple endpoints behind it, one strong suggestion I can give is to replace the dumb switch with a basic managed switch – even a low-end Catalyst or SMB series model. Reason is, with unmanaged switches, you have zero visibility – you can't detect when a device behind it disconnects, there's no MAC aging control, and the switch doesn’t support VLAN tagging or 802.1X supplicant capabilities.

With a managed switch, even a small one, you can do proper 802.1X supplicant-based authentication using something like Cisco NEAT or downloadable interface templates. That way, you authenticate the switch once, and then the port becomes a trunk. ISE can handle dynamic VLANs per endpoint coming behind it, cleanly. Plus, you get better logs, session visibility, and less headaches with MAC learning and session timeout issues.

In your current setup, the best you can do is multi-auth with MAB on the upstream switch, and set session inactivity timeout to handle device disconnections — but still it's a workaround. With a managed switch, you can future-proof the design and reduce ISE overhead by pushing logic to the edge.

So if budget or design allows, try to move from dumb to smart — even if it’s just for this one switch. It’ll save you time in the long run.

Re: Multi-auth and unmanaged switch

iores — Fri, 06 Jun 2025 06:18:25 GMT

With session timeout, will there be any connectivity issues when timeout expires?

Re: Multi-auth and unmanaged switch

iores — Fri, 06 Jun 2025 06:19:51 GMT

I presume you have used external connector to connect with ISE?

Re: Multi-auth and unmanaged switch

Arne Bier — Fri, 06 Jun 2025 20:55:26 GMT

Yep - my CML VM has an additional VM adapter on a VLAN that connects to my ISE/DNAC etc.

I have DNAC and ISE and other systems that are running on ESXi etc. - running those things in CML is too much hassle and too slow.

I created a new CML Bridge in the CML Sysadmin GUI under Networking - add a new "bridge" into the VLAN which you can see as a Linux interface. When you select the External Connector (cloud) icon in CML, you can select whether to use the built-in NAT mode, or your custom bridges you created.

The CML standard external connector only allows outbound connections (i.e. from your CML devices to the external) via NAT. But it doesn't allow external connections INTO your CML. That is why I created these bridges. When I build larger CML labs I use an unmanaged (CML) switch that is bridged to a real lab Management VLAN, and connect all my CML instances' management interfaces to it - they get an IP address from my lab DHCP range when they boot up, or I can assign one statically. Either way, I can then SSH into them and manage them like a real device.

Re: Multi-auth and unmanaged switch

Arne Bier — Fri, 06 Jun 2025 20:52:03 GMT

You need to tell ISE a few things to ensure that you have a seamless re-authentication (no connectivity loss). The Authorization Profile must contain the following information:

termination-action-modifier=1

In my Profile, I set the VLAN to 100, and 28800 seconds re-auth interval - ISE sends these RADIUS attributes to the switch:

Re: Multi-auth and unmanaged switch

iores — Sat, 07 Jun 2025 18:42:10 GMT

@Arne Bier

What is the purpose of using session timeout? What can go wrong if it is not used?

Re: Multi-auth and unmanaged switch

iores — Sat, 07 Jun 2025 18:45:57 GMT

@Arne Bier

How much resources have you used for DNA C? I suspect you have dedicated server - what are the specs?

Re: Multi-auth and unmanaged switch

Arne Bier — Sat, 07 Jun 2025 21:31:17 GMT

I mentioned it earlier - it has to do with managing the session table on the managed switch - every NAC enabled interface will create a new session when a new MAC address is learned - if you don't put a time limit (session timeout) on a session, then the session will live forever - unless the interface link goes DOWN (device disconnected or port shut) - that clears the session. A switch reload also clears the session table.

The problem is that your managed switch has no knowledge that a device was unplugged on the dumb switch. How could it? Therefore you have to solve the issue of "stale sessions" differently. You set a timer (e.g. 18 hours countdown) from the time the MAC address is seen on the managed switch and the session is created. If in that time, the device is unplugged on the dumb switch, the session continues. If you were to check the MAC address table of the managed switch, you'd notice that the MAC address of the removed device will eventually disappear -but the session still lives. After session timeout has reached 0, the managed switch will notice that the MAC address is no longer there and will clear the sessions. On the other hand, if the MAC address was still there because device was still connected, then the managed switch would send a re-auth to ISE and that would reset the timer for another 18 hours - the data traffic is no affected by this (if you do the re-auth like I mentioned).

Re: Multi-auth and unmanaged switch

Arne Bier — Sat, 07 Jun 2025 21:34:26 GMT

I watched some Youtube videos on how to do this and it's pretty much consuming all the RAM of one server with 256GB RAM. To install and run need at least 256GB of RAM - the CPUs required can be less than Cisco recommends - just don't expect it to perform super fast. But for a lab it's fine.

Here are the specs.

Re: Multi-auth and unmanaged switch

iores — Sat, 07 Jun 2025 22:13:00 GMT

@Arne Bier

What would or can happen if the session lives forever?

Re: Multi-auth and unmanaged switch

Arne Bier — Sat, 07 Jun 2025 23:13:20 GMT

Nothing bad. It’s just misleading. If you examine the session table you might think the endpoints are attached , when in fact they are not. Also, as long as the session is active, and ISE is receiving Accounting updates, ISE consumes a license. Just clear inactive sessions with session timeout. It’s the right thing to do.