MAC Adress table änderung bei LLDP-Paketen unter STP

[oweber]

Guten Tag zusammen,

wir haben in unserem Netzwerk mehrere Netgear-Netzwerkswitche untereinander verbunden und verwenden STP.

Angeschlossen ist außerdem ein Lancom-Router an mehrere der Switche, natürlich auch per STP.

Der Router hat 3 Verbindungen zu 3 verschiedenen Switchen. Der Router hat Switch 1 als Root-Path ausgewählt, 2 und 3 als alternative. Switch 1 ist ein GS728TPP, Switch 2 und 3 ein S3300 als Stack zusammengeschaltet.

Auf dem Router ist außerdem LLDP aktiviert. Ein Port-Trace zeigt, dass auf allen 3 Router-Ports LLDP-Pakete versendet werden.

Laut Norm IEEE 802.1AB-2005 zum LLDP ist das auch korrekt.

Nun zum Problem:

In der MAC Adress Table bei den Switchen 2 und 3 sollte jeweils zur MAC-Adresse des Routers der Port zu Switch 1 hinterlegt sein.

Empfängt nun Switch 2 oder 3 ein LLDP-Paket ändert sich jedoch in der Adress-Table der Port auf den direkten Router-Port.

In der Folge werden nun Datenpakete für den Router an den alternative-Port des Routers gesendet und dort verworfen.

Erst wenn vom Router ein Paket über den root-Port gesendet wird, wird die Adress-Table wieder korrekt gesetzt.

Meines Erachtens ist dies ein Fehler in der Behandlung von LLDP-Paketen.

Was kann man hier machen?

Mfg

A. Halbach

[DamianM]

Hallo @oweber,

willkommen in der NETGEAR Community!

In diesem Fall bräuchte ich von Dir eine genaue Zeichnung von Deiner Netzwerk-Topologie mit Modellbezeichnungen der Geräte. Könntest Du mir diese als Anhang schicken? 

Freundliche Grüße
DamianM
NETGEAR Team 
 

[oweber]

Hallo @DamianM,

anbei sende ich dir die Zeichnung von unserer Topologie.

Wie schon erwähnt soll die normale Route der Netzwerkpakete des Clients zum LANCOM-Router über den rot gekennzeichneten Pfad laufen.

Der Lancom sendet auf allen Ports LLDP-Pakete(alle 30 sek). Die S3300 werten diese Pakete so aus, dass sie die Adress-Table ändern.

Netzwerkpakete vom Client zum Router werden dann auf die alternative-Ports des Routers gesendet und dort verworfen.

Erst wenn der Router über den richtigen Pfad wieder ein Paket über den Switch sendet, wird die Adresstable zurück gesetzt und die Kommunikation klappt wieder korrekt. Ist also mehr oder weniger Zufall, ob und wann die Kommunikation funktioniert.

Das Abschalten von LLDP auf dem Router vermeidet das Problem.

Gruß

A. Halbach

[oweber]

Hallo @DamianM ,

ich habe das Problem nun mit einem Workaround gelöst. Das setzt allerdings voraus, dass VLAN verwendet wird.

Bei den Geräten, die STP verwenden sind auch alle Datennetze auf VLANs verteilt.

Die LLDP-Pakete werden ohne Tagging versendet. Daher habe ich nun die PVID auf ein leeres VLAN gesetzt und dieses ungetagged eingestellt. So wird nur in diesem VLAN die Adress-Table geändert, beeinflusst aber nicht die produktiven VLANs.

Eine weitere Möglichkeit wäre, den Port auf "VLAN only" zu setzen. Das habe ich allerdings noch nicht ausprobiert.

Dennoch sollte der Switch die LLDP-Pakete nicht für die Aktualisierung der Adress-Table verwenden.

Ich habe noch eine weitere Art von Paketen auf unserem Netzwerk entdeckt, die anscheinend von Netzwerkkarten selber versendet werden. Das sind SNMP-Traps scheinbar für irgendein veraltetes WfM-Protokoll(https://de.wikipedia.org/wiki/Wired_for_Management). Diese Pakete verändern auch die Adress-Table. Die kann ich aber nicht abschalten. Der oben genannte Workaround hilft hier aber auch.#

Mfg

A. Halbach

[DamianM]

Hallo @oweber,

ich freue mich, dass Du das Problem gelöst hast. 

Ich wünsche Dir einen schönen Nachmittag! 

Freundliche Grüße
DamianM
NETGEAR Team

[oweber]

Hallo @DamianM ,

grundsätzlich freue ich mich auch, dass ich einen Workaround gefunden habe, der in meinem speziellen Fall das Problem löst.

Das ist aber nicht die Antwort, die ich hier erwartet hatte.

Es gibt im Switch einen Fehler bei der Behandlung der LLDP-Pakete,

wodurch die Adress-Table geändert wird, obwohl es laut Standard nicht sein darf.

Es sollte im Sinne von Netgear sein, Fehler zu erkennen und zu beheben, vor allem für die Kunden.

Zumal dieser Workaround nur funktioniert, wenn VLANs verwendet werden. Ein Nutzer, der keine VLANs verwendet, wird hier nicht weiter kommen.

Gruß

A. Halbach