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

set_interface(): bestehende VLAN-Zuordnung kann nicht umgestellt werden (HTTP 400 Association exists) #1

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

Problem

_api_set_interface() legt eine VLAN-Port-Zuordnung immer per POST vlans-ports an, auch wenn der Port die VLAN bereits führt — nur eben in einem anderen Modus:

https://git.netork.io/christianmanivong/napalm-hpe-aruba-procurve/src/branch/master/napalm_procurve/procurve.py#L919-L932

payload = {"vlan_id": vid, "port_id": interface, "port_mode": "POM_TAGGED_STATIC"}
resp = self._api.post("vlans-ports", json=payload)
if not resp.ok and resp.status_code != 409:
    raise ConnectionException(
        f"set_interface({interface}): vlans-ports POST HTTP {resp.status_code}"
    )

Eine bestehende Zuordnung von untagged auf tagged umzustellen ist aber kein Anlegen, sondern eine Änderung. Am Gerät reproduziert (2530-24G-PoEP, REST v7):

POST vlans-ports {"vlan_id":10,"port_id":"10","port_mode":"POM_TAGGED_STATIC"}
  -> 400 {"message":"Association exists"}

PUT vlans-ports/10-10 {"vlan_id":10,"port_id":"10","port_mode":"POM_UNTAGGED"}
  -> 200 {"uri":"/vlans-ports/10-10",...}

Die Ressource heisst {vlan_id}-{port_id} und akzeptiert PUT. Abgefangen wird bisher nur 409; diese Firmware antwortet mit 400.

Auswirkung

Jeder Versuch, einen Port für eine VLAN von untagged auf tagged zu setzen (oder umgekehrt), scheitert. Genau der übliche Fall: Port 10 führt VLAN 10 untagged plus 30/40/50 tagged, und VLAN 10 soll ebenfalls tagged werden.

{"uri": "/vlans-ports/10-10", "vlan_id": 10, "port_id": "10", "port_mode": "POM_UNTAGGED"}
{"uri": "/vlans-ports/30-10", "vlan_id": 30, "port_id": "10", "port_mode": "POM_TAGGED_STATIC"}

Erschwerend: die Fehlermeldung verschluckt den Antworttext. Der ports-PUT unmittelbar darüber hängt resp.text[:200] an, dieser Zweig nicht — dabei stand die Antwort mit "Association exists" direkt daneben und hätte die Ursache sofort genannt.

Lösungsvorschlag

Besteht die Zuordnung bereits, per PUT vlans-ports/{vlan_id}-{port_id} den Modus ändern statt ein Duplikat anzulegen. Beide Zweige (trunk und access) sind betroffen. Und den Antworttext in die Fehlermeldung aufnehmen, wie es der Zweig darüber schon tut.

## Problem `_api_set_interface()` legt eine VLAN-Port-Zuordnung immer per `POST vlans-ports` an, auch wenn der Port die VLAN bereits führt — nur eben in einem anderen Modus: https://git.netork.io/christianmanivong/napalm-hpe-aruba-procurve/src/branch/master/napalm_procurve/procurve.py#L919-L932 ```python payload = {"vlan_id": vid, "port_id": interface, "port_mode": "POM_TAGGED_STATIC"} resp = self._api.post("vlans-ports", json=payload) if not resp.ok and resp.status_code != 409: raise ConnectionException( f"set_interface({interface}): vlans-ports POST HTTP {resp.status_code}" ) ``` Eine bestehende Zuordnung von untagged auf tagged umzustellen ist aber kein Anlegen, sondern eine Änderung. Am Gerät reproduziert (2530-24G-PoEP, REST v7): ``` POST vlans-ports {"vlan_id":10,"port_id":"10","port_mode":"POM_TAGGED_STATIC"} -> 400 {"message":"Association exists"} PUT vlans-ports/10-10 {"vlan_id":10,"port_id":"10","port_mode":"POM_UNTAGGED"} -> 200 {"uri":"/vlans-ports/10-10",...} ``` Die Ressource heisst `{vlan_id}-{port_id}` und akzeptiert PUT. Abgefangen wird bisher nur `409`; diese Firmware antwortet mit `400`. ## Auswirkung Jeder Versuch, einen Port für eine VLAN von untagged auf tagged zu setzen (oder umgekehrt), scheitert. Genau der übliche Fall: Port 10 führt VLAN 10 untagged plus 30/40/50 tagged, und VLAN 10 soll ebenfalls tagged werden. ``` {"uri": "/vlans-ports/10-10", "vlan_id": 10, "port_id": "10", "port_mode": "POM_UNTAGGED"} {"uri": "/vlans-ports/30-10", "vlan_id": 30, "port_id": "10", "port_mode": "POM_TAGGED_STATIC"} ``` Erschwerend: die Fehlermeldung verschluckt den Antworttext. Der `ports`-PUT unmittelbar darüber hängt `resp.text[:200]` an, dieser Zweig nicht — dabei stand die Antwort mit `"Association exists"` direkt daneben und hätte die Ursache sofort genannt. ## Lösungsvorschlag Besteht die Zuordnung bereits, per `PUT vlans-ports/{vlan_id}-{port_id}` den Modus ändern statt ein Duplikat anzulegen. Beide Zweige (`trunk` und `access`) sind betroffen. Und den Antworttext in die Fehlermeldung aufnehmen, wie es der Zweig darüber schon tut.
christianmanivong commented 2026-08-18 09:36:42 +00:00
Author
Owner
Copy Link
Copy Source

Behoben in e3bbac0, ausgeliefert mit NetOrk v0.19.1 und auf 10.10.0.100 deployt

_api_set_port_vlan() versucht weiterhin zuerst den POST und weicht bei „Zuordnung existiert bereits" auf PUT vlans-ports/{vlan_id}-{port_id} aus. Beide Statuscodes gelten dabei als dieses Signal — v7 antwortet 400, andere Firmware 409. Der Antworttext hängt jetzt an beiden Fehlermeldungen.

Am Gerät verifiziert

2530-24G-PoEP, REST v7. Zuerst der ursprüngliche Fehler reproduziert:

POST vlans-ports {"vlan_id":10,"port_id":"10","port_mode":"POM_TAGGED_STATIC"}
  -> 400 {"message":"Association exists"}
PUT  vlans-ports/10-10 (unveränderter Wert)
  -> 200 {"uri":"/vlans-ports/10-10","vlan_id":10,"port_id":"10","port_mode":"POM_UNTAGGED"}

Danach mit dem Fix, bewusst idempotent gewählt — VLAN 30 ist auf Port 10 bereits tagged, der Aufruf hätte also vorher denselben 400 geworfen:

set_interface("10", {"mode": "trunk", "trunk_vlans": [30]})  -> ok, keine Exception

/vlans-ports/10-10  vlan 10  POM_UNTAGGED
/vlans-ports/30-10  vlan 30  POM_TAGGED_STATIC
/vlans-ports/40-10  vlan 40  POM_TAGGED_STATIC
/vlans-ports/50-10  vlan 50  POM_TAGGED_STATIC

Zustand unverändert. VLAN 10 auf Port 10 wurde absichtlich nicht angefasst — siehe unten.

Tests: TestApiSetInterfaceExistingMembership (6) — PUT-Rückfall bei 400 und bei 409, für trunk und access, kein PUT wenn der POST durchgeht, und der Antworttext in beiden Fehlerpfaden. Suite: 63 passed.

Warnung zum eigentlichen Vorhaben

Port 10 an swt-home-core führt zu ap-home-1og, und dieser AP erwartet VLAN 10 untagged (eth0:u* auf br-ap). Stellt man den Port jetzt — mit dem funktionierenden Fix — auf tagged, verliert der AP seine Management-Erreichbarkeit. Erst die AP-Seite umstellen oder den globalen Schalter ap_management_vlan_untagged entsprechend setzen.

## Behoben in e3bbac0, ausgeliefert mit NetOrk v0.19.1 und auf 10.10.0.100 deployt `_api_set_port_vlan()` versucht weiterhin zuerst den POST und weicht bei „Zuordnung existiert bereits" auf `PUT vlans-ports/{vlan_id}-{port_id}` aus. Beide Statuscodes gelten dabei als dieses Signal — v7 antwortet `400`, andere Firmware `409`. Der Antworttext hängt jetzt an beiden Fehlermeldungen. ## Am Gerät verifiziert 2530-24G-PoEP, REST v7. Zuerst der ursprüngliche Fehler reproduziert: ``` POST vlans-ports {"vlan_id":10,"port_id":"10","port_mode":"POM_TAGGED_STATIC"} -> 400 {"message":"Association exists"} PUT vlans-ports/10-10 (unveränderter Wert) -> 200 {"uri":"/vlans-ports/10-10","vlan_id":10,"port_id":"10","port_mode":"POM_UNTAGGED"} ``` Danach mit dem Fix, bewusst idempotent gewählt — VLAN 30 ist auf Port 10 bereits tagged, der Aufruf hätte also vorher denselben 400 geworfen: ``` set_interface("10", {"mode": "trunk", "trunk_vlans": [30]}) -> ok, keine Exception /vlans-ports/10-10 vlan 10 POM_UNTAGGED /vlans-ports/30-10 vlan 30 POM_TAGGED_STATIC /vlans-ports/40-10 vlan 40 POM_TAGGED_STATIC /vlans-ports/50-10 vlan 50 POM_TAGGED_STATIC ``` Zustand unverändert. VLAN 10 auf Port 10 wurde absichtlich **nicht** angefasst — siehe unten. Tests: `TestApiSetInterfaceExistingMembership` (6) — PUT-Rückfall bei 400 und bei 409, für `trunk` und `access`, kein PUT wenn der POST durchgeht, und der Antworttext in beiden Fehlerpfaden. Suite: 63 passed. ## Warnung zum eigentlichen Vorhaben Port 10 an `swt-home-core` führt zu `ap-home-1og`, und dieser AP erwartet VLAN 10 **untagged** (`eth0:u*` auf `br-ap`). Stellt man den Port jetzt — mit dem funktionierenden Fix — auf tagged, verliert der AP seine Management-Erreichbarkeit. Erst die AP-Seite umstellen oder den globalen Schalter `ap_management_vlan_untagged` entsprechend setzen.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
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-hpe-aruba-procurve#1