falsche MAC-TABLE aktualisierung von GS-3126X/XP ?

[JoP75]

Wir haben ein seltsames Phänomen seit der Umstellung auf GS-3126X/XP Switche im Client-Access Bereich:

Mehrere GS-3126X / XP Switche hängen jeweils über einen LACP-Portchannel an einem Dell N2248 Switch als Uplink-Switch zu den Access-Switchen (Po15,17,21). Hinter dessen Uplink zum Core-Switch (in unserem Fall Po2) hängt unsere Firewall als defGW des Client-Netzes (VLAN1).

In regelmäßigen Abständen tauchen vor allem vormittags MAC_MOVEs auf dem Uplink-Switch auf, bei denen angeblich die MAC-Adresse des VLAN1 stdGW (hier 00:XX:XX:XX:XX:XX) von den Port-Channeln der Lancom-Access-Switche kommt - bzw. über die Port-Channel wandert:

<190> Mar 18 07:51:47 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84902 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XX in VLAN: 1 is overwritten from entryType 1 to 1 and port Po21 to Po2
<190> Mar 18 07:51:44 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84901 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XX in VLAN: 1 is overwritten from entryType 1 to 1 and port Po2 to Po21
<190> Mar 18 07:51:41 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84900 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XX in VLAN: 1 is overwritten from entryType 1 to 1 and port Po21 to Po2
<190> Mar 18 07:51:34 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84899 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XX in VLAN: 1 is overwritten from entryType 1 to 1 and port Po15 to Po21
<190> Mar 18 07:51:22 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84863 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XX in VLAN: 1 is overwritten from entryType 1 to 1 and port Po2 to Po15
<190> Mar 18 07:45:59 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84852 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XX in VLAN: 1 is overwritten from entryType 1 to 1 and port Po15 to Po2
<190> Mar 18 07:45:56 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84851 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XX in VLAN: 1 is overwritten from entryType 1 to 1 and port Po17 to Po15
<190> Mar 18 07:45:53 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84850 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XX in VLAN: 1 is overwritten from entryType 1 to 1 and port Po15 to Po17
<190> Mar 18 07:45:46 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84849 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XXin VLAN: 1 is overwritten from entryType 1 to 1 and port Po17 to Po15
<190> Mar 18 07:45:43 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84848 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XXin VLAN: 1 is overwritten from entryType 1 to 1 and port Po2 to Po17
<190> Mar 18 07:45:37 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84847 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XX in VLAN: 1 is overwritten from entryType 1 to 1 and port Po15 to Po2
<190> Mar 18 07:45:34 BLRZ2SW10-1 FDB[dtlAddrTask]: fdb.c(690) 84846 %% INFO MAC_MOVE: Mac 00:XX:XX:XX:XX:XX in VLAN: 1 is overwritten from entryType 1 to 1 and port Po2 to Po15

Das hat bei allen Clients im VLAN1 nun einen kurzen Verbindungsabbruch zum/über den VLAN1 GW zur Folge - bis die MAC wieder auf den Po2 registriert ist.

Daraufhin haben wir einen Teil der VLAN1-Geräte nach uns nach in ein separates VLAN gepackt, bis es irgendwann auch dort losging - nur eben mit der MAC des stdGW Test-VLAN3.

Inzwischen konnten wir als Auslöser für das Problem auf eine Handvoll Windows-Notebooks einschränken, die über eine Dock mit ‚Realtek USB Family Controller‘ (VID 0BDA, PID 8153 / Rev. 3011 bzw. 3111) angeschlossen sind, bzw. den Effekt bei den Geräten nachstellen (sobald der Port an einem GS-3126 'up' kommt). Schließe ich die betroffen Geräte mit dem Geräteinternen NIC (Intel-Chipset) an, passiert nichts negatives.

Gibt s hier bekannte Inkompatibilitäten zwischen Realtek-Chipsätzen oder konkret "RTL8153 Gigabit Ethernet Adapter" und dem Chipsatz in dem GS-3126X/XP verbauten Switchen ? Oder an den Realtek-Treiberversionen für Win11 (1153.10.20.1104 bzw. 1153.17.20.1030) ?

Wir hätten die MAC-MOVEs auf den GS-3126 switchen auch gerne konkret überprüft. Per Syslog kommt man wohl nicht an die Änderungen der MAC-Tabellen auf den Switchen ran (beim Dell-Switch ist das per std. bei Info mit drin). Gibt es hier eine andere Möglichkeit an die Änderungshistorie der MAC-Tabellen auf den GS-3126 Switchen zu kommen ?

Viele Grüße
Jochen

[lna]

Moin Jochen,
um die MAC Tabelle im Switch zu beobachten könntest du dir die SNMP Traps für macadd und macdel schicken lassen.

Code: Alles auswählen

SW-Access-Keller(config)# snmp-server trap ?
    <cword>    Valid words are 'authenticationFailure' 'cmnHistMacChangedMsg'
               'coldStart' 'entConfigChange' 'fallingAlarm' 'linkDown' 'linkUp'
               'lldpRemTablesChange' 'macAdd' 'macDel' 'newRoot' 'risingAlarm'
               'topologyChange' 'warmStart'

Ich habe das Szenario aus deinem Text mal visualisiert, damit ich es mir besser vorstellen kann und wir eine gemeinsame Grundlage haben.
Damit das Gateway zwischen den Links PO21 und PO2 (rot) flappen kann, betroffene Switch das Gateway über zwei Wege lernen können. Ich vermute also, dass du noch ein weiteres Kabel (gestrichelt) entweder zwischen GS-36xx und Core oder zwischen GS-36xx und einer Bridgegroup der Firewall stecken hast (ggf. unbeabsichtigt).
Schau dir mal die Einstellungen und Logs von Spanning-Tree, Loop-Protection, UDLD an (soweit auf den jeweiligen switch zutreffend).

MAC Move sollte man eigentlich nur sehen wenn Roaming stattfindet (Client per WLAN am nächsten AP, Virtuelle Maschine auf einen anderen Hypervisor verschoben, Client abgesteckt und an einer neuen Netzwerkdose angeschlossen)
Wenn die Firewall keine VM ist und nicht Sekündlich verschoben wird, sollte sie im Regelbetrieb nicht über einen anderen Port gelernt werden.

Das Problem wird vermutlich nicht durch die Docks ausgelöst sondern liegt eher in der Netzwerktopologie, die Laptops mit Dock schienen nur intensiver zu reagieren.

t_21021.png

[JoP75]

Hallo Lukas,

danke für die Antwort.

Wir haben alle an den Lancom-Switchen angeschlossenen Access-Ports kontrolliert. An allen Ports hängen definitiv nur Clients.
Ich hatte zum Test ein Notebook über die Dock auf einen separaten Lancom-Switch angeschlossen (kein anderer Port ausser die Uplinks up) - trotzdem lief der MAC-Move auch über den Uplink dieses Switches.
Außerdem hatten wir dann einen Teil der Clients in einem separaten VLAN betrieben (i.d.R. IGEL ThinClients). Der MAC_MOVE trat erst auf, sobald ein Notebook über den Dock/Chipsatz reinkam.

Ich versuch mal über die SNMP-Traps zu loggen und zu ermitteln welcher Access-Port das auslöst.
Danke für den Tipp.

Viele Grüße
Jochen

[lna]

Hallo Jochen,
wenn du das so eng auf einzelne Endgeräte eingrenzen kannst, mal den Port spiegeln, auf dem das Dock angeschlossen wird und mit Wireshark aufzeichnen.
Wenn das Dock den MAC_MOVE verursacht, dann muss das ja darüber sichtbar sein. (Fehlverhalten könnte z.b. fehlformatierte ARP / GARP sein..).
Wenn das Dock nicht irgendwie die MAC"-Identität" des Gateways annimmt (selbst die mac verwendet ggf. garp im namen des gateways verschickt oder Pakete zurück ins Netz wirft weil es denkt, ein switch zu sein...), kann es das eigentlich nicht verursachen.

[rotwang]

Nur mal so ins Unreine gedacht: Die GS-3126X sind mit dem Uplinks-Switch über ein Link-Bündel (LACP) verbunden, wenn ich's richtig verstanden habe?

Nehmen wir mal an, aus irgendeinem Grund bricht das Bündel auf Seiten des GS-3126X zusammen und er behandelt seine Ports wieder als einzelne, dann würde er einen vom Gateway 'downstream' kommenden Broad- oder Multicast über den zweiten Link des (nun aufgelösten) Link-Bündels wieder upstream Richtung Uplink-Router zurück schicken, und der würde die MAC-Adresse des Gateways umlernen.

Wenn PO15/17/21 wirklich Bündel aus mehreren Links sind, vielleicht könnte man eine der Verbindungen mal testweise auf einen einfachen Link umbauen.

[JoP75]

Danke für den Gedankengang - ich hab jetzt die Switche jetzt mal über nen normalen 1-Port Trunk verbunden und schau mir die Tage mal das Logging an.

[JoP75]

Wie es aussieht hab ich die Ursache gefunden und vermute ein Bug in der DHCP-Snooping Verarbeitung der GS-3126 Switche.

Nach dem Rückbau der Uplinks auf einen normalen Trunk sind die MAC_MOVEs verschwunden.
Ich hab dann Testweise wieder einen der Switche redundant per LACP-Trunk angebunden - dann tauchen die MAC_MOVEs unter folgenden Voraussetzungen auf:

- Switch ist über Portbündel (bei uns LACP) im Uplink angebunden
- Switch hat DHCP-Snooping aktiviert (bei uns Uplink-Ports als 'trusted')
- Client im gleichen VLAN fordert die Antwort auf den DHCP-Request als 'Broadcast' an (unter Windows zu konfigurieren: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{InterfaceGUID}: DWORD-Wert DhcpConnForceBroadcastFlag auf 0 für Unicast oder 1 für Broadcast)

Gegenprobe - in den Fällen trat es nicht mehr auf:
- Switch über einen Port angebunden
- DHCP-Snooping ist deaktiviert
- am Client: DHCP-Request-Antwort als Unicast angefordert
- am Client: IP-Adresse wird statisch vergeben (daher dann kein DHCP-Request, bzw. Antwort darauf)

Ich vermute dass die Broadcast-Antwort auf den DHCP-Request dann auf allen Ports bis auf dem der Quelle rausgeschickt wird (incl. 2.Port des Portbündels) und das dann die Effekte auf dem Uplink-Switch auslöst. Das äußert sich dann so, dass das der DHCP-Server des betroffenen VLANs kurzzeitig nicht mehr erreichbar ist. Ist der DHCP-Server auch gleichzeitig Std.GW fällt auch dieser ein paar Sekunden aus.


Wir geben das mal über unseren Lancom-Partner an den Lancom-Support.
Ich hoffe wir kommen da weiter...

Schonmal Danke für die Unterstützung !!!