1 SSID with Multiple VLANs = Roaming?

Solved
Yan_Greben
Conversationalist

1 SSID with Multiple VLANs = Roaming?

Hi all,

We have a scenario where we want to assign multiple VLANs to 1 SSID by way of segmenting the AP's through AP tags.

 

For the sake of simplicity, let's say we have 1st Floor, 2nd Floor, and 3rd Floor AP tags each assigned to VLANs 10, 20, and 30, respectively.

 

My question is: What happens when a client device physically moves from the 1st floor to the 2nd floor and wants to roam to a 2nd floor AP?

 

From my understanding, my device will now have an IP address in the subnet associated with VLAN 10 while having all of its traffic tagged with VLAN 20.

 

Appreciate any help/insight 🙂



(assume the appropriate VLANs are allowed on the switch ports)

1 Accepted Solution
Ryan_Miles
Meraki Employee
Meraki Employee

In your example a client first connecting on floor 1 would get an IP from VLAN 10. When the client roams to 2 or 3 they would associate to an AP on those floors while maintaining their VLAN 10 IP. This is accomplished by a dynamically created AP to AP tunnel. This is with using Client IP Assignment type of "Layer 3 Roaming".

 

This is assuming the switchports connected to the floor 2 & 3 APs DON'T have the 1st floor VLAN on the trunk port. If the trunk ports contain VLAN 10 the client would still remain on VLAN 10, but without the need for an AP to AP tunnel to be created and they would simply join the new AP.

 

This is a nuance of our distributed layer 3 roaming folks often overlook in that a VLAN check occurs and based on presence of the client VLAN on the upstream switchport the roam could be a simple L2 roam or a tunneled L3 roam.

 

It's outlined in great detail here

 

There's also a large building example in the doc based on a deployment I did some years back.

 

I also created a simplified version of this example.

View solution in original post

9 Replies 9
KarstenI
Kind of a big deal
Kind of a big deal

the wireless roaming process in independent of the DHCP process. After the roam the PC has first to realise that the IP config has changed and then do a new DHCP. Your users won't like the IP department with this approach.

Better to configure anything where the IP stays the same:

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

Ryan_Miles
Meraki Employee
Meraki Employee

In your example a client first connecting on floor 1 would get an IP from VLAN 10. When the client roams to 2 or 3 they would associate to an AP on those floors while maintaining their VLAN 10 IP. This is accomplished by a dynamically created AP to AP tunnel. This is with using Client IP Assignment type of "Layer 3 Roaming".

 

This is assuming the switchports connected to the floor 2 & 3 APs DON'T have the 1st floor VLAN on the trunk port. If the trunk ports contain VLAN 10 the client would still remain on VLAN 10, but without the need for an AP to AP tunnel to be created and they would simply join the new AP.

 

This is a nuance of our distributed layer 3 roaming folks often overlook in that a VLAN check occurs and based on presence of the client VLAN on the upstream switchport the roam could be a simple L2 roam or a tunneled L3 roam.

 

It's outlined in great detail here

 

There's also a large building example in the doc based on a deployment I did some years back.

 

I also created a simplified version of this example.

Yan_Greben
Conversationalist

Thank you to you both for the answers!!

Rymiles, really appreciate the additional detail and examples 🙂 

Looks like I have some reading to do!

GreenMan
Meraki Employee
Meraki Employee

Is there a particular reason why you want to map the different floors to different VLANs?   It's generally simpler (& you know how we love simple!) just to provide a common VLAN to all the switches - and then use Layer-2 roaming alone.  Remember that, if you're only placing wireless clients in that VLAN (recommended) and you're enabling Layer-2 isolation, the usual concerns about the size of a broadcast domain, from needing (say) a /23 or /22 subnet, to handle your client base, are not so acute.

 

https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/Wireless_Client_Isolation

The floors visualization was just for simplicity's sake to ask my question 🙂 

In reality, it's an option we were considering for a set of devices, (AV, IOT, etc.), and I wanted to better understand the details of how multiple VLANs on one SSID would work.

In our particular scenario, we created separate SSID's, but I was curious about other options if that was not desirable.

So are you saying that we could have a large campus on let's say a /16 with hundreds if not thousands of devices, but if we use L2 isolation we would not have the types of broadcast issues if there was not any L2 isolation?

 

I find this discussion very interesting and I want to start testing in my lab.

 

Woah there!   I chose my masks carefully...   /23 =  c. 500 clients   /22 = c. 1,000 clients.   = basically doable (think:  short DHCP leases)  but /16 = > 65,000 clients!     That's a big jump and not one I'd recommend.   But there are certainly advantages if you can stick to layer-2 roaming.   One thing to bear in mind - unless you have contiguous coverage between buildings on a campus (i.e. outdoor APs etc.) then clients are not even going to need Layer-2 roaming everywhere, as they won't remain associated between buildings anyway.  It's also much less likely to be manageable to extend the same VLAN between buildings on a campus.   The analogy comparing floors in the same building with different buildings on a campus isn't necessarily the best, unfortunately.   Mind you;  even in a building, maintaining coverage between floors can be a significant challenge anyway (stairwells and lift shafts are difficult and expensive to fully cover).   All these things make a difference.

Given what you said about l2 isolation. It seems like all size subnets should work. Can you help me understand better please?

 

L2 isolation doesn't prevent broadcasts and multicasts from being generated.   Proxy ARP within broadcast suppression will help with this, to some degree and client devices are generally better these days at handling resultant traffic in some volume than previously, but not to the level of a /16 subnet, I would think.

https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Broadcast_Suppression_and_Control...

 

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