Forum Discussion

Aussiewan_19227's avatar
Aussiewan_19227
Icon for Nimbostratus rankNimbostratus
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

 

application delivery
cisco
design
dhcp
LTM
  • Aussiewan_19227's avatar
    Aussiewan_19227
    Icon for Nimbostratus rankNimbostratus
    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