IPリンクダウンと物理リンク不在の違い

管理上稼働しているインターフェースには違いがありますしかし、切断されているか、管理上ダウンしています .

切断

インターフェースが キャリアをダウン する状態。その適切な処理は、インターフェースのドライバーとカーネルのバージョンによって異なる場合があります。通常は ip link show で利用できます .たとえば、仮想イーサネット veth の場合インターフェース:

# 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 それ自体が管理上 UP であり、NO-CARRIER を表示しますおよび同等の operstate LOWERLAYERDOWN フラグ:切断されています。

同等の /sys/ エントリも存在します:

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

通常の設定では、管理上 up になっているインターフェイスの場合 キャリア および operstate 一致 (NO-CARRIER <=> LOWERLAYERDOWN または LOWER_UP <=> UP)。 1 つの例外は、たとえば、IEEE 802.1X 認証を使用する場合です (operstate の詳細カーネルのドキュメント:Operational States で説明されていますが、この説明には必要ありません)。

ethtool 低レベルの API を照会して、この同じキャリアステータスを取得します。

キャリアがなくても、レイヤ 3 設定が有効なままになることはありません。これが発生しても、カーネルはアドレスやルートを変更しません。最終的には、発行されるべきパケットがインターフェイスによって発行されず、もちろん応答も返されないというだけです。たとえば、別の IPv4 アドレスに接続しようとすると、遅かれ早かれ ARP 要求が再度トリガーされますが、これは失敗し、アプリケーションは「ホストへのルートがありません」というメッセージを受け取ります。確立された TCP 接続は、時間をかけ、確立されたままになります。

管理上のダウン

vethb の上 operstate がありますダウンしており、キャリアのステータスは表示されません (これを検出するには、アップしている必要があるためです。もちろん、物理イーサネットインターフェイスも同じように動作します)。

インターフェイスがダウンしたとき (ip link set ... down )、基になるハードウェアデバイスの電源がオフになっている可能性が非常に高く、operstate が "down" になるため、キャリアを検出できなくなります。 ethtool リンクもないと言うだけなので、これには確実に使用できません（確かにいくつかの不明が表示されますエントリもありますが、これに対する信頼できるスキームはありますか?)。

今回は、レイヤ 3 ネットワーク設定に影響します。カーネルは、このインターフェイスを使用してルートを追加することを拒否し、それに関連する以前のルートをすべて削除します:

自動 (proto kernel ) アドレスの追加時に追加される LAN ルート
任意のルーティングテーブル (メイン だけでなく) に追加されたその他のルート (例:デフォルトルート) インターフェース (scope link に直接依存) ) または他の以前に削除されたルート (おそらく scope global ）。これらは、インターフェイスが再起動されたときに再表示されないため (ip link set ... up ) ユーザー空間ツールが追加するまで失われます。

ユーザー空間でのやり取り

NetworkManager などの最近のツールを使用すると、混乱して切断がインターフェイスのダウンに似ていると考えることがあります。これは、NM がリンクを監視し、そのようなイベントが発生したときにアクションを実行するためです。 ip monitor のアイデアを得るにはツールを使用してスクリプトから監視できますが、現在、安定した/解析可能な出力がない (JSON 出力が利用できない) ため、使用が制限されます。

そのため、ワイヤが切断されると、NM は、特定の設定でそれが妨げられない限り、現在の構成を使用していないと見なす可能性が非常に高く、アドレスとルート自体を削除します。ワイヤが再接続されると、NM はその構成を再度適用します。つまり、アドレスとルートを追加し直します (関連する場合は DHCP を使用)。これは同じように見えますが、違います。この間ずっと、インターフェースは稼働したままでした、または接続が戻ったときに NM に警告することさえできなかったでしょう。

まとめ

2 つのケースを区別するのは簡単です:ip link show NO-CARRIER が表示されます +LOWERLAYERDOWN 切断されたインターフェースの場合、および DOWN 管理上停止されたインターフェイスの場合。
インターフェイスを管理的にダウン (およびアップ) に設定すると、ルートが失われる可能性があります
キャリアを失って回復しても、ネットワーク設定は中断されません。遅延が十分に短い場合、進行中のネットワーク接続が中断されることさえありません
ただし、ネットワークを管理するアプリケーションが反応してネットワーク設定を変更する可能性があり、場合によっては管理上のダウンケースと同様の結果になります
ip monitor link のようなコマンドを使用できます管理上のダウン/アップまたはキャリアの変更に設定されたインターフェイスに関するイベント、または ip monitor を受け取る現時点またはその直後に発生する複数の関連イベント (住所または経路の変更を含む) をすべて受信します。
ほとんど ip コマンド (ただし、ip monitor は除く) ) ip -json ... で利用可能な JSON 出力がありますスクリプトを支援する (jq とともに) ).

例 (最初の veth からの続き) 例):

vethb まだダウンしています:
```
# ip -j link show dev vethb | jq '.[].operstate'
"DOWN"

# ip -j link show dev vetha | jq '.[].operstate'
"LOWERLAYERDOWN"
```
vethb を設定アップし、両方でキャリアを取得します:
```
# ip link set vethb up
# ip -j link show dev vetha | jq '.[].operstate'
"UP"
```
これは、3 つの通常の状態について説明します:管理上停止、lowerlayerdown (つまり:稼働しているが切断されている) または稼働 (つまり:操作可能)。