web-dev-qa-db-ja.com

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

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

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

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

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

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

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

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

linuxnetworkingcentos
8
Aron Rotteveel

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

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

1
Aron Rotteveel

小切手

dmesg | less nicエイリアスに関連するもの（eht0など）less /var/log/messages 同じように

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

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

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

4
Oneiroi

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

3
mattdm

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

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

2
Jeff McJunkin

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

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

あなたの ifconfig -a正気を出力？この出力は、存在してはならないネットワークデバイス（仮想デバイスなど）が存在するかどうかを通知します。

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

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

1
Smar

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

0
Joris

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

0
LawrenceC