nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

One SSID with multiple subnets and clients roaming between subnets

unknown

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

Find more posts tagged with

Accepted answers

All comments

andrea_coppini

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.

sid_sok

Andrea hit it on the head, and in the right order.

I came from a company that did offer that client tunneling feature (IP mobility I think it was called), but that had it's own issue. A good example of this short coming is if your "home" network is in building A and you roam to building Z and you want to print to a printer in building Z, the print traffic has to traverse all the way back to Building A first then get routed to the printer in building Z. That was a problem for the network admin at the time sine they wanted to keep the building network separate and did not want the building to talk to each other.

They might have changed one or the other, wlan config or network routing policy, to make it work.

Sid

unknown

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

unknown

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.

unknown

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.

unknown

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?

unknown

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