@EricPerl Some people shared the experience before, but not sure why I cannot open that page anymore. Related post

About your configuration, what I suggest is to try enable the router DHCP(on the controller) first, and double check if your computer can receive correct IP from the router. It is used to test your VLAN settings and port frpfile settings. Make sure the port connected to your computer and virtual NIC (DNS/DHCP server) are on the correct VLAN.

@Somnus,

Thanks for pointing me at that post. I had not seen it. The forum search is not great...

I have access to the external link on scribd. Maybe you no longer have access if you let your 30 day "trial" expire (could just be a matter of deleting some cookies).

I've read through it twice and I find it difficult to follow.

One of the reasons is that the explanations (192xxx) and the screenshots (10xxx) are using different subnets.

I think I somehow can get around this given the convention used to encode the vlan in the subnet.

The other reason is that I can't figure out what IP the router occupies.

I'm mentioning the author @jwaltrip here and maybe he can shed some light on that.

In any case, I thank him for the walkthrough. It give me something to try...

I would definitely like something incremental that I can test in a separate VLAN on top of the state of say FAQ 3091 (How to configure Multi-Networks & Multi-SSIDs on Omada SDN Controller | TP-Link). That's pretty close to what I have. I'd rather not break what I already have until I know how to move forward.

One obvious difference between my approach and the one in this walkthrough is the use of DHCP relays (I didn't use them).

The reason behind this is that I couldn't figure out how to configure my DHCP server to serve the correct range.

As of today, the only piece of information a client "inherits" at the very beginning is the VLAN ID that's added by the switch based on the port the client is connected to.

I have no clue how that is transferred thru a DHCP relay. It's possible the relay ends up in the relayed DHCP_DISCOVER message.

I guess I can enable full logging on the DHCP server and investigate.

It's even more baffling given the fact that the DHCP server of the walkthrough is in a VLAN (SERVERS) and is likely getting untagged traffic.

In my case, I added a virtual NIC for the VLAN subnet to the DHCCP/DNS server and the server sits in the native LAN at this point (I have not yet re-enabled the MGMT VLAN).

In any case, the DHCP/DNS aspects seem to work very well.

As I flip the profile on the port that my test machine is connected to, it gets a proper IP in the correct VLAN/subnet.

The only thing that doesn't work is internet connectivity when IP is from the external DHCP server.

And I attribute that to the fact that the IP is indicate in the gateway box of the interface VLAN is not reachable within that VLAN.

No device seems to have claimed it.

In my other VLANs (per FAQ above), I can ping that IP from all devices in the VLAN. I assume it's assigned to the ER605 router (but maybe my mental model is wrong here).

D'OH!

I just found my mistake after going through some articles related to this post.

As I looked back at my configuration, I noticed I did not check the proper 'LAN interfaces' during network creation...

I only had WAN/LAN1 checked, not the LAN one and that's the one that my main switch is connected to.

I fixed this and voila. Internet connectivity restored in my TEST VLAN.

While I realize that it may not be a configuration for everyone (I could tinker with virtual interfaces on my DHCP router), I'd argue it's a relatively simple configuration when compared to the one outlined by jwaltrip. And I can incrementally switch my other VLANs to target my DHCP/DNS server (create virtual interface, add DHCP range config, update network interface in Omada).

Thx all that got me looking around.

Sorry. I have not checked in a 2qhile.

Do oyu still need assistance?