Die IP-Adresse allein bringt noch keinen Frame zum Nachbarn.

PC A möchte eine Datei von PC B abrufen. Beide stehen am selben Switch und haben passende IPv4-Adressen. Trotzdem muss A vor der Übertragung eine weitere Frage beantworten: Welche Ethernet-Adresse gehört zum nächsten Empfänger? IP entscheidet über das logische Ziel und den Weg; Ethernet benötigt auf diesem lokalen Abschnitt eine passende Ziel-MAC-Adresse. Bei IPv4 kann ARP die benötigte Zuordnung ermitteln.

Ethernet ist eine Familie von Verfahren für lokale Übertragung, standardisiert in IEEE 802.3. Im gewöhnlichen heutigen Büro-LAN verbinden dedizierte Leitungen die Geräte mit Switches. Ein aktiver Link erlaubt die Übertragung von Frames, garantiert aber weder die richtige VLAN-Zuordnung noch Internetzugang. WLAN ist ein anderes Link-Verfahren; ein Access Point kann es mit Ethernet verbinden. Deshalb verwenden wir Ethernet nicht als Synonym für jede Netzwerkverbindung.

Wir verfolgen zunächst die direkte Kommunikation A zu B und anschließend den Weg zu einem entfernten IPv4-Ziel. Voraussetzung sind ein gewöhnliches Ethernet-LAN, passende Access-Ports in einem gemeinsamen VLAN und keine zusätzliche Isolation. Alle Adressen und Tabellen dieses Artikels sind ausdrücklich simuliert. Es wurden keine Pakete versendet und keine Geräte ausgelesen. Die MAC-Werte beginnen mit 02 und sind bewusst erfundene, lokal administrierte Unicast-Adressen.

Der Frame verbindet Adressierung, Nutzlast und Fehlererkennung.

Eine MAC-Adresse besteht im hier betrachteten Ethernet aus 48 Bits, geschrieben als sechs hexadezimale Oktette, etwa 02:00:00:00:10:20. Sie identifiziert eine Link-Schnittstelle im jeweiligen Zusammenhang. Sie ist kein geografischer Standort und kein verlässlicher dauerhafter Personen- oder Gerätenachweis. Adressen können lokal festgelegt, virtualisiert oder geändert werden. Eine IP-Adresse folgt dagegen dem IP-Adressplan und den Routingregeln.

Ein gewöhnlicher ungetaggter Ethernet-II-Frame enthält nacheinander Ziel-MAC, Quell-MAC, EtherType, Nutzlast einschließlich nötigem Padding und FCS. Die MAC-Adressen benötigen jeweils sechs Byte, das Typfeld zwei, die Frame Check Sequence vier. EtherType 0x0800 kennzeichnet IPv4, 0x0806 ARP und 0x86DD IPv6. Das Typfeld hilft dem Empfänger, den Inhalt dem passenden Protokoll zu übergeben.

Für das klassische ungetaggte Format sind 46 bis 1500 Byte Datenfeld üblich: Ein kurzes Paket erhält gegebenenfalls Padding. Das Padding gehört nicht zum enthaltenen IP-Paket. Die 1500 Byte sind die gewöhnliche Ethernet-IP-MTU, nicht die Länge der Anwendungsdatei. VLAN-Tags und andere Rahmenformate verändern die Rechnung. Präambel und Start Frame Delimiter dienen der physischen Erkennung vor dem MAC-Frame; der Interpacket Gap ist eine Übertragungspause und kein Nutzdatenfeld.

Die FCS erkennt Übertragungsfehler durch eine Prüfsumme. Daraus entsteht keine Ende-zu-Ende-Zustellgarantie und keine Verschlüsselung. Ein fehlerhafter Frame kann verworfen werden; höhere Protokolle müssen je nach Dienst mit Verlust umgehen. Bei einer Paketaufzeichnung fehlen FCS und physische Präambel häufig, weil der Adapter sie nicht an die Aufzeichnungssoftware weitergibt. Was ein Tool zeigt, muss deshalb nicht jedes Bit der Leitung enthalten.

Ein Switch lernt von der Quelle und leitet zum Ziel weiter.

Ein gewöhnlicher Layer-2-Switch führt eine MAC-Adresslerntabelle, oft Forwarding Database oder FDB genannt. Trifft ein Frame an Port 1 ein, lernt er dessen Quell-MAC in diesem VLAN an Port 1. Danach sucht er die Ziel-MAC. Ist sie an einem anderen geeigneten Port bekannt, leitet er dorthin weiter. Ist das Ziel bereits am Eingangsport zugeordnet, muss er den Frame nicht wieder auf diesen Port zurücksenden.

Ein unbekanntes Unicast-Ziel führt gewöhnlich zu Flooding: Der Frame wird auf den anderen geeigneten, weiterleitenden Ports desselben VLANs ausgegeben. Ein Broadcast wird ebenfalls innerhalb dieser Broadcast-Domäne verteilt. Das ist kein IP-Routing und kein Weiterleiten in alle beliebigen VLANs. Schleifenvermeidung, Filter oder Portregeln können die Menge tatsächlich nutzbarer Ports begrenzen.

Unicast adressiert eine einzelne Schnittstelle, Broadcast alle Teilnehmer der lokalen Broadcast-Domäne und Multicast eine Empfängergruppe. Die Ethernet-Broadcast-Adresse lautet ff:ff:ff:ff:ff:ff. Multicast kann durch zusätzliche Mechanismen gezielt verteilt werden; es ist nicht grundsätzlich identisch mit Broadcast. Bei einem normalen durch einen Switch weitergereichten Frame bleiben Quell- und Ziel-MAC erhalten. Der Switch ersetzt die Quell-MAC nicht mit seiner eigenen Verwaltungsadresse.

FDB-Einträge sind dynamischer Zustand und können altern. Ein neuer Frame frischt die passende Zuordnung auf; ein Umzug zu einem anderen Port kann sie ändern. Hinter einem Uplink können mehrere MAC-Adressen liegen. Aus einem Tabelleneintrag folgt also nicht „direkt angeschlossener einzelner PC“. Ebenso wenig enthält die FDB automatisch die IP-Adressen der Geräte. Dafür ist die Nachbartabelle eines IP-Hosts eine andere Datenstruktur.

Direktes Beispiel: A fragt nach B.

PC A hat 192.168.10.20/24 und MAC 02:00:00:00:10:20. PC B hat 192.168.10.30/24 und MAC 02:00:00:00:10:30. Das Gateway besitzt 192.168.10.1 und MAC 02:00:00:00:10:01. Im simulierten Switch liegen A an Port 1, B an Port 2 und das Gateway an Port 3. Zu Beginn seien A's ARP-Cache und die dynamische FDB leer.

ARP und MAC-Lernen zwischen zwei simulierten PCsPC A mit IPv4-Adresse 192.168.10.20 und MAC-Endung 10:20 ist an Switch-Port 1. PC B mit 192.168.10.30 und MAC-Endung 10:30 ist an Port 2. A sendet einen Broadcast-ARP-Request, der Switch lernt A an Port 1 und verteilt im VLAN. B antwortet normalerweise per Unicast. Dabei lernt der Switch B an Port 2. Danach kann A an B adressierte IPv4-Frames senden.Simuliert · gemeinsames VLANPC A · Port 1192.168.10.20/2402:00:00:00:10:20Layer-2-SwitchPort 3 führt zum GatewayPC B · Port 2192.168.10.30/2402:00:00:00:10:301 · A fragt per Broadcast:Wer hat 192.168.10.30?2 · B antwortet per Unicast:.30 hat MAC …:10:303 · A sendet IPv4-Frame an BFDB nach Request + Reply…:10:20 → Port 1…:10:30 → Port 2MAC-Werte erfunden · keine Messung
Die durchgehenden Linien zeigen die Topologie A → Switch → B, keine serielle zusätzliche Verbindung. Der Gatewayport gehört zur Broadcast-Domäne; er ist für die direkte Übertragung zu B kein Zwischenrouter.

A's Routingentscheidung ergibt für dieses einfache /24 eine direkt erreichbare Nachbarschaft. Die ARP-Anfrage enthält sinngemäß: „Wer hat 192.168.10.30? Antworte 192.168.10.20.“ Sie trägt A's Sender-IP und Sender-MAC sowie B's gesuchte IP. Der Ethernet-Frame geht an Broadcast. ARP liegt dabei direkt in Ethernet, nicht in einem IPv4-Paket. Das unbekannte Ziel-MAC-Feld innerhalb der ARP-Anfrage ist von der bekannten Ethernet-Broadcast-Zieladresse zu unterscheiden.

Der Switch lernt beim Empfang A's Quell-MAC an Port 1 und verteilt den Broadcast unter anderem zu B und zum Gateway. B erkennt seine Ziel-IP und sendet im normalen Anfrage-Antwort-Fall einen ARP Reply als Unicast an A. Darin nennt es die Zuordnung 192.168.10.30 → 02:00:00:00:10:30. Der Switch lernt nun B an Port 2; A war bereits aus dem Request bekannt, sodass der Reply gezielt zu Port 1 geht.

A speichert die Zuordnung in seinem ARP-Cache und kann das wartende IPv4-Paket in einen Frame an B verpacken. Für eine spätere Antwort benötigt auch B die passende Nachbarinformation; diese kann es bei der ARP-Verarbeitung bereits gelernt haben. Ein gültiger vorhandener Cacheeintrag erspart eine erneute Anfrage. ARP läuft folglich nicht zwangsläufig vor jedem IP-Paket und schon gar nicht vor jedem einzelnen TCP-Byte.

Entferntes Ziel: Gesucht wird die MAC des Next Hops.

Nun sendet A an den ausdrücklich simulierten Server 198.51.100.80 aus einem offiziellen Dokumentationsbereich. A's Routingtabelle enthält die direkte /24-Route und eine Standardroute über 192.168.10.1. Es gibt im Beispiel keine spezifischere Route. Die Routenwahl liefert daher das Gateway als Next Hop. A fragt mit ARP nach 192.168.10.1, nicht nach der MAC des entfernten Servers.

Neue Ethernet-Adressierung nach einer RoutergrenzeA sendet über den lokalen Switch an die Gateway-MAC 02:00:00:00:10:01. Das enthaltene IP-Paket adressiert den Server 198.51.100.80. Der Router verwendet auf seinem zweiten Ethernet-Link Quell-MAC 02:00:00:00:20:01 und die Server-MAC 02:00:00:00:20:80. In dieser vereinfachten Topologie ist der Server direkt am zweiten Link; NAT wird nicht verwendet. Die Ziel-IP bleibt gleich.Simuliert · Routing ohne NATA → Switch → GatewayMAC-Quelle …:10:20MAC-Ziel …:10:01IP-Ziel 198.51.100.80Router entfernt alten FrameRoute + TTL-VerarbeitungNeuer Frame am AusgangRouter → Server-LinkMAC-Quelle …:20:01MAC-Ziel …:20:80IP-Ziel 198.51.100.80Server · 198.51.100.8002:00:00:00:20:80Alle MACs beginnen mit02:00:00:00 · frei erfundenZiel-IP bleibt · MACs je Link neu
Für dieses zweite Bild liegt der Server vereinfacht direkt im Ausgangsnetz des Routers. Ein echter Internetweg enthält meist weitere Router und gegebenenfalls andere Link-Verfahren. Nicht jeder Abschnitt muss Ethernet sein.

Der erste Datenframe hat damit Quelle 02:00:00:00:10:20 und Ziel 02:00:00:00:10:01. Im enthaltenen IPv4-Paket stehen Quelle 192.168.10.20 und Ziel 198.51.100.80. Der Switch verändert diese MAC-Adressen beim gewöhnlichen Weiterleiten nicht. Erst die Routerfunktion beendet die eingehende Link-Kapselung und erzeugt für den Ausgangslink eine neue.

Im Bild besitzt die Router-Ausgangsschnittstelle erfunden MAC 02:00:00:00:20:01, der direkt dort angeschlossene Server 02:00:00:00:20:80. Der Router ermittelt bei Bedarf dessen MAC auf diesem Ausgangslink. Wäre stattdessen noch ein Router dazwischen, wäre dessen Schnittstelle das nächste Link-Ziel. Die MAC des letzten Servers muss A deshalb nicht kennen. Ohne NAT bleiben Quell- und Ziel-IP hier erhalten; TTL und IPv4-Headerprüfsumme ändern sich trotzdem beim Routing.

Dieses Dokumentationsnetz ist ein isoliertes Lehrbeispiel mit passender Rückroute, kein Vorschlag für einen tatsächlichen Internetanschluss. Private Quelladressen werden im öffentlichen Internet nicht einfach global zurückgeroutet. Das übliche Heimnetz ergänzt häufig NAT beziehungsweise NAPT. Diese zusätzliche Funktion kann IP-Adressen und Ports übersetzen. MAC-Neuadressierung an einer Routergrenze und NAT sind zwei verschiedene Vorgänge.

VLAN, Cache und IPv6 begrenzen die einfache Geschichte.

Eine ARP-Anfrage bleibt im lokalen Layer-2-Bereich. Ein gewöhnlicher Router leitet den Broadcast nicht als solchen in ein anderes IP-Netz weiter. VLANs bilden getrennte Broadcast-Domänen: A und B können trotz gleich aussehender /24-Adressen nicht direkt per ARP zueinanderfinden, wenn ihre Ports ohne passende Spezialtechnik in getrennten VLANs liegen. Ein Trunk transportiert mehrere VLANs getrennt weiter; er mischt ihre ARP-Broadcasts nicht zusammen.

Die Routingentscheidung ist umfassender als „die ersten drei Zahlen vergleichen“. Das /24 ermöglicht in unserem Beispiel diese Abkürzung; andere Präfixe und spezifischere Routen verändern die Entscheidung. Betriebssysteme können zusätzliche Regeln oder besondere On-Link-Routen verwenden. CIDR, VLANs und Routing vertiefen diese Aufgaben.

Der ARP-Cache ist ebenfalls vergänglicher Zustand. Systeme prüfen beziehungsweise erneuern Einträge nach eigenen Zustandsregeln. Ein Eintrag zeigt eine gespeicherte Zuordnung, keinen aktuellen Beweis für einen funktionierenden Webdienst. Eine ausbleibende Antwort kann auf falsches VLAN, falsche Adresse, ausgeschaltetes Ziel oder lokale Filter hinweisen. ARP besitzt keine eingebaute kryptografische Identitätsprüfung; manipulierte Antworten sind möglich. Aus einer empfangenen Zuordnung allein folgt keine vertrauenswürdige Serveridentität.

IPv6 verwendet für entsprechende Nachbaraufgaben Neighbor Discovery über ICMPv6, kein ARP. Neighbor Solicitations nutzen im üblichen Auflösungsfall gezieltes IPv6-Multicast und die zugehörige Link-Multicast-Adresse. Routererkennung und Nachbarerreichbarkeitsprüfung gehören ebenfalls zum NDP-Umfeld. Die IPv4-Anweisung „sende einen ARP-Broadcast“ darf daher nicht unverändert in eine IPv6-Erklärung kopiert werden.

Eine Störung mit zwei Tabellen eingrenzen.

Bei einer lokalen Störung hältst du zuerst Adresse, Präfix, Schnittstelle und VLAN fest. Prüfe dann getrennt die Host-Nachbartabelle und die Switch-FDB: Ist die erwartete IP-MAC-Zuordnung vorhanden? An welchem VLAN-Port wurde die MAC gelernt? Ein korrekter ARP-Eintrag auf A erklärt noch nicht, ob der Switch den Frame richtig weiterleiten darf. Ein FDB-Eintrag erklärt umgekehrt nicht, ob B die richtige IPv4-Adresse besitzt.

Unter Linux zeigen ip -4 neigh show, ip -4 addr show und ip -4 route show den lokalen Zustand, ohne dabei selbst einen Ping auszulösen. Ihre Ausgabe hängt vom jeweiligen System ab. „INCOMPLETE“ ist beispielsweise ein Hinweis auf noch nicht abgeschlossene Nachbarauflösung, keine eigenständige Diagnose „Kabel defekt“. Bei einer leeren Tabelle kann schlicht noch keine Kommunikation erfolgt sein. Einträge vorschnell zu löschen beseitigt mögliche Belege.

Im eigenen Lab vergleichst du vor allem die Richtung: Scheitert schon A zu B oder erst der Weg über das Gateway? Liefert eine bekannte IP eine Anwendungsantwort, während der Name scheitert, untersuchst du zusätzlich DNS. Fehlende ARP-Auflösung zum Gateway lässt sich dagegen nicht mit einem anderen DNS-Server reparieren. Die Schichten unterscheiden hilft, passende Belege zu sammeln.

Zwei Next-Hop-Entscheidungen begründen.

Aufgabe 1: A hat 192.168.10.20/24, B 192.168.10.30/24; beide sind im selben VLAN. A's ARP-Cache ist leer. Welche IP wird abgefragt, welche Ethernet-Zieladresse trägt die Anfrage und was lernt der Switch zuerst?

Lösung: Direktes Ziel und Broadcast

A fragt nach B's 192.168.10.30, weil die Route direkt auf den gemeinsamen Link führt. Der Request-Frame geht an ff:ff:ff:ff:ff:ff. Der Switch lernt zuerst A's Quell-MAC am Eingangsport, hier Port 1. Erst B's Antwort liefert die Quell-MAC für B's FDB-Eintrag. Das Gateway ist für diesen direkten Transfer kein notwendiger Vermittler.

Aufgabe 2: A sendet an den simulierten Server 198.51.100.80; die Standardroute zeigt auf 192.168.10.1. Jemand erwartet eine ARP-Antwort des Servers auf A's lokalem VLAN. Was ist falsch, und welche Adressen ändern sich am Router ohne NAT?

Lösung: Die Nachbarauflösung folgt der Route

A löst die Gateway-IP 192.168.10.1 auf und adressiert den ersten Frame an dessen MAC. Der entfernte Server gehört nicht zur lokalen Broadcast-Domäne. Am Router wird für den Ausgangslink ein neuer Frame mit neuen Link-Adressen erzeugt. Ziel-IP und hier auch Quell-IP bleiben ohne NAT erhalten; TTL und IPv4-Headerprüfsumme werden angepasst. Die Antwort benötigt eine passende Rückroute.

Adresskonfiguration und Nachbarauflösung verbinden.

Wie Adresse, Präfix, Gateway und Resolver zum Client gelangen, erklärt DHCP. Die anschließende Nachbarauflösung ist eine andere Aufgabe. Wenn du die Entscheidung „direkt oder über das Gateway?“ noch üben möchtest, hilft das bereits veröffentlichte IPv4-/26-Video mit Netzadresse und Hostbereich. Es erklärt die IPv4-Grundlage; ARP ergänzt anschließend die passende lokale Link-Adresse.

Quellen und fachlicher Stand.

Geprüft am . Eigene Texte, simulierte Adressen und SVGs. Klassisches Ethernet-II-Lehrformat; keine vollständige Darstellung aller IEEE-802.3-Erweiterungen. IPv6 verwendet NDP statt ARP.