マイクロソフト、AzureやMicrosoft 365などに影響した先週の大規模障害の原因報告。WAN内の全ルータが再計算状態に突入し、パケット転送が不可に

今回は「マイクロソフト、AzureやMicrosoft 365などに影響した先週の大規模障害の原因報告。WAN内の全ルータが再計算状態に突入し、パケット転送が不可に」についてご紹介します。

関連ワード （予備的、増加、送信等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

マイクロソフトは、日本時間で先週の1月25日午後4時頃から最大で約5時間半に渡り、Microsoft AzureやMicrosoft 365、Microsoft Teamsなど幅広いサービスがほぼ全世界で利用できなくなっていた大規模障害について、予備的な報告書を公開しました。

WAN内の全てのルーターに誤ったメッセージが送信

報告書の原因について説明している部分を引用します。

まず原因について。同社のワイドエリアネットワークに対して行われた設定変更が全体に影響したと説明しています。

We determined that a change made to the Microsoft Wide Area Network (WAN) impacted connectivity between clients on the internet to Azure, connectivity across regions, as well as cross-premises connectivity via ExpressRoute.

原因としては、Microsoft Wide Area Network (WAN) に対して加えられた変更が、Azureとインターネット上のクライアントとの接続やリージョン間の接続、ExpressRouteを介した企業間の接続に影響を与えた結果であると判断しました。

具体的には、設定変更のためにあるルーターに対して送られたコマンドが、WAN内のすべてのルーターに対して誤ったメッセージを送信。その結果、WAN内のすべてのルーターが再計算状態に突入し、適切にパケットを転送できなくなったことが原因とのこと。

As part of a planned change to update the IP address on a WAN router, a command given to the router caused it to send messages to all other routers in the WAN, which resulted in all of them recomputing their adjacency and forwarding tables. During this re-computation process, the routers were unable to correctly forward packets traversing them.

計画的に行われた設定変更の一環として、あるWANルーターのIPアドレスをアップデートしたところ、そのルーターに送られたコマンドによってWAN内の他のすべてのルーターにメッセージが送信されました。これによって、すべてのルーターで隣接テーブルと転送テーブルの再計算が引き起こされたのです。そして再計算の間、ルーターは通過するパケットを適切に転送できませんでした。

問題の発端となったルーターは、マイクロソフトの認証プロセスで検証されていなかったことも付け加えられています。

The command that caused the issue has different behaviors on different network devices, and the command had not been vetted using our full qualification process on the router on which it was executed.

この問題を引き起こしたコマンドは、ネットワーク機器ごとに動作が異なる上、そのコマンドが実行されたルーターでは、当社の完全な認証プロセスで検証されていませんでした。

2時間後にはほぼ自動回復、健全性維持システムを再起動

障害発生後の同社の対応と今後の対策についても報告書に書かれていますので、簡単にまとめておきましょう。

同社としては、障害発生から約7分後に、DNSとWANに関する問題を検出し調査を開始。発生から1時間5分後にネットワークが自動的に回復し始め、ほぼ同じくして問題の引き金となった問題のあるコマンドが特定されたとのことです。

2時間後にはほぼすべてのネットワーク機器が回復したことが観測され、2時間半後にはネットワークが最終的に復帰したことが確認されたと報告されています。

ただしWAN自身が備えていた健全性維持システム、例えば健全でないデバイスを特定して削除するシステム、ネットワーク上のデータの流れを最適化するトラフィックエンジニアリングシステムなどがWAN自身の障害によって停止してしまっていたため、これを手動で再起動。

これによりWANを最適な動作状態に回復させるまでネットワークの一部でパケットの損失が増加し、約5時間時40分後にこれが完了したとのことです。

今後の対策として、影響度の高いコマンドの実行を遮断し、デバイス上でのコマンド実行は、安全な変更ガイドラインに従うことを義務付ける予定とのことです。

今回の報告は予備的な報告書と位置づけられており、今後改めて詳細な発表が行われる予定とされています。

関連記事

• Microsoft 365の大規模障害、原因は未検証アップデートがデプロイシステムのバグにより通常のプロセスをバイパスして本番環境へ直接デプロイされたこと
• マイクロソフトのクラウドサービス「Microsoft Teams」がサーバ証明書を更新し忘れ。2時間のあいだユーザーからアクセスできなくなる障害発生
• パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生。ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず
• Cloudflareが昨日（2022年6月21日）の障害原因はBGPの設定ミスと報告。東京データセンターを含む19の主要データセンターが一時オフラインに