10
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.5F1CWie 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.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1295957987
Url: https://administrator.de/contentid/1295957987
Printed on: April 26, 2024 at 07:04 o'clock
10 Comments
Latest comment
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.
1
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 ?
Avaya Stack ausgebaut und durch neues Cisco Stack ersetzt. Kein LACP, einzelner Uplink direkt vom Core kommend.
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 !
Genau wegen solchen schei* Problem ist Auweia auch rausgeflogen. Also kein Auweia mehr da! Nur noch Cisco. Damit sollte das ja überflüssig sein.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.
Also: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.
Die Stacks und alle anderen Access-Switche am Standort laufen nur im L2 mit Trunk auf den Core. Der Core (aktuell noch nicht in HA, daher auch keine LACP-Trunks auf die Access Switche) macht unser internes Routing und läuft somit auf L3. Sorry für die fehlenden Info.
Also ich möchte hier auch nochmal auf die bisherigen Erkenntnisse eingehen.
Wie gesagt, das Stack ist direkt mit einem Trunk zum Core verbunden. Das ist der Trunk auf den Port "TenGigabitEthernet6/8"
- Der Server, der den Fehler auf der Netzwerkkarte hatte, meldet mir im Log diese MAC: 40-B5-C1-E2-5F-1C
- Abfrage zu dieser MAC mit deutet auf Port TenGigabitEthernet6/8 über 5 VLANs.
show mac address-table address 40B5.C1E2.5F1C - Abfrage zur MAC-Adresse der MGMT-IP dieses Switches auf Port 6/8 mittels sagt:
sh arp xxx.xxx.xxx..xxx detailhardware address is 40b5.c1e2.5f41 - Im Webinterface ist zu sehen, dass der Master des Stacks die MAC-Adresse 40-B5-C1-E2-5F-00 hat
- Der Slave-Switch im Stack hat eine ganz andere IP-Adresse
Nun ist die Frage: Diese 1C am Ende. Woher nimmt der Server diese Info, mit welchem Port kann ich die in Verbindung bringen. Es sieht ja schwer danach aus, dass es hier um einen Port an dem Switch geht, schließlich sind die vorherigen Stellen in der MAC-Adresse komplett identisch. Uplink zum Core scheint es ja nicht zu sein, der hat ja die 41 am Ende. Aber dadurch, dass der Switch die 00 hat, gehe ich doch davon aus, dass es schon etwas mit diesem Switch bzw. Stack speziell zu tun haben muss.
Hoffe ich konnte damit nochmal einige Fragen näher beleuchten.
Danke schon einmal
Noch zu diesen zwei Punkten:
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.).
Das mit den 5 Minuten ist natürlich ein kurzer Zeitraum. Macht es Sinn das zum Troubleshooting zu verlängern? Wie wäre hier das Kommando für Cisco IOS?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.
Genau das habe ich auch gemacht. Der Core deutet ja auf den Uplink vom Cisco Stack und dort habe ich dann auch nach der MAC gesucht, allerdings ohne Erfolg. Auch hier dann wieder mein Gedanke, ob das vielleicht darauf hindeutet, dass der Core hier eine MAC von einem Port des Stacks nennt, die mir das Stack selbst aber nicht anzeigen kann?
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
Das glaube ich eher nicht.
Ich zweifel auch noch dran ;)Die Fehlermeldung scheint mir doch ziemlich blödsinnig. Ein Adresskonflikt mit 0.0.0.0? Welche Adresse ist das denn, lieber Azubi?
Ich frag mich wie du darauf kommst, dass ich der Azubi bin?! Mir erscheint die auch ziemlich blödsinnig, dennoch habe ich die Fehlermeldung und sie scheint eindeutig auf die Ursache zum Problem hinzuweisen. Die Frage ist also nicht, ob die Fehlermeldung blödsinnig ist, sondern warum die verschiedenen Server die immer mal sporadisch haben und in dem Fall dann jedes Mal keine Netzwerkverbindung aufbauen können, bis man sie dann nochmal neu startet oder einfach deaktiviert und wieder aktiviert.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.
Die VMware NICs haben mit dem Problem nichts zu tun. Es sind VMs mit E1000e und VMs mit VMXNET3 und wir haben das Problem auf beiden!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.
Danke für den Tip. Aber mit der Beschreibung im RFC bin ich jetzt auch nicht wirklich weiter gekommen. Und Du wirst auch verstehen, warum ich vermute, dass die Fehlermeldung falsch ist.
Ich melde mich nochmal. Heute Nacht hatten wir wieder einige Server, die gepatcht wurden und danach nicht mehr online waren. Auch diesmal. Einer mit E1000e und einer mit VMXNET3 betroffen. Diesmal kamen die Fehler aber in Zusammenhang mit dem zweiten neuen Switch Stack. Allerdings gibt es Zusammenhänge. Aufgepasst:
Fehlermeldung:
Das System hat einen Adressenkonflikt der IP-Adresse 0.0.0.0 mit dem Computer mit der Netzwerkhardwareadresse 40-B5-C1-E2-8B-1C ermittelt. Netzwerkvorgänge könnten daher auf diesem System unterbrochen werden.
Hier ist der klare Zusammenhang erkennbar, dass die letzte Oktett wieder die 1C ist. Unterschied des Stacks ist erkennbar an der 5. Oktett. Die 8B ist der Master-Switch des "anderen" Stacks. Gestern war das Stack Hauptgebäude 1. OG und das hier ist im Nebengebäude (Gebäudeverteiler). Nur um euch ggf. die Beschreibung leichter zu machen.
Abfrage nach der MGMT IP seitens Core ergibt hier dann auch wieder die MAC 40B5.C1E2.8B41. Also auch hier die Gemeinsamkeit mit der 41, da beide Stacks ihren Uplink auf dem letzten Port des Masters haben.
Bei der Abfrage nach der 1C kommt am Switch selbst aber wieder kein Ergebnis.
Aufgrund der Gemeinsamkeit stellt sich jetzt mir nach wie vor die gleiche Frage. Wie kommt diese komische Fehlermeldung zustande? Und was genau ist dieser Port mit der MAC 1C. Ist das vielleicht ein virtuelles Interface?
Bitte um mehr Beteiligung an meinem Problem
Fehlermeldung:
Das System hat einen Adressenkonflikt der IP-Adresse 0.0.0.0 mit dem Computer mit der Netzwerkhardwareadresse 40-B5-C1-E2-8B-1C ermittelt. Netzwerkvorgänge könnten daher auf diesem System unterbrochen werden.
Hier ist der klare Zusammenhang erkennbar, dass die letzte Oktett wieder die 1C ist. Unterschied des Stacks ist erkennbar an der 5. Oktett. Die 8B ist der Master-Switch des "anderen" Stacks. Gestern war das Stack Hauptgebäude 1. OG und das hier ist im Nebengebäude (Gebäudeverteiler). Nur um euch ggf. die Beschreibung leichter zu machen.
Abfrage nach der MGMT IP seitens Core ergibt hier dann auch wieder die MAC 40B5.C1E2.8B41. Also auch hier die Gemeinsamkeit mit der 41, da beide Stacks ihren Uplink auf dem letzten Port des Masters haben.
Bei der Abfrage nach der 1C kommt am Switch selbst aber wieder kein Ergebnis.
Aufgrund der Gemeinsamkeit stellt sich jetzt mir nach wie vor die gleiche Frage. Wie kommt diese komische Fehlermeldung zustande? Und was genau ist dieser Port mit der MAC 1C. Ist das vielleicht ein virtuelles Interface?
Bitte um mehr Beteiligung an meinem Problem
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 !
1Zitat von @aqui:
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.
Moin, das sind Cisco 2960-X (glaube 24 PD-L oder so ähnlich) Modelle, meines Wissens können die nicht mal L3. Also daher hat sich die ganze Frage schon erledigt, mal davon abgesehen, dass ich es ja oben schon geschrieben habe.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.
Da habe ich ja jeweils nur das MGMT Interface des Switches selbst. Das ist bspw. im VLAN 1001 und der Server ist im VLAN 1002. Dort haben die Switche aber keine IP-Adresse. Wenn ich nach dem Interface im MGMT VLAN schaue, kommt als MAC-Adresse aber nicht die, die mit 1C endet, sondern jeweils die mit der 41 in der letzten Oktett.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 !
MAC-Adressen der VMs werden nicht manuell verändert, da ist alles auto vom vCenter angelegt.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 !
Spanning Tree macht für mich keinen Sinn. Wir hatten VORHER (vor Austausch der Switch Stacks von Avaya zu Cisco) keine Probleme und jetzt wo am ganzen Standort ausschließlich Cisco läuft haben wir dieses Problem. Ich könnte mir höchstens erklären, dass die neuere Firmware auf den Stacks im Vergleich zu den anderen (baugleichen) Switchen eine Rolle spielt und hier die STP Modis nicht ganz kompatibel sind. Aber an und für sich haben die beiden betroffenen Stacks, die in den Ereignisprotokollen von den Servern zu finden sind, überhaupt keine Berührungspunkte mit den VMs. Die ESXen hängen an anderen Switchen, hier wurde in den letzten Jahren nichts verändert und dann steht zwischen diesen und den beiden Stacks der Core im L3 Modus! Wie zum Teufel kommt also der Konflikt zu Stande. Irgendjemand sonst hier, der den Threat verfolgt und eine Idee hat?
TO: Wenn's das denn nun war bitte dann nicht vergessen diesen Thread zu schliessen:
How can I mark a post as solved?
How can I mark a post as solved?
Moin, ich hatte nun letztlich Kontakt mit Cisco und habe folgende Antwort erhalten:
Sorry for keeping you waiting, but I had to test my findings on my local lab to confirm the results.
Please find the below summary for our case:
[+]2960 running 15.2(7)E4
[+]after connect this switch to the network we starting see conflict error:
"The system has detected an IP address conflict of 0.0.0.0 with the computer with network hardware address 40-B5-C1-E2-8B-1C. Network operations could therefore be interrupted on this system."
[+]this error is due to IP device tracking feature, which is enabled by default on 15.2(7)Ex.
[+]we can confirm that from show run all command.
F241.03.17-C2960X-1#sh run all | i device
device-sensor notify new-tlvs
device-sensor tlv limit 128
ip device tracking probe count 3
ip device tracking probe interval 30
ip device tracking probe delay 0
ip device tracking trace-buffer
[+]this is a known issue when we have ip device tracking and windows machines connected.
[+]it’s happened when the switch is sending an arp prob while windows machine doing duplicate detect.
[+]in order to solve this problem we need to apply this command ”config# ip device tracking probe delay 10”
[+]The goal is to delay the probe from the switch so that Microsoft Windows has time to finish the duplicate IP address detection.
F241.03.17-C2960X-1(config)#ip device tracking probe delay 15
F241.03.17-C2960X-1(config)#
F241.03.17-C2960X-1#sh run all | i device
device-sensor notify new-tlvs
device-sensor tlv limit 128
ip device tracking probe count 3
ip device tracking probe interval 30
ip device tracking probe delay 15
ip device tracking trace-buffer
no device classifier
F241.03.17-C2960X-1#sh run | i device
ip device tracking probe delay 15
F241.03.17-C2960X-1#