Conflit d’IP détecté : trouvez le coupable rapidement

Ce qu’est vraiment un conflit d’IP (et pourquoi ça semble aléatoire)

Un conflit d’IP n’est pas une « erreur réseau ». C’est une erreur de comptabilité. Deux hôtes croient posséder la même adresse IP sur le même domaine de broadcast L2 (ou sur deux domaines accidentellement pontés). Le réseau livre volontiers les paquets à l’hôte qui « gagne » la correspondance entre IP et adresse de liaison (MAC pour IPv4/ARP, ou adresse L2 pour IPv6/NDP). Cette correspondance change dans le temps, ce qui explique pourquoi la panne paraît intermittente et malicieuse.

Ce qui bascule réellement, ce sont les entrées du cache voisin sur les autres appareils :

• En IPv4, les caches ARP mappent IPv4 → MAC. Un conflit provoque un brassage du cache ARP. Vous verrez des logs comme « duplicate address detected », « ARP flux » ou « kernel: arp: duplicate address ».
• En IPv6, NDP (Neighbor Discovery Protocol) mappe IPv6 → link-layer. Les conflits IPv6 sont moins fréquents mais peuvent être plus pénibles car vous pouvez avoir plusieurs adresses IPv6 (SLAAC + DHCPv6 + statique) et des adresses de confidentialité qui compliquent l’attribution.

Les conflits apparaissent souvent dans quelques scénarios typiques :

• Adresses statiques squattées dans une plage DHCP. Quelqu’un configure en dur 192.168.1.50 sur une imprimante parce que « c’est plus simple », et DHCP la distribue ensuite.
• VMs ou containers clonés avec identité réseau préservée. Un template est cloné, une adresse MAC est dupliquée, ou une erreur de gestion de configuration force la même IP sur plusieurs nœuds.
• Serveur DHCP rogue. Un routeur grand public branché sur un port de bureau commence à offrir des baux et des passerelles absurdes.
• Extension de couche 2 non désirée. Un pont, un VLAN mal câblé ou un réseau étendu fait partager le même sous‑réseau entre deux sites sans que vous vous en rendiez compte.
• Tempêtes de gratuitous ARP. Certains appareils spamment des annonces « j’appartiens à cette IP » lors d’un basculement ou d’un redémarrage, et d’autres systèmes les croient.

Une citation qui survit à chaque postmortem est une vérité de fiabilité attribuée à Richard Cook, souvent paraphrasée en opérations : idée paraphrasée : « Les systèmes réussissent parce que les gens s’adaptent constamment ; les échecs surviennent quand cette adaptation ne suit plus. » Dans les conflits d’IP, « l’adaptation » est votre réseau qui réapprend sans cesse ARP/NDP—jusqu’à ce qu’il n’y parvienne plus.

Blague #1 : Un conflit d’IP est le seul moment où deux machines sont d’accord sur quelque chose et où tout le monde en souffre.

Playbook de diagnostic rapide

C’est la partie que vous imprimez (ou du moins que vous mémorisez). Sous pression, ne commencez pas par redémarrer des appareils au hasard. Les redémarrages peuvent « réparer » temporairement en changeant la dernière MAC vue, ce qui détruit des preuves.

Première étape : confirmez que c’est un vrai conflit et bornez-le

1. Identifiez l’IP contestée à partir des logs/alertes/retours utilisateurs.
2. Trouvez au moins deux adresses MAC différentes revendiquant cette IP (preuves ARP/NDP). Si vous n’avez qu’une seule MAC, vous chassez peut‑être un problème de routage ou de pare‑feu.
3. Déterminez le domaine de broadcast/VLAN où vit le conflit. « Même IP » n’est problématique que si c’est sur le même segment L2, ou des segments pontés se comportant comme tel.

Deuxième étape : localisez l’offenseur physiquement/logiquement

1. Depuis un hôte sur le même VLAN, interrogez ARP pour l’IP et notez la MAC.
2. Sur le switch, cherchez cette MAC dans la table de forwarding pour obtenir le switchport (ou le trunk/uplink).
3. Suivez la MAC hop par hop jusqu’à atteindre un port d’accès. Si c’est du sans‑fil, vous tomberez sur la table d’association WLC/AP à la place.

Troisième étape : décidez si c’est DHCP, statique ou virtualisation

1. Vérifiez les journaux/baux DHCP pour cette IP : a‑t‑elle été attribuée, à quelle MAC, quand ?
2. Cherchez un serveur DHCP rogue si les clients ont une passerelle/DNS incorrecte ou des baux d’une source étrange.
3. Vérifiez les plateformes de virtualisation pour MAC dupliquées ou configuration statique dupliquée (VM templates, cloud‑init, netplan, systemd‑networkd, CNI Kubernetes).

Conditions d’arrêt (quand vous en avez assez)

• Vous pouvez nommer les deux adresses MAC et cartographier chacune vers un appareil/port.
• Vous savez laquelle est « légitime » (inventaire, réservation DHCP, attribution statique documentée).
• Vous comprenez le mécanisme : statique dans DHCP, DHCP rogue, clone, mauvais VLAN, comportement de basculement.

Faits intéressants et contexte historique

• ARP est plus vieux que la plupart des habitudes ops « modernes ». ARP a été standardisé au début des années 1980, quand les réseaux étaient plus petits et que les « adresses IP dupliquées » étaient surtout une erreur humaine.
• Le gratuitous ARP a deux visages. Il sert autant d’annonces utiles (basculement, rafraîchissement de cache) que d’abus (spoofing/empoisonnement). Même mécanisme, intentions différentes.
• Certaines OS défendent activement leur IP. Nombre de piles envoient des probes ARP avant d’utiliser une adresse, et peuvent journaliser « address conflict » si des réponses arrivent.
• La détection de conflit DHCP existe, mais ce n’est pas magique. Beaucoup de serveurs DHCP peuvent pinguer une adresse avant de la louer. Cela réduit les conflits mais n’empêche pas les mauvaises configurations statiques après coup.
• Des MAC dupliquées peuvent se faire passer pour des conflits IP. Si deux NIC partagent une MAC (mauvaises clones, MAC configurée manuellement), l’apprentissage sur le switch devient instable, provoquant des rebonds de trafic entre ports.
• IPv6 a tenté de rendre cela plus rare. La Duplicate Address Detection (DAD) est intégrée à NDP. C’est utile, mais cela crée aussi ses propres modes de défaillance quand la couche L2 est instable.
• « ARP flux » est une chose réelle, pas un terme effrayant. Linux peut répondre à l’ARP « sur la mauvaise interface » si la configuration est lâche ; les hôtes multi‑homés peuvent embrouiller leurs pairs.
• La haute disponibilité utilise les mêmes astuces que les attaquants. VRRP, CARP et de nombreux systèmes de clustering reposent sur le transfert rapide d’une IP et la mise à jour des caches voisins ; mal configurés, ils ressemblent à des conflits.

Votre boîte à outils : ARP, NDP, DHCP, switches et captures

Vous résoudrez la plupart des conflits d’IP avec quatre outils : tables de voisins, journaux DHCP, tables MAC des switches et captures de paquets. L’astuce est de les enchaîner pour que chaque réponse réduise l’espace de recherche. Si vous sautez directement sur tcpdump sans savoir quoi chercher, vous passerez une heure à lire du bruit.

IPv4 : ARP est la salle d’audience

Quand deux appareils revendiquent une IPv4, ils l’annoncent avec des réponses ARP (parfois non sollicitées). Tous les autres mettent à jour leur cache. Votre travail est d’attraper ces annonces et de les associer à des MAC et des ports.

IPv6 : NDP et DAD, même drame avec des adresses plus longues

En IPv6, les conflits sont souvent révélés pendant la DAD : l’hôte propose une adresse et écoute les objections. L’objection est une Neighbor Advertisement NDP. Capturer cet échange est précieux car il contient l’adresse de liaison du fautif.

DHCP : la piste écrite (quand elle existe)

DHCP apporte de la structure : baux, réservations, horodatages. Il apporte aussi du chaos quand il y a plus d’un serveur DHCP, ou quand quelqu’un utilise des IP statiques dans le pool. Les journaux DHCP répondent à deux questions vitales : cette IP a‑t‑elle été louée et à qui ?

Switches et contrôleurs sans‑fil : là où le corps est enterré

Une fois que vous avez la MAC fautive, votre infrastructure de commutation peut généralement vous dire le port (ou l’appareil en amont). Cela transforme un « fantôme réseau invisible » en ticket concret : « Port Gi1/0/17 a la MAC aa:bb:cc:dd:ee:ff, étiqueté ‘Conference Room’ ».

Capture de paquets : le sérum de vérité

Quand les logs mentent, les paquets ne mentent pas. Une courte capture ciblée sur ARP/NDP montrera qui revendique l’adresse et à quelle fréquence. Cette fréquence compte : les systèmes HA vont envoyer des rafales puis se taire ; les appareils défaillants spamment sans fin ; les malwares auront des motifs bizarres périodiques.

Blague #2 : Les tables ARP sont comme les plans de bureau—périmées, parfois fausses, et tout le monde leur fait quand même confiance.

Tâches pratiques : commandes, sorties, décisions (12+)

Ce sont des tâches réelles à exécuter pendant un incident. Chacune inclut : la commande, un exemple de sortie, ce que cela signifie et la décision suivante. Exécutez‑les depuis un hôte sur le VLAN affecté quand c’est possible ; les exécuter depuis « ailleurs » vous donnera des données voisins périmées ou non pertinentes.

Task 1: Confirm the IP responds and see MAC resolution (IPv4)

cr0x@server:~$ ping -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=64 time=0.398 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.398/0.405/0.412/0.007 ms

Sens : L’IP est vivante (du moins pour l’instant). Cela ne prouve pas un conflit, mais ça initialise le cache ARP.

Décision : Vérifiez immédiatement l’entrée voisin ; ne laissez pas le cache expirer.

Task 2: Inspect the ARP/neighbor entry (IPv4)

cr0x@server:~$ ip neigh show 10.20.30.40
10.20.30.40 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE

Sens : Votre hôte croit actuellement que 10.20.30.40 se mappe à la MAC 00:11:22:33:44:55.

Décision : Notez la MAC. Ensuite, surveillez si elle change ; les changements sont la signature d’un conflit.

Task 3: Watch ARP cache churn in real time

cr0x@server:~$ watch -n 1 "ip neigh show 10.20.30.40"
Every 1.0s: ip neigh show 10.20.30.40

10.20.30.40 dev eth0 lladdr 00:11:22:33:44:55 STALE
Every 1.0s: ip neigh show 10.20.30.40

10.20.30.40 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Sens : La MAC est passée de 00:11:22:33:44:55 à aa:bb:cc:dd:ee:ff. C’est votre preuve indiscutable : deux appareils répondent pour la même IP.

Décision : Maintenant chassez les deux adresses MAC à travers le réseau. Ne « corrigez » pas encore ; identifiez d’abord les deux points de terminaison.

Task 4: Capture ARP claims (who is shouting “I own this IP”)

cr0x@server:~$ sudo tcpdump -ni eth0 arp and host 10.20.30.40
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:01:10.102345 ARP, Reply 10.20.30.40 is-at 00:11:22:33:44:55, length 28
12:01:10.508901 ARP, Reply 10.20.30.40 is-at aa:bb:cc:dd:ee:ff, length 28

Sens : Deux MAC différentes émettent des réponses ARP pour la même IP. C’est définitif.

Décision : Passez à la recherche dans le switch/WLC pour chaque MAC. Si vous n’y avez pas accès, transmettez ces MAC à qui le peut.

Task 5: Check if your Linux host is the culprit (don’t laugh)

cr0x@server:~$ ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.20.30.41/24 brd 10.20.30.255 scope global eth0
       valid_lft forever preferred_lft forever

Sens : Cet hôte n’est pas configuré avec 10.20.30.40. Bien—vérifiez quand même car les blessures auto‑infligées sont courantes.

Décision : Si il était configuré avec l’IP contestée, arrêtez‑vous et corrigez‑la avant de poursuivre la chasse réseau.

Task 6: Look for kernel duplicate address messages (Linux)

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | egrep -i "duplicate|arp|conflict"
Feb 05 11:58:22 server kernel: arp: 10.20.30.40 is detected on eth0 with different hwaddr aa:bb:cc:dd:ee:ff

Sens : Le kernel a observé une divergence pour le mapping IP/MAC. Cela confirme le problème du point de vue de l’OS.

Décision : Utilisez l’horodatage pour corréler avec les journaux DHCP, les flaps CAM du switch ou un redémarrage d’appareil.

Task 7: Identify the “legitimate” owner via DHCP lease (ISC dhcpd example)

cr0x@server:~$ sudo grep -n "10.20.30.40" /var/lib/dhcp/dhcpd.leases | tail -n 12
1827:lease 10.20.30.40 {
1828:  starts 3 2026/02/05 11:30:01;
1829:  ends 3 2026/02/05 23:30:01;
1830:  cltt 3 2026/02/05 11:30:01;
1831:  binding state active;
1832:  hardware ethernet 00:11:22:33:44:55;
1833:  uid "\001\000\021\"3DU";
1834:  client-hostname "acct-laptop-17";
1835:}

Sens : DHCP croit que 10.20.30.40 appartient à la MAC 00:11:22:33:44:55 (hostname du client inclus).

Décision : Considérez 00:11:22:33:44:55 comme le client légitime probable si votre plage DHCP est correcte et n’est pas empoisonnée. Chassez ensuite aa:bb:cc:dd:ee:ff comme l’intrus.

Task 8: Check systemd-networkd DHCP client logs (to see what server answered)

cr0x@server:~$ journalctl -u systemd-networkd --since "2 hours ago" | egrep -i "DHCPv4|lease|server"
Feb 05 11:31:04 server systemd-networkd[612]: eth0: DHCPv4 address 10.20.30.41/24 via 10.20.30.1
Feb 05 11:31:04 server systemd-networkd[612]: eth0: DHCPv4 server: 10.20.30.2

Sens : Votre hôte a obtenu son bail depuis le serveur DHCP 10.20.30.2. Si des clients obtiennent des baux depuis des serveurs différents, vous pouvez avoir un serveur DHCP rogue.

Décision : Si l’IP du « serveur » est inattendue, escaladez vers l’équipe réseau pour localiser le rogue et activer DHCP snooping/port security.

Task 9: Find the switchport from a MAC (generic approach via ARP + SNMP-friendly workflow)

cr0x@server:~$ arp -an | grep "10.20.30.40"
? (10.20.30.40) at aa:bb:cc:dd:ee:ff [ether] on eth0

Sens : Vous avez la MAC à rechercher dans la table CAM du switch.

Décision : Sur le switch d’accès, lancez une recherche d’adresse MAC (commande spécifique au fournisseur). Si vous ne pouvez pas, envoyez la MAC à quelqu’un qui le peut.

Task 10: Detect MAC flapping on Linux bridge (sometimes the “switch” is a host)

cr0x@server:~$ bridge fdb show br0 | head
00:11:22:33:44:55 dev vnet3 master br0
aa:bb:cc:dd:ee:ff dev vnet7 master br0

Sens : Sur un hôte de virtualisation, vous pouvez voir quels vNICs correspondent à chaque MAC. C’est souvent le chemin le plus rapide en environnements VM‑lourds.

Décision : Mappez vnet3/vnet7 aux noms de VM (libvirt, qemu, etc.) et vérifiez leurs configurations IP ou cloud‑init.

Task 11: Check for duplicated IP configuration in netplan (common in image-based provisioning)

cr0x@server:~$ sudo cat /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    eth0:
      addresses: [10.20.30.40/24]
      gateway4: 10.20.30.1
      nameservers:
        addresses: [10.20.30.2,8.8.8.8]

Sens : Cet hôte est configuré statiquement avec l’IP contestée. Si vous voyez cela sur plusieurs machines à cause d’une image maître, vous avez trouvé votre usine à conflits.

Décision : Corrigez la pipeline de provisionnement : adressage unique via DHCP ou allocation statique templatisée. Ensuite changez l’IP de l’hôte fautif et videz les caches.

Task 12: Flush neighbor cache after the fix (client-side stabilization)

cr0x@server:~$ sudo ip neigh flush 10.20.30.40

Sens : Vous avez supprimé le mapping périmé pour que l’hôte réapprenne rapidement la MAC correcte.

Décision : Faites cela sur les serveurs impactés après remédiation, surtout s’ils ont épinglé la « mauvaise » MAC et continuent d’échouer.

Task 13: IPv6 conflict check: view neighbor entry and DAD hints

cr0x@server:~$ ip -6 neigh show dev eth0 | head
fe80::a00:27ff:fe12:3456 lladdr 08:00:27:12:34:56 router REACHABLE
2001:db8:20:30::40 lladdr 00:11:22:33:44:55 STALE

Sens : Vous avez un mapping voisin IPv6. S’il bascule entre deux lladdrs, vous avez la version IPv6 du problème.

Décision : Capturez NDP (tâche suivante) et cherchez des Neighbor Advertisements depuis plusieurs sources.

Task 14: Capture IPv6 NDP for a specific address

cr0x@server:~$ sudo tcpdump -ni eth0 "icmp6 and (ip6[40] == 135 or ip6[40] == 136)"
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:07:11.001122 IP6 fe80::1 > ff02::1:ff00:40: ICMP6, neighbor solicitation, who has 2001:db8:20:30::40, length 32
12:07:11.003210 IP6 fe80::a00:27ff:fe12:3456 > fe80::1: ICMP6, neighbor advertisement, tgt is 2001:db8:20:30::40, length 32
12:07:11.004001 IP6 fe80::b00:dead:beef:1 > fe80::1: ICMP6, neighbor advertisement, tgt is 2001:db8:20:30::40, length 32

Sens : Deux sources link‑local différentes annoncent la propriété de la même adresse IPv6. C’est un conflit.

Décision : Extraites les adresses L2 (utilisez -e sur tcpdump si nécessaire) et tracez‑les via la commutation/sans‑fil comme vous le feriez pour ARP.

Task 15: Detect rogue DHCP offers on the wire (DORA inspection)

cr0x@server:~$ sudo tcpdump -ni eth0 -vvv "udp and (port 67 or port 68)" -c 20
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:01.100001 IP (tos 0x0, ttl 64, id 1001, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:11:22:33:44:55, length 300, xid 0x1a2b3c4d
12:10:01.101111 IP (tos 0x0, ttl 64, id 2001, offset 0, flags [none], proto UDP (17), length 342)
    10.20.30.2.67 > 10.20.30.41.68: BOOTP/DHCP, Reply, length 314, xid 0x1a2b3c4d, yiaddr 10.20.30.41
12:10:01.101999 IP (tos 0x0, ttl 255, id 3001, offset 0, flags [none], proto UDP (17), length 342)
    192.168.0.1.67 > 10.20.30.41.68: BOOTP/DHCP, Reply, length 314, xid 0x1a2b3c4d, yiaddr 10.20.30.99

Sens : Deux serveurs DHCP différents ont répondu : 10.20.30.2 (attendu) et 192.168.0.1 (très suspect sur ce sous‑réseau). C’est un serveur DHCP rogue, qui peut indirectement provoquer des conflits IP et cause certainement un mauvais routage.

Décision : Intervenez avec le réseau/sécurité : désactivez le port, activez DHCP snooping, localisez le device rogue via la MAC du paquet DHCP (-e) et lookup de switchport.

Trois mini-récits d’entreprise issus des opérations

Story 1: The incident caused by a wrong assumption

L’entreprise était en migration d’un réseau de bureau legacy vers un nouveau design segmenté. Une petite équipe a créé un sous‑réseau « temporaire » pour un lab : même plage RFC1918 que la production, parce que « c’est isolé ». Ils étaient confiants car le switch lab était dans un placard différent et le routeur lab avait une liaison WAN distincte. Isolation, par vibes.

Deux mois plus tard, un prestataire avait besoin d’accès distant au lab. Quelqu’un a ajouté un tunnel VPN et a ponté le VLAN du lab dans le cœur de campus « juste pour une semaine ». Personne n’a mis à jour les diagrammes réseau. Personne n’a mis à jour l’IPAM. Le tunnel est resté.

Puis la fête a commencé : des endpoints production perdaient intermittemment l’accès à un service de fichiers. L’IP du service était stable ; la MAC ne l’était pas. Le helpdesk a accusé l’équipe stockage. Stockage a accusé le pare‑feu. Le pare‑feu a accusé le DNS parce que c’est ce que font les équipes pare‑feu quand elles s’ennuient.

La percée fut douloureusement simple : une capture ARP montrait deux MAC revendiquant l’IP du service. L’une était le serveur réel. L’autre était une VM du lab configurée avec un fichier netplan copié‑collé depuis une page wiki. Le lab « isolé » était devenu partie du domaine de broadcast production via une erreur de pontage.

La correction n’a pas été héroïque. Elle a été soigneuse : supprimer le pont, auditer les chevauchements RFC1918, et imposer une règle—pas d’espaces d’adresses qui se chevauchent entre environnements sauf si vous pouvez prouver la séparation L2 et L3. Le postmortem n’a pas conclu « les gens ont merdé. » Il a conclu « nous avons supposé l’isolation sans vérifier le chemin. »

Story 2: The optimization that backfired

Une autre organisation se vantait de son provisionnement rapide. Ils avaient une image VM « golden » qui démarrait vite et rejoignait la flotte avec peu de dépendances externes. Pour réduire le temps de boot, ils ont décidé de préconfigurer des adresses statiques dans l’image pour un niveau de service spécial : moins d’appels DHCP, mise en service plus rapide, moins de pièces mobiles. Sur le papier, propre.

L’image contenait /etc/netplan/01-netcfg.yaml avec une IP statique. Le plan était « on l’écrase par hôte pendant le provisioning ». Mais l’écrasement dépendait d’une étape cloud‑init qui échouait parfois quand le service metadata était lent. Ces machines démarrèrent avec l’IP intégrée.

Ça n’a pas explosé tout de suite. Ça a couvé. Ce n’est que lors d’événements d’échelle—fenêtres de patch ou pics de trafic—que plusieurs instances démarraient en même temps et se percutait sur la même IP. Le graphe de supervision ressemblait à un pouls : up, down, up, down. L’équipe l’appelait « le flapper ».

Ils ont essayé d’amortir : temps de vie ARP plus longs, keepalives, « peut‑être le load balancer ». Tout cela gérait les symptômes. L’optimisation elle‑même—IP statique intégrée à l’image—était la racine du chaos.

La correction a été d’arrêter d’être trop malins : retirer l’adressage statique de l’image de base, laisser DHCP faire son travail, et utiliser des réservations quand des IP stables sont nécessaires. Le temps de boot a légèrement augmenté. Le nombre d’incidents a chuté de façon spectaculaire. Un compromis acceptable pour la plupart des entreprises.

Story 3: The boring but correct practice that saved the day

Dans un environnement fortement réglementé, l’équipe réseau conservait une habitude peu glamour : chaque VLAN avait des scopes DHCP documentés, des exclusions et des plages réservées pour les statiques. Ils faisaient aussi respecter que les adresses « statiques » soient seulement assignées hors du pool DHCP, jamais dedans. Pas d’exceptions, pas de « juste pour une imprimante », pas de « c’est temporaire ».

Un matin, une vague d’alertes de conflit IP a frappé un segment d’application clinique. Le tri a commencé : des captures ARP montraient deux MAC pour la même IP—l’une appartenant à un modèle thin client connu, l’autre inconnue. L’équipe a consulté le bail DHCP et a tout de suite vu le propriétaire prévu. Cela a réduit le suspect à « quelque chose de statique ou rogue », pas « DHCP qui dysfonctionne au hasard ».

Ensuite, ils ont fait la chose la plus ennuyeuse imaginable : lookup MAC sur le switch. La MAC inconnue était sur un port d’accès dans une salle de réunion qui n’était pas censée être sur ce VLAN. Le port était patché sur un petit switch non géré. De là : un routeur Wi‑Fi consommateur apporté de la maison. Il faisait du bridge et offrait du DHCP, et avait aussi une IP statique provenant d’un environnement précédent qui entrait en collision avec une adresse louée.

La résolution a pris quelques minutes : désactiver le port, retirer l’appareil, vider les caches voisins sur les serveurs clés, confirmer qu’il n’y avait pas d’autres serveurs DHCP rogue. Le rapport post‑incident était satisfaisant et ennuyeux : scopes documentés et traçage de switchport ont fonctionné comme prévu.

La monotonie gagne. Ce n’est pas un slogan ; c’est une vérité opérationnelle.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: “It works for some users but not others”

Cause racine : Les caches ARP diffèrent selon les clients ; certains ont la MAC A pour l’IP, d’autres la MAC B. Le service paraît aléatoirement accessible.

Correction : Capturez les réponses ARP pour confirmer la double revendication, puis tracez les MAC via les tables de switch. Après remédiation, videz les caches voisins sur les clients/serveurs critiques.

2) Symptom: “Conflict happens only after reboots or failover”

Cause racine : Mauvaise configuration d’une paire HA (VRRP/CARP/keepalived) où les deux nœuds pensent être master, ou le basculement envoie des gratuitous ARP trop agressifs et embrouille les équipements en amont.

Correction : Validez la machine d’état HA, les réglages de préemption et les contrôles de santé. Assurez‑vous qu’un seul nœud détient le VIP. Capturez l’ARP pendant le basculement pour prouver le comportement.

3) Symptom: “We see duplicate IP alerts, but the IP doesn’t ping”

Cause racine : L’adresse est revendiquée via ARP mais le pare‑feu de l’hôte bloque l’ICMP ; ou vous observez un ARP spoofing / scan de sécurité ; ou le conflit existe sur un VLAN différent de celui où vous testez.

Correction : Ne vous fiez pas au ping comme vérité. Utilisez les preuves ARP/NDP et la localisation par switchport. Vérifiez le contexte VLAN (tagging trunk, VLAN d’accès).

4) Symptom: “New devices keep getting wrong gateway/DNS”

Cause racine : Serveur DHCP rogue, souvent un routeur grand public ou une VM mal configurée tournant dnsmasq.

Correction : Identifiez les sources d’offres DHCP avec tcpdump, puis isolez par MAC et switchport. Mettez en place DHCP snooping et bloquez les ports serveurs DHCP à la périphérie.

5) Symptom: “The same MAC shows up on two switchports”

Cause racine : Adresse MAC dupliquée (VMs clonées, MAC réglée manuellement, firmware NIC buggy) ou boucle/unmanaged switch provoquant l’instabilité CAM.

Correction : Confirmez dans l’inventaire de virtualisation ; imposez une génération unique de MAC. Vérifiez les boucles L2 ; assurez‑vous que STP est activé ; envisagez la port security pour limiter les mouvements de MAC.

6) Symptom: “IP conflicts only on Wi‑Fi”

Cause racine : Quirks d’isolation client/roaming, plusieurs SSID mappés au même VLAN de manière inattendue, ou contrôleur sans‑fil mal configuré relayant DHCP incorrectement.

Correction : Corrélez via la table clients WLC en utilisant la MAC, vérifiez le mapping SSID→VLAN, et cherchez des points d’accès rogue qui pontent les réseaux.

7) Symptom: “We fixed it, but it came back a day later”

Cause racine : Vous avez corrigé le symptôme (changé l’IP d’un hôte) mais pas le mécanisme (template, chevauchement DHCP, appareil non géré qui revient).

Correction : Discipline de la cause racine : trouvez l’appareil source et la raison pour laquelle il avait cette IP. Mettez à jour l’IPAM, imposez des exclusions et ajoutez des dispositifs de détection.

Listes de contrôle / plan pas à pas

Incident checklist: 15 minutes to clarity

1. Notez : IP contestée, VLAN/sous‑réseau affecté, heure d’observation initiale, qui l’a signalé.
2. Depuis un hôte sur le même VLAN : ip neigh show <IP> et notez la MAC.
3. Exécutez : tcpdump -ni <if> arp and host <IP> pendant 30–60 secondes. Enregistrez toutes les MAC vues.
4. Vérifiez les baux/journaux DHCP : l’IP est‑elle louée ? à quelle MAC ? Des IPs de serveur DHCP inhabituelles ?
5. Tracez la(des) MAC sur le switch : trouvez le port d’accès ou le lien en amont. Répétez hop‑par‑hop.
6. Identifiez l’appareil : inventaire, OUI du vendor, hostname DHCP, mapping virtualisation, entrée client wireless.
7. Arrêtez l’hémorragie : désactivez le port fautif, retirez la config statique, ou corrigez l’état HA. Évitez le « redémarre juste ».
8. Stabilisez : videz les caches voisins sur les serveurs clés, redémarrez les services impactés si nécessaire.
9. Prévenez la récidive : corrigez les chevauchements de scope DHCP, mettez à jour l’IPAM, ajoutez des garde‑fous (snooping, réservations, correctifs de template).

Prevention checklist: make conflicts boring again

• Maintenez une plage statique réservée par VLAN et gardez‑la hors des pools DHCP.
• Activez la détection de conflit DHCP sur le serveur quand disponible (vérification ARP avant offer).
• Activez DHCP snooping et Dynamic ARP Inspection (là où le matériel le supporte) sur les switches d’accès.
• Imposez des adresses MAC uniques dans les templates VM ; ne plantez jamais d’IP statique dans les images golden à moins d’assurer l’unicité.
• Journalisez et alertez sur les flaps MAC pour la même IP (sur firewall, switches, ou via capteurs passifs).
• Gardez un processus minimal « qui est cette MAC » : lookup OUI + mapping inventaire interne.
• Documentez le comportement des VIP HA (VRRP/CARP/keepalived) et testez les scénarios de split‑brain.

Post-incident verification checklist

1. Confirmez que ARP/NDP pour l’IP résout exactement vers une seule MAC sur une fenêtre de surveillance de 5–10 minutes.
2. Confirmez que DHCP n’a pas de bail actif pour cette IP lié à la « mauvaise » MAC (ou supprimez‑le).
3. Confirmez que la table CAM du switch montre la MAC sur le port attendu et que c’est stable.
4. Confirmez que les applications affectées sont stables : pas de resets de connexion, pas de timeouts intermittents.
5. Rédigez la cause racine en une phrase incluant le mécanisme (pas seulement l’appareil coupable).

FAQ

1) How do I know it’s an IP conflict and not DNS?

Les problèmes DNS ne changent pas les adresses MAC. Si ip neigh (ou des captures ARP) montrent plusieurs MAC pour la même IP, c’est un conflit. Le DNS peut aussi être cassé, mais c’est une signature de panne différente.

2) Why does the problem come and go?

Parce que les caches ARP/NDP vieillissent et se rafraîchissent. L’appareil qui a annoncé le dernier « gagne » jusqu’à ce qu’un événement déclenche un rafraîchissement (trafic, expiration de cache, gratuitous ARP, solicitation voisin).

3) Can I just clear the ARP table to fix it?

Vider les caches voisins peut restaurer brièvement la connectivité, mais n’enlève pas le deuxième revendicateur. C’est une étape de stabilisation après correction, pas un remède.

4) What if both devices are “legitimate,” like an HA pair?

Alors un seul d’entre eux devrait être master pour le VIP à un instant T. Si les deux le revendiquent, vous avez un split brain ou une mauvaise configuration de basculement. Capturez l’ARP pendant l’événement et vérifiez les transitions d’état HA.

5) How do I find the device if I only have an IP and no switch access?

Utilisez une capture ARP pour obtenir la MAC. Ensuite utilisez l’inventaire disponible : hostname du bail DHCP, tables bridge d’hyperviseur, listes clients du contrôleur wireless, ou enregistrements de gestion des endpoints indexés par MAC.

6) Do IPv6 networks get IP conflicts?

Oui, mais ils sont souvent détectés plus tôt grâce à la Duplicate Address Detection. Cela dit, des segments mal pontés, des IPv6 statiques ou des images clonées peuvent créer des duplicatas. Utilisez les captures NDP et les tables voisins comme pour ARP.

7) What’s the fastest way to prove there are two devices?

tcpdump sur ARP (ou NDP pour IPv6) et un loop watch sur ip neigh show. Si la MAC alterne, vous avez une preuve difficile à contester.

8) Why do printers and IoT devices show up in these incidents so often?

Ils se voient souvent attribuer des IP statiques « temporairement », sont déplacés entre réseaux, et rarement mis à jour. Ils vivent aussi sous les bureaux ou dans les placards, ce qui en fait des coupables parfaits.

9) Should we put everything on DHCP to avoid conflicts?

Pour la plupart des endpoints et serveurs généraux, oui. Pour l’infrastructure nécessitant des adresses stables, utilisez des réservations DHCP ou une plage statique documentée en dehors du pool. « Un peu de statique, un peu de DHCP, sans documentation » est la façon d’inviter des conflits.

Conclusion : étapes suivantes pour éviter les récidives

Quand un conflit d’IP survient, le meilleur mouvement est d’arrêter de deviner et de commencer à collecter deux identifiants : l’IP contestée et les adresses MAC revendicatrices. À partir de là, c’est de la mécanique pure : mapper la MAC au port (ou au vNIC VM, ou à l’association Wi‑Fi), valider l’intention DHCP, et retirer le revendicateur supplémentaire.

Vos prochaines étapes pratiques :

1. Adoptez le playbook rapide et exigez des preuves ARP/NDP avant toute « correction ».
2. Nettoyez l’adressage : maintenez les IP statiques hors des pools DHCP et documentez les plages réservées.
3. Renforcez la périphérie : DHCP snooping, inspection ARP et politiques de port sensées quand votre matériel le supporte.
4. Corrigez vos templates : pas d’IP statiques intégrées, pas de MAC dupliquées, et pas de configs « temporaires » qui deviennent permanentes.

Si vous faites ces quatre choses, « IP conflict detected » redeviendra une curiosité rare plutôt qu’un personnage récurrent dans votre file d’incidents.