Vatsal Panchal (Customer) asked a question.
Hi everyone,
I’m looking for guidance on how to use the Configuration Management module in WhatsUp Gold to automate firmware upgrades for HP/HPE switches.
My goal is to select a group of HP switches and automate the firmware upgrade process based on the switch model and current firmware version. Since the group may contain different HP switch models, I would like the automation to:
- Identify the switch model.
- Check the current firmware version.
- Apply the appropriate firmware image based on the model/version.
- Transfer the firmware image from our TFTP server.
- Perform the required boot/reload commands.
- Reconnect to the switch after the reboot.
- Verify that the firmware upgrade was successful.
- Report or log the upgrade status for each device.
I have been reviewing the Configuration Management scripting functionality, including variables,
@IF
/
@ENDIF
,
@connect
,
@read
, and related commands. However, I’m having difficulty determining the correct way to implement conditional logic and firmware upgrade workflows for HP switches.
For example, if the selected device is an Aruba 2930F, I would want WUG to detect the model and current firmware, then execute the appropriate upgrade commands. For a different HP model, it should follow a different firmware workflow.
Has anyone successfully implemented automated HP/HPE switch firmware upgrades using WUG Configuration Management?
If so, could you please share an example or recommended approach for:
- Model detection
- Firmware-version comparison
- Conditional execution using
- @IF
- /
- @ENDIF
- Handling the switch reboot and reconnection
- Post-upgrade firmware verification
Any examples, documentation, or recommended scripting practices would be greatly appreciated.
Thank you!
First the help file for the @if says,
"The @if command checks to see if a variable exists. If the variable exists, the lines of script following @if <variable> are executed until @endif is reached in the code. If the variable following @if does not exist, the proceeding lines of script are skipped until @endif is reached."
Variables in Configuration management are set statically in the script, as the help shows, "FirstUSPresident = The Honorable George Washington" so when you call in the script "$(FirstUSPresident)" would be replaced by "The Honorable George Washington". There are a few things what you can assign to a variable when the script runs, but those are values which come from Config. Man.: https://docs.progress.com/bundle/whatsup-gold-custom-scripting/page/Using-variables-with-Configuration-Management-templates.html
Way to do it would be use create an SNMP monitor to get the information you want, most is in the SysDescr, OID 1.3.6.1.2.1.1.1. Some systems have an actual OID which shows the OS version by itself. Then when the monitor goes down, because the version doesn't match what you want, you fire the Configuration Management Action and have it fire the appropriate task/script you want.
Config. Man. currently isn't very interactive with the @if. You could enter a feature request or vote up one which already exists: https://whatsupgold.ideas.aha.io/ideas
Thanks @Mike Rockwell (Progress Software) , I appreciate the explanation about how @IF works in Configuration Management.
The SNMP monitor approach is not suitable for our network environment because we do not want firmware upgrades to be triggered automatically based on monitoring status. We want to maintain control over when firmware upgrades are performed. Our monitoring is primarily used to verify whether the devices are online and reachable.
Our requirement is to select a group of switches and manually initiate the Configuration Management action when we are ready to perform an upgrade. Since the selected group may contain different HP/HPE switch models, the workflow should ideally be able to:
Since Configuration Management has limitations with @IF, is there a recommended way to accomplish this as a manual, group-based process without using an SNMP monitor to trigger the upgrade?
Would it also be possible to create the firmware-upgrade workflow externally using Python or Ansible and integrate it with WhatsUp Gold? For example, could WUG Configuration Management, an API, or another WUG feature trigger an external Python/Ansible script against the selected devices and then return the upgrade status/results back to WUG?
If this type of integration is supported, could you please point me to the recommended API, integration method, or documentation for implementing it?
Any guidance, examples, or recommendations for designing this type of controlled firmware-upgrade workflow would be greatly appreciated.
Thanks again!
You could use Python to connect to the WUG Rest API to get the info about the device, then launch the upgrades.
You could create a WUG dynamic group for the devices which has the attribute for the OS version to group them, then create a task in Config management to push the updates from the SFTP server. Which you don't have to schedule, just apply it to the group then run it ...
Thank you for your response. The dynamic grouping approach is a great idea, and I have been testing it in our environment.
However, I am experiencing some challenges with device attributes, specifically the Default column in the Attributes tab. My dynamic group SQL query depends on this value being set to Yes to identify the correct attribute value.
After upgrading a switch firmware and rescanning the device, I noticed inconsistent behavior. When the Default value changes to No, the attribute continues to display the old firmware version instead of updating to the current version. I tested this with two devices: the Default value remained Yes for one device but changed to No for the other after rescanning.
I am also experiencing another issue with the rescan process. After rescanning a device, WhatsUp Gold displays additional interfaces that are not relevant to our monitoring requirements. We would like to retain the existing interface configuration and avoid adding these unnecessary interfaces. I tried disabling the checkbox in the rescan options intended to preserve the existing interfaces, but it did not resolve the issue.
Could you please advise on the following?
Any recommendations on the correct configuration or best practices for managing these attributes and interfaces would be greatly appreciated.
Thank you for your help!
Try running a "reset device" with the refresh attributes checked.
By running Replace Device->refresh Attributes It refreshes attributes but also it refreshes the Interfaces and Name of the device. I do not see any checkbox when I click on reset device.
Maybe that was the one I was thinking of. I just tested my machine and here is what I did. I deleted the Description attribute. Then I rescanned the machine, just did a basic rescan. The description came back with the new info in it.
The problem is Basic Rescan also Scanning the VLAN and unusable Interfaces. For most of our switches we have removed VLAN Interfaces as well as unused Interfaces. When I do basic rescan it all changes that Interface details.
Would have to do an SNMP monitor to look to see if the version has changed ... and then fire an action if it has.
By basic scan it is changing the Version in Description Attribute in the switch, but it is also updating the Interfaces from Active monitors. We have removed many Interfaces from Monitor, but when I rescan the switch, it again shows that all the Interfaces in active monitor.