01-27-2019 05:25 PM
I should probably know this, but I'm unsure at what point devices re-negotiate DHCP when it has already been leased on a cross-campus shared SSID/WPA.
Will it create problems for devices if I have campus A using 192.168.20.0/24, and campus B using 192.168.21.0/24, but sharing the same SSID/wpa key (when devices cross over between the two subnets)?
Apologies if it's a silly Q...
01-27-2019 05:42 PM
Not silly, and yes you may well get complaints in the area of the crossover coverage.
DHCP renew happens when half the DHCP lease expiration time is up. So if you make the lease time pretty short, things might be OK, depending on how many people are in that overlap area. But a short lease time also causes more DHCP traffic and it's attendant impact on the DHCP server and it's logging. May not be a big issue depending on how may clients you are talking about.
"Humans are allergic to change..They love to say, ‘We’ve always done it this way.’ I try to fight that. "Admiral Grace Hopper, USN, Computer Scientist
"It's not Rocket Science! - Oh wait, Actually it is... "NASA bumper sticker
"Just because you can do something doesn't mean you should."my mantra in the Programming classes I used to teach once upon a time...
01-27-2019 06:40 PM - edited 01-27-2019 06:54 PM
I have a similar setup but with three campuses. Same SSIDs with WPA and RADIUS across campuses.
Campus 1 - 10.1.0.1/23
Campus 2 - 10.2.0.1/23
Campus 3 - 10.3.0.1/23
24 hour DHCP lease time and no issues.
The users enjoy connecting as they travel between campuses without having to enter in passwords.
01-27-2019 07:49 PM - edited 01-27-2019 07:51 PM
There should not be an issue as long as there is no seamless roaming possible between campusses, i.e. as long as there are no AP cells of two campuses that overlap. If you now make all campuses use the same subnet for WiFi, then do look into port isolation (UniFi switch term) and possibly client isolation (guest feature on APs) as well to cut down on broadcasts.
If however this is the case, then it depends on the client if it asks for a new IP lease or not. Not really a good plan.
01-27-2019 08:23 PM
Thanks so much for replies...
@eejimm There isn't any physical overlap between campuses... if that was the scenario you had in mind...
I guess I'm unsure at what point devices re-negotiate an IP address when they discover they are on a network with the same SSID/WPA, just a different AP... i.e. whether they would be surprised by having a different subnet...
Put it this way, I know on my home network, if I changed the subnet my router used, I've had devices that would fail to recognize the change, and would neet to be restarted... and I wouldn't want to cause users that kind of grief...
Or let me flip the question, how would you assign subnets when the two campuses are physically distant, have the same SSID's/WPA, and possess distinct public IP's.
sorry if it's much ado about not very much...
01-27-2019 09:40 PM
You shouldn't have any issues with this as each campus will use its own DHCP server. The WiFI credentials being identical help the users to not enter a new password at the second campus, but the device will get a new lease and new IP when connecting at the other campus.
If you had reservations about it, what's the time to travel from one campus to the next? If it's like one hour to travel, set the lease time for one hour. This way even if someone gets a lease on their way out, it'll expire by the time they arrive at the second campus and they'll reconnect.
01-28-2019 01:52 AM - edited 01-28-2019 01:58 AM
This is a very good question.
Recently l was dealing with the issue where the client was roaming between the APs with the same broadcast domain. In my case, the problematic devices were Windows machines. What we notice is that when the client roams, it sends a traditional re-association request, then it gets a response from the AP. All good at this level and it is expected flow.
At this point, because the client does not know if it roamed to the same broadcast domain or not, it has to config this somehow, so it will send DHCP Request asking for the same IP, it will also ARP for its gateway (we could see this in the tcpdump taken from the AP LAN interface ).
We noticed that the traffic was unidirectional, the client was not getting DHCP ACKs or ARP responses (this potentially could be an issue with switches' MAC address table sync). We are still working on this issue.
Don`t blame the device as it`s always doing what you have asked it to do, this is not always the same as what you want.
01-28-2019 07:59 AM
Thanks again for replies...
What I'm hearing is that the best way to address this is through reduced DHCP lease times. In my case, it takes 10 min to travel between campuses, so a lease time of 20 min. To be fair, this activity on the DHCP server seems achievable as this particular subnet only sees a smallish number of clients & intermittent connections.
Can anyone suggest a better way of ensuring device transition remains seamless.
I had contemplated making both campuses use the same subnet, but assigning DHCP to the lower half of the range for one campus, and DHCP to the upper half for the other campus... Not sure if that's a preferable solution though... The biggest immediate issue there is that I'm hoping to join the two networks by IPsec VPN in the future (to allow access to shared files & printing)... Having overlapping subnets seems like a complete headache at best...
Any ideas or suggestions?
01-28-2019 09:34 AM
You could simply use different SSIDs for each campus. If you are using WPA Enterprise you could arrange for them all to share the same credentials. Devices that roam will then need to know about the different SSIDs, but will connect to whichever one they see.
01-28-2019 04:42 PM - edited 01-28-2019 04:56 PM
What is "smallish number of clients" in numbers, and how many APs are there? If it is indeed rather small, then why not establish one single subnet by tunnel, likely with one single DHCP server and a relay? A lease time of only 20 minutes is not desireable for a normal network in my book.
Also: Are you planning on file and printer sharing in the same subnet (WiFi), or would these services only be available in a different subnet (wired LAN), ready for consumption also by the WiFi subnet? Typically you'd prefer to isolate the WiFi clients from each other, at least to some degree.
There is another dirty option, and it is not perfect. Allow me to quote from Reddit:
Expose the other site's IP space: You can do this with a secondary IP address on the router interface that serves the subnet. Keep serving DHCP on the subnet only for the primary IP range. That way someone that walks over can retain connectivity to the gateway they originally were served, but when they renew their DHCP lease and ask for the IP they currently have they'll get a NAK and then go ahead and discover the proper subnet range. You'll have to set this up both ways.
I think that most clients will issue a new DHCP request once their WiFi interface has been down for "long enough" though - however most clients will have a different definition of "long enough" (consider sleep mode, up to hibernation). More recent drivers will likely try to ping the gateway and try to find out if they can phone home, i.e. have Internet access, and they might as well try a new DHCP lease if they find out something ain't right. Other devices might switch from WiFi to 3G/4G during the transition from site A to site B, which makes it even more likely they will request an IP address once they discover the WiFi APs of site B on arrival.
01-28-2019 06:30 PM - edited 01-29-2019 06:37 AM
thx so much@ub40
Smallish numbers of clients in this case would mean a max of 10 clients roaming back & forth 3 times at most. Total number of clients on the subnet would be about 30.
re: file & printer sharing... For now, I have that in a separate subnet from wifi & wifi client isolation is on... That said, I want to leave the option available to switch off client isolation if they decide they want to start sharing resources between client devices. But even with file & printer sharing in a separate subnet, that wouldn't resolve the VPN overlapping subnet problem (would it?)
While I'd love to have a single DHCP server, both sites are on separate electrical grids & tend to have 4hr+ outages at least once a year (not sure the UPS will last). I wouldn't want to risk losing a DHCP server shared across the VPN just because of an outage at the other site...
I'm curious about the dirty option... I'm not quite following it though. Is it suggesting to have one subnet, two DHCP servers serving different ranges & using a secondary IP address on the router interface that will send clients through the VPN to the other gateway if DHCP is unreleased?
& yes, agreed, I'm guessing most devices will re-negotiate DHCP without issues... I'm just trying to think of the odd older devices & not to leave them hanging...
01-30-2019 09:08 AM
Thinking through this issue, would it be right to think the more logical solution might be this:
- use the same subnet for networks that share a SSID
(assigning discreet DHCP pools for each site network that has a different gateway router).
- navigate the difficulty of overlapping subnets on a tunnel for what it is, a difficulty of IPsec tunneling.
Speaking of which, can anyone confirm that the IPsec overlapping networks bug looks like it will get a fix as of version.2.0?