Aufspüren einer ungültigen Quell-Mac-Adresse

Ich habe die Unterstützung eines Remote-Standorts geerbt, der ein Cisco 4500 enthält und mit ~ 2 Dutzend Cisco-Zugriffsschaltern verbunden ist - hauptsächlich 2960er mit einigen 3750er und 3560er. Nicht alle Access-Switches sind direkt mit dem 4500 verbunden - es gibt eine Verkettung von Switches, die anscheinend auf eine unzureichende Verkabelung zurückzuführen ist. Kürzlich habe ich fehlerhafte Nachrichten auf dem 4500 bemerkt, die darauf hinweisen, dass Frames mit einer ungültigen Quell-Mac-Adresse empfangen wurden:

*Sep 10 09:29:48.609: %C4K_L2MAN-6-INVALIDSOURCEADDRESSPACKET: (Suppressed 102563 times)Packet received with invalid source MAC address (00:00:00:00:00:00) on port Te5/1 in vlan 1460

Das an Te5 / 1 angeschlossene Gerät ist ein Zugriffsschalter (Cisco 3750). Es ist wiederum mit 6 anderen Zugangsschaltern verbunden. Nach einigem googeln sieht es so aus, als ob der 4500 die einzige Cisco-Plattform ist, die ungültige Quell-Mac-Adressen protokolliert. Meiner Meinung nach leiten andere Plattformen (2960, 3750 usw.) die Frames anscheinend weiter, protokollieren sie jedoch nicht als ungültig und fügen auch keinen Eintrag zur Mac-Adresstabelle hinzu. Ich vermute, dass die Ursache für die ungültigen Quell-Mac-Adressen ein fehlerhafter NIC, ein Softwarefehler oder möglicherweise ein falsch konfigurierter VMware-Server sein könnte. Welche Tools sind auf den Zugriffsschaltern verfügbar, um den fehlerhaften Port zu ermitteln?

cisco switch layer2

— User123456
quelle

Ich habe meinen Beitrag gelöscht, habe nicht bemerkt, dass sie überhaupt nicht sichtbar sind. Wenn der Switch sie nicht in CAM einsetzt, ist es wahrscheinlich am besten, die SPAN-Sitzung auf Switches auszuführen, aber selbst dann wäre es schwierig, den Quellport zu finden. Eine andere Möglichkeit wäre, unbekannten Unicast zu deaktivieren und zu prüfen, ob etwas kaputt geht. Ich bin überrascht, dass die Kommunikation funktioniert. Wenn ein Host mit diesem MAC etwas außerhalb seiner Subnetze sendet, müsste das GW ARP, um den MAC des Hosts zu sehen und den Frame zu kapseln, hat das GW irgendwelche seltsamen ARP-Zuordnungen?

— Daniel Dib

Laut supportforums.cisco.com/docs/DOC-36000 sollten diese Frames in HW abgelegt werden, damit zumindest die Leistung der Switches nicht beeinträchtigt wird.

— Daniel Dib

Ja, laut diesem Link: "Bitte beachten Sie, dass Pakete mit ungültiger MAC-Adresse ohnehin verworfen werden. Alle anderen Cisco Catalyst-Switches lassen diese Pakete unbemerkt in HW fallen. Die 4k-Plattform generiert explizit eine Protokollmeldung, wenn ein solches Ereignis auftritt." ... aber ich weiß, dass dies nicht wirklich der Fall sein kann, da der 4500 sich über Frames beschwert, die auf Te5 / 1 ankommen, dem mit dem 3750 verbundenen Port. Dies würde bedeuten, dass der 3750 die Frames mit dem ungültigen weiterleitet Quell-Mac trotz dessen, was DOC-36000 sagt.

— User123456

Teilen & Erobern!

— Generalnetworkerror

Hat Ihnen eine Antwort geholfen? In diesem Fall sollten Sie die Antwort akzeptieren, damit die Frage nicht für immer auftaucht und nach einer Antwort sucht. Alternativ können Sie auch Ihre eigene Antwort eingeben und annehmen.

— Ron Maupin

Antworten:

Sie können versuchen, die Frames mithilfe einer MAC-ACL auf Schnittstellen und / oder Vlans auf den Zugriffsschaltern zu blockieren. Indem Sie die Blöcke selektiv anwenden und prüfen, ob die Fehlermeldungen auf dem 4500 verschwinden oder nicht, können Sie die Quelle des Datenverkehrs ausfindig machen.

Das Verlegen von Kabeln, um festzustellen, ob der in der Fehlermeldung auf dem 4500 angegebene Anschluss auch hilfreich ist, kann sich jedoch in einer Produktionsumgebung als schwierig erweisen.

— Gerben
quelle

Wenn ich das gesehen habe, kommt es im Allgemeinen von einer schlecht konfigurierten VM (die oft auf einem Benutzercomputer gehostet wird). Abhängig von der Situation und dem Umfeld kann es schwierig sein, sie aufzuspüren (viele davon wurden an einer Universität in den CS- und ECE-Abteilungsgebäuden gesehen, die sich wie Studenten bewegten und kamen / gingen).

Sie haben bereits einige gute Antworten, aber Sie können auch die folgende Konfiguration zu den Downstream-Switches hinzufügen (37xx, 36xx, 29xx):

   mac address-table static 0000.0000.0000 vlan <VLAN ID> drop

Dadurch wird jeglicher Datenverkehr mit diesem MAC gelöscht und nicht weitergeleitet. Da dies in Hardware erfolgen sollte (abgesehen von Funktionen / Problemen, die dazu führen, dass MAC-Lookups in Software durchgeführt werden), sollte dies keine negativen Auswirkungen auf die Leistung haben.

— YLearn
quelle

Vielen Dank für diesen Vorschlag. Dies verhindert, dass die Frames über die Amtsleitungen an andere Switches weitergeleitet werden, was ein großer Gewinn ist. Gibt es eine Möglichkeit, durch Protokollierungs- oder Debug-Befehle festzustellen, ob ein Port aufgrund dieser Konfiguration Frames löscht?

— User123456

@fcorrao, leider nicht mit dieser Konfiguration. Sie müssten versuchen, das zu tun, was Gerben vorgeschlagen hat, und eine MAC-ACL oder den Vorschlag von Dave verwenden, den Datenverkehr von den Ports aus zu erfassen. Aber ich gehe davon aus, dass nur das falsch konfigurierte Gerät nachteilig beeinflusst wird. Entweder machen sie es bekannt oder sie bemerken sich selbst gar nicht.

— YLearn

Es scheint mir, dass dieser Fehler die Netzwerkleistung nicht beeinträchtigt, da Sie die Protokollmeldungen selbst entdeckt haben und nicht, dass Sie mit Beschwerden von Benutzern überflutet wurden. Dies lässt mich vermuten, dass das Problem mit einer verbundenen, aber teilweise konfigurierten oder falsch konfigurierten Software oder einem Dienst zusammenhängt, die bzw. der derzeit nicht verwendet wird.

Am besten lassen Sie diesen schlafenden Hund liegen, bis ein Benutzer ein Problem meldet. Wenn Sie Zeit haben, können Sie alternativ SPAN-Sitzungen wie von @Daniel Dib vorgeschlagen ausführen und die Ausgabe genau prüfen, bis Sie einen verdächtigen Port oder ein verdächtiges Gerät gefunden haben.

— Dave in Ohio
quelle