Warum erfasst wireshark fremden / nicht relevanten Verkehr auf meinem Switchport mit einfachem Zugriff?

Auf einem Hauptschalter des Unternehmens (Cisco 3750) habe ich einen einfachen physischen Windows XP-PC an einen Switchport angeschlossen (Switchport-Modus-Zugriff, Switchport-Zugriff vlan 30). Auf dem 3750 sind KEINE Überwachungssitzungen vorhanden. Außerdem verfügt der PC über eine einzelne IP-Adresse auf einer einzelnen Netzwerkkarte. Wenn ich jedoch eine Promiscuous-Erfassung von Wireshark auf dem WinXP-PC starte, werden mehrere Fremdgespräche angezeigt, entweder LAN-zu-LAN oder WAN-zu-LAN (dh src IP und dst IP stimmen nicht mit der IP-Adresse des PCs überein). Dieser Verkehr wird NICHT gesendet (weder L2-Broadcast noch L3-Broadcast). Die Konfiguration des Switches ist eine einfache Konfiguration der Schichten 3 und 2. Nichts Besonderes (wegen Unordnung der Gründe)

Ich habe die MAC- und ARP-Tabelle des Switches überprüft und alles scheint normal zu sein: Der Switchport des PCs zeigt nur 1 MAC-Adresse an und die anderen fremden MAC- und IP-Adressen werden in ihre normalen Ports aufgelöst (mit "show ip arp" und "show mac-addr" usw. .)

Die gesamte Erfassungsidee wurde ins Leben gerufen, weil wir häufige Anwendungsverzögerungen beheben möchten (laut anderen Erfassungen sind viele TCP-Neuübertragungen der mögliche Schuldige).

Irgendwelche Ideen?

======================

BEARBEITEN nach einer IOS-Recherche scheint es eine ziemlich große Chance zu geben, dass meine IOS-Version (12.2 (25) SEB4) schwerwiegende Fehler in Bezug auf CAM-Tabellen und dergleichen aufweist. Ich werde nächste Woche ein Upgrade durchführen und erneut ein Update durchführen.

[Tut mir leid, dass ich zu spät zur Party gekommen bin, aber ich bin darauf gestoßen, als ich nach etwas anderem gesucht habe] Wenn Sie sagen "mehrere ausländische Gespräche erscheinen", meinen Sie damit mehrere Pakete in beide Richtungen oder nur das gelegentliche Paket?

Wenn es sich um vollständige Gespräche handelt, haben Sie definitiv ein Problem mit Ihrem Switch.

Wenn es sich um gelegentliche Pakete handelt, würde ich Spanning Tree-Änderungen verantwortlich machen. Denken Sie daran, dass sich ein Switch standardmäßig 300 Sekunden lang MAC-Adressen merkt. Wenn Ihr Switch 300 Sekunden lang KEINEN Frame von einem bestimmten Gerät gesehen hat und Frames an diese MAC-Adresse gesendet wurden, werden sie an alle anderen Ports weitergeleitet, einschließlich Ihres WinXP / Wireshark-Monitors. Dies würde so lange fortgesetzt, bis der Eigentümer der MAC-Adresse einen Frame gesendet hat.

Bei Geräten mit modernen Betriebssystemen ist die Wahrscheinlichkeit, dass ein Gerät 300 Sekunden lang KEINEN Frame sendet, sehr gering, obwohl andere passivere Geräte für diese Zeit möglicherweise stumm sind.

Zurück zum Spanning Tree. Wenn sich die Spanning Tree-Topologie ändert (z. B. ein Gerät, das eine Verbindung zu einem Switch-Port herstellt / trennt), wird ein Ereignis zur Benachrichtigung über Topologieänderungen an die Root-Bridge gesendet. Die Root-Bridge setzt dann das TCN-Bit auf allen BPDUs für die nächste FWD_DELAY-Periode (15 Sekunden). Wenn Bridges BPDUs mit gesetztem TCN-Bit sehen, reduzieren sie die Alterungszeitgeber für die MAC-Adresstabelle auf FWD_DELAY (15 Sekunden). [Dies ist ein Grund, warum Sie immer den globalen Konfigurationsbefehl spanning-tree portfast default eingeben sollten , um die Erstellung von TCNs zu stoppen, wenn ein Switch-Port aktiviert / deaktiviert wird.]

Wenn sich also Spanning Tree-Änderungen ergeben, ist es wahrscheinlicher, dass gelegentlich Pakete an andere als Ihre eigenen MAC-Adressen gesendet werden.

Sie sagen nicht ausdrücklich, ob eines der angezeigten Pakete aus einem anderen Subnetz stammt (= ein anderes VLAN, wenn Ihr Design korrekt ist). ABER wenn Sie Pakete von einem anderen Subnetz / VLAN sehen, würde ich empfehlen, dass Sie Ihre Inter-Switch-Verkabelung sehr sorgfältig prüfen und die native VLAN- Konfiguration und den Trunk-Port- Status all dieser Links überprüfen . Wenn ein "Subnetz / VLAN" -Leck auftritt, kann dies zu mehreren Topologieänderungen führen, die den Alterungszeitgeber auf 15 Sekunden beschränken und dazu führen, dass viele weitere unerwartete Frames auf Ihrem Wireshark-Capture eintreffen.