Meraki wireless VLAN assignment options

SOLVED
Walter2020
Comes here often

Meraki wireless VLAN assignment options

Hi there,

 

I have a challenge I am sure someone here can help with! I have a customer with about 50 multi-tenanted sites. Each site can have between 20-30 tenant groups and so this becomes a problem with the 15 SSID limit in Meraki.

 

One idea I have to get around this limit is to publish one SSID for all tenants and then assign them into VLANs based on tenant identity. This may be one shared identity between all tenants in one tenant group and then using a RADIUS-based solution ( such as ISE, Packetfence, MS NPS) to assign the tenant users into their correct VLAN.

 

There are a few constraints though. The solution must be easy to manage as the customer does not have a large technical staff and might rely on non-technical staff to provision new tenants.

 

The other is that customers will need to be set up in a new directory scheme, so there is no LDAP or AD to integrate with, unless we set up new users on there.

 

We also need to deploy the authentication solution either in the cloud, for example Azure or the main HQ site, which will be connected via VPN.

 

Then we ideally need to have a default fallback position if the local site cannot talk to the authentication solution, for example if the VPN goes down.

 

I hope this makes sense and apologies it this is a bit of a ramble! Thanks in advance for all replies.

1 ACCEPTED SOLUTION
PhilipDAth
Kind of a big deal
Kind of a big deal

Definately use a single SSID.

 

Using more than about 4 SSIDs is not good.  The beacons use up a lot of the air time substantially reducing what is left for sending actual data.  This results in bad throughput.

 

If you don't mind setting up each client in the Meraki Dashboard once, you can use a group policy (one per client) and and a VLAN tag.

https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/VLAN_Tagging

 

You can also use RADIUS to dynamically assign a group policy using the Filter-Id attribute.

https://documentation.meraki.com/MR/Group_Policies_and_Blacklisting/Using_RADIUS_Attributes_to_Apply...

 

 

There are seperate third party solutions that do this like Splash Access.

https://www.splashaccess.com/co-working-office/

 

View solution in original post

9 REPLIES 9
PhilipDAth
Kind of a big deal
Kind of a big deal

Definately use a single SSID.

 

Using more than about 4 SSIDs is not good.  The beacons use up a lot of the air time substantially reducing what is left for sending actual data.  This results in bad throughput.

 

If you don't mind setting up each client in the Meraki Dashboard once, you can use a group policy (one per client) and and a VLAN tag.

https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/VLAN_Tagging

 

You can also use RADIUS to dynamically assign a group policy using the Filter-Id attribute.

https://documentation.meraki.com/MR/Group_Policies_and_Blacklisting/Using_RADIUS_Attributes_to_Apply...

 

 

There are seperate third party solutions that do this like Splash Access.

https://www.splashaccess.com/co-working-office/

 

Many thanks for your reply, this is the confirmation I needed. Although the first two options you mentioned will work for us I have looked at Splash Access and it seems like a better fit for this requirement. Has anyone here any experience with it?

I haven't used this specific service of Splash Access, but I have many customers using some of their other services (their Retail guest WiFi servcies are really good).

 

They are amazing to deal with I I happily recommend them.

Many thanks for the confirmation about Splash Access, I will get a trial in place.

Agreed, that a network supporting all speeds will be beholden to these restrictions. Meraki documentation expands on some of the considerations: https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Multi-SSID_Deployment_Considerati...

 

A minor point of clarification to the general rule of thumb: the formula depends on multiple variables:

  1. The number of SSIDs
  2. The number of APs on that channel (each SSID on that channel counts as an AP)
  3. The beacon data rate

 

If you are inclined to engineer a little further, adjusting any of the three can provide relief for the other two. Eliminating support for 802.11b data rates can free up a significant amount of RF duty cycle on that channel. The table on the website below paints a grim picture, but please note that it references 802.11b 1Mbps data rates. Downloading the spreadsheet and changing it to 802.11g 12 Mbps yields a radically different result.

 

http://www.revolutionwifi.net/revolutionwifi/p/ssid-overhead-calculator.html

 

Screen Shot 2019-07-29 at 10.02.09 AM.png

 

PhilipDAth
Kind of a big deal
Kind of a big deal

>The number of APs on that channel

 

And to build on @JonH 's excellent answer, these don't even have to be your APs.  They can be APs from other nearby offices.

Walter2020
Comes here often

This is good information, thanks!

Hi Philip!

Do know what's the RADIUS attribute (RADIUS VSA Name/
Attribute Type) and vendor ID for Meraki MR as RADIUS client (authenticator )?
PhilipDAth
Kind of a big deal
Kind of a big deal


@AhmedK wrote:
Hi Philip!

Do know what's the RADIUS attribute (RADIUS VSA Name/
Attribute Type) and vendor ID for Meraki MR as RADIUS client (authenticator )?

 

No sorry.  Never needed to use these fields in a RADIUS server.  I only ever use the standard RADIUS attributes.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels