最近、私はモジュールとイーサネットスイッチの一つとの間のリンクに問題があると思われるサイトを扱った。テストとして、システム管理者は、彼を呼び出す, フレッド, スイッチをpingし、すべてのpingが返信を得たので、フレッドは問題が他の場所にあったと結論付けた。
この結論で問題なのは、モジュールのスイッチへのリンクを越えていなかったということです。
ネットワーク構成を説明しますと、IPアドレスをプライベートネットワークに変更していますが、インターフェースとネットワークの関係は似ています。
モジュールには #enet10 と #enet192 の 2 つのインタフェースがあります。enet10のIPアドレスは10.1.1.1.1で、これは問題のあるリンク上のスイッチに接続されているインターフェイスです。＃enet192のIPアドレスは192.168.1.1.1で、これは別のリンクを介して別のスイッチに接続されています。デフォルトのゲートウェイは192.168.1.254で、他のルートは設定されていません。スイッチの管理IPアドレスは172.16.100.100です。
172.16.100.100 に到達するためには、モジュールはデフォルトゲートウェイを使用しなければならず、デフォルトゲートウェイに到達するためには #enet192 インターフェイスからパケットを送信しなければなりません。スイッチは ping パケットの送信元を #enet192 のアドレス 192.168.1.1 と見なし、そのアドレスに返信します。パケットが#enet10から出たり、#enet10に到着したりすることはありません。重要なのはパケットの宛先アドレスとモジュールのルーティングテーブルだけです。
では、フレッドが#enet10とスイッチの間のリンクをテストする方法はありますか？いいえ、フレッドができる最善の方法は10サブネット上の他のホストにpingすることです。その場合、パケットは#enet10から送信され、ターゲットホストへのリンクを越えて、同じように返信が返ってくることになりますが、#enet10とスイッチの間のリンク、スイッチとターゲットホストの間の他のリンクの両方をテストすることになります。
Fred は "netstat -interface #enet10" コマンドを使用して、ハードウェアやドライバがリンク上で低レベルのエラーを報告しているかどうかを確認することができます。スイッチには、#enet10 に接続されているリンクに接続されているポートのエラーカウントを報告するコマンドもあります。しかし、#enet10 とスイッチの間のリンクをテストする方法はありません。