この投稿は英語から自動翻訳されました。

昨日は、定期メンテナンスとして予定されていたコア・ルーターのファームウェアのアップグレード中に、長時間のネットワーク停止が発生しました。何が起こったのか、そしてなぜ解決にこれほど時間がかかったのかについて、透明性を保ちたいと思います。

何が起こったのか

ファームウェアのアップグレード自体は問題なく完了したように見えた。ルーターはきれいに起動し、インターフェースも存在し、ルーター上のサーバー間のローカルトラフィックは問題なく機能した。しかし、アップストリームのBGPセッションとVXLANトンネルは復旧を拒否しました。

それから約8時間、私たちが遭遇した中で最も奇妙なネットワークの挙動を診断しました。トランジットポートのARP解決は一貫していませんでした。BGPセッションが確立され、トラフィックがルーティングを開始した後、リンクが事実上デッドになり、インターフェイスレベルで実際にダウンしたわけではなく、単にパケットを転送しないだけで、ゼロドロップが報告されました。ルーターを診断しても、エラーもログも何も出ませんでした。

トランジット・プロバイダーに問い合わせたところ、彼らにも異常がないことを確認しました。さまざまな設定を試しました。さらに、問題の切り分けのために、BGPとトンネルのコンフィグをルーターから別のLinuxサーバーに移しましたが、まったく同じ動作が起こりました。その時点では、ルーター自体が原因ではないと思われました。

他のあらゆる手段を尽くした後、私たちは最後の手段としてルーターを工場出荷時の状態にリセットし、ブリッジとVLANのセットアップだけという最小限のコンフィギュレーションをゼロから適用しました。驚いたことに、それは即座に機能した。完璧だ。

根本原因

我々が判断できる限りでは、ファームウェアのアップグレードによってルーターの状態が何らかの形で無言の破損を起こし、トランジットに面したインターフェイスがトラフィックを処理する方法に影響を及ぼした。アップグレードは完全に成功したように見え、ルーターはエラーを報告せず、BGPが全く別のマシンで処理されたときにも問題が再現したにもかかわらず、工場出荷時のリセットとクリーンなコンフィギュレーションだけで解決した。しかし、工場出荷時のリセットとクリーンな設定だけで解決しました。

やるべきこと

• VMにアクセスできない場合、コントロールパネルからVMを停止し、起動してください。ほとんどの場合、これで接続が回復します。
• 停止・起動後も接続できない場合、サポートまでご連絡ください。
• VMに接続する際にSSHホスト・キー変更の警告が表示された場合、これは予期されたものです。VMは新しいセットアップで動作するように一括で再設定され、cloud-initはそのプロセスの一部としてホスト鍵を再生成しました。これはVMが再初期化された際のcloud-initの標準的な動作であり、安全に新しいキーを受け入れることができる。

ダウンタイムが長引き、ご迷惑をおかけしたことをお詫び申し上げます。今後、このような問題をより迅速に特定し、復旧できるよう、アップグレード手順を見直します。