APs from different vendors give out IP addresses in vastly different ranges - roaming affected negatively?How...
Memory usage: #define vs. static const for uint8_t
Is there a way to store 9th-level spells in a Glyph of Warding or similar method?
Renting a 2CV in France
Non-Cancer terminal illness that can affect young (age 10-13) girls?
Boss asked me to sign a resignation paper without a date on it along with my new contract
If angels and devils are the same species, why would their mortal offspring appear physically different?
Converting very wide logos to square formats
In harmony: key or the flow?
Microtypography protrusion with Polish quotation marks
How can the probability of a fumble decrease linearly with more dice?
Why do all the books in Game of Thrones library have their covers facing the back of the shelf?
Does it take energy to move something in a circle?
Translation needed for 130 years old church document
How to politely refuse in-office gym instructor for steroids and protein
How to not let the Identify spell spoil everything?
Why do neural networks need so many training examples to perform?
Why avoid shared user accounts?
Prevent Nautilus / Nemo from creating .Trash-1000 folder in mounted devices
Taking headphones when quitting job
Coworker asking me to not bring cakes due to self control issue. What should I do?
When obtaining gender reassignment/plastic surgery overseas, is an emergency travel document required to return home?
Is there a file that always exists and a 'normal' user can't lstat it?
Single-row INSERT...SELECT much slower than separate SELECT
What is a good reason for every spaceship to carry a weapon on board?
APs from different vendors give out IP addresses in vastly different ranges - roaming affected negatively?
How can I get the same SSID for multiple access points?ADSL Modem/Router sometimes hands out incorrect IP addressesOne static IP for each host in Hyper-VVlan with multiple switchesRouter handles wrong IP addressCisco 2504 WLC setup questionsConfiguring VLANs/IP network for security and performanceVLAN: Cannot connect to internet via AP modeHow many routers do I need to support 3 vlans over a single ethernet connectionNo internet when obtaining IP address automatically(static works) with HP 1910-8 switchNetgear ProSafe with Cisco Aironet - Guest VLAN no Internet
In his encyclopedic answer here, @Spiff touches upon a ton of wireless access point issues, but not the ONE detail I'm looking for!
I'm supporting a pre-Cisco buy-out Meraki wireless network that gives every guest an account in the 10.x.y.z scope, which is awesome. The internal addresses for the Merakis were all on our main 192.168.168.x scope, but because of their guest configuration, it was never an issue.
However, I've finally come up empty trying to find replacements on ebay, and finally broke down and bought a few similarly priced TP-Link APs. Put one on the same switch, configured it to have the same security and SSID. Turns out that while they are as unmanaged as the Merakis, they aren't as smart, and immediately started putting customers phones directly on our main network 192.168.168.x. (To be clear, they defaulted to using the only DHCP server available, THE server, which had only the one scope to put the guests on. Not a misconfiguration on TP-Link's part, just a different (albeit worse) default configuration than the Merakis. The TP-Link solution is to purchase a TP-Link L3 switch that can create VLANs by itself.)
I head to the server and SonicWall interfaces to figure out how to put all of the wireless gear on their very own VLAN. A few days and much head- (and butt-)scratching later, all of the Meraki APs and the tester TP-Link AP are on new VLAN, on a new DHCP scope, handed out by the SonicWall firewall, so they all have internally facing 192.168.2.x. However, clients connected to the Merakis are getting 10.x.y.z IP addresses, and the TP-Links are deferring to the SonicWall, which gives out 192.168.2.x addresses to guests.
TO THE QUESTIONS, AT LONG LAST: I assume that when a guest is roaming over the Meraki network between various APs, they maintain the same IP address.
- Will that roaming still work between such different make and model APs?
- If so, will the massively different IP addresses for the guests either a) slow down the handoff, or b) create browsing issues?
At the end of the day, all of the traffic to the internet is coming out of the same external IP address on the SonicWall, so an external server shouldn't necessarily be noticing them changing IP addresses...
The long-term goal IS to replace the Merakis as they die, so this doesn't need to be a forever solution.
Edit to add: I don't see any way to change the default Meraki behavior of using the 10.0.0.0/8 address pool for clients, and I'd apparently need to buy the aforementioned TP-Link L3 switch to also be able to manage them and what addresses they hand out. But even there, I'd don't know that I'd have a solid way to reserve a chunk of the 10.0.0.0/8 addresses to avoid conflicts with the Merakis.
networking wireless-access-point
asked Feb 22 at 22:09
Dustin KreidlerDustin Kreidler
1013
add a comment |
In his encyclopedic answer here, @Spiff touches upon a ton of wireless access point issues, but not the ONE detail I'm looking for!
I'm supporting a pre-Cisco buy-out Meraki wireless network that gives every guest an account in the 10.x.y.z scope, which is awesome. The internal addresses for the Merakis were all on our main 192.168.168.x scope, but because of their guest configuration, it was never an issue.
However, I've finally come up empty trying to find replacements on ebay, and finally broke down and bought a few similarly priced TP-Link APs. Put one on the same switch, configured it to have the same security and SSID. Turns out that while they are as unmanaged as the Merakis, they aren't as smart, and immediately started putting customers phones directly on our main network 192.168.168.x. (To be clear, they defaulted to using the only DHCP server available, THE server, which had only the one scope to put the guests on. Not a misconfiguration on TP-Link's part, just a different (albeit worse) default configuration than the Merakis. The TP-Link solution is to purchase a TP-Link L3 switch that can create VLANs by itself.)
I head to the server and SonicWall interfaces to figure out how to put all of the wireless gear on their very own VLAN. A few days and much head- (and butt-)scratching later, all of the Meraki APs and the tester TP-Link AP are on new VLAN, on a new DHCP scope, handed out by the SonicWall firewall, so they all have internally facing 192.168.2.x. However, clients connected to the Merakis are getting 10.x.y.z IP addresses, and the TP-Links are deferring to the SonicWall, which gives out 192.168.2.x addresses to guests.
TO THE QUESTIONS, AT LONG LAST: I assume that when a guest is roaming over the Meraki network between various APs, they maintain the same IP address.
- Will that roaming still work between such different make and model APs?
- If so, will the massively different IP addresses for the guests either a) slow down the handoff, or b) create browsing issues?
At the end of the day, all of the traffic to the internet is coming out of the same external IP address on the SonicWall, so an external server shouldn't necessarily be noticing them changing IP addresses...
The long-term goal IS to replace the Merakis as they die, so this doesn't need to be a forever solution.
Edit to add: I don't see any way to change the default Meraki behavior of using the 10.0.0.0/8 address pool for clients, and I'd apparently need to buy the aforementioned TP-Link L3 switch to also be able to manage them and what addresses they hand out. But even there, I'd don't know that I'd have a solid way to reserve a chunk of the 10.0.0.0/8 addresses to avoid conflicts with the Merakis.
networking wireless-access-point
asked Feb 22 at 22:09
Dustin KreidlerDustin Kreidler
1013
2
The problem is not that their IP addresses are different but that they're in different VLANs. It makes no difference what IP addresses they have, but if they are in different VLANs, then roaming can't work.
– David Schwartz
Feb 22 at 22:21
add a comment |
In his encyclopedic answer here, @Spiff touches upon a ton of wireless access point issues, but not the ONE detail I'm looking for!
I'm supporting a pre-Cisco buy-out Meraki wireless network that gives every guest an account in the 10.x.y.z scope, which is awesome. The internal addresses for the Merakis were all on our main 192.168.168.x scope, but because of their guest configuration, it was never an issue.
However, I've finally come up empty trying to find replacements on ebay, and finally broke down and bought a few similarly priced TP-Link APs. Put one on the same switch, configured it to have the same security and SSID. Turns out that while they are as unmanaged as the Merakis, they aren't as smart, and immediately started putting customers phones directly on our main network 192.168.168.x. (To be clear, they defaulted to using the only DHCP server available, THE server, which had only the one scope to put the guests on. Not a misconfiguration on TP-Link's part, just a different (albeit worse) default configuration than the Merakis. The TP-Link solution is to purchase a TP-Link L3 switch that can create VLANs by itself.)
I head to the server and SonicWall interfaces to figure out how to put all of the wireless gear on their very own VLAN. A few days and much head- (and butt-)scratching later, all of the Meraki APs and the tester TP-Link AP are on new VLAN, on a new DHCP scope, handed out by the SonicWall firewall, so they all have internally facing 192.168.2.x. However, clients connected to the Merakis are getting 10.x.y.z IP addresses, and the TP-Links are deferring to the SonicWall, which gives out 192.168.2.x addresses to guests.
TO THE QUESTIONS, AT LONG LAST: I assume that when a guest is roaming over the Meraki network between various APs, they maintain the same IP address.
- Will that roaming still work between such different make and model APs?
- If so, will the massively different IP addresses for the guests either a) slow down the handoff, or b) create browsing issues?
At the end of the day, all of the traffic to the internet is coming out of the same external IP address on the SonicWall, so an external server shouldn't necessarily be noticing them changing IP addresses...
The long-term goal IS to replace the Merakis as they die, so this doesn't need to be a forever solution.
Edit to add: I don't see any way to change the default Meraki behavior of using the 10.0.0.0/8 address pool for clients, and I'd apparently need to buy the aforementioned TP-Link L3 switch to also be able to manage them and what addresses they hand out. But even there, I'd don't know that I'd have a solid way to reserve a chunk of the 10.0.0.0/8 addresses to avoid conflicts with the Merakis.
networking wireless-access-point
asked Feb 22 at 22:09
Dustin KreidlerDustin Kreidler
1013
In his encyclopedic answer here, @Spiff touches upon a ton of wireless access point issues, but not the ONE detail I'm looking for!
I'm supporting a pre-Cisco buy-out Meraki wireless network that gives every guest an account in the 10.x.y.z scope, which is awesome. The internal addresses for the Merakis were all on our main 192.168.168.x scope, but because of their guest configuration, it was never an issue.
However, I've finally come up empty trying to find replacements on ebay, and finally broke down and bought a few similarly priced TP-Link APs. Put one on the same switch, configured it to have the same security and SSID. Turns out that while they are as unmanaged as the Merakis, they aren't as smart, and immediately started putting customers phones directly on our main network 192.168.168.x. (To be clear, they defaulted to using the only DHCP server available, THE server, which had only the one scope to put the guests on. Not a misconfiguration on TP-Link's part, just a different (albeit worse) default configuration than the Merakis. The TP-Link solution is to purchase a TP-Link L3 switch that can create VLANs by itself.)
I head to the server and SonicWall interfaces to figure out how to put all of the wireless gear on their very own VLAN. A few days and much head- (and butt-)scratching later, all of the Meraki APs and the tester TP-Link AP are on new VLAN, on a new DHCP scope, handed out by the SonicWall firewall, so they all have internally facing 192.168.2.x. However, clients connected to the Merakis are getting 10.x.y.z IP addresses, and the TP-Links are deferring to the SonicWall, which gives out 192.168.2.x addresses to guests.
TO THE QUESTIONS, AT LONG LAST: I assume that when a guest is roaming over the Meraki network between various APs, they maintain the same IP address.
- Will that roaming still work between such different make and model APs?
- If so, will the massively different IP addresses for the guests either a) slow down the handoff, or b) create browsing issues?
At the end of the day, all of the traffic to the internet is coming out of the same external IP address on the SonicWall, so an external server shouldn't necessarily be noticing them changing IP addresses...
The long-term goal IS to replace the Merakis as they die, so this doesn't need to be a forever solution.
Edit to add: I don't see any way to change the default Meraki behavior of using the 10.0.0.0/8 address pool for clients, and I'd apparently need to buy the aforementioned TP-Link L3 switch to also be able to manage them and what addresses they hand out. But even there, I'd don't know that I'd have a solid way to reserve a chunk of the 10.0.0.0/8 addresses to avoid conflicts with the Merakis.
networking wireless-access-point
networking wireless-access-point
asked Feb 22 at 22:09
Dustin KreidlerDustin Kreidler
1013
asked Feb 22 at 22:09
Dustin KreidlerDustin Kreidler
1013
edited 6 hours ago
Dustin Kreidler
asked Feb 22 at 22:09
Dustin KreidlerDustin Kreidler
1013
asked Feb 22 at 22:09
Dustin KreidlerDustin Kreidler
1013
asked Feb 22 at 22:09
Dustin KreidlerDustin Kreidler
1013
1013
2
The problem is not that their IP addresses are different but that they're in different VLANs. It makes no difference what IP addresses they have, but if they are in different VLANs, then roaming can't work.
– David Schwartz
Feb 22 at 22:21
add a comment |
2
The problem is not that their IP addresses are different but that they're in different VLANs. It makes no difference what IP addresses they have, but if they are in different VLANs, then roaming can't work.
– David Schwartz
Feb 22 at 22:21
2
2
The problem is not that their IP addresses are different but that they're in different VLANs. It makes no difference what IP addresses they have, but if they are in different VLANs, then roaming can't work.
– David Schwartz
Feb 22 at 22:21
The problem is not that their IP addresses are different but that they're in different VLANs. It makes no difference what IP addresses they have, but if they are in different VLANs, then roaming can't work.
– David Schwartz
Feb 22 at 22:21
add a comment |
2 Answers
2
active
oldest
votes
You would need really really short lease times. Better is to configure things appropriately.
You should be able to terminate all of the APs uplinks at a switch (or two) and have them all talking among themselves, plug the switches into a router of some sort, one side on your "private" LAN and one side on the wireless network, and have it run its own DHCP server on the wireless network side. Really trivial to set up using a old machine with 2 NICs running Linux.
BUT ... you should be aware that just NATing out the guest network through your regular internal LAN, if a guest user knows an IP (or range) they could conceivably connect. Better to use said router above and have the "outside" leg end up in your DMZ or other place on the "edge" of your network, so it is truly "outside" of your internal LAN.
answered Feb 22 at 22:16
ivanivanivanivan
1,25427
Added some clarifications in the third paragraph, and an addendum at the end.
– Dustin Kreidler
6 hours ago
add a comment |
Wi-Fi clients generally expect that all in-range APs publishing the same network name (SSID) will be transparently bridging their traffic onto the same Ethernet [V]LAN, and thus the same IP subnet with the same router and same DHCP server.
If I've read your Question correctly, it sounds like you've got a situation where you have a single guest network SSID, but depending on which AP the client roams to (Meraki vs. TP-Link), it's actually a different [V]LAN underneath with a different valid IP subnet and a different NAPT gateway. This will definitely cause roaming problems of various kinds for your clients.
Some rudimentary clients may not realize their need to double-check their DHCP lease via DNAv4 or other means, and just end up in a broken state where they have Wi-Fi link up but don't have a valid IP address that lets them get anywhere. Users of such clients will likely need to turn their Wi-Fi interface off and back on, or do something else to force a DHCP renewal.
More reasonable clients will use DNAv4 or other means to check their DHCP lease, realize they were lied to and now they're on a different network after all, and proceed to get a new DHCP lease on the new subnet. Not only will this slow down roaming, it will also cause all established connections to drop. So you just lost all your SSH sessions, your big in-progress downloads, your VoIP calls, your video streams, your fileserver mounts, your online game sessions, etc.
I don't know the limitations of your old-school Meraki APs, but my best advice to you is to make it so that all of the APs publishing the guest SSID are all simply transparently bridging that traffic onto a single guest VLAN with a single subnet, a single NAPT gateway router, and a single DHCP server.
answered Feb 22 at 23:59
SpiffSpiff
77.7k10118163
Added some clarifications in the third paragraph, and an addendum at the end, if that helps.
– Dustin Kreidler
6 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1408629%2faps-from-different-vendors-give-out-ip-addresses-in-vastly-different-ranges-ro%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
You would need really really short lease times. Better is to configure things appropriately.
You should be able to terminate all of the APs uplinks at a switch (or two) and have them all talking among themselves, plug the switches into a router of some sort, one side on your "private" LAN and one side on the wireless network, and have it run its own DHCP server on the wireless network side. Really trivial to set up using a old machine with 2 NICs running Linux.
BUT ... you should be aware that just NATing out the guest network through your regular internal LAN, if a guest user knows an IP (or range) they could conceivably connect. Better to use said router above and have the "outside" leg end up in your DMZ or other place on the "edge" of your network, so it is truly "outside" of your internal LAN.
answered Feb 22 at 22:16
ivanivanivanivan
1,25427
Added some clarifications in the third paragraph, and an addendum at the end.
– Dustin Kreidler
6 hours ago
add a comment |
You would need really really short lease times. Better is to configure things appropriately.
You should be able to terminate all of the APs uplinks at a switch (or two) and have them all talking among themselves, plug the switches into a router of some sort, one side on your "private" LAN and one side on the wireless network, and have it run its own DHCP server on the wireless network side. Really trivial to set up using a old machine with 2 NICs running Linux.
BUT ... you should be aware that just NATing out the guest network through your regular internal LAN, if a guest user knows an IP (or range) they could conceivably connect. Better to use said router above and have the "outside" leg end up in your DMZ or other place on the "edge" of your network, so it is truly "outside" of your internal LAN.
answered Feb 22 at 22:16
ivanivanivanivan
1,25427
Added some clarifications in the third paragraph, and an addendum at the end.
– Dustin Kreidler
6 hours ago
add a comment |
You would need really really short lease times. Better is to configure things appropriately.
You should be able to terminate all of the APs uplinks at a switch (or two) and have them all talking among themselves, plug the switches into a router of some sort, one side on your "private" LAN and one side on the wireless network, and have it run its own DHCP server on the wireless network side. Really trivial to set up using a old machine with 2 NICs running Linux.
BUT ... you should be aware that just NATing out the guest network through your regular internal LAN, if a guest user knows an IP (or range) they could conceivably connect. Better to use said router above and have the "outside" leg end up in your DMZ or other place on the "edge" of your network, so it is truly "outside" of your internal LAN.
answered Feb 22 at 22:16
ivanivanivanivan
1,25427
You would need really really short lease times. Better is to configure things appropriately.
You should be able to terminate all of the APs uplinks at a switch (or two) and have them all talking among themselves, plug the switches into a router of some sort, one side on your "private" LAN and one side on the wireless network, and have it run its own DHCP server on the wireless network side. Really trivial to set up using a old machine with 2 NICs running Linux.
BUT ... you should be aware that just NATing out the guest network through your regular internal LAN, if a guest user knows an IP (or range) they could conceivably connect. Better to use said router above and have the "outside" leg end up in your DMZ or other place on the "edge" of your network, so it is truly "outside" of your internal LAN.
answered Feb 22 at 22:16
ivanivanivanivan
1,25427
answered Feb 22 at 22:16
ivanivanivanivan
1,25427
answered Feb 22 at 22:16
ivanivanivanivan
1,25427
answered Feb 22 at 22:16
ivanivanivanivan
1,25427
1,25427
Added some clarifications in the third paragraph, and an addendum at the end.
– Dustin Kreidler
6 hours ago
add a comment |
Added some clarifications in the third paragraph, and an addendum at the end.
– Dustin Kreidler
6 hours ago
Added some clarifications in the third paragraph, and an addendum at the end.
– Dustin Kreidler
6 hours ago
Added some clarifications in the third paragraph, and an addendum at the end.
– Dustin Kreidler
6 hours ago
add a comment |
Wi-Fi clients generally expect that all in-range APs publishing the same network name (SSID) will be transparently bridging their traffic onto the same Ethernet [V]LAN, and thus the same IP subnet with the same router and same DHCP server.
If I've read your Question correctly, it sounds like you've got a situation where you have a single guest network SSID, but depending on which AP the client roams to (Meraki vs. TP-Link), it's actually a different [V]LAN underneath with a different valid IP subnet and a different NAPT gateway. This will definitely cause roaming problems of various kinds for your clients.
Some rudimentary clients may not realize their need to double-check their DHCP lease via DNAv4 or other means, and just end up in a broken state where they have Wi-Fi link up but don't have a valid IP address that lets them get anywhere. Users of such clients will likely need to turn their Wi-Fi interface off and back on, or do something else to force a DHCP renewal.
More reasonable clients will use DNAv4 or other means to check their DHCP lease, realize they were lied to and now they're on a different network after all, and proceed to get a new DHCP lease on the new subnet. Not only will this slow down roaming, it will also cause all established connections to drop. So you just lost all your SSH sessions, your big in-progress downloads, your VoIP calls, your video streams, your fileserver mounts, your online game sessions, etc.
I don't know the limitations of your old-school Meraki APs, but my best advice to you is to make it so that all of the APs publishing the guest SSID are all simply transparently bridging that traffic onto a single guest VLAN with a single subnet, a single NAPT gateway router, and a single DHCP server.
answered Feb 22 at 23:59
SpiffSpiff
77.7k10118163
Added some clarifications in the third paragraph, and an addendum at the end, if that helps.
– Dustin Kreidler
6 hours ago
add a comment |
Wi-Fi clients generally expect that all in-range APs publishing the same network name (SSID) will be transparently bridging their traffic onto the same Ethernet [V]LAN, and thus the same IP subnet with the same router and same DHCP server.
If I've read your Question correctly, it sounds like you've got a situation where you have a single guest network SSID, but depending on which AP the client roams to (Meraki vs. TP-Link), it's actually a different [V]LAN underneath with a different valid IP subnet and a different NAPT gateway. This will definitely cause roaming problems of various kinds for your clients.
Some rudimentary clients may not realize their need to double-check their DHCP lease via DNAv4 or other means, and just end up in a broken state where they have Wi-Fi link up but don't have a valid IP address that lets them get anywhere. Users of such clients will likely need to turn their Wi-Fi interface off and back on, or do something else to force a DHCP renewal.
More reasonable clients will use DNAv4 or other means to check their DHCP lease, realize they were lied to and now they're on a different network after all, and proceed to get a new DHCP lease on the new subnet. Not only will this slow down roaming, it will also cause all established connections to drop. So you just lost all your SSH sessions, your big in-progress downloads, your VoIP calls, your video streams, your fileserver mounts, your online game sessions, etc.
I don't know the limitations of your old-school Meraki APs, but my best advice to you is to make it so that all of the APs publishing the guest SSID are all simply transparently bridging that traffic onto a single guest VLAN with a single subnet, a single NAPT gateway router, and a single DHCP server.
answered Feb 22 at 23:59
SpiffSpiff
77.7k10118163
Added some clarifications in the third paragraph, and an addendum at the end, if that helps.
– Dustin Kreidler
6 hours ago
add a comment |
Wi-Fi clients generally expect that all in-range APs publishing the same network name (SSID) will be transparently bridging their traffic onto the same Ethernet [V]LAN, and thus the same IP subnet with the same router and same DHCP server.
If I've read your Question correctly, it sounds like you've got a situation where you have a single guest network SSID, but depending on which AP the client roams to (Meraki vs. TP-Link), it's actually a different [V]LAN underneath with a different valid IP subnet and a different NAPT gateway. This will definitely cause roaming problems of various kinds for your clients.
Some rudimentary clients may not realize their need to double-check their DHCP lease via DNAv4 or other means, and just end up in a broken state where they have Wi-Fi link up but don't have a valid IP address that lets them get anywhere. Users of such clients will likely need to turn their Wi-Fi interface off and back on, or do something else to force a DHCP renewal.
More reasonable clients will use DNAv4 or other means to check their DHCP lease, realize they were lied to and now they're on a different network after all, and proceed to get a new DHCP lease on the new subnet. Not only will this slow down roaming, it will also cause all established connections to drop. So you just lost all your SSH sessions, your big in-progress downloads, your VoIP calls, your video streams, your fileserver mounts, your online game sessions, etc.
I don't know the limitations of your old-school Meraki APs, but my best advice to you is to make it so that all of the APs publishing the guest SSID are all simply transparently bridging that traffic onto a single guest VLAN with a single subnet, a single NAPT gateway router, and a single DHCP server.
answered Feb 22 at 23:59
SpiffSpiff
77.7k10118163
Wi-Fi clients generally expect that all in-range APs publishing the same network name (SSID) will be transparently bridging their traffic onto the same Ethernet [V]LAN, and thus the same IP subnet with the same router and same DHCP server.
If I've read your Question correctly, it sounds like you've got a situation where you have a single guest network SSID, but depending on which AP the client roams to (Meraki vs. TP-Link), it's actually a different [V]LAN underneath with a different valid IP subnet and a different NAPT gateway. This will definitely cause roaming problems of various kinds for your clients.
Some rudimentary clients may not realize their need to double-check their DHCP lease via DNAv4 or other means, and just end up in a broken state where they have Wi-Fi link up but don't have a valid IP address that lets them get anywhere. Users of such clients will likely need to turn their Wi-Fi interface off and back on, or do something else to force a DHCP renewal.
More reasonable clients will use DNAv4 or other means to check their DHCP lease, realize they were lied to and now they're on a different network after all, and proceed to get a new DHCP lease on the new subnet. Not only will this slow down roaming, it will also cause all established connections to drop. So you just lost all your SSH sessions, your big in-progress downloads, your VoIP calls, your video streams, your fileserver mounts, your online game sessions, etc.
I don't know the limitations of your old-school Meraki APs, but my best advice to you is to make it so that all of the APs publishing the guest SSID are all simply transparently bridging that traffic onto a single guest VLAN with a single subnet, a single NAPT gateway router, and a single DHCP server.
answered Feb 22 at 23:59
SpiffSpiff
77.7k10118163
edited Feb 23 at 0:04
answered Feb 22 at 23:59
SpiffSpiff
77.7k10118163
answered Feb 22 at 23:59
SpiffSpiff
77.7k10118163
answered Feb 22 at 23:59
SpiffSpiff
77.7k10118163
77.7k10118163
Added some clarifications in the third paragraph, and an addendum at the end, if that helps.
– Dustin Kreidler
6 hours ago
add a comment |
Added some clarifications in the third paragraph, and an addendum at the end, if that helps.
– Dustin Kreidler
6 hours ago
Added some clarifications in the third paragraph, and an addendum at the end, if that helps.
– Dustin Kreidler
6 hours ago
Added some clarifications in the third paragraph, and an addendum at the end, if that helps.
– Dustin Kreidler
6 hours ago
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1408629%2faps-from-different-vendors-give-out-ip-addresses-in-vastly-different-ranges-ro%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
The problem is not that their IP addresses are different but that they're in different VLANs. It makes no difference what IP addresses they have, but if they are in different VLANs, then roaming can't work.
– David Schwartz
Feb 22 at 22:21