Linuxネットワーキングのクラッシュ：原因を見つけるための最良の手順は？

昨夜、Linux（CentOS）サーバーの1つに到達できませんでした。

リモートコンソール以外の方法でサーバーに到達できませんでした。リモートコンソールでログインした後、外部ホストにもpingできないことがわかりました。

簡単なことでservice network restart問題は解決しましたが、何が原因なのかまだ疑問です。私のログファイルにはエラーがまったくないようです（ネットワーク接続を必要とし、ネットワーク障害の後に失敗したさまざまなデーモンを除く）。

この問題の原因を見つけるために実行できる追加の手順はありますか？

編集：これはちょうど再び起こった。ネットワークサービスの再起動を発行するまで、サーバーは完全に応答しませんでした。どんなアドバイスでも大歓迎です。これは、ハードウェアコンポーネントの不良が原因である可能性がありますか？

Madhattersのリクエストに従って、当時のログからの抜粋をいくつか示します（ネットワークは20:13にクラッシュしました）。

/ var / log / messages：

Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=100 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:13:34 graviton junglediskserver: Connection to gateway failed: xGatewayTransport - Connection to gateway failed.

最初の3つのメッセージは、LFDファイアウォールを介して設定したiptablesルールに対する単純な応答です。最後のメッセージは、バックアップに使用しているJungleDiskがゲートウェイに接続できなくなったことを示しています。これとは別に、この時期に興味深いメッセージはありません。

EDIT 4 dec： Mattdmのリクエストに従って、以下は出力ですethtool eth0：

（これらは現在動作している設定です。再度問題が発生した場合は、必要に応じてこれを再度投稿します。

Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Jorisの要求に従って、ここにも出力がありroute -nます：

aron@graviton [~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xx.xx.xx.58    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.42    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.43    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.41    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.46    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.47    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.44    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.45    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.50    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.51    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.48    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.49    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.54    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.52    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.53    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.192 U     0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         xx.xx.xx.62    0.0.0.0         UG    0      0        0 eth0

下のxx.62は私のゲートウェイです。

12月28日の編集：問題が再び発生し、上記のテストの出力の一部を比較する機会を得ました。私が見つけたのはarp -an、ゲートウェイの不完全なMACアドレスを返すことです（これは私の制御下にありません。サーバーは共有ラックにあります）。

失敗時：

? (xx.xx.xx.62) at <incomplete> on eth0

後service network restart：

? (xx.xx.xx.62) at 00:00:0C:9F:F0:30 [ether] on eth0

これは私が修正できるものですか、それともデータセンターに連絡するときですか？

小切手

dmesg | lessお使いのNICエイリアス（すなわちeht0）に関連する何のための less /var/log/messagesaswell

まれに、IPアドレスの競合である可能性がありますが、これが再度発生する場合は、

arping -U <gateway ip> -I <nic alias> ただし、arpingを使用してから長い時間が経過しているため、これを確認してください。これは正しくない可能性があります。

成功した場合は、ネットワークサービスをリロードせずに接続を回復する必要があります。

このネットワーク（DHCPまたは静的）でIPアドレスをどのように取得していますか？それが再び発生する場合は、実行ifconfigして、インターフェースが機能していない状態のときにインターフェースの状態を確認してください。住所はありますか？エラーはありますか？を実行した場合ethtool、リンクはありますか？（そして、適切な速度とデュプレックスにネゴシエートされていますか？）

発生した問題に基づいて、私はIPアドレスの競合を非常に疑います。ネットワークを再起動すると、そのIPを再び引き継ぐgratuitous ARPが送信され、問題が解消されます。

同じブロードキャストドメイン（同じネットワーク）内の別のホストにarpwatchをインストールし、他のマシンがサーバーのIPに対するARP要求に応答しているかどうかを確認します。その場合は、どのマシンかを確認し（スイッチのMACアドレステーブルを使用して、接続されているポートを確認する場合があります）、別の静的アドレスまたはDHCPに設定します。

たぶんTCP接続プールがいっぱいになりますか？何かがますます接続を開いており、多分試みてnetstat（たとえば、インターフェースを表示するために-iを試してみてください）接続を開くことについての洞察が得られます。

実際の接続（およびiptables / routes / whatever：you_are_using構成）に問題がなければ、たとえばネットワークインターフェイスの構成に問題がある可能性があります。

あなたのifconfig -a出力は正気ですか？この出力は、仮想デバイスなど、存在してはならないネットワークデバイスがあり、パケットが不安定になる原因があるかどうかを示します。

貼り付けたこのルーティングテーブルは、非常に奇妙に見えます。そんな時に動作しますか、接続が切れてから変化しますか？はいの場合、何かがルーティングテーブルの変更を引き起こしています。おそらくiptablesに関連するものです。

最後に、CentOS固有のもの：NetworkManagerを使用していますか？これは、Xを持たない仮想マシンであっても、何らかの理由でCentOSでデフォルトで有効になっているため、この接続が2倍になり、ルーティングの変更などが可能になります。必要なことがわかっている場合を除いて、オフに切り替えることをお勧めします（オンとオフの接続があるなど）。

この問題はかなり前に解決されました。問題は明らかにハードウェアに関連したものでした。

新しいNICが問題を解決しました。

どこからテストしていますか？サブネット内またはその外？ルートはいくつありますか？自動ゲートウェイ選択は、一見予期しないことをするかもしれません。

私はRedHatやCentOSを使用していませんが、実行時に呼び出されるスクリプトを調べてみてservice network restart. ください。そのスクリプトで何かが発生するとネットワークが正常に戻るため、それを絞り込むのに役立つ場合があります。

うーん。

たぶん、iptablesを誤って変更したのでしょうか？到達できなかった理由と、ログに異常がない理由の両方を説明できます（おそらく、iptablesを記録していません。そうですか？）