2017年8月25日の大規模インターネット障害

2017/8/29-1

先週の金曜日、Googleが誤った経路をインターネットに流したことによって、大規模な通信障害が発生しました。大きな影響を受けたのが日本のOCNとKDDIだったとされていますが、様々な事業者が影響を受けたようです。

今回の障害は、世界中の組織とBGP(Border Gateway Protocol)で繋がっている巨大なネットワークを持つ「Googleだからこそ」の事例と言えそうです。

ここでは、その理由を紹介します。

ネットワークのネットワークを作るBGP

実際に何が起きたのかを説明する前に、今回の障害の背景となるBGPについて紹介します。ネットワーク同士を接続するためのプロトコルであるBGPは、インターネットを構成する非常に重要な要素です。

「インターネット」という単語の語源を考えると、「BGPこそがインターネット」と言っても過言ではありません。「インターネット」という表現は、Inter-networkingから来ています。 interというのは「～間の」という意味を持ちますが、複数のネットワークを接続させることを「internetworking」、それを短縮した単語として複数のネットワークによって構成される「ネットワークのネットワーク」の名称を「internet」としてたのが、今の「インターネット」の語源です。

「ネットワークのネットワーク」であるインターネットで、ネットワーク同士をつなげるプロトコルがBGPなのですが、BGPが接続する「ネットワーク」は「AS(Autonomous System/自律システム)」と呼ばれています。 ASには番号があり、BGPはAS番号を使って経路制御を行います。たとえば、今回の障害を発生させる要因となったGoogleのAS番号は15169です。

BGPそのものの紹介は、ここでは割愛します。BGPそのものに関しては、2009年に書いた記事をご覧ください。

BGPを解説してみた

金とチカラのBGP

ネットワーク同士をつないでいるBGPですが、BGPでは「誰とお隣さんになるのか？」が非常に重要な要素です。 BGPで接続して「お隣さん」になることを「ピア(Peer)になる」とか「ピアする」とか「ピアリング」と言いますが、誰とどのように「お隣さん」になるのかによって、ネットワークの運用費が変わったり、お金をもらえるようになったりします。さらに、「お隣さん」が多くなればなるほどネットワークとしての「ちから」が増大し、交渉力もつくようになります。 BGPはネットワークプロトコルですが、「金とチカラ」が関係する実に人間臭いプロトコルなのです。

参考：金と力のインターネット

コンテンツ事業者によるピアリング

通信品質を向上させたり、運用コストを削減するといった目的もあり、Webサイトを運用するコンテンツ事業者が積極的にピアリングを行うことも多いです。たとえば、今年6月に、日本でTwitterやSpotifyがBGPでのピアリングを呼びかけていました。

Googleも、世界中で積極的にピアリングを行っています。日本も例外ではなく、日本においても非常に多くのASとピアリングしています。

Googleとどこでどのようにピアリングが可能であるのかは、peeringdbにて公開されています。

たとえば、IX(Internet eXchange)のpublic peeringであればBBIX、Equinix、JPIX、JPNAP、1対1のprivate peeringであればAT TOKYO、ComSpace I、Equinix、KDDI Otemachi、NTT Telepark Dojimaで行えることがわかります。

どのような条件でピアリングが可能であるのかといったピアリングポリシは、以下のURLで公開されています。

https://peering.google.com/#/options/peering

このように、世界中で非常に多くのASとGoogleはつながっているのですが、BGPで繋がるということは相手のネットワークに対する経路を持っているということでもあります。今回の障害では、持っていた経路を誤って外に広告してしまったのですが、その規模が凄まじいです。

今回、Googleの誤設定によって広告された経路は13万5000プレフィックスであったとBGPMonの記事にあります。BGPによるインターネット全体の経路である「フルルート」の数を計測し続けている「CIDR Report」によると、8月17日時点でのフルルートは約68万プレフィックスとあります。観測地点によって異なるものの、Googleの誤設定によって、フルルートが一瞬で約20%増加してしまったことになります。

言い方を変えると、数だけで言えば、フルルートの2割ぐらいの規模のプレフィックスをGoogleがBGPのピアリングによって得ているということです(プレフィックス長が違うのでフルルートの2割とは違いますが)。今回の経路は細かったので、インターネット全体の約2割が間に他のASを挟まずにGoogleと直接繋がっているわけではありませんが、数だけで見ると、けっこうな規模感です。

Googleは、BGPでGoogleとの直接の「お隣さん」になっているネットワークの経路を全部吐き出すと、インターネット全体の経路数の2割に達する規模になるのです。

なお、余談ではありますが、今回、Googleが漏らしてしまった情報を見ることで、Googleがどの組織と直接ピアリングをしているのかが垣間見えるというのも興味深いところではあります。そういった情報は表に出ないこともあるので。

longest match

Googleによって広告された経路が細かかったことも、今回の大きな要素です。経路が細かいということは、各経路のプレフィックス長が長いということです。

プレフィックス（prefix）は、英語で「接頭辞」や「前に置く」や「前に置いてあるもの」という意味を持つ単語です。 IPアドレスの前半部分がネットワークを示し、後半部分がネットワーク内でのホストを示すものとなるため、前半部分の何ビット目までがネットワーク部であるかを示すのがプレフィックス長です。プレフィックス長を使ってネットワークを表現するとき、そのネットワークをIP アドレスと「/」に数字が続く形で表現します。たとえば、192.0.2.0/24となっていれば、192.0.2.0の最初の24ビットがネットワーク部を示します。

BGPでは、たとえば、10.0.0.0/8という経路と、10.0.0.0/24という経路があったとき、プレフィックス長が長い10.0.0.0/24という経路が採用されるのです。プレフィックス長が長いということは、より細かく明示的なネットワークを示しているとも言えます。たとえば、10.1.1.1は、10.0.0.0/8に含まれますが、10.0.0.0/24には含まれません。

BGPでは、より明示的であるネットワークが採用されますが、そのような条件は「longest match」と呼ばれています。より長いビット数がマッチするものが採用されるのです。

今回、Googleの誤設定をトリガーとし、Verizon(AS 701)から世界中に広告されたBGPでの経路は、非常に細かいものが多かったのが障害を発生させた要因です。

たとえば、OCN(AS 4713)から正式に出ている経路が/16のものだったとして、VerizonとGoogleを経由する経路が/24で出ていた場合、/24がlongest matchするのでVerizonとGoogleを経由する経路が選ばれやすくなったりします。

今回、Googleから誤って広告された細かい経路ですが、誰が細かい経路を最初に設定したのかは、現時点では明確に公表されてなさそうです。可能性としては、Googleとピアリングしている組織がトラフィック制御をするために意図的に細かい経路をGoogleに対して広告していることも考えられます。オリジンが細かい経路を生成してGoogleに伝えていたというものです。たとえば、Googleと複数拠点でBGP接続をしているようなときに、特定のネットワークへのトラフィックがGoogleと接続したどの拠点から来るようにするのかを誘導するためです。 Googleからのトラフィックが巨大なので、そういった対処が必要になることもあるという背景があります。

さらに余談ですが、2008年2月にパキスタンのISPが「YouTubeはこっちにあるよ！」という嘘の情報をBGPで流してしまい、約40分間にわたり世界中にYouTubeが見られなくなってしまうという事件がありましたが、そのときに行われたBGPハイジャックも、longest matchが大きな要素でした。

何が起きたのか？

で、実際に何が起きていたのかですが、もしかしたら、複数のことが同時に発生していたかも知れません。

まず第一に、Googleの誤設定によって、本来は通過すべきではない経路をパケットが通過するようになった可能性が考えられます。たとえば、OCN(AS 4713)に直接接続したASであったにもかかわらず、太平洋を超えてVerizon(AS 701)→Google(AS 15169)を経由しつつ太平洋を戻ってきてから通信するといった経路になってしまったことで、RTTが増大してしまい通信速度が著しく低下していた可能性が考えられます。ここで重要なのが、全く同じプレフィックス長であればAS PATHが短い方が選択されたものの、今回は細かい経路がGoogleから漏れたという点です。 OCN(AS 4713)が流している経路よりも、Googleが漏らした経路の方がプレフィックス長が長かったので、Googleが漏らした経路側でlongest matchが成立してしまっため、AS PATHが長くてもそちらが優先されてしまった可能性があるのです。

さらに、意図しない大量のトラフィックを受け入れてしまった途中経路上で、急激な輻輳(ネットワークの混雑)が発生し、通信品質が低下していた可能性も考えられます。

BGPで大量の経路情報を受け取ってしまうと、BGPルータの性能が著しく低下することがあります。 Googleの誤設定による細かい大量の経路情報が、他組織のBGPルータを過負荷状態へと陥らせた可能性も考えられます。

何が起きたのかに関する技術的な話は、他の方々も書かれているので、ここでは割愛します。技術的な内容に関しては、以下の2つが超オススメです。

[PDF] 08/25の通信障害概説(IIJのmazさんの発表資料)
パブリックデータから経路リークを探る - LGTM

あと、少しだけ技術的な話を私も書いてみました。

Googleは誤設定を行ったが、不正な設定だろうか？

今回の問題は、Googleが誤設定を行ったことによって発生しています。ただし、注意が必要なのは、今回発生したことが不正な行為であるとも言えなさそうだと思えるという点です。

Googleが誤って提示してしまったのは選択肢のひとつであり、その情報を受け取った世界中のBGPルータが「最適な経路」として、本来は通らない方が良い経路を選択してしまったために起きた問題とも言えます。

さらに、Googleは偽情報を出したわけではなさそうというのも個人的にはポイントだと考えています。

今回、漏れてしまった経路情報は、Googleが実際にピアリングをしている相手です。トランジットを行う契約ではないだろうと思うものの、物理的には実際に繋がっているのです。

Googleがその気になれば、いつでもTier 1になる能力を持っていることを見せつけられた事件でもあった、というのが個人的な感想です。 Dynのブログにある障害発生時のtraceroute結果を見る限り、一時的かつその経路を最適と選択した組織からのみとはいえ、本来なら他のASを通過するはずだった一部AS向けのトラフィックを世界中から吸い込んだうえで、それをある程度制御できていることを示唆していますし。

(たとえば、日本国内での事情を考えると、Tier 1になるということは日本国内でコンテンツ事業者ではなくなって通信事業者になるので、通信の秘密などに関する制限を今より受けてしまうこともあり、そっちの方向に行かない可能性も高いとは思いますが。あと、米国でも日本での場合とは異なる事情で通信事業者になることを選択するようには思えません。あと、Googleなどのハイパージャイアントの影響力が大きくなり、Tier 1の影響力は低下しているという話も、8年ぐらい前から言われています。)

過去記事

過去記事一覧

超凄いIPv6解説書(488ページ)を無料配布します！