ネットワークポート updown 繰り返し の原因特定と対処法｜物理的な抜き差しを検知するための確認コマンド完全解説

この記事で分かること

ネットワークポートのupdownが繰り返される障害は、原因が物理層なのかドライバーなのか、あるいはONUや対向機器の問題なのかを素早く切り分けることが重要です。この記事では、Linuxのethtool・ip link show・journalctlなどのコマンドを使ってリンクダウンのイベントを検知・記録・分析する手順を具体的に解説します。ケーブルの接触不良、ドライバー問題、ONUの不具合、対向スイッチのポート設定まで、原因別の見分け方と対処法をまとめています。

updownが繰り返されるとはどういう状態か

ネットワークインターフェースの「updown繰り返し」とは、ポートのリンク状態がUP（接続中）とDOWN（切断）を短時間で交互に繰り返す現象です。スイッチの用語ではフラッピング（flapping）とも呼ばれます。

この状態が発生すると、以下のような症状が起きます。

• 通信が定期的に数秒〜数十秒途切れる
• pingで断続的にパケットロスが発生する
• DHCPアドレスの再取得が繰り返される
• syslogやjournalにリンクダウン／アップのログが大量に記録される

見た目の症状だけでは「回線が不安定」としか判断できないことが多く、物理的な切断なのか、ソフトウェア的な問題なのかを区別する確認手順が必要です。

まず確認すべき：ログでイベントの頻度と時刻を把握する

最初にすべきことは、インターフェース状態の変化がいつ・どのくらいの頻度で起きているかをログから把握することです。原因を推測する前にデータを取ります。

journalctlでリンクイベントを確認する（Linux）

Linuxシステムではjournalctlでカーネルログからリンク状態の変化を抽出できます。

journalctl -k | grep -E "(link (is|became)|Link (Up|Down)|NIC Link is)" | tail -50

どこを見るか：同じインターフェース名（例：eth0、ens3）でUP/DOWNが交互に記録されている場合、フラッピングが確定します。タイムスタンプの間隔が数秒〜1分以内であれば物理層の問題（接触不良・ケーブル断線）を強く疑います。数分〜数十分間隔であればドライバーやONUの不具合も候補に入ります。

/var/log/syslog または messages を確認する

grep -E "(eth0|ens3|link|carrier)" /var/log/syslog | tail -100

インターフェース名は環境に合わせて変更してください。carrierキーワードが含まれるログはリンクの物理的な変化を示すため重要です。

ip link show でインターフェース状態をリアルタイム確認する

ネットワークポート updown 繰り返しの調査において、ip link showはリンク状態の現在値と変化カウンターを確認するための基本コマンドです。

基本的なリンク状態確認

ip link show eth0

出力例：

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff

どこを見るか：state UPがリンクアップ、state DOWNがリンクダウン。LOWER_UPフラグがあれば物理層でキャリアを検出しています。NO-CARRIERフラグが見えればケーブルが物理的に認識されていません。

変化を監視する（watchコマンドと組み合わせ）

watch -n 1 "ip link show eth0"

1秒ごとに状態を更新表示します。状態が画面上でUP/DOWNと変化していれば、フラッピングが現在進行中であることを目視で確認できます。

ethtool コマンドで物理層の詳細を確認する

ethtool コマンドはネットワークインターフェース 物理層 障害の診断において最も情報量が多いコマンドです。リンク速度、デュプレックス、オートネゴシエーションの状態、そしてリンク変化の回数まで取得できます。

基本的なインターフェース情報確認

ethtool eth0

出力の中で特に注目すべき行：

統計情報でリンク変化回数を確認する

ethtool -S eth0 | grep -i "link\|carrier\|down\|reset"

どこを見るか：link_down_eventsやcarrier_changesのカウンター値が短時間で増加していれば、その間にリンクダウンが発生し続けています。再起動後からのカウントなので、現在の値と数分後の値を比較して増加スピードを確認します。

ドライバーとファームウェアのバージョン確認

ethtool -i eth0

どこを見るか：driver・version・firmware-versionを確認します。古いドライバーバージョンがリンクフラッピングの既知バグを持つケースがあります。Intelのigb・e1000eドライバーなどは過去にリンク安定性に関するバグ修正リリースが複数出ています。

原因別の見分け方と確認フロー

ネットワークポートのupdownが繰り返される場合、原因は大きく4つのカテゴリに分かれます。以下の表と手順で絞り込んでください。

ケーブル接触不良・ケーブル断線の確認手順

ネットワークケーブル 接触不良 検知の最も確実な方法は、別の正常なケーブルに交換して症状が消えるかどうか確認することです。その前に以下を試みます。

# ケーブルをコネクタごと抜き差しし、クリック音を確認
# その後、リンク変化のカウンターが増えているか確認
ethtool -S eth0 | grep carrier_changes

コネクタのツメが折れているケースや、ケーブルを特定の角度に曲げるとリンクが落ちる内部断線は、別ケーブルへの差し替えで即座に症状が消えます。物理的な切断の疑いが高い場合はケーブル交換が最優先です。

dmesgでドライバーエラーを確認する

dmesg | grep -E "(eth0|ens3|reset|error|watchdog|hang|timeout)" | tail -30

どこを見るか：TX timeout・reset adapter・Detected Tx Unit Hangなどのメッセージはドライバーレベルのリセットを示します。この場合はケーブル交換では解消せず、ドライバーのアップデートやNICの交換が必要になります。

ONUの不具合を疑う場合の確認

ONUの不具合が原因の場合、サーバーやPCとスイッチ間のリンクは安定しているのに、ONUとルーター間またはONUとスイッチ間のポートだけがリンクダウンするパターンになります。

# ONU直下のインターフェース確認
ip link show wan0
ethtool wan0

ONUが原因の場合、ONU本体の再起動で一時的に回復することがありますが、再発する場合はISP（インターネットサービスプロバイダー）への問い合わせと機器交換が必要です。

ifconfig や ip コマンドでインターフェースを手動でdown/upして確認する

ifconfig down up 原因特定の手法として、インターフェースを意図的に再起動して正常状態に戻るか確認する方法があります。ただし、これはあくまで一時的な確認手段であり、根本原因の解消にはなりません。

ip コマンドでインターフェースを再起動する

ip link set eth0 down
sleep 2
ip link set eth0 up
ip link show eth0

再起動後にstate UPかつLOWER_UPが出ていれば物理リンクは回復しています。それでも数秒後にDOWNに戻る場合は物理層（ケーブル・コネクタ・対向ポート）に問題があります。

オートネゴシエーションを手動設定で確認する

対向スイッチとのネゴシエーション失敗が原因の場合、速度とデュプレックスを固定することで症状が消えることがあります。

# 100Mbps全二重に固定する例
ethtool -s eth0 speed 100 duplex full autoneg off

# 設定後に確認
ethtool eth0 | grep -E "Speed|Duplex|Auto-neg"

注意：この設定は再起動後にリセットされる場合があります。恒久的な設定は/etc/network/interfacesやNetworkManagerの設定ファイルに記載します。また、対向スイッチ側も同じ設定に合わせる必要があります。

継続的な監視：リンクイベントをリアルタイムで記録する

障害が断続的に発生していて、現象が起きたタイミングを把握できていない場合は、リンク状態の変化をリアルタイムで記録する仕組みを設けます。

ip monitor でリンク変化を常時記録する

ip monitor link >> /var/log/link_events.log &

バックグラウンドで実行し、インターフェースの状態が変化するたびにタイムスタンプ付きで記録されます。しばらく稼働させた後、ログを確認します。

cat /var/log/link_events.log | grep -E "(eth0|DOWN|UP)"

どこを見るか：同じインターフェースのDOWN→UPが短時間で連続している場合は物理層のフラッピング確定です。一定時間だけダウンしていた場合は電源断やメンテナンスイベントと区別できます。

ethtoolの統計を定期取得してカウンターの増加率を見る

# 60秒ごとにcarrier_changesを記録するシェルスクリプト
while true; do
  echo "$(date): $(ethtool -S eth0 | grep carrier_changes)"
  sleep 60
done >> /var/log/carrier_changes.log &

60秒間でカウンターが複数増加していれば、その間に複数回リンクダウンが発生しています。1時間に1〜2回程度の増加であれば、タイムスタンプを別の外部イベント（工場の機械稼働時間・空調の動作サイクルなど）と照合すると原因特定に繋がることがあります。

よくある勘違いと確認時の落とし穴

現場でネットワークポートのupdown繰り返し障害を調査する際、以下の勘違いが原因特定を遅らせることがあります。

勘違い1：ケーブルを抜き差ししたらLEDが点灯したのでOK

LEDが点灯（リンクアップ）しても、数秒後に再びダウンする接触不良のケースがあります。ケーブル交換後は最低5〜10分間ip monitorかwatchコマンドで状態を監視し、リンクが安定していることを確認してください。

勘違い2：対向スイッチ側は正常と思い込む

スイッチのポートが物理的に劣化していたり、PoE給電ポートの電源回路が不安定だったりすることがあります。別のポートに差し替えて症状が消えれば対向スイッチ側の問題です。

# Ciscoスイッチ側でのインターフェース確認
show interface GigabitEthernet0/1 | include (line|Last input|input errors|CRC)

CRCエラーや入力エラーが増加している場合は、スイッチポートまたはケーブルの物理的な問題を示しています。

勘違い3：NICドライバーを疑わずにケーブルだけ交換し続ける

ドライバー問題が原因の場合、ケーブルをいくら変えても症状は変わりません。dmesgでTX timeout・resetが出ていないかを必ず確認してからケーブル交換の作業に入る順番が正しいです。

確認作業の推奨順序

まとめ：ネットワークポートのupdown繰り返し障害を効率よく解決するために

ネットワークポート updown 繰り返しの障害は、闇雲にケーブルを交換したり機器を再起動したりするだけでは解決しません。journalctlやdmesgでリンクイベントの頻度と文脈を把握し、ethtoolで物理層の状態とドライバー情報を確認してから、ケーブル・スイッチポート・ONUの順で物理層を切り分けていく手順が効率的です。

ip monitorを使ったリアルタイム記録は、断続的な障害の原因特定に特に有効です。インターフェース状態の変化をログとして残すことで、「どのタイミングで落ちているか」という時系列情報が得られ、外部要因（電源変動・空調の動作・業務時間帯）との相関が見えてくることがあります。物理的な切断なのかドライバー問題なのかを混同せず、コマンドの出力を根拠に一つずつ原因を絞り込むことが現場での最短解決につながります。

よくある質問（FAQ）

関連記事

• ルータインターフェース速度ダウン原因対処法｜show interfaceコマンドで統計情報から異常を読み取る
• ネットワーク接続が遅いと感じた時の確認手順｜トラブルシューティングコマンドと確認ポイント
• ルータのリソース使用状況を確認するためのコマンドとチェックポイント｜CPUやメモリの見方を解説