Multi-auth and unmanaged switch

[iores]

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?

[Arne Bier]

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.

[paulwelchh]

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.

[Arne Bier]

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

[iores]

@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?

[Arne Bier]

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.

[iores]

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?

[Arne Bier]

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. 

[Arne Bier]

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)

[iores]

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

[Arne Bier]

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.

[iores]

@Arne Bier

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

[Arne Bier]

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.

[sidshas03]

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.

[iores]

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