Controllerless Networks

We just changed switches from a Nortel 450 to a Meraki MS120.

I have an SSID with dynamic VLAN assignment as follows :

For some reason vlan 1800 isn't being assigned, and I'm getting the following error:

Devices that are being assigned to vlan 2370 are getting through.

I've verified the trunk port on the Meraki is correctly set up, and it's uplink is setup with the appropriate vlans being allowed on the trunks. This is occurring on all the access points we have connected to Meraki switches. Working perfectly fine on our avaya/extreme/cisco switches. Anyone know if there is something specific about the Meraki switches that needs to be configured for dynamic vlan assignment to work?

Your rule will only work if you are returning an Aruba VSA for "Named VLAN".  Do you have that defined on your radius server?

@cjoseph

Any device that receives the 'Mobile" named vlan is able to connect and authenticate.

It is the devices that do not receive a named vlan, and should be defaulted to 1800 do not authenticate.

I'm using the same Service with Same enforcement policy I've been using. I do not suspect anything in the service to be the issue.

Here's the profile:

Enforcement:

This same profile works when I move the IAP back to any other make of switch in the same cluster. Just doesn't work for IAPs on Meraki switches. I still have it working on all our IAPs connected to Avaya/Cisco/Nortel/Baystack/Extreme switches.

We need to see what the access tracker is saying that it is sending to the Instant AP, to understand what is going on.  Showing the enforcement policies shows what should be sent.  Showing the access tracker under the output tab shows what IS being sent. 

Here's the access tracker output:

Alert:

At the top, you can see that it is sending the deny access profile.  You need to find out why.

EDIT, the second message says that the client timed out.  That is typical for a client that needs to accept a new radius server certificate.  There are other reasons, but this one exists on the client.

Here's the same client when he roams to another access point connected to a Cisco switch with the same device.

same SSID and same cluster, but different results.

I don't know enough about your setup to determine what is wrong.  ClearPass is saying that it is not receiving a response from the client.  Hopefully you only have trunking enabled on that switchport and not 802.1x.

What other reasons could exist for the 9002 error?
I've verified that the client has the appropriate radius cert, not expiring until october.

802.1x isn't configured on  these meraki switches, no ACL setup either. Trunk for the IAP setup the same as every other IAP, uplink on the switches are trunk and tagged with the correct vlans.

Not sure if it would be related at all, but I am seeing some unusual Swap usage:

Conventional wisdom says that if it works until you introduce a new part, see what is different on that new part.  They are from the same manufacturer.  Maybe others have better guesses than I do...

EDIT:  Compare both Access Tracker events and see what is different to understand what could be wrong.  I am not sure the swap is your problem.

Only major difference I can think of is I havent enabled RSTP on these meraki switches yet. Don't think that would affect RADIUS authentications for the IAP client tho. 

Thanks for the Help so far, it is appreciated.

The authentication piece happens before client traffic is trunked.  I would check to make sure that the same service is triggered on both authentications, and there are no attributes specific to Cisco switch that would make ClearPass handle it different from the Meraki device.

It's hitting the same service. I'm noticing that in the Computed Attributes when the device fails, it shows the Outer method as EAP, but when it succeeds it shows as EAP-PEAP. not sure if this is because of the timeout. 

.

If the client didn't negotiate the inner EAP method, that method might not be available.  Narrow it down and try a different client.

I'll be scheduling a maintenance window and rebooting the Meraki switches. I've got one of them near me I tested with the same config and a couple clients and they are working correctly.

I rebooted the problem IAP's before without success on the issue. Considering it's all the same config I think rebooting the switches could at least eliminate the possibility of something wrong on their startup.

Please keep us posted 

I ended up changing the pvid of the switch port to a different vlan, and had the uplink vlan on the IAPs defined as it's mgmt. that ended up getting it to work.

the iap was still joining the cluster when the pvid and t he uplink vlan matched, so I'm unsure why this happened. I know pvid on avaya/nortel switches is different than meraki, so that might have something to do with it.