Chapitre 04
Adressage, ARP, routage
Objectifs du chapitre
- Voir et poser une adresse IP avec
ip addr, pour se placer dans le bon plan de la cellule. - Comprendre le routage (
ip route) et pourquoi joindre un device hors subnet passe par la passerelle. - Manier ARP (
ip neigh) — le pont entre l'IP et la MAC — et tester la joignabilité parpingetarping. - Diagnostiquer les fautes IP classiques en OT, au premier rang desquelles le redoutable doublon d'adresse IP.
1. Voir et poser une adresse
Avant de tester quoi que ce soit, il faut savoir où l'on est. La commande de référence est
ip addr show, mais pour un coup d'œil rapide on préfère la vue condensée
ip -brief addr :
$ ip -brief addr
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.0.71/24 fe80::215:5dff:fe6c:1a2b/64Ici l'interface eth0 est bien dans le plan de la cellule (192.168.0.0/24).
Si ce n'est pas le cas — par exemple parce qu'on vient de brancher un poste neuf — on ajoute une adresse
dans le bon subnet :
# Se placer dans le plan machine 192.168.0.0/24
sudo ip addr add 192.168.0.71/24 dev eth0
# Vérifier
ip -brief addr show eth0
# Retirer l'adresse quand on a fini
sudo ip addr del 192.168.0.71/24 dev eth0Le /24 n'est pas décoratif : c'est lui qui dit à Linux « toutes les adresses
192.168.0.1 à 192.168.0.254 sont sur mon lien local, joignables directement ».
Sans le bon masque, l'automate voisin devient un inconnu à router.
Sur un WSL2 en mode NAT (cf. chapitre 1), poser une adresse
192.168.0.71 avec ip addr add ne suffit pas à voir le fil : la
trame ne sort jamais de la carte physique. Cette section suppose que tu es sur l'edge
ou sur un WSL en mode miroir. Poser une IP donne l'illusion d'être connecté ; seul le
trafic réel (§4) le confirme.
Poser une adresse déjà utilisée sur le segment, c'est créer un doublon — la faute
OT la plus perturbante (§5). Avant tout ip addr add sur une installation vivante,
vérifie que l'IP visée est libre : un arping -D (§5) tranche la question en deux
secondes. Ne jamais « prendre » une IP au hasard sur un réseau de production.
2. Le routage : rester local ou passer la passerelle
Quand Linux doit émettre un paquet, il consulte sa table de routage. On la lit
avec ip route :
$ ip route
default via 192.168.0.240 dev eth0 # passerelle par défaut (le Scalance/routeur)
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.71Deux entrées, deux logiques :
- La ligne
192.168.0.0/24 … scope linkdit : « pour toute IP de ce subnet, je parle directement sureth0» — c'est le cas du CPU (192.168.0.1) et des ET 200SP. - La ligne
default via 192.168.0.240dit : « pour tout le reste (une IP hors de mon subnet), j'envoie au routeur192.168.0.240, qui saura relayer ».
Pour atteindre un autre segment de la cellule — mettons un banc d'essai en
192.168.10.0/24 derrière le Scalance .240 — on ajoute une route explicite :
# Joindre le segment 192.168.10.0/24 via le Scalance .240
sudo ip route add 192.168.10.0/24 via 192.168.0.240
# Retirer la route
sudo ip route del 192.168.10.0/24Retiens la règle du « même quartier » : deux IP dans le même subnet se parlent en direct (ARP + trame Ethernet, couche 2). Deux IP dans des subnets différents ne se voient pas : il faut un routeur (couche 3) pour faire le pont. En OT, ce routeur est très souvent aussi le pare-feu IT/OT — d'où des blocages qui ne sont pas des pannes, mais des règles.
C'est la raison pour laquelle un ping vers un device « hors quartier » peut échouer même si tout fonctionne : le paquet part bien vers la passerelle, mais le pare-feu OT décide de ne pas le relayer. Diagnostiquer, ici, c'est distinguer « pas de route », « route mais filtré » et « device réellement absent ».
3. ARP, le pont L2 ↔ L3
Sur un même subnet, l'IP ne suffit pas à livrer une trame : Ethernet ne connaît que les
adresses MAC. Le protocole ARP (Address Resolution Protocol)
fait la traduction. Quand ton poste veut parler à 192.168.0.1, il crie en broadcast
« qui a 192.168.0.1 ? dis-moi ta MAC », et le CPU répond « c'est moi,
00:1b:1b:2a:10:01 ». Le résultat est mis en cache dans la table des
voisins, qu'on lit avec ip neigh :
$ ip neigh
192.168.0.1 dev eth0 lladdr 00:1b:1b:2a:10:01 REACHABLE
192.168.0.20 dev eth0 lladdr 00:1b:1b:2a:10:20 STALE
192.168.0.21 dev eth0 lladdr 00:1b:1b:2a:10:21 REACHABLE
192.168.0.240 dev eth0 lladdr 00:1b:1b:2a:10:f0 STALEChaque ligne associe une IP à une MAC (lladdr) et porte
un état :
- REACHABLE — le voisin a répondu récemment, l'entrée est fraîche et fiable.
- STALE — l'entrée est connue mais vieillissante ; elle sera revalidée au prochain trafic. Ce n'est pas une panne, juste un cache qui refroidit.
- DELAY / PROBE — états transitoires : le noyau est en train de re-sonder le voisin.
- FAILED — personne n'a répondu à l'ARP : l'IP ne correspond à aucune MAC sur le lien. Là, c'est un vrai signal d'absence.
Pour forcer une re-résolution — par exemple après avoir remplacé un équipement, donc changé la MAC derrière une IP — on vide la table :
# Purger toute la table des voisins sur eth0
sudo ip neigh flush dev eth0
# Ou une seule entrée
sudo ip neigh flush 192.168.0.20Un cache ARP obsolète est un piège de diagnostic classique : on a remplacé une ET 200SP,
la nouvelle a la même IP mais une nouvelle MAC, et le poste continue de parler à l'ancienne MAC tant
que l'entrée n'a pas expiré. Après tout remplacement de matériel, un ip neigh flush
remet les compteurs à zéro.
4. Tester la joignabilité : ping, mais pas seulement
Le réflexe est le ping, qui envoie des paquets ICMP echo request et attend
l'echo reply :
$ ping -c4 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.42 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=255 time=0.38 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=255 time=0.40 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=255 time=0.39 ms
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3051ms
rtt min/avg/max/mdev = 0.380/0.397/0.420/0.015 msQuelques options utiles au diagnostic OT :
-c4— s'arrêter après 4 paquets (sinon, boucle infinie : Ctrl+C pour couper).-i 0.2— intervalle entre paquets (par défaut 1 s). Utile pour resserrer un test, mais reste modéré en production.-s 1400— taille de charge utile, pour éprouver la fragmentation / le MTU d'un lien.-W 1— timeout d'attente d'une réponse, en secondes : raccourcit le verdict sur un device muet.
Mais voici le piège central de l'OT : beaucoup d'équipements industriels ne répondent pas
à l'ICMP. Pile réseau minimaliste, ICMP désactivé, ou pare-feu qui le filtre : le device
est bien là, parfaitement fonctionnel en Profinet, mais un ping le déclare « injoignable ».
Conclure une panne sur ce seul silence est une erreur de débutant.
$ ping -c3 192.168.0.20
PING 192.168.0.20 (192.168.0.20) 56(84) bytes of data.
--- 192.168.0.20 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2043msLa vraie question n'est pas « répond-il à l'ICMP ? » mais « est-il présent sur le
lien ? ». Pour cela on descend d'une couche : arping envoie une requête
ARP (couche 2) et attend une réponse ARP. Or tout équipement IP qui
possède l'adresse doit répondre à l'ARP pour exister sur le réseau — ICMP filtré
ou pas :
$ sudo arping -I eth0 -c3 192.168.0.20
ARPING 192.168.0.20 from 192.168.0.71 eth0
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:20] 0.703ms
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:20] 0.688ms
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:20] 0.691ms
Sent 3 probes (1 broadcast(s))
Received 3 response(s)Verdict : la station .20 est bel et bien là, elle répond en L2 avec
sa MAC 00:1b:1b:2a:10:20. Le ping muet ne signifiait qu'une chose : son
ICMP est filtré. Le lien est sain.
Un ping sans réponse en OT ne veut pas dire « device absent ».
Beaucoup d'automates, capteurs et modules I/O ne répondent pas à l'ICMP par conception. Avant de
conclure à une panne, fais un arping -I eth0 <ip> : une réponse ARP prouve la
présence sur le lien, même si l'ICMP est fermé.
Combo de terrain pour trancher « présent ou pas » :
$ ping -c2 -W1 192.168.0.20 || sudo arping -I eth0 -c2 192.168.0.20Si le ping échoue, le arping prend le relais et donne le verdict L2. Deux
réponses ARP = joignable ; zéro = vraie absence (à confirmer par câble/port au chapitre 2).
5. Le doublon d'IP, faute OT emblématique
Voici la panne qui rend fou. Deux équipements portent la même adresse IP sur le même segment — typiquement une ET 200SP de rechange configurée avec l'IP de celle qu'elle devait remplacer, mais l'ancienne est restée branchée. Le symptôme : comportement erratique. Le CPU perd puis retrouve la station, les échanges Profinet claquent par intermittence, le ping répond « une fois sur deux » avec des temps qui sautent — parce que c'est tantôt un équipement, tantôt l'autre qui répond.
La cause profonde est au niveau ARP : deux MAC différentes revendiquent la même IP. La table des voisins oscille :
$ ip neigh show 192.168.0.20
192.168.0.20 dev eth0 lladdr 00:1b:1b:2a:10:20 REACHABLE
# quelques secondes plus tard…
$ ip neigh show 192.168.0.20
192.168.0.20 dev eth0 lladdr 00:1b:1b:2a:10:aa STALELa MAC associée à .20 a changé entre deux lectures : signal d'alerte. Pour
confirmer franchement le doublon, on utilise la Duplicate Address Detection de
arping avec l'option -D. Elle sonde l'IP et signale toute réponse ;
lorsqu'on ne porte pas l'IP, deux MAC différentes qui répondent = doublon avéré :
$ sudo arping -D -I eth0 -c3 192.168.0.20
ARPING 192.168.0.20 from 0.0.0.0 eth0
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:20] 0.71ms
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:AA] 0.83ms
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:20] 0.69ms
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:AA] 0.80ms
Sent 3 probes (3 broadcast(s))
Received 4 response(s) ← plus de réponses que de sondes : DEUX répondeursLe diagnostic est sans appel : une seule IP, deux MAC
(…:10:20 et …:10:AA) répondent. Il y a bien deux équipements physiques qui se
disputent 192.168.0.20. Le nombre de réponses supérieur au nombre de sondes est un indice
immédiat.
192.168.0.20 ? » déclenche deux réponses avec des MAC différentes
(contours rouges). arping -D rend cette collision visible ; le CPU, lui, la vit comme une
station qui apparaît et disparaît.D'autres indices convergents, à corréler :
- Le noyau lui-même le remarque parfois, dans
dmesg:
$ sudo dmesg | grep -i "using our"
[ 8123.44] eth0: IPv4 duplicate address 192.168.0.20 detected!
[ 8123.44] arp: 192.168.0.20 using our address on eth0- Un scan ARP du segment liste deux MAC pour la même IP :
$ sudo arp-scan -I eth0 192.168.0.0/24 | grep 192.168.0.20
192.168.0.20 00:1b:1b:2a:10:20 Siemens AG
192.168.0.20 00:1b:1b:2a:10:aa (Unknown) ← doublonLa commande qui tranche un doublon, à connaître par cœur :
$ sudo arping -D -I eth0 -c5 192.168.0.20Plus de réponses que de sondes, ou des MAC qui alternent : doublon confirmé. Une seule MAC répétée : pas de doublon, l'IP est bien portée par un seul équipement.
Côté S7-1500, un doublon d'IP se signale dans le tampon de diagnostic et sur l'IHM par un message
explicite de type « conflit d'adresse IP » / IP address already used,
souvent accompagné d'une perte intermittente de la station Profinet concernée. Quand TIA Portal crie au
conflit et que ton arping -D montre deux MAC, tu tiens la même vérité par les deux
bouts : reste à débrancher physiquement l'intrus (identifié par sa MAC).
La bonne pratique préventive : jamais poser une IP sans l'avoir testée. Un
arping -D -I eth0 <ip> qui ne renvoie aucune réponse confirme que l'adresse
est libre. Une seule habitude qui évite la moitié des doublons créés lors des remplacements de
matériel.
6. traceroute vers l'IT : voir où ça bloque
Quand on veut joindre un serveur du côté IT (supervision, historian, mise à jour) à travers le
pare-feu OT, et que ça ne passe pas, traceroute montre le chemin sauté par sauté et
où il s'arrête :
$ traceroute 192.168.100.10
traceroute to 192.168.100.10 (192.168.100.10), 30 hops max, 60 byte packets
1 192.168.0.240 (192.168.0.240) 0.51 ms 0.44 ms 0.47 ms # passerelle OT
2 * * * # pare-feu : silence
3 * * *
4 * * *Lecture : le premier saut (la passerelle .240) répond ; ensuite, des
* * * — le pare-feu IT/OT ne laisse pas passer, ou n'autorise pas ICMP/UDP sur ce trajet.
Ce n'est pas forcément une panne : c'est souvent une règle qui fait exactement son
travail. L'information utile est « ça meurt au saut 2, donc au pare-feu », pas sur le
câble ni sur le serveur cible.
Pour un diagnostic vivant et continu, mtr combine traceroute et
ping dans un tableau qui se met à jour : on repère d'un coup d'œil le saut où la
perte grimpe.
# Rapport mtr non-interactif, 10 cycles
mtr --report --report-cycles 10 192.168.100.10Si traceroute meurt au premier saut (même la passerelle ne répond pas), le problème est
local — route absente, mauvais masque, mauvais subnet. S'il meurt après la
passerelle, le problème est en amont — pare-feu ou routage IT. Ce simple « avant
ou après la passerelle ? » oriente la moitié du dépannage L3.
Récapitulatif
- Adresse :
ip -brief addrpour voir,sudo ip addr add 192.168.0.71/24 dev eth0pour se placer dans le plan machine,ip addr delpour retirer. Le masque/24définit qui est « local ». - Routage :
ip route; même subnet = direct (L2), autre subnet = via la passerelle/pare-feu (L3).ip route add … via …pour un autre segment. - ARP :
ip neightraduit IP → MAC. États REACHABLE (frais), STALE (à revalider), FAILED (personne).ip neigh flushforce une re-résolution après remplacement. - Joignabilité :
ping -c4d'abord, mais l'ICMP est souvent filtré en OT :arping -I eth0prouve la présence en L2 même sans réponse ICMP. - Doublon d'IP :
sudo arping -D -I eth0 <ip>— deux MAC pour une IP = doublon. Corréler avecip neighqui oscille,dmesg(« duplicate address »),arp-scan, et le « conflit IP » du CPU. - Vers l'IT :
traceroute/mtrmontrent où ça bloque — avant la passerelle (local) ou après (pare-feu).
Exercices
Exercice 1 — Se placer dans le plan et confirmer le CPU
Ton poste (edge ou WSL miroir) est branché sur le segment mais n'a pas encore d'adresse dans le plan
machine. Configure eth0 en 192.168.0.71/24, puis vérifie la joignabilité du
CPU 192.168.0.1 par ping et par arping.
Interprète le cas où le ping resterait muet.
Voir la solution
$ sudo ip addr add 192.168.0.71/24 dev eth0
$ ip -brief addr show eth0
eth0 UP 192.168.0.71/24 ...
$ ping -c3 192.168.0.1
64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=0.41 ms
... 0% packet loss
$ sudo arping -I eth0 -c3 192.168.0.1
Unicast reply from 192.168.0.1 [00:1B:1B:2A:10:01] 0.70ms
Received 3 response(s)Le ping répond : le CPU est joignable en L3 et son ICMP est ouvert. Si le ping avait été
muet (100% packet loss) mais le arping répondu, on ne
conclurait pas à une panne : le CPU serait présent sur le lien (MAC
00:1b:1b:2a:10:01 visible), simplement son ICMP serait filtré. Le verdict « présent »
vient de la réponse ARP, pas de l'ICMP.
Exercice 2 — Détecter un doublon d'IP
Le CPU signale un conflit sur la station 192.168.0.20 et les échanges Profinet claquent.
Lance la Duplicate Address Detection sur cette IP et explique ce que la sortie ci-dessous
révèle.
$ sudo arping -D -I eth0 -c3 192.168.0.20
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:20] 0.71ms
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:AA] 0.83ms
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:20] 0.69ms
Unicast reply from 192.168.0.20 [00:1B:1B:2A:10:AA] 0.80ms
Sent 3 probes (3 broadcast(s))
Received 4 response(s)Voir la solution
Deux adresses MAC différentes — 00:1B:1B:2A:10:20 et
00:1B:1B:2A:10:AA — répondent pour la même IP 192.168.0.20.
C'est la signature d'un doublon d'adresse IP : deux équipements physiques
distincts revendiquent la même adresse. L'indice quantitatif : Received 4 response(s)
pour seulement 3 probes — plus de réponses que de sondes, impossible avec un seul
répondeur.
Pour corréler et localiser : ip neigh show 192.168.0.20 montrera la MAC osciller,
sudo dmesg | grep -i duplicate confirmera côté noyau, et arp-scan listera les
deux MAC. La MAC intruse (…:10:AA, non conforme au plan) désigne l'équipement à
débrancher.
Exercice 3 — Lire la table des voisins
À partir de la sortie ip neigh ci-dessous, dis pour chaque voisin ce que son état
indique sur la santé du lien, et lequel doit t'inquiéter.
$ ip neigh
192.168.0.1 dev eth0 lladdr 00:1b:1b:2a:10:01 REACHABLE
192.168.0.21 dev eth0 lladdr 00:1b:1b:2a:10:21 STALE
192.168.0.42 dev eth0 FAILEDVoir la solution
- 192.168.0.1 — REACHABLE : le CPU a répondu récemment, entrée fraîche et fiable. Lien sain, rien à signaler.
- 192.168.0.21 — STALE : l'ET 200SP
.21est connue (MAC présente) mais le cache a refroidi faute de trafic récent. Ce n'est pas une panne : au prochain échange, le noyau revalidera l'entrée (DELAY → REACHABLE). Un simplepingouarpingla « réveille ». - 192.168.0.42 — FAILED, sans
lladdr: personne n'a répondu à l'ARP, aucune MAC n'est associée. Là, c'est un vrai signal d'absence : l'IP ne correspond à aucun équipement présent sur le lien (device éteint, débranché, ou IP fantôme). C'est celui-ci qui doit t'inquiéter.
Nuance à garder : STALE décrit un cache, pas un état de santé — il ne faut jamais le
confondre avec une panne. Seul FAILED (ou une entrée absente après arping)
atteste réellement d'une absence sur le segment.