このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
Cloudflareでは、弊社独自のゾンビハンティングでハロウィーンをお祝いしています。削除したいゾンビは、インターネットがトラフィックをルーティングする方法を担当するコアフレームワークであるBGP（ボーダーゲートウェイプロトコル）を妨害するものです。
BGPゾンビとは、インターネットのデフォルトフリーゾーン（DFZ）で立ち行かなくなったルートのことです。DFZとは、デフォルトルートを必要としないすべてのインターネットルーターの集合体であり、潜在的にはプレフィックスの取り消し、または喪失が原因です。
ルーターのソフトウェアのバグから、単に一般的なルート処理の遅さまで、ゾンビの根本原因として複数のものが考えられます。これは、BGPプレフィックスがインターネットから失われることになっているのですが、何らかの理由でアンデマンドのメンバーとなり、一定期間存続するという状況です。
これらのゾンビは、長ければ長いほど、運用への影響が大きくなり、ネットワーク運用者にとっては大きな頭痛の種になります。ゾンビは、ルートループ内にパケットを閉じ込めたり、過度に遠回りなルートを選択させたりすることで、パケットを誤ってリードさせる可能性があります。本日は、ハロウィーンを祝い、BGPゾンビが形成される仕組みと、BGPゾンビがインターネットトラフィックに大打撃を与える可能性を減らす方法について取り上げたいと思います。
BGPゾンビにつながりかねない遅延を理解するには、パスハンティングについて説明する必要があります。パスハンティングは、BGPを実行するルーターが、最長プレフィックス一致（LPM）およびパス長やローカルプリファレンスなどのBGPルーティング属性によって決定された、プレフィックスへの最適なパスを徹底的に検索するときに発生します。これは、経路がどのように、どれくらい長く停滞するのか、そして、インターネット上でどの程度目に見えるのかを観測することに関連しています。
たとえば、パスハンティングは、より具体的なBGPプレフィックスがグローバルルーティングテーブルから削除され、ネットワークはより具体的でないBGPアドバタイズにフォールバックする必要があるときに発生します。この例では、より具体的なBGPアナウンスに2001:db8::/48を使用し、より具体的ではないプレフィックスには2001:db8::/32を使用します。発信元の自律システム（AS）によって/48が撤回されると、BGPルーターはそのルートが欠落していることを認識して、2001:db8::/32ルートを介して2001:db8::1などのIPにトラフィックをルーティングし始めなければなりません。プレフィックス2001:db8::/48はなくなっていますが、
実際にどのような結果につながるのか、いくつかの図を使って見てみましょう。
図1：アクティブな2001:db8::/48ルート
この初期の状態では、2001:db8::/48がトラフィックの転送にアクティブに使用され、AS64511に向かう途中ですべてAS13335を経由します。この場合、AS64511はCloudflareのBYOIP顧客です。AS64511は、別のインターネットサービスプロバイダー（ISP）であるAS64510へのバックアップルートもアナウンスしますが、このルートは、2001:db8::1に転送するためのAS64510のルーティングテーブルでもアクティブではありません。これは、2001:db8::/48がより長いプレフィックス一致であるためです。 2001:db8::/32と比較した場合：
物事がより興味深いものになるのは、2001:db8::/48のAS64510シグナルがCloudflareによって取り消されることです（AS13335）。
お客様が2001:db8::/48のアナウンスを取り消すためにCloudflareに信号を送ると、すべてのBGPルーターがこの更新に収束しなければなりませんが、これにはパスハンティングが含まれます。AS13335は、2001:db8::/48のBGP取り消しメッセージを、直接接続されたBGPネイバーに送信します。廃止のニュースはAS13335から他のネットワークにすばやく広がるかもしれませんが、近隣の一部のネットワークにはより迅速に伝達されることがあります。つまり、すべてのユーザーが取り消しを受信・処理するまで、ネットワークはAS13335が削除した後でも、相互にルーティングして2001:db8::/48プレフィックスに到達する可能性があるのです。
図2：2001:db8::/48 pathさせる（AS13335を介して廃止）
AS64501が残りのASより少し遅っていることを想像してみてください。古いハードウェアの使用、ハードウェアの過負荷、ソフトウェアのバグ、特定の設定設定、不運、またはその他の要因が考えられますが、まだ/48の削除処理がされていません。経路がごくわずかな時間だけ停止するため、これ自体がBGPゾンビである可能性があります。2001:db8::1に向けたpingは、実際にはAS64511に到達できません。AS13335は/48が削除されることを知っているのですが、完全なテーブルを伝送するルーターは、その結果にまだ収束していません。
パスハンティングに費やす時間は、最小ルートアドバタイズ間隔（MRAI）と呼ばれるものによって増幅されます。MRAIは、BGPルーターからのBGPアドバタイズメッセージ間の最小時間を指定します。つまり、各BGPアドバタイズの更新の間に意図的な秒数の遅延を導入するのです。RFC4271では、eBGP更新のMRAI値を30秒にすることを推奨しています。これにより、BGPのチャットを軽減することができ、更新のサイクルを軽減できますが、パスハンティングにも時間がかかります。
次のパスハンティングのサイクルでは、以前AS13335から存在しない/48ルートを指していたAS64501でさえ、/32アドバタイズは2001:db8::1に向けて残されているだけであることを見つける必要があります。これを完了すると、トラフィックフローは次のようになります：
図3：2001:db8::/32 と 2001:db8::/48へのルーティングフォールバックがDFZからなくなっている
これにより、BGPパスハンティングは終わり、インターネットは、2001:db8::/32が2001:db8::1に向けて利用できる最善のルートであることを認識し、2001:db8::/48は本当になくなったことを認識しました。この例では、意図的にパスハンティングを最後の2サイクルだけにしていますが、特にAS13335が世界中の何千ものピアリングネットワークやTier-1に高度に接続している場合、現実にはそれ以上になる可能性があります。
BGPパスハンティングとその仕組みについて説明してきましたが、これでBGPゾンビが大量発生し始める方法や、ルーティングテーブルが長時間にわたって固定される可能性があることがお分かりいただけると思います。以前からのより具体的なプレフィックスを探す過剰なBGPパスハンティングは、ゾンビが追跡する可能性がある初期の指標となり得ます。
ゾンビは最近注目を集めています。一部のお客様は、Magic TransitのBring-Your-Own-IP（BYOIP）オンデマンド広告を利用しているからです。BYOIPは、プレフィックスが継続的に通知される「常時オン」と、顧客が選択した場合にのみプレフィックスが通知される「オンデマンド」の2つのモードで設定できます。一部のオンデマンドのお客様では、アナウンスと取り消しのサイクルがより頻繁に発生するため、BGPゾンビの増加につながる可能性があります。
このことを念頭に、パスハンティングの仕組みを理解したうえで、インターネット上に独自のゾンビを出現しましょう。そのために、IPv4とIPv6の余分なブロックを取り出して、次のようにアナウンスします。
ルートが発表され、安定すると、Cloudflareを介してグローバルにアドバタイズされたより具体的なルートを削除します。数回のクリックで、彼らが死角を作り直すことができました。
バリアントA：トランスフォーメーションゲートウェイズ
ゾンビがよく発生する場所のひとつは、上流のISP間です。あるISPネットワーク内の1つのルーターの更新が少し遅いと、ルートは停止することがあります。
例えば、上流パートナー2社間で観測された次のようなループを考えてみましょう。
7. be2431.ccr31.sjc04.atlas.cogentco.com
8. tisparkle.sjc04.atlas.cogentco.com
9. 213.144.177.184
10. 213.144.177.184
11. 89.221.32.227
12. (waiting for reply)
13. be2749.rcr71.goa01.atlas.cogentco.com
14. be3219.ccr31.mrs02.atlas.cogentco.com
15. be2066.agr21.mrs02.atlas.cogentco.com
16. telecomitalia.mrs02.atlas.cogentco.com
17. 213.144.177.186
18. 89.221.32.227
または、同じ取り消しテストで観察されたこのループは、2つの異なるプロバイダー間で発生します。
15. if-bundle-12-2.qcore2.pvu-paris.as6453.net
16. if-bundle-56-2.qcore1.fr0-frankfurt.as6453.net
17. if-bundle-15-2.qhar1.fr0-frankfurt.as6453.net
18. 195.219.223.11
19. 213.144.177.186
20. 195.22.196.137
21. 213.144.177.186
22. 195.22.196.137
バリアントB：無制限LAN（ローカルエリアネットワーク）
同時に、ゾンビは特定のネットワーク内で発生することもあります。Cloudflareのネットワークからルートが撤回されると、ネットワーク内の各デバイスは、個別にルート削除プロセスを開始する必要があります。これはたいていスムーズなプロセスですが、行き詰まることがあります。
たとえば、ネットワーク内のルーターが、まだ削除を完全に処理していない状況を考えてみましょう。接続パートナーは、（まだ削除を受け取っていないため）そのルーターに向けてトラフィックをルーティングし続けますが、実際にトラフィックを処理できるルーターの背後にあるホストは残りません。結果は、内部専用のループパスです。
10. 192.0.2.112
11. 192.0.2.113
12. 192.0.2.112
13. 192.0.2.113
14. 192.0.2.112
15. 192.0.2.113
16. 192.0.2.112
17. 192.0.2.113
18. 192.0.2.112
19. 192.0.2.113
多くの現実的複数のゾンビとは異なり、当社の高度に可視化されたゾンビは、ほとんどの主要ネットワークで寿命に限りがある。この例ではわずか6分程度で、その後、ほとんどの攻撃者は最も具体的でないネットワークに再コンバージェンスし、パス。残念ながら、これは短い方です。場合によっては、長命なゾンビが10分以上にわたって到達可能な問題を引き起こすこともあります。これは、ほとんどのネットワーク事業者が通常の状況下でBGPコンバージェンスにかかる時間よりも長い時間と言っても過言ではありません。
しかし、これは前述の過剰なパスハンティングなのか、BGPゾンビなのかという疑問もあるでしょう。実際には、BGPコンバージェンスがプレフィックスの削除処理にどれくらいの時間を要すべきかに関する期待と許容度によります。いずれの場合、より具体的なプレフィックスを削除してから30分以上が経過しても、ルートビューのパブリックコレクターでゾンビルートを簡単に確認することができます。
~ % monocle search --start-ts 2025-10-28T12:40:13Z --end-ts 2025-10-28T13:00:13Z --prefix 198.18.0.0/24
A|1761656125.550447|206.82.105.116|54309|198.18.0.0/24|54309 13335 395747|IGP|206.82.104.31|0|0|54309:111|false|||route-views.ny
Tier-1ネットワーク層の最悪の場合、BGPが収束するのには6～11分（あるいはそれ以上）が妥当な時間だと主張するかもしれませんが、それ自体が延長線上にあるように思えます。それを差し置いても、当社のデータからは、ごく本物のBGPゾンビがグローバルルーティングテーブルに存在し、トラフィックに悪影響を及ぼしていることがわかります。興味深いことに、パスハンティングの遅延はIPv4でさらに悪化しており、主要（Tier-1）ネットワークで観測された最長のIPv6への影響は4分強でした。これは、インターネットグローバルルーティングテーブルにあるIPv4プレフィックスの数がIPv6グローバルテーブルよりはるかに多いこと、そして、BGPスピーカーがそれらを別々に処理していることによるものと推測できます。
出典：RIPEstatのBGPlay
遅延の一部は、AS13335の相互接続方法に起因しているようです。インターネットの大半と大量にピアリングされているため、経路が特定の場所で行き詰る可能性が高まります。そう考えると、逆方向で運用すれば、ゾンビは短命に終わるでしょう。具体的でないメッセージを13335に持続的にアナウンスし、通常運用中にローカルISP経由で詳細をアナウンスします。取り消しは、ピアリングが不十分なネットワークから行われるため、コンバージェンスまでの時間がより短縮される可能性があります。
実際、予測したようにルートは行き詰っているのですが、Tier-1ネットワーク層で約20秒しか存在しません。
19. be12488.ccr42.ams03.atlas.cogentco.com
20. 38.88.214.142
21. be2020.ccr41.ams03.atlas.cogentco.com
22. 38.88.214.142
23. (waiting for reply)
24. 38.88.214.142
25. (waiting for reply)
26. 38.88.214.142
残念ながら、その20秒は影響力のある20秒です。良いとはいえ、私たちが望む場所には至っていません。正確な時間は接続しているネイティブISPネットワークによって異なり、ルーティングが停止する数分に相当する可能性があります。
どちらのケースも、最初の発表までの時間で損失は発生せず、ゾンビが作成されることもありませんでした。両方の経路が最初の存続時間中は有効のままであったためです。ゾンビは、より具体的なプレフィックスが完全に取り消された場合にのみ作成されました。新たに発表されたルートは、取り消されたより具体的なルートと同様に、パスハンティングの対象にはなりません。言われるように、良い（新しい）ニュースは速く情報を拡散します。
この調査結果から、より具体的なプレフィックスを削除することで、ゾンビがより長い時間にわたって横ばいする可能性があると考えています。このため、BGPゾンビルーティングがオンデマンドBGP機能に依存しているお客様への影響を軽減するためのいくつかの改善を検討しています。
スタックルートでCloudflareに到達したトラフィックに関しては、たとえルートが誤って弊社を指していても、トラフィックをより安全に撤回できるよう、BGPトラフィックフォワーディングの改善を内部に導入する予定です。これは、BGPを実行しているサーバーが行う、BGPの有名な非エクスポートコミュニティの機能によく似ています。つまり、 ルーティング が停止しているために外部者からのトラフィックを受け取った場合でも、トンネル接続または Cloudflareネットワーク Interconnect（CNI）経由でトラフィックを配信する機会が得られます。デフォルトでトラフィックをさらに際限なく解消できるように、この改善を行った後、プラスの影響をご報告できることを楽しみにしています。
Cloudflareのエッジに到達せず、ネットワークプロバイダー間をループするトラフィックについては、別のアプローチを使用する必要があります。より固有のプレフィックスルーティングフォールバックは、BGPゾンビが発生しやすいことがわかっているため、Cloudflareのエッジからトラフィックを排除してオンデマンドのプレフィックスを確保する場合は、複数ステップのドキュメンテーションプロセスを使用することをお客様にお勧めします。ルートループやブラックホールイベントを導入している可能性があります。CloudflareからBYOIPプレフィックスのトラフィックを削除する際のプロセスは次のようになります：
お客様はすでにCloudflareからプレフィックスの例をアナウンスしており、例：198.18.0.0/24
お客様は、トラフィックをフェイルオーバーしたいインターネットサービスプロバイダーに対して、ネットワークからプレフィックス198.18.0.0/24（Cloudflare経由で知らせるプレフィックスと同じ長さ）をネイティブに広報し始める。
数分後に、お客様が198.18.0.0/24プレフィックスのCloudflareからBGPの取り消しを伝えます。
結果は、刷新され、同じ長さのプレフィックス（198.18.0.0/24）がグローバルルーティングテーブルに残っているため、影響のあるゾンビは回避されます。ルーターは、失われたより具体的なプレフィックス一致を積極的に探す必要はなく、ネイティブに発信されたパスから顧客のネットワークへのルーティングテーブルに永続的な同じ長さのアナウンスにフォールバックできるため、過剰なパスハンティングは回避されます。
出典：RIPEstatのBGPlay
今後、より多くの洞察を得られるよう、BGPゾンビの測定方法の改良を続けていきます。また、ゾンビの測定に関するコミュニティ内の他の人の作業もあり、興味深いもので、有用なデータが生成されています。BGPゾンビの作成に関するソフトウェアバグに対処するために、ルーティングベンダーはRFC9687、BGP SendHoldTimerを実装する必要があります。一般的には、遠側のルーターがBGPメッセージの処理を予期せず停止した場合、ローカルのルーターがSendHoldTimerを介して検出できると考えられます。これにより、ゾンビが長時間にわたって立ち行かなくなる可能性は低くなります。
さらに、この記事で、より具体的なプレフィックスアナウンスと過剰なパスハンティングについて観察したことも念頭に置いておくべきでしょう。ネットワークオペレータとして、フェイルオーバーやトラフィックエンジニアリングのために、より具体的なBGPプレフィックスアナウンスに依存している場合、完全なBGPコンバージェンスが発生する前に、ルートが長時間にわたって停止する可能性があることに注意する必要があります。
BGPゾンビのような問題に興味をお持ちの方は、Cloudflareでの入社やインターンシップへの応募を検討してください。私たちと一緒に、より良いインターネットを構築しましょう！