8
Ethernet Frame without valid MAC
Hallo,
wie verfährt ein Switch wenn er ein Ethernet Frame welches als Source und Destination MAC 00:00:00:00:00:00 eingetragen hat empfängt?
VG
wie verfährt ein Switch wenn er ein Ethernet Frame welches als Source und Destination MAC 00:00:00:00:00:00 eingetragen hat empfängt?
VG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 356753
Url: https://administrator.de/contentid/356753
Ausgedruckt am: 26.11.2024 um 12:11 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Broadcast an alle ports oder einfach Packet verwerfen.
Du mußt ausprobieren, was Deiner macht.
lks
PS: Sag Deinem Lehrer er soll die Aufgaben so stellen, daß man nicht in einem Forum fragen muß.
Broadcast an alle ports oder einfach Packet verwerfen.
Du mußt ausprobieren, was Deiner macht.
lks
PS: Sag Deinem Lehrer er soll die Aufgaben so stellen, daß man nicht in einem Forum fragen muß.
Moin,
hast Du nicht aufgepasst, oder warum stellst Du komische Fragen?
Auswirkungen Ethernet Kollisionen geswitchtes Netz
Sind WIR für Deine Hausaufgaben zuständig?
Innerhalb von 10 Minuten die jetzige und oben genannten Fragen lassen den Schluss zu, daß Du Deine Hausaufgaben nicht machst.
Gruss Penny
hast Du nicht aufgepasst, oder warum stellst Du komische Fragen?
Auswirkungen Ethernet Kollisionen geswitchtes Netz
Sind WIR für Deine Hausaufgaben zuständig?
Innerhalb von 10 Minuten die jetzige und oben genannten Fragen lassen den Schluss zu, daß Du Deine Hausaufgaben nicht machst.
Gruss Penny
Antwort: "These (switch) messages are informational and tell you that a frame that has a source MAC address of 00-00-00-00-00-00 is found, and the switch will never add that to the CAM table. However, the switch will forward traffic sourced from an all-zero MAC address."
Das ist die ofizielle (Cisco) Definition ! Daran wird sich auch der Rest der Netzwerkwelt halten, da offizieller IEEE Standard.
Fazit: der Switch filtert alle Pakete mit Destination Macs mit 00-00-00-00-00-00. Er forwardet aber Pakete mit einer Source Mac 00-00-00-00-00-00 die eine gültige Destination Mac hat. Gibt dann eine Warnung aus das er diese ungültige Mac nicht in seine CAM Table (Mac Forwarding Tabelle) speichern kann.
Wenn du dir einen Wireshark Sniffer nimmst kannst du das im Handumdrehen auch selber sehen !
Typischer Fehler wenn man in Hypervisoren (VmWare usw.) Mist macht und für die VM keine gültige Mac definiert !
Das ist die ofizielle (Cisco) Definition ! Daran wird sich auch der Rest der Netzwerkwelt halten, da offizieller IEEE Standard.
Fazit: der Switch filtert alle Pakete mit Destination Macs mit 00-00-00-00-00-00. Er forwardet aber Pakete mit einer Source Mac 00-00-00-00-00-00 die eine gültige Destination Mac hat. Gibt dann eine Warnung aus das er diese ungültige Mac nicht in seine CAM Table (Mac Forwarding Tabelle) speichern kann.
Wenn du dir einen Wireshark Sniffer nimmst kannst du das im Handumdrehen auch selber sehen !
Typischer Fehler wenn man in Hypervisoren (VmWare usw.) Mist macht und für die VM keine gültige Mac definiert !
Zitat von @aqui:
Typischer Fehler wenn man in Hypervisoren (VmWare usw.) Mist macht und für die VM keine gültige Mac definiert !
Typischer Fehler wenn man in Hypervisoren (VmWare usw.) Mist macht und für die VM keine gültige Mac definiert !
In dem Fall werden die Pakete nicht von einem Hypervisor bzw. einer dazugehörigen VM generiert sondern von einem physikalischen Client (Debian). Das passiert allerdings nicht kontinuierlich sondern im Schnitt so alle 15 Minuten und das dann so für ca. 3 Minuten.
Die Pakete an sich sehen folgendermaßen aus:
07:57:39.666044 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.667509 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.674509 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.676003 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.683656 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.685089 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.686610 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.688044 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
Währenddessen steigt dann im Netz die Latenz enorm an. Hast du eine Idee wodurch das verursacht wird?
Kaputte NIC?
Gleiche Symptome vor 10 Jahren, war die NIC
Gleiche Symptome vor 10 Jahren, war die NIC
Zitat von @FIGH7ER:
In dem Fall werden die Pakete nicht von einem Hypervisor bzw. einer dazugehörigen VM generiert sondern von einem physikalischen Client (Debian). Das passiert allerdings nicht kontinuierlich sondern im Schnitt so alle 15 Minuten und das dann so für ca. 3 Minuten.
Zitat von @aqui:
Typischer Fehler wenn man in Hypervisoren (VmWare usw.) Mist macht und für die VM keine gültige Mac definiert !
Typischer Fehler wenn man in Hypervisoren (VmWare usw.) Mist macht und für die VM keine gültige Mac definiert !
In dem Fall werden die Pakete nicht von einem Hypervisor bzw. einer dazugehörigen VM generiert sondern von einem physikalischen Client (Debian). Das passiert allerdings nicht kontinuierlich sondern im Schnitt so alle 15 Minuten und das dann so für ca. 3 Minuten.
Dann stell die Frage doch gleich richtig und erwecke nicht den Eindruck, als ob Du ein Schüler wärst, der Hausaufgabenhilfe sucht.
Die Pakete an sich sehen folgendermaßen aus:
07:57:39.666044 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.667509 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.674509 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.676003 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.683656 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.685089 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.686610 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.688044 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
Währenddessen steigt dann im Netz die Latenz enorm an. Hast du eine Idee wodurch das verursacht wird?
07:57:39.666044 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.667509 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.674509 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.676003 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.683656 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.685089 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.686610 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
07:57:39.688044 00:00:00:00:00:00 > 00:00:00:00:00:00 Null Information, send seq 0, rcv seq 0, Flags [Command], length 46
Währenddessen steigt dann im Netz die Latenz enorm an. Hast du eine Idee wodurch das verursacht wird?
Kaputte NIC würde ich tippen. Häng mal die debian-Kiste direkt an an Analysegerät oder einen anderen Client ohne switch dazwischen an und schau mit wireshark, was dann passiert. (mit wirescharl/tcpdump kann man auch auf dem debian schauen, ob der wirklich die Pakete wegschickt.
lks
Client (Debian). Das passiert allerdings nicht kontinuierlich sondern im Schnitt so alle 15 Minuten und das dann so für ca. 3 Minuten.
Uhhhh...gruselig. Da solltest du ganz schnell mal die NIC tauschen. Kollege LKS hat Recht hier. Die Mac ist eigentlich fest in ein Prom eingebrannt und immer auslesbar. Sog. "BIA".Es sei denn man manipuliert sie per Software im Treiber. Das geht auch die BIA im Prom bleibt aber immer bestehen, denn die ist Read Only.
Hast du eine Idee wodurch das verursacht wird?
Da kann man nur spekulieren.Renomierte Switches verwerfen sowas sofort in Hardware. Möglich das billige China Böller da einen Lookup bis zum Sankt Nimmerleinstag machen im CAM und sich dann die Karten legen da die das meist in Software machen.
Das beeinflusst dann wie immer die Forwarding Rate.
Bei so mit heisser Nadel gestrickten Firmwares wird meist nicht sauber programmiert was mit Frames passiert die es nicht geben dürfte. Sowas wird meistens schlicht ignoriert. Da gilt dann das darf es nicht geben also muss ich mich nicht drum kümmern. Das Resultat siehst du dann.
Das ist jetzt aber auch nur Spekulation.
Wenn man einen renomierten Hersteller mit Wartungsvertrag hat sollte man bei sowas immer einen Support Case eröffnen und sowas klären lassen.
Heutzutage wird die Mehrheit der Firmwares direkt beim Kunden "betagetestet" ! Besonders im Billig- und Consumer Bereich.
