One SSID with multiple subnets and clients roaming between subnets

  • 1
  • Question
  • Updated 2 years ago
  • Answered
I'm making some big changes to the LAN that will affect how our APs and ZoneDirector are configured. I'm at the planning stage so nothing is set in stone yet. This is what I would like, not necessarily what I'll end up doing.

We have a large site, about 200 acres, each building or open area has it's own subnet (about 12 subnets). APs have the ZD's IP set static. The APs get a local management IP address via DHCP and connects back to the ZD over the Layer-3 (routed) network. I'll need to have 3 or 4 SSIDs that ultimately need varying levels of security, I'll call the SSIDs LOW, MID, HIGH, and GUEST. I'd like to keep the number of WLAN subnets down and keep the same vlan on the SSID regardless of which LAN switch it is serviced through.

So two wireless clients who are relatively close and on the same SSID could be in different subnets, this wouldn't be a problem. But if a client roams from one subnet to another it would need to renew it's IP and some of our applications will not survive this. So how do I get around this? I've worked with other products that solve this issue by using L3 tunneling between APs and the controller so the wireless client can retain it's IP even when that subnet isn't directly attached to it's current AP. Of course this add to the LAN traffic on the APs and to the mesh traffic on APs that aren't root. Most of the security would be ACLs not vlans or subnets.

What are my alternatives? Am I over thinking this? Will it tunnel the L3 traffic? Is the extra traffic too little to be concerned with?

 Thoughts?

Thanks
Photo of Randall Cohen

Randall Cohen

  • 8 Posts
  • 0 Reply Likes

Posted 2 years ago

  • 1
Photo of Andrea Coppini

Andrea Coppini

  • 60 Posts
  • 26 Reply Likes
Short answer - don't do it.
Having the same SSID on different VLANs is asking for trouble.  Roaming is always client-driven, so you have no control over when a client will roam and to which AP.  Also, some clients do not renew their IP when they roam from one AP to another within the same SSID.  Remember the client doesn't know it's switching VLANs, so it assumes it's still good to go on its old IP.

You have a couple of options (in order of my preference):
a) Reconfigure your wired LAN to have a flat VLAN for WiFi throughout the entire property.  Management of the APs can be on different VLANs, but the WiFi clients would all be on the same VLAN irrespective of which switch they are on.

b) tunnel - as you mentioned, the solution is usually to tunnel all traffic back to the controller.  The main bottleneck here will be the controller itself, since the ZD only uses a single Gigabit port for all traffic - effectively giving you about 500Mbps of total bandwidth throughout your LAN*.

c) use different SSIDs on each VLAN.  Clients will need to switch SSIDs as they move through the campus.

d) Enable 'Force DHCP' on the VLANs.  This will mean that a client will be kicked out if it doesn't send a DHCP request within X seconds of joining/roaming an AP.  Not the cleanest and some clients don't like to be kicked out.

*  If this is your only/preferred option and you need more than 500Mbps of throughput, you may wish to consider migrating to a SZ-124 which has two 10Gbps SFP+ ports dedicated to tunnelling.
Photo of Sean

Sean

  • 342 Posts
  • 87 Reply Likes
In refrence to
d) Enable 'Force DHCP' on the VLANs.  This will mean that a client will be kicked out if it doesn't send a DHCP request within X seconds of joining/roaming an AP.  Not the cleanest and some clients don't like to be kicked out.
Be careful as there is a bug with Force DHCP which stops internet tarffic to clients when they roam between AP's on 9.10.1.0.59 firmware and upwards, and has yet to be fixed (I have a case open with Ruckus Support)

Have you thought about 1 x SSID and Dynamic VLANs:

https://support.ruckuswireless.com/answers/000001989
(Edited)
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
I think Randall is talking about the kind of network w/ routed connections between each building, where the same subnets are not available in all buildings.

If that's the case, Dynamic VLANS (by themselves) will not be able to solve the problem.
Photo of Sean

Sean

  • 342 Posts
  • 87 Reply Likes
@ Bill: He is asking for alternatives.

If you want to apply group security and be able to roam between buildings with application survivability, then Dynamic VLANs is the best option in my opinion.

Then you can control who gets access to what and where by means of Radius config.
(Edited)
Photo of JC Jordan

JC Jordan

  • 1 Post
  • 0 Reply Likes
@Sean

Do you have a case number you can share for the Force DHCP issue?  We've been experiencing the issue as well and have not gotten a clear response from Ruckus.
Photo of Sean

Sean

  • 342 Posts
  • 87 Reply Likes
I cant share case numbers unfortunately as we had an NDA with Ruckus, but realise that we are chasing and they are working on it.
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
I don't use tunneling w/ Ruckus but that may be what you need to solve your problem.

Some other (non Ruckus) Wireless Controller based solutions tunnel *all* traffic back to the controller in order to avoid the problem you're experiencing.
That way, all your wireless VLANs are able to exist in all locations.
(and you don't end up w/ the "DHCP" problem where you end up using the wrong IP in the wrong building/subnet)

Without doing any investigation:
(so don't take my word on this)
Tunneling may not be compatible w/ Ruckus Mesh.
So, if you use Mesh anywhere and you plan to use tunneling to solve your problem, you need to confirm that you can Tunnel and Mesh traffic to/from an AP.

Also:
If you've got limited bandwidth on the routed connections between your buildings, you need to watch out for the problem that Sid is describing, as this will force all WiFi traffic to be tunneled out of the building you're in (over a limited bandwidth connection?) only to be routed right back over the same link to reach a wired device in the same building.

This is a big problem when multi-building school districts tunnel traffic back to one centralized wireless controller. It works fine for internet access, but whenever wireless devices try to access local servers (at high bandwidth) it causes the WAN connections to get clogged and breaks the network.

If that ("incompatibility" w/ limited bandwidth) is a show stopper for you, then tunneling is not your solution.
Photo of David Henderson

David Henderson

  • 85 Posts
  • 13 Reply Likes
The first option mentioned above is
a) Reconfigure your wired LAN to have a flat VLAN for WiFi throughout the entire property.  Management of the APs can be on different VLANs, but the WiFi clients would all be on the same VLAN irrespective of which switch they are on.

This will certainly allow client to roam since wifi is one big flat network. What if you have a few thousand clients though, wouldn't a single vlan of this size be a problem with broadcast and multicast traffic?
Photo of Randall Cohen

Randall Cohen

  • 8 Posts
  • 0 Reply Likes
Thanks for all the info, here's what I'm going with.

For a number of reasons I can't flatten the entire network. One of the SSID is already tunneling so I'll expand that. I also don't have a problem with all the communications coming back to one site, none of the wireless devices interact with anything on the building subnets. Our in-house applications aren't bandwidth intensive so even that won't be an issue. Guest/Internet might use a lot of bandwidth so I'll limit that in order to keep our primary apps working. Eventually I'm hoping to move up to something with a 10G port but for now this will work.

Thanks again