02-27-2017 08:18 AM
Ok, I've attempted two different DHCP templates today and couldn't get either setup to work. I'm certain that it's a misconfiguration somewhere on our side, but here goes:
and tried to use Option 66 as an alternative (added a config file for Option 67)
After DHCP has been negotiated, the switch will then attempt to TFTP the file image. It still attempts to pull it from the DHCP server instead of the TFTP server :(
The TFTP server is reachable by the switch. However, the logs seem to indicate that the switch is mistaking the DHCP server to be the specified TFTP server.
I 02/27/17 14:53:07 00083 dhcp: AM1: updating IP address and subnet mask I 02/27/17 14:53:07 05177 ip: AM1: Setting IP address 10.3.35.1 as default gateway. I 02/27/17 14:53:07 00025 ip: AM1: DEFAULT_VLAN: ip address 10.3.35.28/24 configured on vlan 1 I 02/27/17 14:53:07 03783 dhcp: AM1: DHCP server did not offer all the DNS parameters on Primary VLAN I 02/27/17 14:53:07 05101 amp-server: AM1: AMP server details configured. I 02/27/17 14:53:08 00091 dhcp: AM1: Trying to download Image File (using TFTP) received in DHCP from 10.8.0.26 W 02/27/17 14:53:20 00136 tftp: AM1: Connection to 10.8.0.26 failed W 02/27/17 14:53:35 00136 tftp: AM1: Connection to 10.8.0.26 failed I 02/27/17 14:53:37 00179 mgr: AM1: SME CONSOLE Session - MANAGER Mode ---- Bottom of Log : Events Listed = 103 ---- HP-Switch-5406Rzl2# ping 10.11.64.244 10.11.64.244 is alive, time = 1 ms HP-Switch-5406Rzl2#
I've included two packet captures, each one with their respective DHCP options.
Please note that I did change the IP addresses in my original post to match their actual addresses. Our security team has a legacy rule about obfuscating/"translating" our internal addresses when we post on forums (something about a breach 7 years ago), but since the packet captures have the actual addresses, there's really no point in trying to "hide" anything now :D
02-27-2017 06:43 PM - edited 02-27-2017 10:01 PM
02-28-2017 12:40 AM
When I don't specify option-66 on DHCP server, my switch too tries to contact DHCP server to download image and config files.
Please update your DHCP server configuraton with option-66.
This should resolve your issue.
02-28-2017 08:05 AM - edited 03-01-2017 04:04 PM
I think I have an idea of what's going wrong here. It looks as though QIP is including Option 66 in a different part of the packet.
In the image I've attached, you'll notice that Option 66 is set in QIP. However, the DHCP Offer holds it in the Server field (similar to the File field) rather than listing it in the DHCP options. QIP also treats the field as Text, not an IP, which may be out of the format that the Aruba switches expect. . .
QIP does not allow for multiple Option values to be defined in its database (e.g. I cannot create another Option 66 field under a different folder and change the type), so it looks like I have a few calls to make in order to get this figured out.
Update: We've discovered that QIP will, by default, move Options 66 and 67 into the Bootp header as `sname` and `file`, respectively. This is why the options are not in the list. We'll change a setting called `LeaveBootpParametersInOptions` to True which will instead copy the values. Hopefully this will work and not impact other Bootp-/TFTP-reliant devices (e.g. IP phones)
03-01-2017 04:09 PM
Ok, we just finished our RFC and regenerated the DHCP leases. A packet capture confirms that changing this setting will leave Options 66 and 67 in the Options list (it will still show in the Bootp `sname` and `file` fields). The switch recognized these values and successfully transferred the necessary files.
While this resolves the issue (and I will mark it as answered), I'm a little confused as to why the switches were able to read the bootfile field correctly from the Bootp header but did not read the TFTPBoot server field. I mean, why not read that as well if it's available?