失敗の理由は、レベル3プロバイダーであるCenturyLinkがBGPルールを誤って作成したためです。セキュリティプロトコルのFlowspec。 BGP Flowspecはトラフィックのリダイレクトに使用されるため、このエラーはプロバイダーのネットワーク内で重大なルーティングの問題を引き起こし、グローバルインターネットの安定性にも影響を及ぼしました。もちろん、米国のユーザーは最も大きな打撃を受けましたが、問題の反響は世界中で感じられました。
CenturyLinkは、AT＆TとVerizonに次ぐ、アメリカで3番目に大きな通信会社であることに注意することが重要です。
IETFによってBGPフロースペックは、RFC 5575と含まBGP MP-BGPのマルチプロトコル拡張として記載されているネットワーク層到達可能性情報（NLRI）を。 BGP FlowSpecは、ルートからの攻撃DDoSトラフィックをダンプする代替方法であり、攻撃アドレスからのすべてのトラフィック、または宛先アドレスへのトラフィックがブロックされている場合、RTBH（リモートトリガーブラックホールフィルタリング）よりも攻撃を回避するためのより巧妙な方法と見なされます。一般に、RTBHは「最悪の武器」であり、攻撃を阻止するための最後の手段です。RTBHを使用すると、攻撃者が望むことを達成できる、つまりアドレスの1つを分離できることが多いためです。
BGP FlowSpecはより微妙で、本質的には特定のポートとプロトコルをフィルタリングし、どのトラフィックがどのルートを通過するかを決定するためにBGPに挿入されるファイアウォールフィルターです。したがって、「白い」トラフィックは宛先アドレスに送信され、DDoSとして定義されます-ルートからドロップされます。トラフィックは、少なくとも12のNLRIパラメーターによって分析されます。
- 宛先プレフィックス。一致する宛先プレフィックスを指定します。
- ソースプレフィックス。元のプレフィックスを指定します。
- IPプロトコル。IPパケットのIP値バイトをマップするために使用される{演算子、値}のペアのセットが含まれています。
- ポート。パケットをTCP、UDP、またはその両方で処理するかどうかを決定します。
- . , FlowSpec.
- . , FlowSpec.
- ICMP.
- ICMP.
- TCP.
- . IP- ( 2, IP-).
- DSCP. Class Of Service flag.
- Fragment Encoding
CenturyLink自体からの本格的なクラッシュレポートはなく、オンタリオ近郊のデータセンターについてのみ言及しています。ただし、ルーティングの失敗は、一般ユーザーだけでなく、CenturyLinkのサービスを大規模なプロバイダーとして使用しているCloudFlareエンジニアにも気付かれるほど深刻でした。CloudFlareのレポートに
よると、すべては8月30日の午前10：03GMTに522エラーの急増から始まりました。
たとえば、自動障害再ルーティングシステムは、エラーの数を減らしてピーク値の25％に減らすことができましたが、ネットワーク接続とリソースの可用性に関する問題は依然として永続的であり、グローバルな性質でした。これらはすべて、クラッシュの開始時の午前10:03からUTCの午前10:11までのウィンドウで実行されました。この8分間、自動化とエンジニアは、北米の48（！）の都市でCenturyLinkからインフラストラクチャを切断し、トラフィックを他のプロバイダーのバックアップチャネルにリダイレクトしました。
明らかに、これはCloudFlareだけで行われたのではありません。しかし、これは問題を完全には解決しませんでした。問題のあるプロバイダーが米国とカナダの通信市場にどのような影響を与えるかを明確にするために、同社のエンジニアはCenturyLinkサービスの可用性の公式マップを提供しました。
米国では、プロバイダーは4,900万人によって使用されています。つまり、一部の顧客にとって、CloudFlareレポート、さらにはデータセンター全体について言えば、CenturyLinkが利用可能な唯一のプロバイダーです。
その結果、CenturyLinkがほぼ完全に崩壊したため、CloudFlareのスペシャリストは世界のインターネットトラフィックを3.5％削減しました。同社が提携している6つの主要プロバイダーのグラフは次のようになっています。 CenturyLinkはその上で赤です。
プロバイダー自身が述べたように、障害がグローバルであり、「オンタリオ州外のデータセンターの問題」だけではないという事実は、Flowspecルールの更新のサイズによって証明されています。通常、BGP Flowspec構成の更新のサイズは約2メガバイトですが、CloudFlareの専門家は最大26 Mb（！）のBGP構成の更新を記録しました。
15分ごとに配布されるこれらの更新は、ルートの状態の変更に関する情報をホストと共有します。これにより、地域の問題に柔軟に対応できます。通常の10〜15倍の更新は、プロバイダーのネットワークのほぼ全体がダウンしているか、接続に非常に深刻な問題があることを示しています。
CloudFlareは、失敗の原因が誤ったグローバルBGP Flowspecルールであると考えています。このルールは、大多数のルーターによって受信され、接続を復元しようとして逆再起動しました。これは、4時間以上続いたクラッシュの写真に当てはまります。ルーターのメモリとCPUの過負荷により、エンジニアが多数のノードと制御インターフェイスへのリモートアクセスを失う可能性があったのはそのときでした。
ちなみに、この話は決してユニークではありません。1年ちょっと前、CloudFlare自体の障害とDNSの障害により、世界中のインターネットが「停止」しました。さらに、同じ会社が7年前にFlowspecで同様の問題について正直に言及し、その後、その使用を断念しました。