Zwei Geräte, eine Adresse: den Doppelgänger aufspüren

Symptome, die auf einen Adresskonflikt hindeuten

Ein Adresskonflikt zeigt sich selten mit einer klaren Meldung. Windows erkennt Konflikte beim Setzen einer Adresse und schreibt dann das Ereignis 4199 der Quelle Tcpip ins Systemprotokoll, mit der MAC-Adresse des anderen Geräts. Linux-Systeme und viele eingebettete Geräte melden dagegen nichts. Auf Cisco-Routern und Layer-3-Switches erscheint die Syslog-Meldung IP-4-DUPADDR mit Adresse, Interface und fremder MAC-Adresse, wenn ein anderes Gerät die Adresse des Router-Interfaces selbst beansprucht.

Häufiger sind indirekte Hinweise. Verbindungen brechen in unregelmäßigen Abständen ab, ein Ping zeigt einzelne Aussetzer oder sogar Antworten von unterschiedlichen Geräten, und im ARP-Cache des Gateways wechselt die MAC-Adresse. Wer diese Muster kennt, verdächtigt früh die Adressierung statt der Hardware.

• Flattern der Erreichbarkeit

  Ein Gerät ist für einige Minuten weg und kommt ohne Eingriff wieder. Der Rhythmus folgt dem ARP-Verkehr des zweiten Geräts.

• Wechselnde MAC-Adresse im ARP-Cache

  show ip arp am Gateway oder arp -a am Client zeigen für dieselbe IP-Adresse zu unterschiedlichen Zeiten unterschiedliche MAC-Adressen.

• Windows-Meldung und Ereignis 4199

  Windows zeigt einen Hinweis auf den Konflikt und protokolliert die MAC-Adresse des anderen Geräts im Systemprotokoll. Diese MAC-Adresse ist der Startpunkt für die Suche.

• Syslog am Gateway

  Cisco meldet IP-4-DUPADDR, wenn ein Gerät die Adresse des Router-Interfaces selbst beansprucht. Für Konflikte zwischen zwei Endgeräten bleibt das Gateway stumm.

Den Konflikt bestätigen: arping, ARP-Cache und Wireshark

Der schnellste Beweis ist arping im Modus für Duplicate Address Detection. Das Werkzeug fragt per ARP nach der Adresse, ohne selbst eine Absenderadresse einzutragen, und zählt die Antworten. Antwortet mehr als ein Gerät oder ein Gerät, dessen MAC-Adresse nicht zum erwarteten passt, ist der Konflikt bestätigt. Das Verfahren entspricht der Address Conflict Detection aus RFC 5227, die viele Betriebssysteme vor dem Setzen einer Adresse selbst ausführen.

Im Mitschnitt hilft Wireshark mit einer eingebauten Erkennung. Sieht Wireshark für dieselbe IP-Adresse ARP-Pakete von zwei verschiedenen MAC-Adressen, markiert es das Paket mit dem Feld arp.duplicate-address-detected und verweist im Feld arp.duplicate-address-frame auf das frühere Paket. Mit dem Filter auf die Absenderadresse siehst du beide MAC-Adressen nebeneinander.

Auf dem Gateway selbst zeigt show ip arp die aktuelle Zuordnung. Ruf den Befehl mehrmals im Abstand von einigen Minuten auf oder lösche den Eintrag gezielt mit clear ip arp, um den Wechsel zu provozieren.

# Linux, iputils-arping: Duplicate Address Detection
sudo arping -D -I eth0 -c 3 10.12.40.25
# Unicast reply from 10.12.40.25 [3C:52:82:1A:BB:07]  0.8ms
# Received 1 response(s)  -> Adresse wird bereits genutzt

# Linux und Windows: ARP-Cache
ip neigh show 10.12.40.25
arp -a 10.12.40.25
Get-NetNeighbor -IPAddress 10.12.40.25

! Cisco-Gateway
show ip arp 10.12.40.25
clear ip arp 10.12.40.25

# Wireshark-Anzeigefilter
arp.duplicate-address-detected
arp.src.proto_ipv4 == 10.12.40.25

Die MAC-Adresse bis zum Port verfolgen

Mit der fremden MAC-Adresse beginnt die Suche am Switch, an dem das Gateway hängt. show mac address-table address zeigt, an welchem Port die Adresse gelernt wurde. Ist es ein Access Port, bist du am Ziel. Ist es ein Uplink oder ein Trunk, zeigt CDP oder LLDP, welcher Switch dahinter hängt, und dort wiederholst du die Abfrage.

Endet die Spur an einem Port, hinter dem ein Hypervisor hängt, geht die Suche im Hypervisor weiter, wo die MAC-Adresse einer virtuellen Netzwerkkarte zugeordnet ist. Die ersten drei Bytes der MAC-Adresse, die Herstellerkennung, verraten oft schon, ob es sich um eine VM, einen Drucker oder ein Smartphone handelt.

Beachte, dass Cisco MAC-Adressen in Gruppen zu vier Hex-Ziffern mit Punkten schreibt, Windows mit Bindestrichen und Linux mit Doppelpunkten. 3c52.821a.bb07, 3C-52-82-1A-BB-07 und 3c:52:82:1a:bb:07 bezeichnen dieselbe Adresse.

CORE-01# show mac address-table address 3c52.821a.bb07
          Mac Address Table
-------------------------------------------
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  40    3c52.821a.bb07    DYNAMIC     Te1/1/3

CORE-01# show cdp neighbors TenGigabitEthernet1/1/3 detail | include Device ID|IP address
Device ID: ACC-2OG-01
  IP address: 10.12.10.21

! oder ohne CDP
CORE-01# show lldp neighbors TenGigabitEthernet1/1/3 detail

ACC-2OG-01# show mac address-table address 3c52.821a.bb07
  40    3c52.821a.bb07    DYNAMIC     Gi1/0/17

ACC-2OG-01# show interfaces GigabitEthernet1/0/17 description

Die häufigsten Ursachen

Die Ursache bestimmt, welche Gegenmaßnahme dauerhaft hilft. Ein abgeschalteter Port behebt den akuten Konflikt, aber nicht den Prozess, der ihn erzeugt hat.

• Statische Adresse im DHCP-Bereich

  Die häufigste Ursache. Jemand hat einem Gerät eine feste Adresse gegeben, die im DHCP-Pool liegt, oft nach einem erfolglosen Ping. Der DHCP-Server weiß davon nichts und vergibt die Adresse früher oder später erneut.

• Geklonte virtuelle Maschinen

  Eine Vorlage mit fester IP-Adresse oder ein Klon, der die MAC-Adresse der Vorlage behalten hat, erzeugt Konflikte, sobald zwei Instanzen gleichzeitig laufen. Testumgebungen, die neben der Produktion im selben VLAN stehen, sind besonders anfällig.

• Fremder DHCP-Server

  Ein mitgebrachter Router, ein Access Point im Router-Modus oder eine Appliance mit aktivem DHCP-Dienst vergibt Adressen aus demselben oder einem anderen Bereich, ohne die Leases des echten Servers zu kennen.

• Überlappende Bereiche auf zwei DHCP-Servern

  Zwei Server, die ohne Failover-Beziehung dasselbe Netz bedienen, vergeben dieselben Adressen an unterschiedliche Clients, wenn sich ihre Bereiche überschneiden.

• Verlorene oder alte Lease-Datenbank

  Nach einer Wiederherstellung oder einem Serverwechsel kennt der DHCP-Server die aktuellen Leases nicht und vergibt belegte Adressen neu.

Gegenmaßnahmen: DHCP Snooping, Dynamic ARP Inspection und Konflikterkennung

DHCP Snooping baut auf dem Switch eine Tabelle, welche IP-Adresse per DHCP an welche MAC-Adresse an welchem Port vergeben wurde, und lässt DHCP-Antworten nur an vertrauenswürdigen Ports zu. Damit sind fremde DHCP-Server wirkungslos. Dynamic ARP Inspection prüft auf dieser Grundlage jedes ARP-Paket an nicht vertrauenswürdigen Ports und verwirft solche, deren Zuordnung nicht in der Tabelle steht. Cisco beschreibt DAI als reine Prüfung eingehender Pakete, die auf die Bindungstabelle von DHCP Snooping angewiesen ist.

Geräte mit statischen Adressen tauchen in dieser Tabelle nicht auf. Für sie legst du ARP-ACLs an, sonst verwirft DAI ihre ARP-Pakete, und genau die Server, die du schützen willst, werden unerreichbar. Führe DAI deshalb VLAN für VLAN ein und beobachte die Zähler, bevor du das nächste VLAN aktivierst. IP Source Guard ergänzt das um eine Prüfung der Absenderadresse in IP-Paketen.

Auf dem DHCP-Server prüft die Konflikterkennung jede Adresse vor der Vergabe mit einem Ping. Auf Windows Server ist sie standardmäßig aus und wird mit Set-DhcpServerSetting eingeschaltet. Cisco IOS als DHCP-Server pingt Adressen standardmäßig vor der Vergabe an und führt gefundene Konflikte in einer eigenen Liste, die show ip dhcp conflict anzeigt.

! DHCP Snooping und DAI für VLAN 40
ip dhcp snooping
ip dhcp snooping vlan 40
ip arp inspection vlan 40
!
! Statischer Drucker: Zuordnung per ARP-ACL erlauben
arp access-list STATISCH-VLAN40
 permit ip host 10.12.40.25 mac host 3c52.821a.bb07
ip arp inspection filter STATISCH-VLAN40 vlan 40
!
interface TenGigabitEthernet1/1/1
 description Uplink zum Distribution-Switch
 ip dhcp snooping trust
 ip arp inspection trust
!
show ip arp inspection statistics vlan 40
show ip dhcp snooping binding vlan 40

# Windows Server: Konflikterkennung mit zwei Versuchen
Set-DhcpServerSetting -ComputerName dhcp01 -ConflictDetectionAttempts 2

Nacharbeit im Adressplan

Jeder gefundene Konflikt ist ein Hinweis darauf, dass Adressplan und Realität auseinanderlaufen. Halte im IPAM fest, welches Gerät die Adresse rechtmäßig nutzt, wer dafür zuständig ist und ob es dauerhaft eine statische Adresse braucht oder besser eine DHCP-Reservierung bekommt. Reservierungen sind fast immer die bessere Wahl, weil der DHCP-Server die Adresse dann kennt.

Prüfe außerdem, ob der statische Teil des Netzes und der DHCP-Bereich sauber getrennt sind. Ein DHCP-Pool, der das ganze Teilnetz umfasst, lädt zu Konflikten ein, weil jede statische Adresse zwangsläufig darin liegt. Lege fest, welcher Abschnitt des Netzes für feste Adressen reserviert ist, und schließe ihn im DHCP-Server aus.

Ein regelmäßiger Abgleich der ARP-Tabellen aller Gateways mit dem IPAM findet die nächste Abweichung, bevor sie zum Konflikt wird. Adressen, die im ARP auftauchen, aber im IPAM fehlen, sind die Kandidaten. Ein kleines Skript, das die Tabellen per SSH oder API einsammelt und mit dem IPAM vergleicht, reicht dafür aus.

Für IPv6 gilt dasselbe Prinzip mit anderem Werkzeug. Hosts prüfen dort jede neue Adresse per Duplicate Address Detection nach RFC 4862, bevor sie sie verwenden. Doppelte Adressen sind deshalb seltener, aber nicht ausgeschlossen, und tauchen dann im Neighbor-Cache statt im ARP-Cache auf.