Inconsistent Value: ArubaOS Switches verweigern Konfiguration

Bei der Neukonfiguration eines bisher ungenutzten Interfaces, verweigerte der Aruba 2930M Switch-Clusters die Änderung des Default (Untagged) VLANs. Egal ob über CLI, VLAN-Menü aber auch über das WebGUI das Default-VLAN 1 wurde nicht ersetzt. Bei der CLI wird immer die Fehlermeldung «Incosnsistent Value» ausgegeben. Nachfolgend einige Beispiele:

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.

Eine Recherche zur Fehlermeldung «Inconsistent Value» im Zusamenhang mit ArubaOS brachte eher ernüchternde Resultate: In einem HPE-Forum hat ein Benutzer berichtet, dass ein Reload das Problem gelöst hat. Andernorts wird auch das komlette Löschen der Running-Config und ein anschliessender Neuaufbau der Konfiguration empfohlen. Dies wollten wir vermeden, da der Switch sich im Produktivbetrieb befand.

In unserem Fall zeigte sich nach einigem herumprobieren, dass wohl die Konfigruation des VLAN 1 korrupt ist. In der Running-Config konnten wir zwar keine Abweichungen feststellen, es war jedoch irgendwann offensichtlich, dass nur Konfigurationen die direkt oder indirekt das VLAN 1 beeinflussen diese Fehlermeldung provozieren. Die Vermutung war dann, dass es vermutlich noch eine Art «Applied-Config» neben der Running-Config gibt welche direkt auf der Hardware liegt. Diese Schattenkonfiguration ist nun wohl inkonistent. Und die Fehlermeldung «Inconsistent Value» bezog sich wohl darauf.

Lösungsansatz – Reimport der Running-Config

Unser Lösungsansatz war, bevor wir den Cluster komplett neu aufsetzen müssen, den Switch irgendwie dazu zu bringen die Running-Config neu in die die Schatten-Konfiguration. Die Idee war die aktuelle Running-Config über das Configuration-Management im WebGUI zu sichern und dann als neue Konfiguration wieder zu importieren. Dabei reicht es nicht die bestehende Konfigurations-Datei zu überschreiben, da der Switch dann beim Import bloss ein differenzieller Import durchführt. In unserem Fall unterscheidet sich die eben exportierte Running-Config nicht von der Konfiguration «config1». Deshalb geschehen auch keine Änderungen an der «Schatten-Config».

Den Differenziellen Import kann man umgehen in dem man die heruntergeladene Konfigurationsdatei lokal umbenennt und als neue Datei wieder hochlädt. Dann lässt sich die Konfiguration über den Befehl «cfg-restore» via CLI komplett in die Running-Config (und damit auch in die «Schatten-Konfiguration») schreiben.

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 unserem Fall liess sich nach dem Import der Konfiguration über «cfg-restore» die gewünschte Konfigurationsänderung vornehmen. Das Problem liess sich so ohne neuaufsetzen oder Reboot des Switch-Stacks lösen.

Inwiefern sich diese Problemlösung auf andere ArubaOS-Switches anwenden lässt kann ich nicht sagen.

Danke!

Vielen Dank an Robin, Herby und 2x Dani für die Unterstützung.

Quellen:

• 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
• Artikelbild: https://pixabay.com/photos/code-coding-computer-data-1839406/