Hilfe zu sporadischen IP-Adresskonfikt mit nicht eindeutig identifizierbarer MAC-Adresse
Hallo zusammen,
ich bräuchte mal etwas Hilfe auf der Suche nach der Quelle eines IP-Adresskonflikts.
Wir haben im Azubi-Projekt zwei Avaya Switch Stacks zu Cisco Switch Stacks gemacht. Seitdem haben wir immer wieder mal Probleme im Netz mit Geräten und heute bin ich dem Problem auf die Spur gekommen. Der Server (Win Server 2012 R2 VM auf VMware) loggt im Ereignisprotokoll folgenden Fehler nach dem Neustart:
Das System hat einen Adressenkonflikt der IP-Adresse 0.0.0.0 mit dem Computer mit der Netzwerkhardwareadresse 40-B5-C1-E2-5F-1C ermittelt. Netzwerkvorgänge könnten daher auf diesem System unterbrochen werden.
Das Problem äußert sich wie folgt:
Nach einem Neustart verschiedenster Server springt deren Netzwerkkarte auf Fehler und baut keine Verbindung auf. Somit ist der Server nicht mehr erreichbar, außer über VMware Console. Die Netzwerkkarte hat aber eine fest IP-Adresse. Dies passiert uns seit einiger Zeit immer wieder mal beim automatischen Patchen der Server, sodass man dann manuell eingreifen muss. Deaktivieren und wieder aktivieren der Netzwerkkarte reicht schon aus.
Das Problem ist, dass man es nicht gezielt reproduzieren kann. Der Fehler tritt manchmal gar nicht auf und manchmal dann bei 3-4 Servern gleichzeitig oder auch mal nur bei einem einzigen. Sehr sporadisch also.
Ich habe daher auf dem Core nach dem Quell-Port zur MAC-Adresse nachgeschaut. Quelle ist der Uplink auf einen der beiden Cisco Stacks und zwar auch aus verschiedenen VLANs und nicht nur aus einem. Das heißt für mich, dass es womöglich etwas mit dem Switch selbst zu tun haben muss und nicht mit einem Gerät dahinter.
Auf dem Switch hab ich dann auch gesehen, dass der Master des Stacks (2er Stack) die MAC-Adresse 40-B5-C1-E2-5F-00 hat. Das heißt Quelle muss ja einer der Ports des Switches sein.
Nach kurzer Recherche hat sich auch bestätigt, dass (war für mich eigentlich auch logisch) jeder einzelne Port eine eigene MAC-Adresse hat.
Quelle: Does each port have a MAC address?
every port on a switch has a unique factory-assigned MAC address.
Aus www.oreilly.com/library/view/ethernet-switches/9781449367299/ch01.html
Mit dem Befehl komme ich auf dem betroffenen Stack aber nicht mehr weiter und in der running config sind keine Interfaces mit der IP-Adresse 0.0.0.0 angelegt. Es ist lediglich ein Interface im MGMT VLAN angelegt, mit welchem wir den Switch managen. Auf dem Default Vlan1 ist kein Interface konfiguriert.
Wie kann ich jetzt auf der Suche nach der IP-Adresse 0.0.0.0 fortfahren? Ist die MAC-Adresse mit der 1C am Ende ein Switchport? Wie finde ich heraus welcher Switchport das ist? Kann es dann auch das Endgerät sein, welches an diesem Port angeschlossen ist, oder dürfte das nicht der Fall sein?
Ich hoffe ihr könnt mir behilflich sein.
ich bräuchte mal etwas Hilfe auf der Suche nach der Quelle eines IP-Adresskonflikts.
Wir haben im Azubi-Projekt zwei Avaya Switch Stacks zu Cisco Switch Stacks gemacht. Seitdem haben wir immer wieder mal Probleme im Netz mit Geräten und heute bin ich dem Problem auf die Spur gekommen. Der Server (Win Server 2012 R2 VM auf VMware) loggt im Ereignisprotokoll folgenden Fehler nach dem Neustart:
Das System hat einen Adressenkonflikt der IP-Adresse 0.0.0.0 mit dem Computer mit der Netzwerkhardwareadresse 40-B5-C1-E2-5F-1C ermittelt. Netzwerkvorgänge könnten daher auf diesem System unterbrochen werden.
Das Problem äußert sich wie folgt:
Nach einem Neustart verschiedenster Server springt deren Netzwerkkarte auf Fehler und baut keine Verbindung auf. Somit ist der Server nicht mehr erreichbar, außer über VMware Console. Die Netzwerkkarte hat aber eine fest IP-Adresse. Dies passiert uns seit einiger Zeit immer wieder mal beim automatischen Patchen der Server, sodass man dann manuell eingreifen muss. Deaktivieren und wieder aktivieren der Netzwerkkarte reicht schon aus.
Das Problem ist, dass man es nicht gezielt reproduzieren kann. Der Fehler tritt manchmal gar nicht auf und manchmal dann bei 3-4 Servern gleichzeitig oder auch mal nur bei einem einzigen. Sehr sporadisch also.
Ich habe daher auf dem Core nach dem Quell-Port zur MAC-Adresse nachgeschaut. Quelle ist der Uplink auf einen der beiden Cisco Stacks und zwar auch aus verschiedenen VLANs und nicht nur aus einem. Das heißt für mich, dass es womöglich etwas mit dem Switch selbst zu tun haben muss und nicht mit einem Gerät dahinter.
Auf dem Switch hab ich dann auch gesehen, dass der Master des Stacks (2er Stack) die MAC-Adresse 40-B5-C1-E2-5F-00 hat. Das heißt Quelle muss ja einer der Ports des Switches sein.
Nach kurzer Recherche hat sich auch bestätigt, dass (war für mich eigentlich auch logisch) jeder einzelne Port eine eigene MAC-Adresse hat.
Quelle: Does each port have a MAC address?
every port on a switch has a unique factory-assigned MAC address.
Aus www.oreilly.com/library/view/ethernet-switches/9781449367299/ch01.html
Mit dem Befehl
show mac address-table address 40B5.C1E2.5F1C
Wie kann ich jetzt auf der Suche nach der IP-Adresse 0.0.0.0 fortfahren? Ist die MAC-Adresse mit der 1C am Ende ein Switchport? Wie finde ich heraus welcher Switchport das ist? Kann es dann auch das Endgerät sein, welches an diesem Port angeschlossen ist, oder dürfte das nicht der Fall sein?
Ich hoffe ihr könnt mir behilflich sein.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1295957987
Url: https://administrator.de/forum/hilfe-zu-sporadischen-ip-adresskonfikt-mit-nicht-eindeutig-identifizierbarer-mac-adresse-1295957987.html
Ausgedruckt am: 25.12.2024 um 07:12 Uhr
10 Kommentare
Neuester Kommentar
zwei Avaya Switch Stacks zu Cisco Switch Stacks gemacht.
Wie jetzt ?? Umlackiert und einen anderen Hersteller Bäppel draufgemacht oder wie darf man sich das vorstellen ??Vermutlich habt ihr wohl einen Auweia Stack mit einem Cisco Stack entweder mit einem einfachen Uplink oder mit einem LACP LAG verbunden, richtig ?
ACHTUNG:
Da muss man gewaltig aufpassen mit dem Spanning Tree !!
Zu befürchten ist das der Auweia Stack kein PVSTP+ Spanning Tree macht wie der Cisco im Default. Er kann vermutlich nur ein einfaches Single Span Verfahren. Wenn dem so ist, dann sind die NICHT kompatibel im Spanning Tree, denn der Cisco benutzt vollkommen andere BPDU Mac Adressen die der Auweia dann nicht erkennt. Du bekommst dann die wildesten Side Effects indem der oder die Koppellinks dann heftigst wechseln im Forwarding Mode (Link Flapping) und andere chaotische Dinge. Macs werden in unterschiedlichen VLANs gelernt und PVSTP+ Frames geflutet usw. usw. Hier hilft immer ein Blick ins Switch Log
Es ist sehr wahscheinlich das die IP Problematik eine Folge davon ist.
Ein typischer Anfängerfehler und ganz besonders bei Azombies denen diese STP Problematik meist nicht bewusst ist weil keiner Spanning Tree und die unterschiedlichen STP Protokolle auf dem Radar hat. Sinnvoll also das gleich mal zu lernen für die Azubis !
Cisco supportet KEIN Single Span Verfahren und auch kein PVSTP was auf RSTP basiert. Einzig den globalen Standard MSTP supportet Cisco.
Das solltest du also wasserdicht prüfen und wenn dem so ist dann musst du zwingend den Cisco und auch den Auweia auf MSTP Spanning Tree umstellen, denn das ist das kleinste gemeinsame (STP) Vielfache zw. diesen Herstellern. Es sei denn Auweia kann auch PVSTP+ ?!
Wie sowas dann recht einfach zu machen ist kannst du an einem Lancom Beispiel in diesem Thread sehen:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)
Das solltest du zuallererst checken bevor du mit der Mac Adresse weitermachst !
Die Mac Adressen auf den Ports des Switches sind vollkommen irrelevant und nicht von Bedeutung, da sie an einer Layer 2 Kommunikation von Endgeräten NICHT beteiligt sind. Sie sind einzig nur relevant wenn die Switches im Layer 3 Mode mit diesen Ports arbeiten.
Da du aber keinerlei Aussage dazu machst ob sie im L2 oder L3 Mode betrieben werden kann man hier nur im freien Fall raten.
Ansonsten, wenn wir von Layer 2 ausgehen, sind deine Troubleshooting Schritte absolut richtig. Mit show mac-address siehst du dir die Mac Adress Tabelle an und checkst auf welchem Port diese Mac gelernt wurde. Beachte das diese Macs bei Inaktivitaät austimen ! Der generelle Wert des Aging Timers liegt Hersteller übergreifend auf 300 Sekunden (5 Min.).
Solltest du die Mac auf einem Uplink Port sehen musst du auf den an diesem Uplink liegenden Switch wechseln und dort wieder nach der Mac und dem Port suchen.
Moin,
Das glaube ich eher nicht.
Die Fehlermeldung scheint mir doch ziemlich blödsinnig. Ein Adresskonflikt mit 0.0.0.0? Welche Adresse ist das denn, lieber Azubi?
Welche VMWare-Version ist das denn? Welchen virtuellen NIC habt Ihr konfiguriert? Ich kämpfe auch schon länger mit diesem Fehler, der, so der letzte Hinweis, den ich bekommen habe aber noch nicht verifizieren konnte, daran liegt, dass Server 2012R2 nicht mit den virtuellen NICs der VMWare zurecht kommt außer dem E1000e. Ich kann das insofern schon als wahrscheinlich bezeichnen, als dass ich auf derselben VMWare zwei Server mit und zwei Server ohne das Problem habe. Die zwei mit haben E1000 und die zwei ohne E1000e als virtuellen NIC.
Einfach mal im RFC schauen, welche Adresse das ist. Dann weißt Du auch, warum sie da und doch nicht da ist. Und Du wirst auch verstehen, warum ich vermute, dass die Fehlermeldung falsch ist.
hth
Erik
Zitat von @ITler7:
Wir haben im Azubi-Projekt zwei Avaya Switch Stacks zu Cisco Switch Stacks gemacht. Seitdem haben wir immer wieder mal Probleme im Netz mit Geräten und heute bin ich dem Problem auf die Spur gekommen.
Wir haben im Azubi-Projekt zwei Avaya Switch Stacks zu Cisco Switch Stacks gemacht. Seitdem haben wir immer wieder mal Probleme im Netz mit Geräten und heute bin ich dem Problem auf die Spur gekommen.
Das glaube ich eher nicht.
Der Server (Win Server 2012 R2 VM auf VMware) loggt im Ereignisprotokoll folgenden Fehler nach dem Neustart:
Das System hat einen Adressenkonflikt der IP-Adresse 0.0.0.0 mit dem Computer mit der Netzwerkhardwareadresse 40-B5-C1-E2-5F-1C ermittelt. Netzwerkvorgänge könnten daher auf diesem System unterbrochen werden.
Das System hat einen Adressenkonflikt der IP-Adresse 0.0.0.0 mit dem Computer mit der Netzwerkhardwareadresse 40-B5-C1-E2-5F-1C ermittelt. Netzwerkvorgänge könnten daher auf diesem System unterbrochen werden.
Die Fehlermeldung scheint mir doch ziemlich blödsinnig. Ein Adresskonflikt mit 0.0.0.0? Welche Adresse ist das denn, lieber Azubi?
Welche VMWare-Version ist das denn? Welchen virtuellen NIC habt Ihr konfiguriert? Ich kämpfe auch schon länger mit diesem Fehler, der, so der letzte Hinweis, den ich bekommen habe aber noch nicht verifizieren konnte, daran liegt, dass Server 2012R2 nicht mit den virtuellen NICs der VMWare zurecht kommt außer dem E1000e. Ich kann das insofern schon als wahrscheinlich bezeichnen, als dass ich auf derselben VMWare zwei Server mit und zwei Server ohne das Problem habe. Die zwei mit haben E1000 und die zwei ohne E1000e als virtuellen NIC.
Wie kann ich jetzt auf der Suche nach der IP-Adresse 0.0.0.0 fortfahren?
Einfach mal im RFC schauen, welche Adresse das ist. Dann weißt Du auch, warum sie da und doch nicht da ist. Und Du wirst auch verstehen, warum ich vermute, dass die Fehlermeldung falsch ist.
hth
Erik
Generell musst du erstmal klären ob der oder welcher Stack im L3 oder L2 Mode arbeitet.
Im L2 Mode sind ALLE Mac Adressen des Switches irrelevant weil sie an der IP Kommunikation nicht teilhaben !
Im L3 Mode sind die einzelnen Port Mac Adressen auch irrelevant weil auch sie innerhalb der VLAN Zuordnung nicht an einer IP Kommunikation teilhaben. Die Ports sind ja virtuell im Switche einer VLAN ID zugeordnet und arbeiten switchintern untereinander nur im L2 Mode.
"In" dem VLAN ist allerdings das virtuelle VLAN IP Interface eingehängt was die L3 Funktion übernimmt. (z.B. "int vlan 1" bei Cisco)
Die Mac Adresse dieses L3 IP Interfaces wird im Switch manchmal dynamisch gebildet. Die meisten Hersteller übernehmen in der Regel eine physische Port Mac Adresse des niedrigsten VLAN Member Ports in diesem VLAN für das L3 Interface. Die letztere Methode ist weiter verbreitet weil so die Einzigartigkeit der Mac Adresse des Switch Routing Interfaces gewährleistet bleibt.
Ein show int vlan 1 z.B. zeigt dir die Mac Adresse des L3 Interfaces im VLAN 1 an und wo du dieses Verhalten sehen kannst.
Auf einem Endgerät was VLAN übergreifend also routend kommuniziert mit dem Switch (und NUR VLAN übergreifend !) kannst du diese Mac Adresse in den ARP Caches der Endgeräte sehen mit arp -a (bzw. show arp a.d. Switch).
Logisch, denn diese Endgeräte müssen zuerst ARPen mit dem L3 VLAN IP Switchinterface in dem VLAN in dem sie stecken. Im L2 Mode machen die Endgeräte das immer direkt ohne Beteiligung des Switches.
Fazit:
Es ist technisch völlig unmöglich das die switcheigenen Mac Adressen im Netz mit irgendetwas kollidieren, denn diese sind weltweit einzigartig.
Es können also nur andere Mac Adressen im Netz sein. Sehr wahrscheinlich sind hier VM Mac Adressen da diese manuell oder dynamisch generiert werden. Hier besteht also die Gefahr von Doppelungen. Meist wenn man manuell fummelt und Vendor Code usw. nicht beachtet.
Die Switches selber wirst du vermutlich als Ursache komplett ausschliessen können sofern du zwingend die o.a. Spanning Tree Hinweise beachtet hast !
Im L2 Mode sind ALLE Mac Adressen des Switches irrelevant weil sie an der IP Kommunikation nicht teilhaben !
Im L3 Mode sind die einzelnen Port Mac Adressen auch irrelevant weil auch sie innerhalb der VLAN Zuordnung nicht an einer IP Kommunikation teilhaben. Die Ports sind ja virtuell im Switche einer VLAN ID zugeordnet und arbeiten switchintern untereinander nur im L2 Mode.
"In" dem VLAN ist allerdings das virtuelle VLAN IP Interface eingehängt was die L3 Funktion übernimmt. (z.B. "int vlan 1" bei Cisco)
Die Mac Adresse dieses L3 IP Interfaces wird im Switch manchmal dynamisch gebildet. Die meisten Hersteller übernehmen in der Regel eine physische Port Mac Adresse des niedrigsten VLAN Member Ports in diesem VLAN für das L3 Interface. Die letztere Methode ist weiter verbreitet weil so die Einzigartigkeit der Mac Adresse des Switch Routing Interfaces gewährleistet bleibt.
Ein show int vlan 1 z.B. zeigt dir die Mac Adresse des L3 Interfaces im VLAN 1 an und wo du dieses Verhalten sehen kannst.
Auf einem Endgerät was VLAN übergreifend also routend kommuniziert mit dem Switch (und NUR VLAN übergreifend !) kannst du diese Mac Adresse in den ARP Caches der Endgeräte sehen mit arp -a (bzw. show arp a.d. Switch).
Logisch, denn diese Endgeräte müssen zuerst ARPen mit dem L3 VLAN IP Switchinterface in dem VLAN in dem sie stecken. Im L2 Mode machen die Endgeräte das immer direkt ohne Beteiligung des Switches.
Fazit:
Es ist technisch völlig unmöglich das die switcheigenen Mac Adressen im Netz mit irgendetwas kollidieren, denn diese sind weltweit einzigartig.
Es können also nur andere Mac Adressen im Netz sein. Sehr wahrscheinlich sind hier VM Mac Adressen da diese manuell oder dynamisch generiert werden. Hier besteht also die Gefahr von Doppelungen. Meist wenn man manuell fummelt und Vendor Code usw. nicht beachtet.
Die Switches selber wirst du vermutlich als Ursache komplett ausschliessen können sofern du zwingend die o.a. Spanning Tree Hinweise beachtet hast !
TO: Wenn's das denn nun war bitte dann nicht vergessen diesen Thread zu schliessen:
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?