La différence entre le lien ip down et l'absence de lien physique

Il y a une différence entre une interface qui est administrativement up mais déconnecté ou administrativement en panne .

Déconnecté

L'interface obtient un porteur vers le bas statut. Sa bonne gestion peut dépendre du pilote de l'interface et de la version du noyau. Normalement, il est disponible avec ip link show . Par exemple avec un ethernet virtuel veth interface :

# ip link add name vetha up type veth peer name vethb
# ip link show type veth
2: [email protected]: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 02:a0:3b:9a:ad:4d brd ff:ff:ff:ff:ff:ff
3: [email protected]: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether 36:e3:62:1b:a8:1f brd ff:ff:ff:ff:ff:ff

vétha qui est lui-même administrativement UP, affiche NO-CARRIER et l'équivalent operstate LOWERLAYERDOWN flags :il est déconnecté.

Équivalent /sys/ des entrées existent aussi :

# cat /sys/class/net/vetha/carrier /sys/class/net/vetha/operstate
0
lowerlayerdown

Dans les paramètres habituels, pour une interface administrativement up le transporteur et état d'exploitation match (NO-CARRIER <=> LOWERLAYERDOWN ou LOWER_UP <=> UP). Une exception serait par exemple lors de l'utilisation de l'authentification IEEE 802.1X (détails avancés de operstate sont décrits dans cette documentation du noyau :États opérationnels, mais ce n'est pas nécessaire pour cette explication).

ethtool interroge une API de niveau inférieur pour récupérer ce même statut de transporteur.

L'absence d'opérateur n'empêche pas les paramètres de la couche 3 de rester en vigueur. Le noyau ne change pas les adresses ou les routes lorsque cela se produit. C'est juste qu'au final un paquet qui devrait être émis ne le sera pas par l'interface et bien sûr aucune réponse ne viendra non plus. Ainsi par exemple essayer de se connecter à une autre adresse IPv4 déclenchera tôt ou tard à nouveau une requête ARP qui échouera, et l'application recevra un "No route to host". Les connexions TCP établies ne feront qu'offrir leur temps et resteront établies.

Défaillance administrative

Au-dessus de vethb a état d'exploitation DOWN et n'affiche aucun statut de porteuse (puisqu'il doit être actif pour le détecter. Une interface Ethernet physique se comporte bien sûr de la même manière).

Lorsque l'interface est arrêtée (ip link set ... down ), la porteuse ne peut plus être détectée car le périphérique matériel sous-jacent a très probablement été mis hors tension et l'état de fonctionnement devient "hors service". ethtool dira simplement qu'il n'y a pas de lien aussi, donc ne peut pas être utilisé de manière fiable pour cela (il affichera sûrement quelques inconnus également, mais existe-t-il un schéma fiable pour cela ?).

Cette fois, cela aura un effet sur les paramètres réseau de la couche 3. Le noyau refusera d'ajouter des routes à l'aide de cette interface et supprimera toutes les routes précédentes qui lui sont liées :

l'automatique (proto kernel ) Routes LAN ajoutées lors de l'ajout d'une adresse
toute autre route ajoutée (par exemple :la route par défaut) dans n'importe quelle table de routage (pas seulement la principale table de routage) dépendant directement de l'interface (scope link ) ou sur d'autres itinéraires précédemment supprimés (probablement alors scope global ). Comme ceux-ci ne réapparaîtront pas lorsque l'interface sera réactivée (ip link set ... up ) ils sont perdus jusqu'à ce qu'un outil de l'espace utilisateur les rajoute.

Interactions avec l'espace utilisateur

Lors de l'utilisation d'outils récents comme NetworkManager, on peut être confus et penser qu'une déconnexion est similaire à une interface en panne. C'est parce que NM surveille les liens et effectuera des actions lorsque de tels événements se produisent. Pour se faire une idée le ip monitor L'outil peut être utilisé pour surveiller à partir de scripts, mais il n'a pas de sortie stable/analysable actuellement (pas de sortie JSON disponible), donc son utilisation est limitée.

Ainsi, lorsqu'un câble est déconnecté, NM considérera très probablement qu'il n'utilise plus la configuration actuelle à moins qu'un paramètre spécifique ne l'en empêche :il supprimera alors lui-même les adresses et les routes. Lorsque le câble est reconnecté, NM appliquera à nouveau sa configuration :ajoute des adresses et des routes (en utilisant DHCP le cas échéant). Cela ressemble à la même chose mais ce n'est pas le cas. Pendant tout ce temps, l'interface est restée active , ou il n'aurait même pas été possible pour NM d'être averti lorsque la connexion était rétablie.

Résumé

Il est facile de distinguer les deux cas :ip link show affichera NO-CARRIER +LOWERLAYERDOWN pour une interface déconnectée, et DOWN pour une interface supprimée administrativement.
la configuration administrative d'une interface vers le bas (et vers le haut) peut perdre des routes
la perte de l'opérateur et sa récupération ne perturbent pas les paramètres réseau. Si le délai est suffisamment court, il ne devrait même pas perturber les connexions réseau en cours
mais les applications gérant le réseau peuvent réagir et modifier les paramètres du réseau, parfois avec un résultat similaire à un arrêt administratif
vous pouvez utiliser des commandes comme ip monitor link pour recevoir des événements sur les interfaces définies administrativement vers le bas/vers le haut ou les changements d'opérateur, ou ip monitor pour recevoir tous les multiples événements connexes (y compris les changements d'adresse ou d'itinéraire) qui se produiraient à ce moment ou peu de temps après.
La plupart ip commandes (mais pas ip monitor ) ont une sortie JSON disponible avec ip -json ... pour aider les scripts (avec jq ).

Exemple (continuant du premier veth exemple):

vethb est toujours en panne :
```
# ip -j link show dev vethb | jq '.[].operstate'
"DOWN"

# ip -j link show dev vetha | jq '.[].operstate'
"LOWERLAYERDOWN"
```
Définir vethb up, qui obtient désormais une porteuse sur les deux :
```
# ip link set vethb up
# ip -j link show dev vetha | jq '.[].operstate'
"UP"
```
Cela indique les 3 états habituels :administrativement down , couche inférieure (c'est-à-dire :activé mais déconnecté) ou up (c'est-à-dire :opérationnel).