Forum Discussion
francisco_1_162
Nimbostratus
Nimbostratusbootp 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.
- JRahm
Admin
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. - JRahmPlease 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 
James_ThomsonEmployee
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.- JRahmThe more customers who open cases against this, the more visible the request becomes...the CR is CR50233
francisco_1_162I have already open a case with F5 support. i will speak to them tomorrow morning about CR50233.
thanks chaps.
Franco.- francisco_1_162j.thomson,
what software version on the ltm are u using mate?
