• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 462
  • Last Modified:

Will this tagged VLAN setup work?

I just want to make sure that my understanding of this network is sound and that what I'm trying to do here will actually work.

I have a customer who has two different ISPs - one is a fast(ish) 4G cellular network which has limited bandwidth. The other is a slow satellite connection which has no bandwidth restrictions. They want to be able to connect to one network, or the other, at will. They also have a large house, and need multiple access points around the house to get good coverage.

I'm using Engenius EAP350 access points, which can broadcast 2x SSIDs and support 802.1q VLAN tagging depending on which SSID the computer connects to. I also have a SG200-8P Cisco switch which these APs are connected to, which also supports tagged VLANs.

The idea is that wherever they are in the house, they can select the desired wifi network to connect to and that will allow them to control which ISP they're using.

Here's a rough diagram of my network:

Example network diagram
Am I correct in that:

1) The DHCP servers of the two respective routers should not interfere with each other, because they are on separate VLANs

2) Desktop A will get an IP Address in the 192.168.20.xxx range on VLAN2 and access the 4G internet without any special configuration

3) Desktop B will get an IP Address in the 192.168.0.xxx range on VLAN1 and access the Satellite internet without any special configuration

4) Laptop C and D should be able to select whichever wireless network they want, and they will be assigned an appropriate IP address in the correct range, and the user can jump between one network and the other in order to select which ISP they want to use

... Is that correct?
  • 3
  • 2
1 Solution
Yes, your assumptions are correct.
Frosty555Author Commented:
Naderz - a followup question:

Are you aware of any weird issues with DHCP clients "caching" the IP address they were assigned  based on the network they're connected to?

The reason I ask is that I have in the past seen my desktop computer obtain an IP address over DHCP extremely quickly - almost impossible fast - when I stay on the same network, e.g. if I disconnect the network cable, and then plug it back in.

And... I'm having a semi-intermittent issue where sometimes one of the laptops on the network will fail to get the correct IP when they jump from one Wifi network to the other - the computer retains the old IP address they had before on the previous network. An ipconfig release/renew fixes it, but the customer doesn't know how to do that.

I'm wondering if maybe the DHCP client implements some sort of optimization trick that where it identifies the network it was on, and remembers it's old DHCP lease and uses that, instead of asking the router for a new IP address every time.

Based on your understanding of how DHCP works, does any of that sound plausible or is that just not the way it works and it is not something to be concerned about?
Well, DHCP does have a timeout for the leases. The Timeout value is configured in the DHCP server's configuration. This is recorded in the DHCP database. The IP address in DHCP database is associated with the device's NIC MAC address. So, when a device goes off the network for some reason (e.g. the cable is unplugged and plugged back in) and then comes back it is possible to get the same IP address based on the lease timeout.

With WiFi the process is the same as wired. If the WiFi NIC is on a certain network (SSID) and goes off and comes back, it should get the same address within the timeout value. When you say "...from one Wifi network to the other.." do you mean different SSIDs with different IP address subnets? Or, same SSID but different Access Point (AP)?

If the WiFi devices are moving from one SSID to another that has a different IP subnet and DHCP scope, then the device will get a new IP address. There should be not be a delay.

Seamless roaming within the same WiFi SSID comprised of more than one AP will have its own challenges and requirements not associated with DHCP. That would be a different discussion.
In addition to above, one more note: I have not experienced any unusual delay issues with WiFi clients "hopping" from one SSID to another SSID and getting an IP address. Basically, what should happen is that the WiFi NIC in effect resets itself and broadcasts for an IP address. At this point you could say that no, there is no caching as far as the WiFi NIC's DHCP client.

WiFi NICs and adapters do behave differently. Sometimes they need the latest driver. What I have experienced is that I let Windows (on Windows machines) handle the WiFi settings and not the client provided by the WiFi AP manufacturer.

Are you experiencing this with devices other than the laptop in question? Do you have another tablet (e.g. iPad) or phone that you can test with?
Frosty555Author Commented:
Just wanted to put some closing comments on this post - it turned naderz you were correct in how DHCP works, and there's no problem going from one WiFi network to another.

The DHCP problem I was experiencing was caused by me accidentally not saving the settings to the Cisco switch. After a power cycle, the switch forgot all of it's configuration, and of course the computers couldn't get an IP address. They would temporarily use their previously obtained IP address for 30-40 seconds before timing out and reverting to a 169 address. This doesn't happen if both DHCP servers are active and reachable.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now