RADIUS Monitoring Mode Missing

[EDIT]

Recently deployed my Meraki MS120-8 on Cisco ISE and as I am testing out my access policy, I lose connection to any device behind the port (Hyper-V switch <> VMS). I thought enabling RADIUS testing would allow monitoring mode but I later realized that's just for a Keep Alive to the RADIUS box and not monitor mode.

From the Meraki MS Access Policies doc, it shows the MS switch can do monitoring mode as well as a screenshot showing RADIUS monitoring as an option but I'm not seeing in the dashboard

https://documentation.meraki.com/MS/Access_Control/MS_Switch_Access_Policies_(802.1X) <<< Under "Suspend Port Bounce", RADIUS Monitoring is an option.

In the below screenshot, notice I do not have the option. Is there anything I'm missing to enable this feature since the traditional ACL approach via CLI is not available?

 

[alemabrahao]

What version are you running?

This feature must be enabled to track RADIUS server reachability. If not enabled, clients will continue to be put on the Guest or Critical Auth VLANs even after connectivity between the MS and RADIUS server has been restored.

[KarstenI]

RADIUS monitoring is something completely different than the Catalyst modes of Monitoring/Low Impact/Closed. These modes are not available on Meraki MS. Can you explain a little more detailed what your problems are?

[EDIT]

@alemabrahao running latest 15.21.1

@KarstenI ,

Thanks for clarifying. I misunderstood the doc because it mentions it can be done on MS switches. My issue is that I'm trying to test RADIUS authentication using Cisco ISE as my RADIUS server and lose access to my all of my end host when I apply my RADIUS access policy to my switchport.

My setup is as follows:

Edge router<>MX67 Gateway<>MS120-8 Switch<>HyperV Virtual Switch<>End host

Note: ISE host is connected to the virtual switch and the virtual switch is configured to support 802.1x

Per Meraki MS doc, port must be in Access mode. The virtual switch is connected to an access port on the Meraki MS switch and the MS switch uplink is also set to access port.

For my Meraki Access Policy, I set it the host mode to multi auth. 

[KarstenI]

Do I understand you right that you want to do 802.1X for your VMs? This is a bad idea in 99% of all cases. 

[alemabrahao]

It is not common to enable authentication on server ports, not to mention that this can cause several problems.

[EDIT]

Ok thanks for the added info. It sounds like I need to test on a port where Cisco ISE is not connected to, at least in my use case. I have another laptop that I can physically connect to another switchport or connect my MR access point and do wireless 802.1x

[EDIT]

Hi @KarstenI, not necessarily, really the end goal is to test wired 802.1x authentication. I was unaware that 802.1x for VMs is not best practice so thank you for sharing and any additional links you can provide for more detail would be greatly appreciated.

In that case, will leave the VMs out of the flow and move forward with testing just my physical server. Is it possible to enable 802.1x for only the server hosting the Hyper V virtual switch? Trying to see if the following would work:

802.1x for PC hosting Hyper V switch where ISE sits behind the vswitch

MS120-8<>HyperV switch<>physical end host <<<<< but I believe this would inherit the access policy causing issues for the hosted VMs?

Or should it be the following?:

MS120-8<>physical adapter of host<>Windows10 <<<< Taking vswitch out of the flow

[KarstenI · Accepted solution]

802.1x for PC hosting Hyper V switch where ISE sits behind the vswitch

the same bad idea ... The ISE has to be reachable all the time to do the authentication.

---

MS120-8<>HyperV switch<>physical end host <<<<< but I believe this would inherit the access policy causing issues for the hosted VMs?

with physical end host you probably mean the VM? Because I had no idea how to connect a physical host to a virtual switch. IMO still a bad idea, but it could work in two scenarios:

1) The switch-port is configured for multiple-host mode and only the HyperV has to authenticate to the switch. All VMs are allowed to connect "piggyback" on this connection.

2) The switch-port is configured for multi-auth, here all VMs need a supplicant to authenticate to the network. This will only work if the virtual switch does not interfere with the EAPOL communication.

---

MS120-8<>physical adapter of host<>Windows10 <<<< Taking vswitch out of the flow

---

This is the best way to do it from the 802.1X standpoint. One port, one end-device. But likely not the best solution from a VM standpoint.

[EDIT]

Thanks @KarstenI for helping shed light on the misconfig and best practices. I now know which route to take 🤙