NAPALM/napalm-netgear
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

get_config() liefert die Uptime mit — jeder Vergleich meldet eine Änderung #2

New Issue
Closed
opened 2026-08-18 03:29:00 +00:00 by christianmanivong · 1 comment
christianmanivong commented 2026-08-18 03:29:00 +00:00
Owner
Copy Link
Copy Source

Problem

get_config() gibt die Ausgabe von show running-config unverändert zurück. Der Kopf dieser Ausgabe enthält auf Smart-Managed-Switches einen Kommentarblock mit Laufzeitzustand:

show running-config
SYSTEM CONFIG FILE ::= BEGIN
! Model: GS110TPv3
! System Description: GS110TPv3 8-Port Gigabit Smart Managed Pro Switch with PoE+ and 2 SFP Ports
! Firmware Version: 7.1.1.17 [Apr 16 2026 - 17:26:24]
! Loader Version: 1.0.0.5 [2019-03-15 17:08:23 UTC]
! Config Version: 0
! Hardware Version: 0
! System Name:
! MAC Address: 28:94:01:6D:26:7D
! Serial Number: 7LE4535SA0117
! System Up Time: 3 days, 9 hours, 22 mins, 45 secs      <-- Zustand, keine Konfiguration
!

! System Up Time: ändert sich zwangsläufig zwischen zwei Abfragen. Alle übrigen Zeilen des Blocks sind stabil und gehören zu Recht in ein Konfigurations-Backup — eine geänderte Firmware-Version ist eine meldenswerte Änderung.

Auswirkung

Jeder Aufrufer, der zwei Abfragen vergleicht, sieht bei jedem Durchlauf eine Änderung. In NetOrk erzeugt das pro Poll einen Git-Commit im Konfigurations-Backup und eine config_changed-Warnung am Gerät. Gemessen auf dem betroffenen GS110TPv3:

hostname     | driver        | snapshots | changed
swt-eze-core | netgear_smart |       894 |     876

876 von 894 Snapshots als geändert markiert — praktisch jeder Poll. Zum Vergleich liegen alle anderen Geräte derselben Installation zwischen 2 und 18. Die Historie ist damit für dieses Gerät wertlos: eine echte Konfigurationsänderung wäre zwischen hunderten Uptime-Diffs nicht auffindbar.

Nur netgear_smart ist betroffen. netgear_plus.get_config() liefert durchgehend leere Strings.

Lösungsvorschlag

Die Uptime-Zeile in get_config() verwerfen. Bewusst nur diese eine Zeile — die restlichen Kopfzeilen sind stabil und ihr Wegfall würde Informationen aus dem Backup entfernen.

Zu beachten: der Fix erzeugt beim ersten Poll nach dem Update einmalig eine echte Änderung, weil die Zeile aus der gespeicherten Config verschwindet. Das ist unvermeidbar und einmalig.

## Problem `get_config()` gibt die Ausgabe von `show running-config` unverändert zurück. Der Kopf dieser Ausgabe enthält auf Smart-Managed-Switches einen Kommentarblock mit Laufzeitzustand: ``` show running-config SYSTEM CONFIG FILE ::= BEGIN ! Model: GS110TPv3 ! System Description: GS110TPv3 8-Port Gigabit Smart Managed Pro Switch with PoE+ and 2 SFP Ports ! Firmware Version: 7.1.1.17 [Apr 16 2026 - 17:26:24] ! Loader Version: 1.0.0.5 [2019-03-15 17:08:23 UTC] ! Config Version: 0 ! Hardware Version: 0 ! System Name: ! MAC Address: 28:94:01:6D:26:7D ! Serial Number: 7LE4535SA0117 ! System Up Time: 3 days, 9 hours, 22 mins, 45 secs <-- Zustand, keine Konfiguration ! ``` `! System Up Time:` ändert sich zwangsläufig zwischen zwei Abfragen. Alle übrigen Zeilen des Blocks sind stabil und gehören zu Recht in ein Konfigurations-Backup — eine geänderte Firmware-Version *ist* eine meldenswerte Änderung. ## Auswirkung Jeder Aufrufer, der zwei Abfragen vergleicht, sieht bei jedem Durchlauf eine Änderung. In NetOrk erzeugt das pro Poll einen Git-Commit im Konfigurations-Backup und eine `config_changed`-Warnung am Gerät. Gemessen auf dem betroffenen GS110TPv3: ``` hostname | driver | snapshots | changed swt-eze-core | netgear_smart | 894 | 876 ``` 876 von 894 Snapshots als geändert markiert — praktisch jeder Poll. Zum Vergleich liegen alle anderen Geräte derselben Installation zwischen 2 und 18. Die Historie ist damit für dieses Gerät wertlos: eine echte Konfigurationsänderung wäre zwischen hunderten Uptime-Diffs nicht auffindbar. Nur `netgear_smart` ist betroffen. `netgear_plus.get_config()` liefert durchgehend leere Strings. ## Lösungsvorschlag Die Uptime-Zeile in `get_config()` verwerfen. Bewusst nur diese eine Zeile — die restlichen Kopfzeilen sind stabil und ihr Wegfall würde Informationen aus dem Backup entfernen. Zu beachten: der Fix erzeugt beim ersten Poll nach dem Update einmalig eine echte Änderung, weil die Zeile aus der gespeicherten Config verschwindet. Das ist unvermeidbar und einmalig.
christianmanivong commented 2026-08-18 03:49:18 +00:00
Author
Owner
Copy Link
Copy Source

Behoben in 5317af0, ausgeliefert mit NetOrk v0.18.1 und auf 10.10.0.100 deployt

get_config() verwirft die Uptime-Zeile jetzt aus running und startup. Bewusst nur diese eine Zeile — Model, Firmware, Serial und MAC sind stabil und gehören ins Backup.

Tests: TestGetConfigDropsRuntimeState (6), darunter der eigentliche Punkt — zwei Leseoperationen mit unterschiedlicher Uptime müssen gleich vergleichen — sowie die Zusicherung, dass die stabilen Kopfzeilen und die eigentliche Konfiguration erhalten bleiben. Suite: 72 passed.

Nach dem Deploy verifiziert

Gespeicherte Config des betroffenen GS110TPv3, die Uptime-Zeile ist fort, der Rest unverändert:

! Model: GS110TPv3
! Firmware Version: 7.1.1.17 [Apr 16 2026 - 17:26:24]
! MAC Address: 28:94:01:6D:26:7D
! Serial Number: 7LE4535SA0117
!

Drei Polls hintereinander ausgeführt. Der erste erzeugte den erwarteten einmaligen Commit:

2026-08-18 03:45:27 +0000
 config.txt | 1 -
 1 file changed, 1 deletion(-)
-! System Up Time: 3 days, 10 hours, 23 mins, 55 secs

Die beiden folgenden Polls erzeugten gar keinen Commit mehr. Damit ist der Effekt bestätigt.

Nebenbefund

Der Commit unmittelbar davor zeigt, was in dem Rauschen bisher unterging — eine echte Konfigurationsänderung an diesem Switch:

- switchport hybrid allowed vlan add 30,40,50 tagged
- switchport hybrid allowed vlan add 10 untagged
+ switchport hybrid allowed vlan add 10,30,40,50 tagged

Genau der Fall, für den die Historie da ist, und genau der, der zwischen 876 Uptime-Diffs nicht auffindbar war.

## Behoben in 5317af0, ausgeliefert mit NetOrk v0.18.1 und auf 10.10.0.100 deployt `get_config()` verwirft die Uptime-Zeile jetzt aus `running` und `startup`. Bewusst nur diese eine Zeile — Model, Firmware, Serial und MAC sind stabil und gehören ins Backup. Tests: `TestGetConfigDropsRuntimeState` (6), darunter der eigentliche Punkt — zwei Leseoperationen mit unterschiedlicher Uptime müssen gleich vergleichen — sowie die Zusicherung, dass die stabilen Kopfzeilen und die eigentliche Konfiguration erhalten bleiben. Suite: 72 passed. ## Nach dem Deploy verifiziert Gespeicherte Config des betroffenen GS110TPv3, die Uptime-Zeile ist fort, der Rest unverändert: ``` ! Model: GS110TPv3 ! Firmware Version: 7.1.1.17 [Apr 16 2026 - 17:26:24] ! MAC Address: 28:94:01:6D:26:7D ! Serial Number: 7LE4535SA0117 ! ``` Drei Polls hintereinander ausgeführt. Der erste erzeugte den erwarteten einmaligen Commit: ``` 2026-08-18 03:45:27 +0000 config.txt | 1 - 1 file changed, 1 deletion(-) -! System Up Time: 3 days, 10 hours, 23 mins, 55 secs ``` Die beiden folgenden Polls erzeugten **gar keinen Commit** mehr. Damit ist der Effekt bestätigt. ## Nebenbefund Der Commit unmittelbar davor zeigt, was in dem Rauschen bisher unterging — eine echte Konfigurationsänderung an diesem Switch: ``` - switchport hybrid allowed vlan add 30,40,50 tagged - switchport hybrid allowed vlan add 10 untagged + switchport hybrid allowed vlan add 10,30,40,50 tagged ``` Genau der Fall, für den die Historie da ist, und genau der, der zwischen 876 Uptime-Diffs nicht auffindbar war.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something is broken
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
christianmanivong
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: NAPALM/napalm-netgear#2