DHCP Relay on TL-R605
DHCP Relay on TL-R605
I recently bought an entire Omada Network including the OC200 hardware controller, the R605 Security Gateway, 3 Jetstream switches and 3 EAP access points.
At the moment I am trying to implement DHCP relay configuration because I have a server running a DHCP service which I need to use for a couple of subnets in my environment.
I am used to add DHCP relay configuration to the vlan interface on my routing device/gateway with for example the 'ip helper' command (on Cisco devices). In my setup, the TL-R605 is the routing device/gateway so I want to apply the DHCP relay configuration on that device. This is the point where I get lost: I do not seem to be able to find this particular setting in the Omada controller.
I can only find DHCP Relay configuration on the switches. But for that to work, I have to activate the vlan interfaces in the switch for those particular vlans and that messes with my design: My switches should function as OSI layer 2 switches, only the router/gateway should handle the OSI layer 3 (and higher) traffic. The only vlan interface my switches need, is there own management interface.
Under 'Settings>Wired Networks>LAN>Edit Network' there is a 'Legal DHCP Servers' option, but this only seems to be a DHCP snooping feature and has no DHCP relay functionality as far as I can tell from the testing I have done.
I am curious how others have handled this and if I am overlooking something in the Omada Controller. Is this option available when deploying the TL-R605 as a standalone? Maybe @Fae can shine some light on this?
I appreciate your help!
Edit: I found a simular thread from a few months ago, but no solution or clarity is provided yet.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Good News!
I had a remote session with one of the engineers from the support team. After checking my configuration, we found the issue causing this.
The tl;dr:
You need to enable VLAN Interfaces for all your VLANs/Subnets. So in my case, I have a my server/shared services separated from my normal clients and needed a VLAN Interface there as well. After I configured and enabled one, my clients got their lease from my DHCP server, which is connected on a different switch and different VLAN.
So go to devices -> click on your switch -> Config -> VLAN Interface -> Edit -> Enter an IP address or set it to DHCP, configure DHCP Relay address -> Apply and then enable the VLAN Interface
Repeat for all switches/VLANs
The details for those interested:
So in my setup things are splitted up nicely:
- one VLAN for all my normal clients (PCs, mobil clients, etc.)
- one VLAN for Guests
- one VLAN for all shared services/servers
- one VLAN for everything IoT related
- one VLAN for management of Omada devices
In my thinking, the VLAN interface was only needed for the client VLAN, as it would act as another gateway and relay the DHCP messages. I have a ER-605 which I thought was responsible routing between the switches. So the interfaces, it had configured should be enough for inter VLAN routing (which in fact is enough for one direction). But the switches need their L3 interfaces as well.
A working example with my address ranges:
- Client Subnet is 192.168.200.0/24 with VLAN 200
- Server Subnet is 192.168.50.0/24 with VLAN 50
- Interfaces on the ER-605: 192.168.50.1 and 192.168.200.1
- DHCP Server address: 192.168.50.2
Since I have two switches I needed four more addresses to cover all SVIs (need to clear the address of my DHCP so the .2 gets available for the SVI):
- Switch1: 192.168.50.100 and 192.168.200.2
- Switch2: 192.168.50.101 and 192.168.200.3
Example config for Switch 1:
Devices -> Switch 1 -> Config -> VLAN Interface
VLAN 200 (enabled):
- Management VLAN: not enabled
- IP Address Mode: Static
- IP Address: 192.168.200.2/24
- DHCP Mode: DHCP Relay
- Server Address: 192.168.50.2
VLAN 50 (enabled):
- Management VLAN: not enabled
- IP Address Mode: Static
- IP Address: 192.168.50.101/24
- DHCP Mode: None
Repeated that on Switch 2 with the other addresses and my client got his lease from my DHCP.
I hope that this makes sense and that it resolves your issues as well. If you have trouble and I should share more of my configuration let me know.
- Copy Link
- Report Inappropriate Content
So due to a better alternative I gave my switches an IP address in the client vlan so I can configure the DHCP relay information.
Although this sort of works, it is not flawless. Somehow the clients take very long to receive an IP address from my DHCP server (MS Windows server) which belongs to a different vlan (this is offcourse why I need the DHCP relay). If this happens only the first time then I could live with it, but some (wireless) clients loose there IP address on a daily basis somehow. When that happens, it takes a lot of effort to regain there IP (forcing them to reconnect for instance). This makes my network very unreliable. In my previous setup (Cisco Meraki) I had no issues with DHCP relay or my DHCP server.
Does someone recognise this strange behaviour? Is there a bug I am not aware of? Is my implementation wrong? @Fae maybe you can pitch in?
- Copy Link
- Report Inappropriate Content
Dear @haggyman,
haggyman wrote
So due to a better alternative I gave my switches an IP address in the client vlan so I can configure the DHCP relay information.
Although this sort of works, it is not flawless. Somehow the clients take very long to receive an IP address from my DHCP server (MS Windows server) which belongs to a different vlan (this is offcourse why I need the DHCP relay). If this happens only the first time then I could live with it, but some (wireless) clients loose there IP address on a daily basis somehow. When that happens, it takes a lot of effort to regain there IP (forcing them to reconnect for instance). This makes my network very unreliable. In my previous setup (Cisco Meraki) I had no issues with DHCP relay or my DHCP server.
Does someone recognise this strange behaviour? Is there a bug I am not aware of? Is my implementation wrong? @Fae maybe you can pitch in?
Where is your DHCP Server (MS Windows server) located?
What's the model number and firmware version of the SDN Switch?
Could you please also provide your network diagram for further analysis?
Would wired clients suffer from the same issue and lose their IP addresses every day?
If only some of the wireless clients have the issue, you may check their signal strength and verify whether they are located in the same VLAN?
If possible, it's also suggested to capture packets between the DHCP Server and clients to check the DHCP Interaction.
- Copy Link
- Report Inappropriate Content
@Fae Thank you for your reply.
Just a few days before your reply I caved in and started using the TL-R605 as DHCP server so I did not have to use relay configuration. Today I gave it another try and tested everything thoroughly. I found out the following:
- When only one switch has the relay config and the (wired or wireless) client is connected to a different switch, DHCP Discoveries do get send to the DHCP server. The DHCP server receives them and gives an DHCP Offer. The offer never reaches the client. What does happen is that the router sends a 'Destionation unreachable' message back to the DHCP server. In below screenshot, the switch has the 172.16.0.1 adres within the client subnet. 10.10.10.21 is the DHCP server.
Capture on the DHCP server
- When switch 2 has the relay config, it works, although the 'Destination unreachable' messages still get send by the gateway. In this case switch 2 (172.16.0.2) handles the relay because the client is connected to switch 2:
Capture on the DHCP server
There is one issue: Relay only works when the client is connected to switch 2, probably because the DHCP server is as well. When connecting through switch 1 or 3 it does not work for wired and wireless clients. The issue is the same as in the first bullitpoint: the DHCP discovery is sent by the client and received by the server. The server sends a DHCP Offer, but it is never received by the client: the Gateway is not able to reach the client or switch IP in client subnet.
My topology is as follows:
Good to know:
- When I config static IP information on the client whitin the 172.16.0.0/24 subnet, there are no connection issues what so ever.
- All the switches are reachable from the DHCP server on their respective client IP address (172.16.0.1, .2 and .3).
So L2 and L3 connectivity is not the issue. It looks like the router/gateway does not know what to do with the DHCP Offers, offered by my DHCP server.
I really hope you can help me with this issue, because I feel I am pretty blind when it comes to troubleshooting on the Omada hardware. There does not seem to be logging which I can consult or send to for example a syslog server.
- Copy Link
- Report Inappropriate Content
Dear @haggyman,
haggyman wrote
I really hope you can help me with this issue, because I feel I am pretty blind when it comes to troubleshooting on the Omada hardware. There does not seem to be logging which I can consult or send to for example a syslog server.
For your case, I'd like to escalate to the TP-Link support team who could help you more efficiently.
They will reach you via your registered email address shortly, please pay attention to your email box later.
Once the issue is addressed or resolved, I'd encourage you to share it with the community.
Thank you so much for your cooperation and support!
- Copy Link
- Report Inappropriate Content
Fae wrote
For your case, I'd like to escalate to the TP-Link support team who could help you more efficiently.
They will reach you via your registered email address shortly, please pay attention to your email box later.
Once the issue is addressed or resolved, I'd encourage you to share it with the community.
Thank you so much for your cooperation and support!
I've encountered the exact same problem. I was wondering, if you could get this resolved with the help from the support team and can share the solution? If not, can I help with providing more information on my setup, configuration etc.?
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
Dear @dapL,
dapL wrote
I've encountered the exact same problem. I was wondering, if you could get this resolved with the help from the support team and can share the solution? If not, can I help with providing more information on my setup, configuration etc.?
I found that the support team hasn't received a reply yet, so the issue was stuck without any progress.
For your case, I'd like to escalate to the TP-Link support team for further investigation.
They will reach you via your registered email address shortly, please pay attention to your email box later.
Once the issue is addressed or resolved, I'd encourage you to share it with the community.
Thank you so much for your cooperation and support!
- Copy Link
- Report Inappropriate Content
@Fae I am sorry I did not respond earlier. I have been very busy. I have received an email from support as you stated and will reply to it today and provide the asked information.
Update:
Just sent the e-mail and provided TP-link with the information that was asked for.
When I have information to share with the community, I will do so!
- Copy Link
- Report Inappropriate Content
So I received a reply from Technical Support. For now, they are checking the issue with @dapL. Hopefully he can provide more information soon.
- Copy Link
- Report Inappropriate Content
haggyman wrote
So I received a reply from Technical Support. For now, they are checking the issue with @dapL. Hopefully he can provide more information soon.
Just an update on the state with my support case.
I reached out to them and provided my configuration, my topology and dumps from a client who is trying to get an IP address via DHCP on two different switches. The DHCP server is connected to one of them.
The Support Team first thought that an ACL that I configured and overlooked was causing this issue, but even disabling it and specifically allowing DHCP traffic with an gateway ACL did not help.
I'll have a remote session with one of the engineers tomorrow, since they have trouble recreating this. I'll update this thread afterwards.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 7431
Replies: 13
Voters 0
No one has voted for it yet.