F5 DHCP Relay in multi-hop configuration issue

The cisco router should unicast the request to the ip-helper address. http://www.cisco.com/en/US/docs/ios/12_4t/ip_addr/configuration/guide/htdhcpre.html

Have you verified the traffic you see on F5 is the traffic from the test client itself?

Does it work if the client is on the same subnet as F5?

Thanks for your reply, Kunjan.

All DHCP relays/IP Helpers have to translate the DHCP broadcasts to unicast. I'm familiar with that part of the process, but the F5 is where I am less skilled.

I haven't done any logging to specifically check that the packets hitting the F5 are from my test laptop, but when the laptop is not on, the stats don't change, and as soon as it powers up or I tell it to get an IP, the stats on the VS start increasing. So while not confirmed, I'm pretty confident that the requests from the client are hitting the F5. Unfortunately I can't get the client machine to sit on the same subnet as the F5 (or vice versa) to test that it works otherwise. Unfortunately my real DHCP server is on the same subnet as I want it F5 to listen on, so as soon as I add a scope for that subnet, the DHCP server will deliver responses directly to the clients instead of via the F5.

The "alternate configuration" information on the second link in my original post has relevant bits for this situation, but I believe they shouldn't stop the packets getting to the DHCP server pool, only make them have incorrect values such as the originating IP address.

I have just disabled the firewall on the DHCP server to see if that makes any difference at all. It didn't.

I will look at options for setting up the DHCP server on another VLAN to do testing for the F5 converting the DHCP broadcasts to unicast, but that will likely take some time and is not an architecture I want to use.

Any other suggestions of things I can try would be greatly appreciated.

Regards, Philip

Hi Philip, on the DHCP stats screen do you see OUT traffic for DISCOVER? a tcpdump on the outgoing interface will tell if the traffic send to DHCP server and also the outgoing interface IP.

You may also want to try creating a scope for 10.2.0.0, outgoing interface subnet.

Hi Kunjan,

Thanks again for your thoughts.

I have attached an image of the stats from the VS. Unfortunately I'm not familiar enough with the F5 to know how to do a tcpdump of the traffic, and the resource we have who does that kind of thing is not available for 2 weeks.

If I create a DHCP scope for that subnet, I am concerned that it will potentially cause issues for the subnet, as it's a production environment. Wireshark should show the traffic hitting the DHCP server regardless of that anyway, which it does not.

Cheers.

It seems like the traffic is leaving. You can verify the traffic from cli

tcpdump -ni 0.0 port 67 or 68

You should see traffic incoming to LTM and outgoing from LTM as it captures traffic on all interfaces. This will help to verify the SNAT.

You also can specify the interface and helps to check if the traffic leaves by the interface facing DHCP server.

eg: tcpdump -ni 1.2 port 67 or 68

Unfortunately I haven't had a chance to do any further testing with this as yet.

Does anyone happen to know whether the pool members of a DHCP VS should show traffic stats? This should be relevant regardless of whether it's in a multi-hop or single-hop configuration.

Anyone have any experience with DHCP via F5? I'm still interested to know whether a working setup, either in single-hop or multi-hop mode, shows stats on the pool members or not.

perhaps not something you want to hear, but have you tried contacting support? it seems the experience here with using the F5 for DHCP relay are limited.

DHCP relay works fine but I recall running into an issue where the request and response were getting hashed to different TMMs.

BIGIP uses an IP/port hash to distribute connections and, because the request and response are on 67 & 68, the response got treatment from a different TMM and dropped on the floor. I'm reasonably certain they'd have fixed it by now but, if all else fails, I'd turn off CMP on that VS if it isn't already.

I'd start with some of the previous suggestions to ensure we're at least getting this far though.

If you could send the output of the tcpdump kunjun suggested above as well as the VS configuration we should be able to spot what the problem is

Thanks boneyard, I think we will have to resort to contacting F5.

Bernie - we use HA, but active/standby, so I wouldn't have thought the hashing would be an issue. We only have a single DHCP server in the pool at the moment, but even if we had more, from what I have read the DHCP profile makes the request hit all pool members at the same time.

I'll wait for our F5 guru to be back in the office and try tcpdump to try see what is happening at the packet level, and then escalate to F5 if we don't see anything useful.

Thanks everyone for your help.