Overlapping SSID in multioccupancy building

[Lorenzo2]

I have two separate departments of the same organisation on adjacent floors using the same SSID.

Depending on physical location the SSID of the adjacent floor is picked up, which incidentally uses a different IP range.

I can not change the SSID name as its provided by an external orga

nisation.

Is there a mechanism block the broadcast of the SSID from an AP on the adjacent floor or is manipulation of RF the only option?

I don't think Air Marshall can do anything in this situation.

Look forward to any suggestions.

Thank-you.

[mloraditch · Accepted solution]

You would need to adjust RF.

Normally I would want the same SSID in the same building to share the same VLAN handoff for these situations but if that's not possible for whatever reason you are stuck with trying to tune the RF to prevent bleedthrough.

[BrandonD1]

Hi Lorenzo,

I tend to agree with @mloraditch on this one, the design is unfortunate but I understand it sounds like you are limited to adjustments at this time.

That being said, I just wanted to touch on Air Marshall, as we do support the ability to 'Contain' SSIDs however this is typically designed around environments with potential Rouge APs that are not owned by the organization.

This feature works by sending deauthentication packets with the spoofed MAC address of the rogue access point (the BSSID of the rogue wireless network). The deauthentication packets force any clients that are connected to the rogue access point to disconnect (but does not affect coverage/roaming from a client perspective.)

If a client attempts to connect to the rogue network, they will be immediately forced off by the Air Marshal. More on this in the below article:

https://documentation.meraki.com/MR/Monitoring_and_Reporting/Air_Marshal#Overview_of_Air_Marshal_Containment

• Warning: Care should be taken when configuring SSID block list policies as these policies will apply to SSIDs seen on the LAN as well as off of the LAN from neighboring WiFi deployments.
• Containment can have legal implications when launched against neighbor networks, and it may harm your own network by increasing channel utilization and potential disrupt clients connecting to your APs. Ensure that the rogue device is within your network and poses a security risk before you launch the containment.

The only other potential solution outside of an SSID change or coverage adjustments would be an additional authentication such as RADIUS on both SSIDs to prevent association unless allow listed on the RADIUS server - such as below:

https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_with_WPA2-Enterprise#Add_APs_as_RADIUS_Clients_on_the_NPS_Server

[Philip D'Ath]

Are all the MRs (both departments) in the same org? Do you have "Admin" access to the Meraki Dashboard, even if you are not allowed to change the SSID?

If so, try creating a radio profile for the MRs so clients on different floors are less likely to attach. These are some pretty safe values.

https://documentation.meraki.com/MR/Radio_Settings/RF_Profiles

Failing that, you could consider enabling L3 roaming which allows people to roam between APs that give users different IP addresses.

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MR_Wireless/Wireless_Layer_3_Roaming_Best_Practices

[Lorenzo2]

Unfortunately, they are separate departments of the same public organisation that consume the same external authentication service provided to all public organisation. The irony is bit we're using meraki and coexisting before one changed vendor and I suspect probably went to WIFI 6.

Thank you to all who replied I really appreciate you taking the time to reply and share your knowledge and experience 🙏