Forum Discussion
Johan_Linder_10
Nimbostratus
NimbostratusDHCP relay
Is it possible to use the LTM as a DHCP relay? In my setup I got one untagged VLAN (vlan269) on one physical interface. And about 10 tagged VLANs (NGP_*) on another physical interface. Since the LTM is running Linux I figured I could use "dhcrelay", see below:
big-ip dhcrelay -i NGPA_10_6_3_0 -i vlan269 -i NGPA_10_6_7_0 10.6.3.10
Internet Systems Consortium DHCP Relay Agent V3.0.1
Copyright 2004 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/NGPA_10_6_7_0/00:01:d7:6a:95:83
Sending on LPF/NGPA_10_6_7_0/00:01:d7:6a:95:83
Listening on LPF/vlan269/00:01:d7:6a:95:82
Sending on LPF/vlan269/00:01:d7:6a:95:82
Listening on LPF/NGPA_10_6_3_0/00:01:d7:6a:95:83
Sending on LPF/NGPA_10_6_3_0/00:01:d7:6a:95:83
Sending on Socket/fallback
Ok, looks good. The problem is that it doesn't seem to actually listen on those interfaces. I'm logging the traffic with a filter:
Jan 4 13:54:21 tmm tmm[930]: 01250002:5: test (86): accept on vlan 273, len: 342 [IPv4 328 0.0.0.0 -> 255.255.255.255 UDP 68 -> 67]
Jan 4 13:54:22 tmm tmm[930]: 01250002:5: test (87): accept on vlan 277, len: 590 [IPv4 576 0.0.0.0 -> 255.255.255.255 UDP 68 -> 67]
I also tried setting up a listening port with "nc":
big-ip nc -l -p 3000
host-on-client-vlan telnet 10.6.3.1 (big-ip floating IP or IP of master)
Trying 10.6.3.1...
telnet: connect to address 10.6.3.1: Connection refused
telnet: Unable to connect to remote host: Connection refused
Ok, that didn't work, try connecting to that port on localhost:
big-ip telnet localhost 3000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Ok, that did work. Does this mean that it's not possible run services that listens on the VLAN interfaces?
Have I done something wrong or is there some other way to do it?
// Johan
hoolioCirrostratus
Can you try adding the port(s) you want to allow access to, to the self IP Port Lockdown list (in the admin GUI under Network >> Self IPs >> Port Lockdown).
For more info on Port Lockdown, take a look at SOL7317 (Click here).
Aaron
Johan_Linder_10Thanks for the reply!
Yes, that sure helped some. It now answers on the ports, but dhcrelay doesn't receive the traffic. Could it be that the DHCP request is destined for 255.255.255.255 and the BIG IP don't answers to broadcasts? I've also set:
bigpipe db TM.AllowEthernetSourceType
TM.AllowEthernetSourceType = any
But that didn't help either. Any ideas?
// J- hoolioI'm not too sure on that. You might try increasing the TMM logging using the Log.Tmm.Level db key and see if you get logging for the packets. Else, you could consider creating a virtual server to handle the traffic. That might be a cleaner solution.
Aaron 
cralston_17844I'm in the same boat. I've allowed udp/67 on the selfip's in question. If I run tcpdump on the bigip's command line, I can see the dhcp requests. When I run dhcrelay -d, I don't even see any requests come in. I don't have any ACL's that are getting hit.- cralston_17844...aaaaand in other news, the bigip is smarter than us:
01020060:3: IP Address 255.255.255.255 is invalid, must not be all ones.
You can't create a virtual server on broadcast. - cralston_17844I also tried creating a 0/0 VS listening on 67, first on IP forwarding mode and then L2 (not expecting it to do any good), in the hopes that TMM would recognize 255.255.255.255:67 as something to react to, and it still didn't show up in dhcrelay, even though I could see the packets in tcpdump the whole time.
So I guess what it goes back to is whether or not there's some other place that's akin to "b db *" that has a setting to handle broadcast packets, too, instead of just silently ignoring them or whatever its current behavior is.
... I guess I should add that I also have a 0/0 IP forwarding VS that load balances all my outbound (SNAT'ed) traffic through two routers. I doubt that would affect this, but it might be relevant info. - Johan_Linder_10I can just agree with your tests, I got the same. But I don't have a 0/0 IP forwarding VS and it doesn't work anyway. So I think we can rule that out. As you said, the packets show up in tcpdump, but the TMM seems to ignore them.
- Apparently we don't yet support DHCP relay, but there is an open CR.
Please open a case with F5 Support and request it be linked to CR50233. The more customers request it, the sooner it will be added.
/deb 
Chris__Bloss_10Any update on this? I'm moving in to a new datacenter in 6 months and having DHCP working from all segments would be nice. Currently the F5 being in front of a few segments is an issue for DHCP relay. I'd hate to have a bunch of systems running just to encapsulate the DHCP request and forward to the DHCP server.- hoolioI'd suggest opening a case with F5 Support (https://websupport.f5.com or http://www.f5.com/training-support/customer-support/contact/). This way you can get an official status on the request. If it hasn't be added to the product, you can add your case to the request.
Aaron
