クラウドフレア社、
技術的な作業中に、バックボーンの XNUMX つからトラフィックの一部を削除するために、エンジニアは、指定されたプレフィックスのリストに従ってフィルタリングされ、バックボーンを介して受け入れられるルートのリストを定義する設定ブロック内の XNUMX 行を削除しました。 ブロック全体を非アクティブ化するのが正しいはずですが、誤ってプレフィックスのリストを含む行のみが削除されてしまいました。
{マスター}[編集] atl01# ショー | 比較する
[ポリシー オプション ポリシー ステートメントを編集 6-BBONE-OUT 用語 6-SITE-LOCAL から] ! 非アクティブ: プレフィックス リスト 6-SITE-LOCAL { … }
ブロック内容:
から {
プレフィックス リスト 6-SITE-LOCAL。
}
それから {
ローカル優先 200;
コミュニティは SITE-LOCAL-ROUTE を追加します。
コミュニティ追加 ATL01;
コミュニティに北米を追加。
受け入れる;
}
プレフィックスのリストへのバインディングが削除されたため、ブロックの残りの部分がすべてのプレフィックスに配布され始め、ルーターはすべての BGP ルートを他のバックボーンのルーターに送信し始めました。 偶然にも、新しいルートには、自動交通最適化システムによって他のルートに設定された優先度 (200) と比較して、より高い優先度 (ローカル優先度 100) が設定されていました。 その結果、バックボーンからルーティングが削除される代わりに、優先度の高い BGP ルートが漏洩し、その結果、他のバックボーン宛てのトラフィックがアトランタに送信され、ルーターの過負荷とネットワークの一部の崩壊につながりました。
今後同様のインシデントが発生するのを防ぐために、月曜日にCloudflareのバックボン設定にいくつかの変更が加えられる予定です。 BGP セッションにはプレフィックスの最大数の制限 (maximum-prefix) が追加され、あまりにも多くのプレフィックスがルーティングされると問題のあるバックボーンがブロックされます。 この制限が以前に追加されていれば、問題の問題によりアトランタのバックボーンがシャットダウンすることになっていたでしょうが、Cloudflareネットワークは個々のバックボーンに障害が発生しても許容されるように設計されているため、ネットワーク全体の運用には影響しなかったでしょう。 すでに採用されている変更の中で、ローカル ルートの優先順位 (local-preference) の改訂が注目されており、これにより、XNUMX つのルータがネットワークの他の部分のトラフィックに影響を与えることがなくなります。
出所: オープンネット.ru