02-22-2017 09:10 AM - edited 02-27-2017 07:14 AM
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?
Solved! Go to Solution.
02-22-2017 12:41 PM
I created this document a long time ago maybe it can help you. Let me know if you still have questions.
02-22-2017 12:48 PM - edited 02-22-2017 12:48 PM
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.
02-23-2017 12:57 AM
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.
02-23-2017 03:13 AM
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?
02-23-2017 03:32 AM
Aruba Airheads - Powered By community for empower the community
************ Don't Forget to Kudos + me,If i helped you******************
02-23-2017 08:03 AM
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.
02-23-2017 08:08 AM
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.