Inconsistent Value: ArubaOS Switches Refuse Configuration

When reconfiguring a previously unused interface, the Aruba 2930M switch cluster refused to change the default (untagged) VLAN. Whether through CLI, VLAN menu, or WebGUI, the default VLAN 1 was not replaced. The CLI always displayed the error message “Inconsistent Value.” Here are some examples:

A2930M(config)# VLAN 123
A2930M(vlan-123)# untagged 3/A1
3/A1: Inconsistent value.

A2930M(config)# int 3/A1 untagged vlan 123
123: Inconsistent value.

Researching the error message “Inconsistent Value” in connection with ArubaOS yielded rather disappointing results: In an HPE forum, a user reported that a reload solved the problem. Elsewhere, it was recommended to completely delete the Running-Config and then rebuild the configuration. We wanted to avoid this since the switch was in productive operation.

In our case, after some trial and error, it became apparent that the configuration of VLAN 1 was likely corrupt. Although we could not find any discrepancies in the running config, it eventually became clear that only configurations directly or indirectly affecting VLAN 1 triggered this error message. The assumption was that there might be an “applied config” alongside the Running-Config that resides directly on the hardware. This shadow configuration is now likely inconsistent, and the error message “Inconsistent Value” probably referred to this.

Solution Approach – Reimporting the Running-Config

Our approach was to get the switch to reapply the running config to the shadow configuration before we had to completely rebuild the cluster. The idea was to save the current Running-Config via the configuration management in the WebGUI and then reimport it as a new configuration. Simply overwriting the existing configuration file is not enough, as the switch performs a differential import during the import process. In our case, the recently exported Running-Config does not differ from the “config1” configuration. Therefore, no changes occur to the “shadow config.”

To bypass the differential import, you can rename the downloaded configuration file locally and upload it as a new file. Then, the configuration can be completely written into the Running-Config (and thus also into the “shadow configuration”) using the “cfg-restore” command via CLI.

A2930M(config)# show config files

Configuraton files:
id | act pri sec | name
--------------------------------------------------------------------------------
1  |  *   *   *  | config1
2  |             | config2
3  |             |
4  |             |
5  |             |

A2930M(config)# cfg-restore flash config2
Current running-configuraton will be replaced with 'config2'.
Continue (y/n)? y
Configuration restore is in progress, configuration changes are temporarily disabled.

Successfully applied configuration 'config2' to running configuration.

In our case, after importing the configuration via “cfg-restore,” the desired configuration change could be made. This solved the problem without having to rebuild or reboot the switch stack.

To what extent this solution can be applied to other ArubaOS switches, I cannot say.

Sources:

• https://community.hpe.com/t5/switches-hubs-and-modems/quot-inconsistent-value-quot-response/td-p/3998635
• https://community.arubanetworks.com/discussion/2930f-untagged-vlan
• https://higherlogicdownload.s3.amazonaws.com/HPE/MigratedAssets/Config_Restore_without_Reboot.pdf
• Article Picture: https://pixabay.com/photos/code-coding-computer-data-1839406/