Der Unterschied zwischen IP-Link-Down und fehlender physischer Verbindung

Es gibt einen Unterschied zwischen einer Schnittstelle, die administrativ aktiv ist aber getrennt oder administrativ down .

Getrennt

Die Schnittstelle erhält einen Trägerausfall Status. Die richtige Handhabung hängt möglicherweise vom Treiber für die Schnittstelle und der Kernel-Version ab. Normalerweise ist es mit ip link show verfügbar . Zum Beispiel mit einem virtuellen Ethernet veth Schnittstelle:

# 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

vetha das selbst administrativ UP ist, zeigt NO-CARRIER an und der entsprechende operstate LOWERLAYERDOWN flags:es ist getrennt.

Entspricht /sys/ Einträge existieren auch:

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

In üblichen Einstellungen für eine Schnittstelle, die administrativ in Betrieb ist der Spediteur und operieren übereinstimmen (NO-CARRIER <=> LOWERLAYERDOWN oder LOWER_UP <=> UP). Eine Ausnahme wäre zum Beispiel die Verwendung der IEEE 802.1X-Authentifizierung (erweiterte Angaben zu operstate sind in dieser Kernel-Dokumentation beschrieben:Operational States, werden aber für diese Erklärung nicht benötigt).

ethtool fragt eine API auf niedrigerer Ebene ab, um denselben Trägerstatus abzurufen.

Das Fehlen eines Trägers verhindert nicht, dass Layer-3-Einstellungen in Kraft bleiben. Der Kernel ändert in diesem Fall keine Adressen oder Routen. Nur wird am Ende ein Paket, das ausgesendet werden sollte, von der Schnittstelle nicht ausgesendet und es kommt natürlich auch keine Antwort. So wird beispielsweise der Versuch, sich mit einer anderen IPv4-Adresse zu verbinden, früher oder später erneut eine ARP-Anforderung auslösen, die fehlschlägt, und die Anwendung erhält ein "No route to host". Aufgebaute TCP-Verbindungen werden nur ihre Zeit abwarten und aufgebaut bleiben.

Administrativ ausgefallen

Über vethb hat Betrieb DOWN und zeigt keinen Trägerstatus an (da er aktiv sein muss, um dies zu erkennen. Eine physische Ethernet-Schnittstelle verhält sich natürlich genauso).

Wenn die Benutzeroberfläche heruntergefahren wird (ip link set ... down ), kann der Träger nicht mehr erkannt werden, da das zugrunde liegende Hardwaregerät sehr wahrscheinlich ausgeschaltet wurde und der Betriebszustand "down" wird. ethtool wird nur sagen, dass es auch keinen Link gibt, kann also nicht zuverlässig dafür verwendet werden (es werden sicherlich ein paar unbekannte angezeigt auch Einträge, aber gibt es dafür ein verlässliches Schema?).

Diesmal wirkt sich dies auf die Netzwerkeinstellungen der Schicht 3 aus. Der Kernel verweigert das Hinzufügen von Routen über diese Schnittstelle und entfernt alle vorherigen damit verbundenen Routen:

• die automatische (proto kernel ) LAN-Routen hinzugefügt, wenn eine Adresse hinzugefügt wird
• jede andere hinzugefügte Route (z. B. die Standardroute) in einer beliebigen Routing-Tabelle (nicht nur der main Routing-Tabelle) direkt abhängig von der Schnittstelle (scope link ) oder auf anderen zuvor gelöschten Routen (wahrscheinlich damals scope global). ) . Da diese nicht wieder erscheinen, wenn die Schnittstelle wieder hochgefahren wird (ip link set ... up ) gehen sie verloren, bis ein Userspace-Tool sie wieder hinzufügt.

Userspace-Interaktionen

Bei der Verwendung neuerer Tools wie NetworkManager kann man verwirrt werden und denken, dass eine Trennung einem Schnittstellenausfall ähnelt. Das liegt daran, dass NM Links überwacht und Maßnahmen ergreift, wenn solche Ereignisse eintreten. Um sich ein Bild zu machen, die ip monitor Das Tool kann zur Überwachung von Skripten verwendet werden, hat jedoch derzeit keine stabile/parsierbare Ausgabe (keine JSON-Ausgabe verfügbar), sodass seine Verwendung eingeschränkt ist.

Wenn also eine Leitung getrennt wird, wird NM sehr wahrscheinlich davon ausgehen, dass es die aktuelle Konfiguration nicht mehr verwendet, es sei denn, eine bestimmte Einstellung verhindert dies:Es löscht dann die Adressen und Routen selbst. Wenn das Kabel wieder angeschlossen wird, wendet NM seine Konfiguration erneut an:fügt Adressen und Routen zurück (unter Verwendung von DHCP, falls relevant). Das sieht genauso aus, ist es aber nicht. Während dieser ganzen Zeit blieb die Schnittstelle in Betrieb , oder es wäre nicht einmal möglich gewesen, NM zu warnen, wenn die Verbindung wieder da war.

Zusammenfassung

• Es ist einfach, die beiden Fälle zu unterscheiden:ip link show zeigt NO-CARRIER an +LOWERLAYERDOWN für eine getrennte Schnittstelle und DOWN für eine administrativ heruntergefahrene Schnittstelle.

• Wenn Sie eine Schnittstelle administrativ nach unten (und nach oben) setzen, können Routen verloren gehen

• Das Verlieren und Wiederherstellen des Netzbetreibers stört die Netzwerkeinstellungen nicht. Wenn die Verzögerung kurz genug ist, sollte sie nicht einmal laufende Netzwerkverbindungen unterbrechen

• aber Anwendungen, die das Netzwerk verwalten, reagieren möglicherweise und ändern die Netzwerkeinstellungen, manchmal mit einem ähnlichen Ergebnis wie bei einem administrativ ausgefallenen Fall

• Sie können Befehle wie ip monitor link verwenden um Ereignisse über administrativ eingestellte Schnittstellen oder Netzbetreiberänderungen zu erhalten, oder ip monitor um alle damit verbundenen Ereignisse (einschließlich Adress- oder Routenänderungen) zu erhalten, die zu diesem Zeitpunkt oder kurz danach stattfinden würden.

• Die meisten ip Befehle (aber nicht ip monitor ) verfügen über eine JSON-Ausgabe, die mit ip -json ... verfügbar ist um Skripte zu unterstützen (zusammen mit jq ).

  Beispiel (Fortsetzung vom ersten veth Beispiel):

  vethb ist immer noch down:

  # ip -j link show dev vethb | jq '.[].operstate'
  "DOWN"
  
  # ip -j link show dev vetha | jq '.[].operstate'
  "LOWERLAYERDOWN"
  

  Setzen Sie vethb up, die nun auf beiden einen Träger bekommt:

  # ip link set vethb up
  # ip -j link show dev vetha | jq '.[].operstate'
  "UP"
  

  Dies sagt über die 3 üblichen Zustände aus:administrativ down , untere Schicht nach unten (dh:aktiv, aber getrennt) oder aktiv (dh:betriebsbereit).