Forum Discussion

francisco_1_162's avatar
francisco_1_162
Icon for Nimbostratus rankNimbostratus
Jan 16, 2008

bootp through the ltm

Below is the setup i have. I have LTM with two interfaces, one connected to dmz vlan and the other connected to a cisco firewall. The firewall is connected to a switch and behind the switch i have DHCP server. What i need is to get a server we are building on the dmz to get ip address from the DHCP server(192.168.80.100) bootpc.

 

 

DMZ Servers (DMZ Vlan)

 

-

 

- 10.1.0.1/254 -(LTM Internal Int)

 

BIP LTM

 

- 10.2.0.1/24 -(LTM external Int)

 

- 10.2.0.2/24 -(Firewall DMZ Int)

 

Firewall

 

- 10.3.0.1/24 -(Firewall Inside)

 

-

 

Switch

 

Vlan 80

 

DHCP Server - 172.25.80.100

 

 

 

 

To allow new servers on the to get ip from dhcp servers enable BOOTP and PXE traffic through the LTM, i have setup the following

 

 

 

Step 1: run this CLI command:

 

b db TM.AllowMulticastL2DestinationTraffic enable

 

 

Setup 2: create a set of pool/ virtual server:

 

BOOTP and DHCP traffic is sent to the destination port 67/udp.

 

 

Setup 3: create a pool that contains your PXE server. 172.25.80.100

 

Pool member: PXE server; Service port "* all services"

 

 

Setup 4: create a virtual server listening on the port 67

 

Destination Type: Network

 

Address: 0.0.0.0

 

Mask: 0.0.0.0

 

Service port: Other > 67

 

Default pool: pool created above

 

 

Setup 5: And another one listening on port 68

 

Destination Type: Network

 

Address: 0.0.0.0

 

Mask: 0.0.0.0

 

Service port: Other > 68

 

Default pool: pool created above

 

 

This should allow the BIG-IP to forward the BOOTP and DHCP traffic to the PXE server located on the other VLAN. BUT it doesnt work. infact i dont see any traffic when i look at the pool members statictics or vitual server statictics.

 

 

Please advise.

 

 

 

6 Replies

  • bootp is a broadcast, and the LTM is not yet capable of dhcp relay. You'll need to configure a relay agent in the DMZ to handle this for you.
  • Please open a support case against the CR noted in this thread:

     

     

    http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=19651&ptarget=19782

     

  • I can get the initial bootp request through the LTM, but the response doesn't make it back through because of what a dhcp response looks like. Here is what I see in my testing.

     

     

    DHCP Server: 10.10.10.100

     

    External: 10.10.10.10

     

    Internal: 192.168.10.10

     

    Client: none (about to get dhcp to 192.168.10.100)

     

     

    Client sends out bootp request destination 255.255.255.255 and source 0.0.0.0

     

    LTM catches it in the vip and shoots it out the other end.

     

    Here we can either SNAT it or not SNAT it. Either way, the source mac address is now the BIG-IP.

     

    When the DHCP server gets it, it responds with a packet, source IP 10.10.10.100 dest ip: (192.168.10.100). Destination mac, LTM’s mac address.

     

    Now that packet reaches the LTM

     

    If you have a forwarding virtual on the external side, TMM accepts it and then says, ok, where is this destination IP 192.168.10.100? I have no arp entry so I’ll ask. It then sends and arp query out the client side asking for 192.168.10.100. No one owns it and the packet dies.

     

     

    Something in the LTM needs to receive the DHCP request and act as a dhcp proxy where it remembers the original bootp request and can recognize that the bootp response belongs to that client’s mac.

     

    That’s what a linux program called dhcprelay is designed to do, but we haven’t implemented that on LTM.

     

     

    I think we need to request that F5 add this to their product by creating a support case.

     

  • The more customers who open cases against this, the more visible the request becomes...the CR is CR50233
  • I have already open a case with F5 support. i will speak to them tomorrow morning about CR50233.

     

    thanks chaps.

     

     

     

    Franco.