Forum Discussion
Aussiewan_19227
Nimbostratus
NimbostratusF5 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:
- https://devcentral.f5.com/articles/dhcp-relay-virtual-server
- https://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 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
kunjanThe 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?
Aussiewan_19227Thanks 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
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.
- Aussiewan_19227
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.
- kunjan
It seems like the traffic is leaving. You can verify the traffic from cli
tcpdump -ni 0.0 port 67 or 68You 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 - Aussiewan_19227
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.
- Aussiewan_19227
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.
boneyardMVP
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.
Bernie_Ongewe_6DHCP 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
- Aussiewan_19227
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.