2009年2月17日 世界的インターネット経路障害解説
2009年2月17日に発生した世界的なインターネット経路障害に関しての解説、及びその後調べたことです。(参考:インターネットが壊れました)。
BGPとは何かに関しての解説も書いたので、インターネット通信技術そのものに関して知りたい方はそちらもご覧下さい。
何が発生していたのか?
チェコのプロバイダが非常に長いAS pathを流してしまい、その長いAS pathを受け取ったルータがBGP peerを切れたり上げたりを繰り返しました。 BGPのpeerが切れた次の瞬間に、また接続し直してpeerが復活し、そしてまた問題のAS path情報を受け取って切れるという状況を繰り返してしまったようです。
BGP peerが切れるのは、パケットがISP間で転送されなくなるという事なので、世界中で「到達出来ない場所」が発生しました。 この障害は約1時間弱続きました。
問題をトリガーしたチェコのプロバイダと何故わかったのか?
以下がNANOGに流れていた情報です。 それによると、「Long AS path」として表示されているAS path(AS_PATH)は 6461→1299→29113→47868と続いた後に、47868がひたすら続いているのがわかります。 BGPルータが隣接するBGPルータにAS pathを伝えると、伝わったAS列の前に伝えてきたAS番号が入るので、47868を連発しているのが47868のASか、29113のASであると推測できます。
Feb 16 16:44:36.065 GMT: BGP: x.x.x.x Bad attributes
Feb 16 16:45:43.389 GMT: %BGP-6-ASPATH: Long AS path 6461 1299 29113 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868 47868
47868 47868 47868 47868 received from x.x.x.x: Has more than 255 AS
Feb 16 16:45:43.389 GMT: %BGP-5-ADJCHANGE: neighbor x.x.x.x Down BGP Notification sent
Feb 16 16:45:43.389 GMT: %BGP-3-NOTIFICATION: sent to neighbor x.x.x.x 3/11
(invalid or corrupt AS path) 516 bytes 50020200 02FF193D 051371B9 BAFCBAFCBA
Feb 16 16:45:43.389 GMT: BGP: x.x.x.x Bad attributes
そして、AS番号からASを保持している組織を調べると、チェコのISPであることがわかります。 AS番号と組織のマッチングはWHOISと呼ばれるサービスを使って調べますが、全てのAS番号をWHOISで調べ上げて公開してくれているようなWebサイトもいくつかあるので、それらを見た方が早く情報が発見できるかも知れません。
以下がWHOISで得られる公開情報です。
AS番号 | 29113 |
名前 | SLOANE-AS |
ハンドル | JF596-RIPE |
場所 | 160 00, Czech Republic |
組織 | Sloane Park Property Trust, a.s. Autonomous System - Luzna 2/716 - Praha 6 - Vokovice - 160 00 - Czech Repulic |
AS番号 | 47868 |
名前 | SUPRO-AS |
ハンドル | PS8170-RIPE |
場所 | Premysla Otakara II 2476, 688 01 Uhersky Brod |
組織 | AS SUPRO-NET - SUPRO, spol. s r.o. |
同じAS番号が連発してるのは何?
AS-PATH prependingと呼ばれる一般的な手法があります。 200個以上並べるのは一般的とはとても言えませんが、何個か並べるのは普通に使われています。
これは、AS pathをわざと長く見せるための手法です。 他のASが自分の所をベストパスに選んで欲しくない時に、数回同じASを記述することによって、最短AS pathにならないようにできます。
ただし、この方法は完全ではなく、AS-PATH prependingをしたとしてもベストパスとして選ばれる事もあります。
今回は凄い勢いで47868が連発されていますが、よっぽどトラフィックが来て欲しくなかったのだろうと思い始めました。
また、問題を発生させたISPが変なBGPルータ実装を使っていた可能性もあります。 例えば、製品によってはAS-PATH prependigは10個以上は出来ないようになっています。 これだけ連発するというのは、そもそもメッセージを作成したルータのバグなのかも知れません。
開通前?
AS pathで連続している47868に関する情報を見てみると、以下のようになります。
whois -h whois.radb.net as47868 aut-num: AS47868 as-name: SUPRO-AS descr: AS SUPRO-NET descr: SUPRO, spol. s r.o. org: ORG-Sssr1-RIPE import: from AS25512 accept ANY import: from AS34692 accept ANY export: to AS25512 announce AS47868 export: to AS34692 announce AS47868 admin-c: Sh3979-RIPE tech-c: Sh3979-RIPE notify: supro@supro.cz mnt-by: MNT-SUPRONET mnt-routes: MNT-SUPRONET changed: hostmaster@ripe.net 20080908 source: RIPE
あれ?exportに29113がありません!!!
一方、29113の方を見ると以下のようになります。 29113の方が大きいISPですね。
whois -h whois.radb.net AS-SLOANE-CUST as-set: AS-SLOANE-CUST descr: Sloane Park Property Trust, a.s. descr: AS29113 customers. members: AS13036 members: AS15425 members: AS24641 members: AS24806 members: AS25036 members: AS28851 members: AS28905 members: AS28972 members: AS34040 members: AS34080 members: AS34093 members: AS34095 members: AS34302 members: AS34315 members: AS34692 members: AS35592 members: AS39392 members: AS39790 members: AS39817 members: AS39904 members: AS41267 members: AS41670 members: AS41824 members: AS42000 members: AS43542 members: AS43709 members: AS44070 members: AS44489 members: AS44592 members: AS47269 members: AS47317 members: AS47493 members: AS47699 members: AS47727 members: AS47868 members: AS47949 tech-c: SPHR1-RIPE admin-c: SPHR1-RIPE mnt-by: SLOANE-MNT changed: gomola@sloane.cz 20090212 source: RIPE
先ほどのAS47868がCUSTOMERだと言っています。 しかし、顧客側であるAS47868は、それを言っていません。
AS29113のwhois結果の「changed」部分を見ると、「changed: 20090212」と記述してあります。 実際に何処が変更されたのかは確認できていませんが、恐らく47868に関する記述を追加したのだろうと思いました。 これらの結果から、47868は29113の顧客に最近なった、もしくはこれから顧客になるのだろうと思います。
開通日で失敗したか、事前試験で失敗したのかも知れませんね。
47868は新規プロバイダ?
SUPROのWebサイトを見ると一番古い情報が2008年9月1日になっています。 WiFi、光ファイバ、電話、ホットスポットの項目と値段が記述してあるように見えるので、プロバイダではありそうです。
routeviews(参考:「インターネットの形」を探るための基礎データ集)で公開されているBGPのフルルート経路表を見ると、29113からの経路は一つだけで、それ以外の37経路は全てAS25512経由になっていました。
昨年後半に新規開始したプロバイダが2本目の回線を契約する過程で発生させてしまった設定間違いという構図ですかね?
ただし、whois情報では「export: to AS25512 announce AS47868、export: to AS34692 announce AS47868」とあるので、実は3本目の回線なのかも知れません。
問題の「バグ」はどれか?
問題を発生させていたルータは複数社製品に上るようです。 RFC4271が発行される以前から稼働しているBGPルータもありますし「イレギュラーなもの」に関しての挙動で明確に決定されていない部分にたまたまハマってしまったという可能性もあります。 なので、そもそも今回の問題が発生した背景は「バグ」では無い可能性もあります。
NANOGで紹介されていたものは、Cisco社に関するものでした。 マーケットシェアが一番大きいので情報が真っ先に出てきているだけかも知れないのでご注意下さい。
「CSCee30718を適応していないCicsoルータがBGP peerを切断していた」という記述がいくつかありました。 以下がCSCee30718に関しての記述です(Cisco社Webサイトより)。
Release Notes for Cisco IOS Release 12.1 E on the Catalyst 6500 MSFC
Cisco IOS BGP is implemented with limits of 255 standard communities and 128 extended communities. RFC1771 Border Gateway Protocol 4 (BGP4) specifies that these communities should not be limited. This problem is resolved in Release 12.1(27b)E1. (CSCee30718)
バグ登録も行われたようです。 ただし、これが正式にバグとして受理されるかどうかは別問題なのでご注意下さい。 (バグの登録と、それがバグと認められる事は同義ではありません。)
[c-nsp] Invalid Formatted BGP update with AS prepending update
CSCsx73770
Invalid BGP formatted update causes peer reset with AS prepending
*Note: The title may show up as: BGP peer resets when receiving update with > 255 AS hops
Cisco IOS device that receives a BGP update message and as a result of AS prepending needs to send an update downstream that would have over 255 AS hops will send an invalid formatted update. This update when received by a downstream BGP speaker triggers a NOTIFICATION back to the sender which results in the BGP session being reset.
Conditions:
This problem is seen when a Cisco IOS device receives a BGP update and due to a combination of either inbound, outbound, or both AS prepending it needs to send an update downstream that has more than 255 AS hops.
影響範囲はどれぐらいだったのか?
世界中で影響があったようです。
知人がいる某ASの観測では、定常時に約20万個以上ある経路が、障害時に約1000個減っていたそうです。 そのASでは、経路の数だけで言えばインターネットの0.5%が「消えた」ように見えたということです。なお、実際は/32の経路と/8の経路でネットワーク規模が全然違うので経路の数だけで「インターネットから0.5%のホストが消えた」という表現をするのは正しくないのでご注意下さい。
Renesys Blogにて、影響があった地域を示した地図が公開されています。 Renesys Blogでは271175経路から1215経路が消えたと記述されています。 この図は世界中の観測地点でのフルルート情報を元に経路の減少と地域を組み合わせて可視化したものです。
一つ目の図が問題発生の1時間前で、二つ目が問題発生中だそうです。
問題発生前 : Renesys Blogより
問題発生中 : Renesys Blogより
世界中で到達不能になっている場所があるのがわかります。
どのように回復したのか?
今回の問題が発生してから1時間も経過せずに問題は収束へと向かいました。 これは、世界中のネットワーク運用者が各自で必死になって対応を行ったためです。 主な対応としては、フィルタによって問題となる経路を遮断するか、AS path長の最大値を手動で設定するというものだったと思われます。
フィルタによる個別対応に加えて、チェコのプロバイダへの連絡も行われていました。 問題発生から数十分以内に世界各地のネットワーク運用者が問題を発生させている組織を突き止め、その組織の連絡先を発見し、運用者へ連絡を取って問題を修正させたことも凄いと思います。
このような事ができるように情報公開が世界的に行われている事と、連絡手段が提供されているという点もインターネットの対障害性を示していると思われます。 ただ、「1時間近くも壊れた」と受け取るか「1時間で復旧出来て凄い」と受け取るかは、人それぞれだとは思います。
ネットワークの運用管理を行う「ネットワーク屋(ただし、インターネット屋の方)」は、会社や組織を超えて様々な人とコミュニケーションを取る人がいる気がします。 周りから見ると、単なるエンジニア同士の「仲良しクラブ」に見えるかも知れませんが、このような時に素早く情報交換をしながら復旧をするには「組織を超えた連携」を日頃から行っている必要があるのだろうと思います。 JANOGやNANOGのように、競合他社と堂々とオンラインで障害情報を交換するというのは通信業界以外では少ないでしょうし、理解できないのかも知れません。 いや、「通信業界」でもあり得なくて、「インターネット業界」か。。。
ネットワークプロトコルを作るときも同様で、様々な実装や、様々なユースケースや、様々なニーズの人が集まって「さあ、皆でプロトコルを作ろう!」というのがIETF(Internet Engineering Task Force)の活動です。
個人的には、このような「自分のためにオープンにすること」や「自分のために交遊すること」が経験的に当たり前になっていくのがネットワークエンジニアの良い所だと感じる事があります。
最後に
以上が、2月17日未明に発生した大規模インターネット通信障害の解説です。 この解説が「インターネットとは何か?」や「ネットワークエンジニアが考えている事」などに対する理解の一助となれば幸いです。
過去に実際に起きた「インターネットが壊れて復旧した」事件を端緒に、「粘り強いが壊れやすく、壊れやすいが粘り強い」という視点でインターネットの形を探るという本を書きました。 インターネットを構成する基礎技術TCP/IPを解説した書籍は非常に多くありましたが、そのTCP/IPを使ってインターネットがどのように運用構築されているのかに関しては、あまり知られていません。本書は「TCP/IPを知っていてもインターネットはわからない、一方でインターネットを知るにはTCP/IPの細かい話を全て知る必要もない」という思想で、教科書的にならずに、あくまで「読み物」として楽しんで頂けることを目標に書いています。 2009年の経路障害は2章で紹介しています。
最近のエントリ
- 「ピアリング戦記」の英訳版EPUBを無料配布します!
- IPv4アドレス移転の売買価格推移および移転組織ランキング100
- 例示用IPv6アドレス 3fff::/20 が新たに追加
- ShowNet 2024のL2L3
- ShowNet 2024 ローカル5G
- ShowNetのローカル5G企画(2022年、2023年)
過去記事