We're having an annoying problem which has been going on for a couple of days now. We are in the early stages on our BL implementation and are in the process of trying to setup the Provisioning infrastructure. I have so far configured a server which is running blpxe and bltftp (Linux). We have a client machine (DL385) which we are using to test provisioning. We've had a new VLAN setup and allocated it's own IP address range. All of the machines in question have their first onboard NIC connected into this VLAN, which we'll use for provisioning traffic. The layer3 interface on the VLAN has an ip_helper configured to forward DHCP traffic from the VitalQIP server to hosts connected to this VLAN.
I've done a lot of investigation into the problem, and from what I can see DHCP is functioning as expected. Machines making DHCP requests on interfaces connected to the provisioning VLAN receive a response from the DHCP server offering IP, Subnet, Gateway (all the usual stuff), plus in my WireShark (ethereal) packet captures I can also see that the DHCP Options 211 and 212 (bl-server / bl-port) are also being sent.
The value of these options is in hex in the packet capture, and when converted from hex I can see that the 211 option equates to our App Server's IP address (the one on the provisioning VLAN) and option 212 equates to 9831.
So, everything here looks fine. I setup a packet capture running, whilst PXE booting my bare metal DL385 test server.
The machine boots from NIC1, PXE kicks in, and I see it obtain an IP, Subnet, Gateway etc as well as the 211 and 212 options. The machine goes to TFTP and pulls down the gentoo amd64 image (this is Linux provisioning by the way) and boots no problem. It then runs through setting up the NIC interfaces (which is painfully slow, but that's another story), and eventually bmi is called. It spits out a lot of messages, as follows:
reading DHCPACK response
read DHCPACK from server
BL_AS = 10.210.56.249
BL_AP = 0
But when we look at what is captured by the packet trace I have running, I can see the following events...
Bare Metal Client Broacasts DHCP Inform
DHCP ACK received via ip_helper on layer3 interface (gateway for all intents and purposes)
DHCP Discover sent by Bare Metal Client in which I can see this under the BootStrap Protocol in the packet...
Option (t=55,l=3) Parameter List Request
Option: (55) Parameter List Request
6 = Domain Name Server
211 = Private
212 = Private
Then the response comes in from the DHCP server...
DHCP Offer come in via ip_helper address with the following contents...
Option 53 = DHCP Message Type = DHCP Offer
Option 54 = Server Identifier =
Option 6 = DNS Server = empty
Option 15 = Domain Name = xxx.xxx.com
Option 51 = IP Lease Time = 1hour
Option 211 = Private
Option 212 = Private
Again, the hex values of options 211 and 212 are correct, they work out to be the right IP and port.
So although everything seems to be happening as it should, for whatever reason, BMI is not interpreting the 212 option (bl-port) properly.
Any ideas? I'm really getting a bit stuck with this now.
Many Thanks - Lee