web-dev-qa-db-ja.com

pingに0.0.0.0として返信する理由や方法は何ですか?

私よりもネットワーキングについて多くのことを知っている人への質問...

そのため、簡単に言えば、今夜、リモートサーバーで問題が発生し、完全なRTFMを実行した後でも、ILO(HPの帯域外管理テクノロジ)で修正できませんでした。このサーバーのILOファームウェアバージョンが5年以上前のものであることに気付き、それが問題の原因である可能性があると考えたため、アップグレードしようとしましたが、できませんでした。 (ILO Web管理コンソールには、ファームウェアの更新を行うメカニズムがあります。)長い間後悔しているので、テクニカルサポートに電話して、ファームウェアを更新する方法を尋ねることができました。実際に彼らのアドバイスを聞いて、インターフェースのソフトリセットを(ILO Web管理コンソールを介して)実行すると、応答しなくなりました。

予期された動作であり、ILOインターフェイスのIPアドレスに対してping -tを開始したので、いつ復旧したかがわかります。 pingがすべてReply from 0.0.0.0: ...として戻ってきたことを除いて、リセットが何か奇妙なことをしている場合に備えて、とにかく数分与えることにしました。さて、30分後もまだ0.0.0.0から返信があったので、誰かにサーバーのプラグを抜いてもらいました。これにより、ping応答がRequest timed out.に変更されました。プラグが差し戻されるとすぐに、0.0.0.0からのping応答が再開されました。 6時間後の今でも、そのILOインターフェイスの「実際の」IPアドレスへのpingは、0.0.0.0からの応答で応答します。

価値があるので、ILO用の個別のVLANまたはサブネット(私はそれに取り組んでいます))はありません。サブネット内のアドレスにpingを実行しても、何も含まれていません。Request timed out.アドレスへのtracertは、スイッチを経由して、メインオフィスのリンクから、リモートサイトのT1の反対側に移動します...そして0.0.0.0を表示します。pingリモートVPN(別のVLANとサブネット)を介した要求が返されますRequest timed out.

ネットワーキングについて私が知っているすべてのことから、昨日と同じくらい最近知っていたと思っていたよりも明らかに少ないので、0.0.0.0から返信を受け取ることはできません。それが「任意の」アドレスです。したがって、ILOインターフェイスのアドレスが0.0.0.0にリセットされたとしても、0.0.0.0として応答を送信することはできないはずです。だから...まあ、なぜこれが起こっているのか誰か知っていますか?または、これもcould起こるのでしょうか?

更新:ILOの設定を確認するために現場の誰かを雇いました、そして確かに、インターフェースのIPアドレスは0.0.0.0にリセットされました。

Zeros

2
HopelessN00b

これはおそらくファームウェアのバグですが、0.0.0.0からの-sources-パケットについて聞いた唯一の状況は、IPアドレスを見つけるためにすべてゼロのMACから要求を送信するRARP(リバースARP)です。これはかつてディスクレスブートのコンポーネントでしたが、しばらくは見られませんでした。

PingステーションがILOのMACアドレスをキャッシュに保持している可能性があります。もちろん、中間スイッチも保持しています。 ILOがアドレスを失った場合、RARP/BOOTPプロセスを経ていた可能性があります。またはそれはちょうどその心を失った。

3
rnxrx

これは0.0.0.0についてではなく、ILOの回復についてです...

ILOを収容するサーバーがWindowsとLinuxのどちらを実行しているかはわかりませんが、サーバーにアクセスできると仮定すると、ILOをホストオペレーティングシステムから適切なIPアドレスにリセットすることをお勧めします。これは、hponcfgユーティリティ( LinuxWindows )を使用してすばやく実行できます。

今までにわからない場合は、HPProLiantの世界ではファームウェアが非常に重要です。ホストから更新を実行し、古いファームウェアリビジョンでILOWebインターフェイスを介した更新を回避します。

2
ewwhite