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 !!!
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 !!!
Statistik: Verfasst von JoP75 — Heute, 14:11
