Hi all, We have 2x F5 BIG-IP 4000 units with APM Base, GTM-DNS and LTM Base licenses, running version 11.6.0 (build 3.0.412). We are having trouble with a multi-hop DHCP relay config where the F5 does not have a presence in the client VLAN. The reason we are wanting the F5 in the mix is so that we can take advantage of Server 2012 R2 DHCP redundancy/failover features and switch DHCP servers far quicker than updating 200 devices at once. We do not want or need the F5 to service DHCP broadcast requests hitting it's own interfaces. We have been using these documents to try get this running: https://devcentral.f5.com/articles/dhcp-relay-virtual-serverhttps://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-11-6-0/29.html We have the following setup: Client network config: Client on VLAN20Cisco switch (C4500X with iOS XE 03.04.05) with VLAN20 configured with 10.1.0.1/24 and an IP Helper pointing to 10.2.0.5 which is 3 hops awayA single laptop with a wired connection to a switchport configured for VLAN20. F5 config: F5 Virtual Server configured with Type DHCP, Source Address 0.0.0.0/0, Destination (Other) 10.2.0.5, listening only on the VLAN where 10.2.0.5 is present.DHCPv4 Profile configured using default settings, but tried in both Relay and Forward mode, with Idle Timeout set to Indefinite, Max Hops set to 30, Default TTL set to 2000, and TTL Decrement Amount set to 0, with no change in result.Member Pool with 1x Windows Server 2012 R2 member on 10.2.0.6:67 running MS DHCP with a DHCP pool for 10.1.0.0/24. Also tried with a Windows Server 2008 R2 member.No iRules applied.SNAT rule created to map 10.1.0.1 to 10.1.0.1, but tried with and without this in placeTried with and without a Self IP on 10.2.0.5 (not sure if it's required with a unicast DHCP packet instead of broadcast) DHCP Server config: Windows Server 2012 R2 with DHCP service installedScope created for 10.1.0.0/24 with gateway, DNS and domain name setStatic route added for 10.1.0.1/32 to go via 10.2.0.5 What we're seeing: Virtual Server stats show traffic in and out, including recognising the DHCPDISCOVER packet, however it shows that all requests are timing out.Pool stats show zeroes across the board for bits, packets, connections etcWireshark on the Windows DHCP server monitoring UDP port 67 and destination IP of 10.2.0.5. We see the DHCP health checks appear as malformed BOOTP packets, but no "real" DHCP packets. Other thoughts I've had: Cisco IOS doesn't seem to allow adding/editing a Max Hops value on IP Helper.In DHCP mode, a Virtual Server forwards DHCP packets to all members at the same time. This may prevent the stats from reporting in an expected way. Any tips or help that anyone can provide would be greatly appreciated. Regards, Philip

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

Forum Discussion

Aussiewan_19227

Nimbostratus

Mar 16, 2015

F5 DHCP Relay in multi-hop configuration issue

Hi all,

We have 2x F5 BIG-IP 4000 units with APM Base, GTM-DNS and LTM Base licenses, running version 11.6.0 (build 3.0.412). We are having trouble with a multi-hop DHCP relay config where the F5 does not have a presence in the client VLAN. The reason we are wanting the F5 in the mix is so that we can take advantage of Server 2012 R2 DHCP redundancy/failover features and switch DHCP servers far quicker than updating 200 devices at once. We do not want or need the F5 to service DHCP broadcast requests hitting it's own interfaces.

We have been using these documents to try get this running:

We have the following setup:

Client network config:

Client on VLAN20
Cisco switch (C4500X with iOS XE 03.04.05) with VLAN20 configured with 10.1.0.1/24 and an IP Helper pointing to 10.2.0.5 which is 3 hops away
A single laptop with a wired connection to a switchport configured for VLAN20.

F5 config:

F5 Virtual Server configured with Type DHCP, Source Address 0.0.0.0/0, Destination (Other) 10.2.0.5, listening only on the VLAN where 10.2.0.5 is present.
DHCPv4 Profile configured using default settings, but tried in both Relay and Forward mode, with Idle Timeout set to Indefinite, Max Hops set to 30, Default TTL set to 2000, and TTL Decrement Amount set to 0, with no change in result.
Member Pool with 1x Windows Server 2012 R2 member on 10.2.0.6:67 running MS DHCP with a DHCP pool for 10.1.0.0/24. Also tried with a Windows Server 2008 R2 member.
No iRules applied.
SNAT rule created to map 10.1.0.1 to 10.1.0.1, but tried with and without this in place
Tried with and without a Self IP on 10.2.0.5 (not sure if it's required with a unicast DHCP packet instead of broadcast)

DHCP Server config:

Windows Server 2012 R2 with DHCP service installed
Scope created for 10.1.0.0/24 with gateway, DNS and domain name set
Static route added for 10.1.0.1/32 to go via 10.2.0.5

What we're seeing:

Virtual Server stats show traffic in and out, including recognising the DHCPDISCOVER packet, however it shows that all requests are timing out.
Pool stats show zeroes across the board for bits, packets, connections etc
Wireshark on the Windows DHCP server monitoring UDP port 67 and destination IP of 10.2.0.5. We see the DHCP health checks appear as malformed BOOTP packets, but no "real" DHCP packets.

Other thoughts I've had:

Cisco IOS doesn't seem to allow adding/editing a Max Hops value on IP Helper.
In DHCP mode, a Virtual Server forwards DHCP packets to all members at the same time. This may prevent the stats from reporting in an expected way.

Any tips or help that anyone can provide would be greatly appreciated.

Regards, Philip

Aussiewan_19227
Nimbostratus
Mar 16, 2015
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
kunjan
Nimbostratus
Mar 16, 2015
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?