Chapitre 02
Couche physique & liaison (L1/L2)

Objectifs du chapitre

Lister et nommer les interfaces réseau d'un poste, et lire leur état de lien (UP, LOWER_UP, porteuse) depuis le shell.
Diagnostiquer une faute de couche 1 avec ethtool : débit, duplex, auto-négociation — et reconnaître le fameux port Profinet tombé en 10 Mbit/s half-duplex.
Lire les compteurs d'erreurs matériels (FCS/CRC, frame, dropped) et distinguer une erreur ponctuelle d'une dérive qui grimpe — signe de bruit EMI ou de câble abîmé.
Repérer physiquement le bon port dans l'armoire (LED clignotante), comprendre VLAN 802.1Q, MTU, et traquer un lien qui « flappe ».

1. Lister et nommer les interfaces

Avant de diagnostiquer un lien, il faut savoir lequel. Sur Linux moderne, on n'utilise plus ifconfig mais ip, de la suite iproute2. Pour un inventaire lisible d'un coup d'œil :

$ ip -brief link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             b8:27:eb:4a:1c:70 <BROADCAST,MULTICAST,UP,LOWER_UP>
enp3s0           DOWN           00:1b:21:8f:33:a2 <BROADCAST,MULTICAST>

La sortie complète, plus verbeuse, se lit avec ip link :

$ ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:4a:1c:70 brd ff:ff:ff:ff:ff:ff

Trois champs comptent ici. Le mot-clé UP dit que l'administrateur a activé le port (côté logiciel). LOWER_UP dit que la porteuse est présente : un câble est branché et le lien physique est établi. Enfin state UP résume l'état effectif. Un port branché mais mal câblé donnera UP sans LOWER_UP, et state DOWN.

Un mot sur les noms. Le noyau nommait historiquement les cartes eth0, eth1… dans l'ordre de détection — instable d'un boot à l'autre. Les distributions récentes utilisent des noms prévisibles dérivés de la position physique : enp3s0 = bus PCI 3, slot 0. Sur l'edge Debian tu croiseras souvent ces noms ; sur WSL2, l'interface reste eth0. Le cours écrit eth0 par convention, remplace-le par le vrai nom (ip -brief link) sur ton matériel.

Activer un port éteint côté logiciel :

# Activer / désactiver l'interface (côté administratif)
sudo ip link set eth0 up
sudo ip link set eth0 down

ip -brief link et ip -brief addr sont tes deux réflexes d'entrée : un tableau serré, une interface par ligne. Ajoute -c (ip -c -br link) pour la couleur : les interfaces UP ressortent en vert, tu vois l'état du parc en une seconde.

2. L'état du lien : débit, duplex, auto-négociation

ip link dit si le lien est là, mais pas à quelle vitesse ni en quel mode. Pour cela, l'outil de référence est ethtool, qui interroge directement le PHY (la puce d'interface physique) de la carte :

$ sudo ethtool eth0
Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHY address: 1
	Auto-negotiation: on
	Link detected: yes

Trois lignes à lire en priorité. Link detected: yes confirme la porteuse (équivalent de LOWER_UP). Speed et Duplex donnent le régime négocié. En Profinet, un port device est presque toujours 100 Mbit/s Full duplex : c'est le régime nominal d'un ET 200SP, d'un CPU S7-1500 ou d'un port Scalance. Le duplex intégral supprime les collisions ; c'est ce que le temps réel exige.

Un port tombé en 10 Mbit/s ou surtout en Half duplex est une panne silencieuse : le lien « marche », le ping passe, mais l'auto-négociation a mal tourné — souvent un câble médiocre, une paire coupée, un connecteur oxydé, ou un côté fixé en manuel face à un côté en auto. En half-duplex, l'émission et la réception ne peuvent pas coexister : collisions, retransmissions, jitter. Le Profinet RT le déteste — tu verras des IO-devices « clignoter » (Station failure intermittent) sans jamais comprendre pourquoi si tu ne regardes pas Speed/Duplex.

Quand un lien est douteux, compare le régime négocié (Speed, Duplex) à ce que les deux côtés annoncent (Advertised link modes). Si un côté n'annonce plus le Gigabit alors qu'il le supporte, c'est le symptôme classique d'une paire de cuivre défaillante : la négociation retombe sur le plus petit dénominateur commun.

Sur le CPU S7-1500, chaque port a un voyant Link/Activity vert. Dans TIA Portal, la vue « Diagnostic en ligne » d'un port physique affiche exactement Vitesse de transmission et Mode (Full/Half), et lève un défaut de diagnostic si le lien tombe sous le régime attendu. ethtool est la même information, mais lue côté poste de diagnostic, sans ouvrir le projet d'ingénierie ni être en ligne sur l'automate.

3. Les compteurs d'erreurs matériels

Un lien « 100 Full, Link yes » peut quand même être malade : il transporte des trames, mais une partie arrive corrompue et se fait jeter. Ces rejets sont comptés par le matériel. Vue synthétique avec ip -s link :

$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:4a:1c:70 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    481203344  912774   2183       0       0   118402
    TX:  bytes packets errors dropped carrier collsns
    390115820  874009      0       0       0       0

Ici RX errors 2183 : plus de deux mille trames reçues, jetées à l'entrée. Pour savoir pourquoi, on descend au détail par-compteur du pilote avec ethtool -S :

$ sudo ethtool -S eth0 | grep -iE 'err|crc|drop|coll|frame'
     rx_errors: 2183
     rx_crc_errors: 2181
     rx_frame_errors: 2
     rx_dropped: 0
     tx_errors: 0
     tx_dropped: 0
     collisions: 0

Le verdict est net : presque toutes les erreurs sont des CRC (contrôle FCS raté). La trame est arrivée abîmée sur le fil — le contenu ne correspond plus à sa somme de contrôle. C'est un problème de couche physique, pas de configuration : câble pincé ou trop long, blindage coupé, connecteur RJ45 mal serti, ou bruit électromagnétique — un variateur de fréquence qui commute juste à côté du câble dans l'armoire est un coupable classique.

Repères d'interprétation des compteurs RX :

rx_crc_errors — trame corrompue (FCS invalide) : câble, blindage, EMI. Le plus parlant en armoire.
rx_frame_errors — trame de longueur non entière en octets (alignement) : souvent la même cause physique.
rx_dropped — trame correcte mais jetée faute de ressources (buffers, filtrage) : plutôt un souci système/charge que câble.
collisions / tx_errors — non nuls sur un lien Full duplex moderne = anomalie de négociation (retour au §2).

La vraie question : est-ce que ça grimpe ?

Un compteur à 2183 depuis le dernier boot il y a trois mois n'est pas alarmant : peut-être un débranchement à chaud ancien. Ce qui compte, c'est de savoir s'il augmente maintenant. On fait deux relevés espacés et on regarde le delta :

Relever un compteur, attendre, relever à nouveau, et lire la différence :

$ ethtool -S eth0 | awk '/rx_crc_errors/{print $2}'; sleep 10; \
  ethtool -S eth0 | awk '/rx_crc_errors/{print $2}'
2181
2199          # +18 CRC en 10 s → dérive active, câble à suspecter

Pour surveiller en direct pendant qu'on manipule un câble, la boucle watch rafraîchit chaque seconde et fait clignoter les chiffres qui bougent :

$ watch -n1 -d "ethtool -S eth0 | grep -i err"

Bouge le câble, tape sur le chemin de câbles, éloigne du variateur : si les CRC s'emballent au geste, tu tiens le coupable physique.

Un compteur figé pendant que la ligne fonctionne = lien sain. Un compteur qui monte régulièrement même à faible cadence = dégradation en cours, à corriger avant qu'elle ne provoque des pertes de cycle Profinet.

ethtool ne voit que ta propre carte et le seul segment qui la relie à son port de switch. Il ne dit rien des autres liens du réseau. Si un ET 200SP distant décroche à cause de son câble (segment « switch ↔ device » auquel ton poste n'appartient pas), tu ne verras rien monter dans ethtool -S eth0 — c'est normal. Les erreurs de ce segment sont comptées par le port du switch managé en face du device : on les lit en SNMP (ifInErrors, cf. chapitre 10), avec le même raisonnement de delta. Règle simple : un port n'observe que le lien auquel il touche.

4. Identifier la carte… et le port physique

Quel pilote, quelle puce ? ethtool -i le dit — utile pour chercher un bug de driver ou vérifier une version de firmware :

$ sudo ethtool -i eth0
driver: igb
version: 5.15.0
firmware-version: 3.25, 0x800005d0
bus-info: 0000:03:00.0
supports-statistics: yes

Mais le problème le plus fréquent en armoire est trivial et pénible : quel port RJ45 de l'edge, parmi quatre identiques, est branché sur le CPU ? ethtool -p fait clignoter la LED du port ciblé pendant N secondes :

# Faire clignoter la LED du port eth0 pendant 15 s pour le repérer
sudo ethtool -p eth0 15

Devant l'armoire, lance sudo ethtool -p eth0 30 et regarde quelle LED clignote anormalement : c'est physiquement ce port-là. Bien plus fiable que de suivre un câble à la main dans un chemin de câbles bondé. Tous les pilotes ne supportent pas -p ; s'il ne se passe rien, retombe sur la méthode « débranchement » de l'exercice 3.

5. VLAN 802.1Q et MTU

Le Profinet RT circule fréquemment dans un VLAN tagué 802.1Q, avec la priorité 6 (classe temps réel) inscrite dans le champ PCP de la balise — c'est ainsi que les switches Scalance donnent la priorité au trafic cyclique face au reste. Pour voir les détails de couche 2 d'une interface, dont son éventuelle appartenance VLAN, on ajoute -d :

$ ip -d link show eth0.100
7: eth0.100@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:4a:1c:70 brd ff:ff:ff:ff:ff:ff
    vlan protocol 802.1Q id 100 <REORDER_HDR> ...

Pour observer ou injecter du trafic dans un VLAN précis depuis le poste de diagnostic, on crée une sous-interface tagée :

# Créer une sous-interface sur le VLAN 100, puis l'activer
sudo ip link add link eth0 name eth0.100 type vlan id 100
sudo ip link set eth0.100 up

# La retirer une fois le diagnostic terminé
sudo ip link delete eth0.100

Dernier point de couche 2 : la MTU, visible dans chaque sortie ip link (mtu 1500). Le Profinet cyclique tient dans de petites trames, mais les échanges acycliques (paramétrage d'un device, lecture d'enregistrements, mise à jour) peuvent produire de gros paquets. Un MTU incohérent entre deux équipements (l'un à 1500, l'autre bridé plus bas) laisse passer les petites trames et casse silencieusement les grosses : le lien « marche » mais certaines opérations acycliques échouent ou traînent. Vérifie que la MTU est homogène de bout en bout.

Figure 2.1. Où chaque commande regarde. Le câble (couche 1) entre dans le PHY, qui négocie débit et duplex et alimente les compteurs matériels. ip link donne l'état administratif et la porteuse ; ethtool lit le régime du PHY ; ethtool -S expose les erreurs comptées par le matériel — trois angles sur le même port.

6. Un lien qui « flappe »

Le pire défaut de couche 1 n'est pas le lien mort, c'est le lien intermittent : un connecteur à moitié enclenché, une soudure fatiguée, un câble sectionné par des vibrations. Le lien monte, tombe, remonte — et à chaque cycle le Profinet perd sa connexion IO. Le noyau journalise chaque transition ; on la suit en direct avec dmesg -w (mode follow) :

$ sudo dmesg -wT | grep -i eth0
[mar. 03 juil. 2026 14:22:07] igb 0000:03:00.0 eth0: Link is Down
[mar. 03 juil. 2026 14:22:09] igb 0000:03:00.0 eth0: Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
[mar. 03 juil. 2026 14:22:41] igb 0000:03:00.0 eth0: Link is Down
[mar. 03 juil. 2026 14:22:43] igb 0000:03:00.0 eth0: Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX

Deux coupures en vingt secondes, à intervalle irrégulier : signature typique d'un contact mécanique intermittent. L'option -T horodate chaque ligne, ce qui permet de corréler les coupures avec un événement (une machine qui démarre, une porte d'armoire qu'on ferme, une vibration). Croise toujours dmesg avec le §3 : un flap s'accompagne souvent d'une bouffée de rx_crc_errors juste avant que le lien lâche.

Manipuler un câble ou débrancher un port en production coupe le device Profinet correspondant — et selon le programme, peut figer une partie de process. Sur une installation vivante, on lit d'abord passivement (dmesg, compteurs, ethtool sans rien changer) et on ne débranche qu'après avoir prévenu et sécurisé. Les exercices ci-dessous se font sur banc de test.

Récapitulatif

Inventaire & état : ip -brief link pour la liste ; UP = activé côté admin, LOWER_UP = porteuse présente. Activer : sudo ip link set eth0 up.
Régime du lien : ethtool eth0 → Speed, Duplex, Link detected. En Profinet on attend 100 Mb/s Full ; un 10 Mb ou Half = négo/câble défectueux → jitter et retransmissions.
Erreurs matérielles : ip -s link (vue) et ethtool -S (détail). rx_crc_errors qui monte = physique/EMI/câble. Ce qui compte est le delta entre deux relevés, pas la valeur absolue.
Repérage : ethtool -i (pilote), ethtool -p eth0 15 (LED clignotante pour trouver le bon port dans l'armoire).
Couche 2 : ip -d link montre le VLAN 802.1Q (Profinet RT = priorité 6) ; ip link add … type vlan crée une sous-interface tagée ; une MTU incohérente casse silencieusement les gros paquets acycliques.
Flapping : sudo dmesg -wT | grep eth0 révèle les Link Up/Down répétés d'un contact intermittent.

Exercices

Exercice 1 — Ce port est-il sain ?

Sur ton edge Debian, l'interface câblée sur le switch OT s'appelle eth0. Affiche son débit, son duplex et l'état du lien, puis juge si le port est dans le régime attendu pour du Profinet. Qu'est-ce qui te ferait dire « non » ?

Voir la solution

$ sudo ethtool eth0 | grep -E 'Speed|Duplex|Link detected'
	Speed: 100Mb/s
	Duplex: Full
	Link detected: yes

100 Mb/s, Full, Link yes : c'est exactement le régime nominal d'un port Profinet — port sain. Ce qui devrait t'alerter : Speed: 10Mb/s (négociation retombée au plancher, câble suspect), Duplex: Half (collisions garanties, jitter), ou Link detected: no (pas de porteuse — câble débranché ou coupé). Un Speed: 1000Mb/s n'est pas une faute en soi, mais s'il apparaît là où l'ingénierie attend du 100 Full, vérifie que le device et le switch sont d'accord.

Exercice 2 — Erreur ponctuelle ou dérive ?

Le lien entre ton edge et son port de switch est instable : la connexion se dégrade par moments et tu suspectes ton câble. Relève les erreurs CRC de ton interface, attends, relève à nouveau, et conclus : s'agit-il d'un vieil incident figé ou d'une dégradation active ? Donne la commande et le raisonnement. Enfin : si c'était le câble d'un ET 200SP distant qu'on suspectait, pourquoi ethtool ne suffirait-il pas, et quel outil faudrait-il ?

Voir la solution

$ ethtool -S eth0 | grep rx_crc_errors; sleep 30; \
  ethtool -S eth0 | grep rx_crc_errors
     rx_crc_errors: 40571
     rx_crc_errors: 40794     # +223 en 30 s

La valeur absolue (40 571) ne dit rien seule : elle a pu s'accumuler sur des mois. Le delta, lui, est parlant : +223 CRC en 30 secondes, soit une dérive franche et continue sur ton lien → couche physique en cause (câble, blindage, ou EMI d'un variateur voisin). Si le second relevé avait donné exactement 40 571 (delta nul), on aurait conclu à un incident ancien et figé, sans rapport avec l'instabilité actuelle. Pour confirmer visuellement pendant qu'on bouge le câble :

$ watch -n1 -d 'ethtool -S eth0 | grep -i crc'

Et pour un ET 200SP distant ? ethtool ne lit que les compteurs de ta carte, donc uniquement le segment « ton port ↔ ton port de switch ». Le câble « switch ↔ ET 200SP » est un autre segment, auquel tu n'appartiens pas : ses CRC sont comptés par le port du switch managé qui fait face au device. On les lit alors en SNMP sur le switch (ifInErrors, ifOperStatus — cf. chapitre 10), avec exactement le même raisonnement de delta : commande différente, logique identique.

Exercice 3 — Quel port va au CPU ?

L'edge a quatre ports RJ45 identiques ; tu ne sais pas lequel monte vers le CPU S7-1500 (192.168.0.1). Trouve-le de deux façons : d'abord sans rien débrancher, puis par une méthode de repli si la première échoue.

Voir la solution

Méthode 1 — LED clignotante (non-intrusive). Fais clignoter chaque port et regarde l'armoire :

sudo ethtool -p eth0 20   # puis eth1, eth2… en observant les LED

Le port dont la LED clignote anormalement pendant 20 s est physiquement celui que tu interroges. En suivant son câble jusqu'au switch/CPU, tu identifies le bon lien sans jamais couper le trafic.

Méthode 2 — corrélation par débranchement (si -p n'est pas supporté). Sur banc de test uniquement : lance un suivi du lien, puis débranche/rebranche le câble suspect :

$ sudo dmesg -wT | grep -iE 'eth[0-9]'
[... 14:31:02] igb ... eth2: Link is Down
[... 14:31:05] igb ... eth2: Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX

C'est l'interface dont le lien tombe au débranchement (eth2 ici) qui porte le câble du CPU. Vérifie en aval que ce segment porte bien 192.168.0.1. Cette méthode coupe le Profinet le temps de la manipulation : à réserver au banc, jamais en production sans accord.

Chapitre 02Couche physique & liaison (L1/L2)

Objectifs du chapitre

1. Lister et nommer les interfaces

2. L'état du lien : débit, duplex, auto-négociation

3. Les compteurs d'erreurs matériels

La vraie question : est-ce que ça grimpe ?

4. Identifier la carte… et le port physique

5. VLAN 802.1Q et MTU

6. Un lien qui « flappe »

Récapitulatif

Exercices

Exercice 1 — Ce port est-il sain ?

Exercice 2 — Erreur ponctuelle ou dérive ?

Exercice 3 — Quel port va au CPU ?

Chapitre 02
Couche physique & liaison (L1/L2)