I just deployed a Meraki network in a residential building in which our company provides wifi to tenant units. The building has 108 apartments, so I though it would be a perfect opportunity to deploy our first environment in which we use greater that 50 PSKs (1 for each unit).
The general theory is that we've built a /24 subnet for each apartment, tied to a group policy with VLAN tagging for that particular subnet, and a unique PSK to connect to the single SSID. Each unique PSK will place tenants in their correct group policy, and subnet. At first, we did not enable WPN, as we had a subnet for each tenant, and a group policy pointing towards it, so no need for it right - the group policy should take care of everything?? Not quite.
During the deployment, we had a lot of trouble with Access Points randomly restarting, and dropping off the network. When we turned off all broadcasting, things went back to normal. As soon as we turned on the SSID with the PSK environment, back to APs dropping.
Turns out, if you are using more than 50 PSKs in a GP environment, WPN HAS to be turned on. As soon as that setting was enabled, everything went back to normal. We have another property with 48 units (48 PSKs) and WPN does NOT need to be on for things to perform normally. Interesting.
This was not plainly expressed in the config guide so I just thought I'd share my experience, to save someone else a headache in the future. I know WPN and >50PSK is rather new, and required 29.1 or greater firmware, so things may change going forward.
Has anyone else had a similar experience?
Hi @CWK_Rob ,
You're correct, WPN supports > 50 iPSK groups by default on r29 firmware. It looks like you tried to use iPSK w/o RADIUS without WPN, which is a valid use case.
Currently, the number of iPSK groups is limited to 50 when using iPSK w/o RADIUS without WPN. However, we are working on scaling iPSK w/o RADIUS to > 50 iPSK groups, and this will be available in the upcoming r29 firmware release.
Once done, both iPSK w/o RADIUS without WPN AND iPSK w/o RADIUS with WPN will support > 50 iPSK groups. Keep an eye on the release notes 🙂
Fantastic - I was getting confused as to why I needed WPN on. It made for some confusing moments during deployment, but that's the way things go when you're an early-adopter. I'm happy you corroborated my theory @AlexanderN
Splash Access has a solution for the education sector for dorms where each dorm gets a seperate network and supports self-onboarding. I would check this out, as it might make things much easier for you.
Im a little confused here ... WPN is for when you use one VLAN for all clients, and they are still seperated by #merakimagic right ?
And iPSK with GP is for when you have multiple VLANs and want to separate clients on VLANs (of course you could put clients into the same VLAN with iPSK+GP but in this use case it does not really apply)
Im currently running a dorm with iPSK+GP. And the way I got round the 50PSK limitation (with GP) was to create a SSID pr. floor. That way Im down to around 30 - 40 GP/PSKs.
But I would really like to try just doing one large VLAN .. like a /22 or /21 and do one SSID with WPN and have clients separated by this. (using around 100 - 200 APs or so).
But I always wonder if it will work 🙂
That was my thought exactly...I had a VLAN for each apartment, with GPs pushing clients to their correct VLAN using PSK. So I thought no need to turn on WPN.
However, the APs acted REALLY strange until I turned WPN on. @AlexanderN says that will be corrected in future updates.
I also had an SSID per floor as a back-up solution pre-configured with 28 PSKs per floor. I was just about to fall back to this method until I said "hey-let's turn WPN on,just to see what happens, even though it's not the correct use case". And BINGO, it worked. One SSID for the whole building 🙂
Yes, iPSK w/o RADIUS scale (50+ iPSK groups) should be available in 29.4. Don't forget that WPN builds on top of iPSK w/o RADIUS.
IPSK w/o RADIUS by itself offers:
No RADIUS dependency = No Complexity (obviously)
Multiple PSKs per a single SSID
Different policies per PSK based on Group Policy
WPN adds automatic L2 segmentation for devices that use different PSKs.
Because of that, make sure that you are OK with that 1) your wireless clients that belong to different iPSK groups cannot communicate with each other and 2) these wireless clients cannot access wired resources on the same VLAN. This is because we use GUE encapsulation, and wired devices cannot make sense of it.
I understand what you are doing @CWK_Rob but be aware of WPN caveats if you are not using WPN for its primary purpose - L2 segmentation b/w iPSK groups to improve the use of discovery protocols like mDNS on shared wireless networks 🙂
One question. How many APs does WPN scale to ?
Can I have 100 ? 200 ? (or more ) APs using it in the same Network / VLAN ?
There is no AP limit. The only limit is 5,000 PSK per SSID and no more than 2x SSIDs per network. However, these are not hard limits but rather documented recommendations. They are not being enforced.
Thanks for the heads up. To get away from the caveats, I'm looking forward to the release of 29.4 so I can turn WPN off. I'm definitely not using it for it's primary purpose, but it's the closest thing I have right now to allow me to use >50 PSKs.
Thank you so much for your insight and a peak behind the Meraki curtain 🙂
>Yes, iPSK w/o RADIUS scale (50+ iPSK groups) should be available in 29.4
When you say "50+" - what kind of scale are you aiming for without RADIUS?
Isn't it so that at each roam/association the AP needs to brute force each PSK to see what key was originally used. So the more PSK's you add the more keys need to be tested to derive the correct keying material?
We have a bit of Meraki magic to make this happen 🙂
iPSK w/o RADIUS + WPN (and soon, iPSK w/o RADIUS w/o WPN) has a brilliant way of handling 1000s of keys. That makes it possible to support 5K PSKs per SSID without string AP CPU.
OK, so for so many PSKs, one of the main hurdles is PMK ID calculation. This is done on the backend and not on the actual devices, which helps offload much of this work from the actual hardware. This and some other tricks make supporting 1000s of PSKs possible.
Oh wow, so you should use this only in areas where people don't roam too much.
So at every roam you need a round trip and a calculation.
If the cloud connection would fail does it stop working or fall back to a local calculation?
Not necessarily. PMK calculation only happens in the backend when a new iPSK group is added. This pre-calculation is always done on the backend and pushed to APs as part of their config.
I'm happy so many of you weighed in. My next deployment is coming in November - This one is a brand-new building with 75 apartments so I'll be using the iPSK model again with full Meraki stack. I'm hoping the next MR release will drop by then, so I can pilot iPSK without WPN.
I'm wondering if I may be finding holes in WPN enabled WITH GP VLAN assignments also enabled.
I'm getting a lot of unanswered DHCP request errors on each of my APs. The only networks that is occurring in is the 2 I have with WPN enabled.
I have a VERY similar network that has only 48 PSKs (So WPN is disabled) and there are virtually NO DHCP request errors.
Are the WPN protocol and DHCP assignment (through GP) fighting, causing a 'double tagging' scenario?
I just found out something about the WPN feature that i DID not know.
GP override VLAN works together with WPN.
Or so it seems from the network i "converted" from multiple SSIDs (because of the 50 iPSK limit) to WPN.
Yeah they did. And I thought they would not, and just use the "SSID configured" VLAN for WPN.
I dont mind, its fine. But I was just surprised.
So Im guessing you could "mix and match" (I have not tested this).
So two different GP (with the same VLAN override setting) and then two different iPSKs on the WPN enabled SSID would not be able to communicate. So you could have a "Group" of different GP (that would not be able to communicate) on VLAN 10 .. and another group of GPs using VLAN20 (that would not be able to communicate) .. on the same SSID ... I dont have a good usecase here ... But I now see WPN as a kind of iPSK scaling.