Wired Intelligent Edge

Hello there! Once again, I'm looking into ways for automating the setup of our equipment. This time I'm trying to add DHCP options to inform new equipment what firmware or configuration it should run and the TFTP server to retrieve it from.

 

We're able to set DHCP (sub)options so that the target device will recognize the name of the file(s) to retrieve. As a point of reference, I am following this guide. The DHCP configuration is as follows:

• Options 1, 3, 6, 15, 43 are set.
• Option 43:
  • Suboption 145: KB_16_03_0003.swi (hex [91114B425F31365F30335F303030332E737769])
  • (Suboption for Airwave is still set; please ignore messages regarding it.)
• Option 66: 10.11.64.244

(For here, IP 10.8.0.26 will be the DNS and DHCP server from VitalQIP; 10.3.35.28 will be the switch; 10.11.64.244 will be the TFTP server.)

 

A packet capture on Wireshark is able to read all of the requested/granted DHCP options and values correctly. The switch will read the DHCP options just fine but will try to grab the firmware from the DHCP server instead of the TFTP server. The log is as follows:

 

I 02/22/17 16:44:11 00083 dhcp: AM1: updating IP address and subnet mask
I 02/22/17 16:44:11 05177 ip: AM1: Setting IP address 10.3.35.1 as default gateway.
I 02/22/17 16:44:11 00025 ip: AM1: DEFAULT_VLAN: ip address 10.3.35.28/24 configured on vlan 1
I 02/22/17 16:44:11 03783 dhcp: AM1: DHCP server did not offer all the DNS parameters on Primary VLAN
I 02/22/17 16:44:11 05101 amp-server: AM1: AMP server details configured.
I 02/22/17 16:44:12 00091 dhcp: AM1: Trying to download Image File (using TFTP) received in DHCP from 10.8.0.26
W 02/22/17 16:44:24 00136 tftp: AM1: Connection to 10.8.0.26 failed
W 02/22/17 16:44:39 00136 tftp: AM1: Connection to 10.8.0.26 failed
W 02/22/17 16:44:54 00136 tftp: AM1: Connection to 10.8.0.26 failed
W 02/22/17 16:45:09 00136 tftp: AM1: Connection to 10.8.0.26 failed
W 02/22/17 16:45:24 00136 tftp: AM1: Connection to 10.8.0.26 failed
W 02/22/17 16:45:27 00089 dhcp: AM1: Unable to download Image File (using TFTP) with 5 Retries

I'm not sure why it's doing this. This is similar for both a 3810M and 5400Rzl2. I've read three or four other guides that all say to set Option 66 as the TFTP server and it should run just fine. Am I missing a step?

I created this document a long time ago maybe it can help you. Let me know if you still have questions.

This is actually the guide that I used during my setup and linked to (thank you for making it). We tried this before with just fetching a configuration file, however it still appears that the switches aren't attempting to reach the TFTP server. Again, the switches will try to pull the configuration file/image from the DHCP server instead of the TFTP server.

Understood. I'm based in EMEA so it's almost night. I'll have quick look for you tomorrow.

No worries. Thank you for the quick response!

1. Is switch able to ping your tftp server i.e 10.1.2.2?

2. As per the event logs that you shared, switch is unable to connect TFTP server.

2. Please share the packet capture, to analyze this issue further.

Need to check what options the DHCP server is sending.

Just to make sure this is probably a typo but you mention in the message that IP of DHCP is 10.1.1.2 but in the switch log it's connecting to 10.1.2.2? Probably a typo but maybe good to have a look. I just quickly build up everything and btw if you have openDHCP server you need add " " around IP addr of TFTPserver option 66. Since this is string packet. For me it's all working. Can you make packet trace of the offer and ack on the DHCP server?

Does TFTP port (UDP69) is enabled in your network? i see the GW is 10.1.3.1 , can it passed TFTP request to your TFTP server?

Thank you for pointing out the typo. I was purposefully replacing the real IP addresses with example ones and missed that. Hopefully that doesn't mislead anyone.

 

We're using VitalQIP and not openDHCP, but I will see if I can find any manuals that specify if there's special encapsulation needed for this field. Perhaps QIP is expecting a different format, and surrounding the IP with quotes will force it to read it as ASCII.

 

As I responded to another individual, I am out until Monday but will see if I can get a coworker to perform a packet capture for me to upload.

Sure no problem have a nice weekend! 

1. The switch is able to ping the TFTP server. We checked this and even manually transferred it via TFTP.

 

2. I'm not scheduled to return to work until Monday, but I will see if I can get someone to perform a packet capture for me to attach here before then.

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:

 

This is the list of options requested by the 5406/5412

I tried to use Option 150 for specifying the TFTP server

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

Hi, Please use option 66 to specify TFTP server IP address.

Please refer the attached screen shot.

Hi, Please use option 66 to specify TFTP server IP address.

Please refer the attached screen shot.

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.

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)

Great, once you make appropriate changes on QIP, please  post your updates on this thread, so that it would be helpful for others, who hit these issues.

 

 

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?