Sy1k
FISI – Systemintegration

Netz von Null · 2/50 · 50 Min. angesetzt – Langform, jedes Wort zählt

Broadcast, ARP, warum DHCP schreien muss

Ein Rechner, der gerade eingeschaltet wurde, kennt oft noch keine IPv4-Adresse. Er kann niemanden persönlich anschreiben, weil „persönlich“ schon eine Nummer voraussetzt. Also schreit er in das Segment. Dieser Schrei heißt Broadcast. DHCP beginnt genau dort. Wer Broadcast und Router verwechselt, versteht nie, warum ein zweites VLAN ohne Helper stumm bleibt.

Unicast

Eine Nachricht an genau einen Empfänger. Alltag, sobald Adressen bekannt sind: dein Rechner an das Gateway, der Browser an einen Server.

Broadcast

Nachricht an alle im Segment. Ethernet nutzt die MAC ff:ff:ff:ff:ff:ff. IPv4 nutzt oft 255.255.255.255 oder die letzte Adresse des Subnetzes. Wichtig: ein normaler Router leitet Broadcasts nicht in fremde Netze weiter. Das Segment endet an der VLAN-Grenze bzw. am Router.

Multicast

An eine Gruppe, die sich darauf angemeldet hat. IPv6 arbeitet viel mit Multicast statt mit Broadcast. Router Advertisements und Nachbarsuche sitzen dort.

Praktische Folge: Ein DHCP-Server, der nur in VLAN 10 hängt, hört Discoverys aus VLAN 20 nicht. Entweder hängt in VLAN 20 ein eigener Server (oder ein zweites Interface), oder ein Relais (IP-Helper) nimmt den Schrei und trägt ihn als Unicast zum Server. Das Relais setzt ein Feld giaddr – die Adresse des Interfaces, an dem der Schrei ankam. Daran erkennt der Server, aus welchem Netz die Frage kommt, und wählt den passenden Adresspool.

ARP

Address Resolution Protocol in IPv4. Frage: „Wer hat die IP 10.20.30.1?“ Antwort: „Diese MAC.“ Ohne ARP kennt dein Rechner die Hardware-Adresse des Gateways nicht. Dann verlässt das Paket den Rechner nicht sinnvoll, obwohl ipconfig eine schöne Adresse zeigt. Windows: arp -a. Linux: ip neigh.

Cache

Kurzzeitgedächtnis. ARP-Cache merkt IP→MAC. DNS-Cache merkt Name→Daten. DHCP-Lease-Datei merkt, wer welche Adresse hat. Caches machen Netze schnell und lügen nach Änderungen. Deshalb leerst du nach einer Korrektur zuerst den passenden Cache, bevor du das Betriebssystem beschuldigst.

Der nackte Client, Schritt für Schritt

  1. Die Karte meldet Link up. Kabel sitzt oder WLAN ist assoziiert. Noch keine IPv4 vom Netz.
  2. DHCP Discover: Broadcast, Quelle oft 0.0.0.0, UDP-Port 68 nach Port 67.
  3. Ein Server antwortet mit Offer: vorgeschlagene Adresse plus Optionen (Maske, Gateway, DNS, Lease-Zeit).
  4. Der Client fordert mit Request genau dieses Angebot an. Mehrere Server können bieten, einer wird gewählt.
  5. Ack macht den Lease gültig. Nak schickt den Client zurück an den Start.
  6. Oft prüft der Client per ARP, ob die Adresse schon lebt. Dann Decline, und der Server soll sie nicht wieder anbieten.
  7. Jetzt erst gehen bewusste Unicast-Pakete an das Gateway. Die erste Namensfrage geht an den DNS aus Option 6.
# Windows
ipconfig /all
arp -a
# Linux
ip addr
ip neigh
sudo tcpdump -ni eth0 port 67 or port 68

APIPA

169.254.0.0/16. Automatische private IPv4, wenn DHCP nach mehreren Versuchen nicht geantwortet hat. Der Client kann höchstens Nachbarn mit derselben Notadresse erreichen, nicht das Firmennetz und nicht das Internet. APIPA ist der dokumentierte Fehlschlag, kein „halbes Netz“.

Prüfungs- und Betriebssatz: Ping auf 169.254.x.x heißt nicht „ein bisschen DHCP“. Es heißt: Discover ist ins Leere gelaufen. Ursachenkette: Kabel, VLAN, Relais, Dienst aus, Pool voll, Firewall auf UDP 67/68, Server an das falsche Interface gebunden.

Prüfung

Broadcasts gehen typisch …