RouteViews と BGP 可視化を支える基盤

エグゼクティブサマリー

RouteViews はオレゴン大学がホストし、Network Startup Resource Center が運用する測定プロジェクトであり、ボランティアネットワークから BGP 経路を受信し、Routing Information Base のスナップショットと更新メッセージを記録し、そのデータを MRT アーカイブ、ライブストリーム、API、ウェブの Looking Glass を通じて配信する。
このプロジェクトは、Randy Bush と RAINET を通じて提供された初期の MAE-WEST フィードを含む1995年の外部ビュー実験から発展した。David Meyer はオレゴン大学で主要な初期アーキテクトであり、NLANR/MOAT による計画的な日次アーカイブは1997年11月に開始された。
RouteViews のコレクターはルーティングコントロールプレーンを観測するが、通常のエンドユーザートラフィックを運んだり、通常のサービスのプレフィックスポートフォリオを発信したり、他のネットワークの経路を撤回・修復・強制する権限を持たない。その価値は証拠に基づく。すなわち、選択されたアナウンス、撤回、パスを提供された観測点から可視化する。
2026年1月の2025年レビューでは、277のユニークな自律システムから883のフルルートセッション、8つの新コレクター、67TB の RIB および更新ストレージ、API と Looking Glass の拡張、刷新された Kafka 基盤、Bimper BMP プロセッサーの導入が報告された。これらの数字は異なる単位を表しており、単一のコレクター数として扱ってはならない。
RouteViews が不可欠である理由の一つは、そのアーカイブが事後的に再作成できないことにある。また、設計上不完全でもある。BGP ピアはポリシーで選択された経路、通常はベストパスのみをエクスポートし、ボランティアの観測点セットには地理的、トポロジー的、ネットワークタイプの偏り、冗長性、セッションアーティファクト、運用ノイズが含まれる。
このプロジェクトの長期的な問いは、自由にアクセスでき、機関がホストし、一部寄贈された可観測性レイヤーが、ルーティングテーブル、商用利用、ほぼリアルタイムのアクセス需要が増大し続ける中で、ストレージ、ソフトウェア、人員、複製、ガバナンスを拡張できるかどうかである。

インターネットは一箇所から全体を見ることができない

インターネットはしばしば一つのグローバルなネットワークとして説明されるが、実際には独立して制御される数千のネットワークとして運用されている。各自律システムは、独自のルーター、内部トポロジー、相互接続契約、エクスポートポリシー、運用目標を管理している。ボーダーゲートウェイプロトコルはこれらのシステムが到達可能性情報を交換することを可能にするが、普遍的なコントロールルームを作り出すわけではない。事業者は自身のルーターが受信する経路と、自身のポリシーの下で選択された経路を見ることができる。しかし、遠く離れたネットワークが発信するプレフィックスをどのように伝搬しているか、ベストパス選択によって隠された代替経路は何か、あるいは他の事業者が何をエクスポートしないことを選択したかを自動的に見ることはできない。

この完全なビューの欠如は、十分に強力なダッシュボードを待つ一時的な失敗ではない。それはアーキテクチャに起因する。BGP は管理境界を越えて部分的な情報を配信する。ネットワークは自らのポリシーが許容するものを開示し、その結果生じるコントロールプレーンの状態は場所によって異なる。ある経路はある地域では可視であり、別の地域では抑制され、あるプロバイダー経由で優先され、別の場所ではより具体的なアナウンスによって置き換えられるかもしれない。二つのルーターが同じプレフィックスを受信しても、商用関係とローカル設定が異なるために異なるパスを選択するかもしれない。

RouteViews はその構造的な隙間に存在する。世界中にとってどの経路が正しいかを決定する権威になろうとはしない。それはより狭い運用上の問いを立てる。つまり、ある特定の時点で、ある特定のコレクターに対して、寄与するネットワークがどのようなルーティング情報をエクスポートしたか、である。そのような多数の回答を収集し、保存し、再利用可能にすることによって、RouteViews は、単一の所有者も包括的なネイティブメモリも持たないシステムのために、公共の観測レイヤーを創出する。

観測と制御の区別がプロジェクトの基盤である。RouteViews のコレクターは BGP セッションに参加するが、通常のトランジットプロバイダーのようには振る舞わない。ピアから経路を受信し、記録する。AS6447 の PeeringDB プロファイルは、発信 IPv4 および IPv6 プレフィックスがゼロで、トラフィックが低く、主に着信であることを報告しており、この受動的な役割と一致している。RouteViews は通常、データを提供するネットワークに通常の経路を送り返さない。したがって、優先パスを公開してインターネットをリダイレクトしたり、別の自律システムのポリシーを編集してリークを修復したり、正当な所有者の代わりにハイジャックされた経路を撤回したりすることはできない。

その制限こそが、プロジェクトを分析的に誠実なものとしている。証拠は、予期しない起点が現れたこと、パスが変化したこと、より具体的なアナウンスが広がったこと、複数の観測点から経路が消えたことを示すことができる。証拠自体は、パケットが辿った物理的な経路、二つのネットワーク間の商用契約、あるいは変更の背後にある意図を証明するものではない。RouteViews はルーティングの振る舞いをより可観測にする。事業者、研究者、セキュリティシステムは、その振る舞いを解釈し、それをローカルのログ、RPKI データ、データプレーンの計測、直接の通信と組み合わせなければならない。

これは出力が運送ではなく知識である基盤の一形態である。コレクターは稼働中のルーティングシステムに接続され、アーカイブはその変化を記録し、アクセスサービスはそれらの記録を配信する。このプロジェクトが重要である理由は、どの参加者も単独では調査できないシステムに関する証拠に、重要な運用上の決定が依存するからである。その貢献はルーティングに対する主権的な命令ではない。それは、自身を理解しようとしているネットワークの外部から、ルーティング現実の選択された部分を観察するための持続的な方法である。

一つの MAE-WEST ビューから公共ユーティリティへ

RouteViews は1995年に始まった。当時は、公開ウェブベースのルッキンググラスがまだネットワーク運用の日常的な一部ではなかった。当初の問題は実践的だった。ネットワークはプレフィックスを発信し、自社のルーターが正しく設定されていることを確認できたが、他の場所のプロバイダーがそのアナウンスをどのように見ているかについては不確かなままだった。発信元のネットワーク内部からのトラブルシューティングでは、外部の疑問に答えることはできなかった。事業者は自身の管理境界の外からのビューを必要としていた。

プロジェクトの歴史資料は、初期の外部フィードが MAE-WEST にあったとしている。MAE-WEST は当時の重要な相互接続環境の一つである。Randy Bush が RAINET を通じてビューを提供した。David Meyer の後の一人称の記述は、オレゴン大学で eBGP マルチホップセッションを受信し、利用が拡大するにつれてピア、研究者、システムを追加していったことを記している。証拠は Meyer を主要な初期アーキテクト兼運用者として支持するが、起源を単一の創設者の物語に還元することは支持しない。Bush のフィード、オレゴン大学の Advanced Network Technology Center、そして追加のビューを自発的に提供した事業者たちは、すべてシステムの創造の一部であった。

当初のサービスホスト名である route-views.oregon-ix.net は、その限定的な初期目的を反映していた。ユーザーはルーターに接続し、設定権限を与えられたりトランジット顧客になることなく、外部で学習された BGP 情報を調査することができた。その価値は役割の分離にあった。寄与するネットワークがビューを提供し、オレゴン大学がアクセスをホストし、問い合わせを行う事業者が視点を得た。ビューが有用であるために、中央機関が経路を認証する必要はなかった。

利用は強化するサイクルを生み出した。事業者は外部視点が価値あるものだと感じた。そのためより多くのネットワークがフィードを提供するようになった。追加のフィードは、プロバイダーや場所ごとの違いを露呈させることでツールをより有用にした。その後、研究者は、繰り返しの観測が即時のトラブルシューティングを超えた疑問に答えられることを認識した。ライブテーブルは、あるネットワークが一つの瞬間にどう世界を見ているかを示すことができた。一連のテーブルは、成長、ポリシーの変化、不安定性、時間の経過に伴う障害への応答を明らかにすることができた。

したがって、このプロジェクトは明確な設立時の境界なしに、サービスからユーティリティへと移行した。定義された製品ロードマップ、専任スタッフ、分散アーキテクチャを持つ完全なグローバル測定プラットフォームとして立ち上げられたわけではない。ユーザーが以前の形態の限界を暴露し続けたために、それらの特性を蓄積していった。この歴史が重要なのは、それが今日でも見える制度的性格を説明するからである。RouteViews は、本番サービス、学術データセット、事業者間の協力、そして公共基盤への依存が同時に存在するものである。

そのハイブリッドなアイデンティティは、なぜこのプロジェクトが独立した企業として説明されるべきでないかも説明している。現在の記録は、オレゴン大学の内部にあり、運用上は Network Startup Resource Center の内部にあるとしている。その公開インターフェースは、名称、ASN、DOI、ソフトウェアリポジトリ、ピアリングポリシーを持つが、独立して検証された法的実体、株主、収益計算書、あるいは独立した理事会は持たない。このプロジェクトの権威は、コレクターを運用し、データを維持し、継続的な参加を得ることから生まれるのであり、観測する経路の企業的所有からではない。

したがって、創業の物語は、英雄的な伝記として扱うよりも、基盤のメカニズムとして扱う方がより示唆的である。あるネットワーク事業者が有用なビューを提供した。大学のチームがそのビューを安全に公開した。さらに多くのネットワークが自発的に参加した。ユーザーが需要を生み出した。アーカイブ化は一過性の状態を再利用可能な証拠へと変えた。各ステップは、人々がルーターを設定し、システムを運営し、出力を利用したために現実のものとなった。RouteViews をあらかじめ重要にした宣言はなかった。重要性は、繰り返される運用上の依存から生まれた。

ライブルッキンググラスがどのように歴史的アーカイブになったか

ライブビューは現在のトラブルシューティング問題を解決できるが、誰かが記録していなければ、昨日のルーティングシステムがどのように見えたかを答えることはできない。NLANR/MOAT は1997年11月に RouteViews の出力の計画的な日次アーカイブを開始した。この行為はプロジェクトの性質を変えた。サービスはもはや事業者が現在の状態を調査できる場所だけではなくなった。それはインターネットの変化し続けるコントロールプレーンの記憶となった。

最も初期のアーカイブは、日次のコマンド出力ダンプで構成されていた。これらのファイルは、そうでなければ消えてしまう情報を保存していたために価値があったが、その周期とフォーマットは再構成できる内容を制限した。経路は、二つの日次スナップショットの間にアナウンスされ、変化し、撤回され、いずれにも現れない可能性があった。ルーターのコマンドラインから抽出されたテキストは、プロトコルの状態を表現するために設計されたバイナリ記録よりも、標準化されたプログラム的な分析には不向きであった。

2001年3月、RouteViews はテーブル収集の周期を2時間に増やした。この間隔は、現在のプロジェクトの Routing Information Base アーカイブと関連付けられたままである。RIB スナップショットは状態に関する問いに答える。つまり、このコレクターはスナップショット時点でどの経路を保持していたか？それ自体は、スナップショットの前後に発生したすべての変化を説明するものではない。そのためには、アナリストは更新ストリームーースナップショットの間の状態の間に観測されたアナウンス、撤回、属性変更ーーを必要とする。

ローカル MRT 記録への移行は、したがって、単純なファイル頻度の増加以上に重要であった。MRT は、ルーティングメッセージ、ピア情報、状態変化、RIB コンテンツのための機械可読な構造を提供する。コレクターは、到着する更新を記録し、多数のリモートユーザーが show コマンドを実行することに依存せずに、定期的にテーブル状態をエクスポートすることができる。結果として得られるファイルは、BGPStream、BGPKIT、bgpdump、カスタム研究ソフトウェアなどのツールによって解析され得る。

このアーキテクチャは、共通の分析ワークフローを可能にした。研究者は RIB スナップショットをロードして初期状態を確立し、その後、後続の更新を適用して、その状態がどのように変化したかを再構成する。この方法は、起点変化、パス変化、撤回、ディスアグリゲーション、イベント伝搬の研究をサポートする。また、データの完全性の重要性も露呈させる。失われた更新ファイル、中断されたセッション、パーサーエラー、またはコレクターの停止は、再構成された状態とピアが実際にエクスポートしたものとの間にギャップを生み出し得る。

長年のアーカイブは、RouteViews の最も強力な資産の一つである。なぜなら、歴史的なコントロールプレーンの証拠は更新不可能だからである。新しいコレクターは明日から観測を開始できるが、1998年、2008年、2018年に決して記録されなかったパスアナウンスを再創出することはできない。アーカイブは、研究者がテーブルの成長、IPv6 の採用、自律システムの出現と消失、変化するパス構造、そして数十年にわたる主要なインシデントのルーティングへの影響を調査することを可能にする。

しかしながら、「1997年以来継続」は、プログラムの継続性として解釈されなければならず、すべてのコレクター、ピア、ファイルが中断なく存在してきたという保証ではない。分散システムは、メンテナンス、リセット、ネットワーク障害、欠落した間隔を経験する。最も初期のアーカイブも、フォーマット、頻度、地理的カバレッジにおいて、現在の収集とは物質的に異なる。データの責任ある利用は、アーカイブ全体を一つの均一な器具として扱うのではなく、関連するコレクターと期間を特定する。

したがって、アーカイブの価値は、深さと文書化された限界の両方から来る。それは観測の記録であり、完全な歴史的真実ではない。それは、参加したルーターが、当時の運用条件下で利用可能なコレクターに対してエクスポートしたものを保存する。それは、主要な科学的および運用上の作業を支えるのに十分であるが、利用者が長い記録を全知のものと混同しないことを条件とする。

分布が戦略になる前に中央集権は失敗した

当初の RouteViews モデルは、多くのフィードとユーザーを中央のルーターに集中させた。2000年半ばまでに、Cisco 7200VXR が50以上のマルチホップ BGP セッションと、一日あたり約5,000のインタラクティブなログインを処理していた。システムは、それを創り出したアーキテクチャを超えるほど有用になっていた。CPU、メモリ、セッションの安定性、コマンドラインアクセスが、一つの運用面上で競合していた。

最初の対応には、新しいソフトウェアが含まれた。RouteViews は2001年10月に、Linux 上の Zebra BGPD を使用して route-views2 を立ち上げた。汎用システムとオープンソースルーティングへの移行は、戦略的に重要だった。なぜなら、コレクターはトラフィックを運ぶコアルーターの完全な転送ハードウェアを必要としないからである。信頼できる BGP 実装、ルーティングテーブルを保持するのに十分なメモリ、状態を記録するメカニズムが必要である。ソフトウェアルーティングは、より低コストで、より高い自動化の可能性を提供した。

初期の Zebra はすぐには問題を解決しなかった。歴史資料は、約60のピアを処理するのに困難があったことを記録している。この教訓は、現代の基盤分析にとって重要である。プロプライエタリハードウェアをオープンソフトウェアに置き換えることは、自動的にキャパシティアップグレードになるわけではない。本番ルーティングは、実装の成熟度、メモリ挙動、プロトコルの正確性、可観測性、障害回復に依存する。RouteViews は、ソフトウェアパスが発展する間、ハードウェアを保持し、改善した。

より持続的な対応は、アーキテクチャの分離であった。MRT 記録は、インタラクティブな CLI スクレイピングへの依存を減らした。複数のコレクターは、一つのシステムへの依存を減らした。専用のアーカイブと処理レイヤーは、ユーザーアクセスをプロトコル収集から分離した。それぞれの分離は、一つのルーターがピアにサービスし、データをアーカイブし、何千もの人間および自動化されたクエリを同時に満たすことを許すのではなく、そのワークロードのために設計されたコンポーネントに責任を割り当てた。

中央マルチホップモデルは、概念的な弱点も持っていた。オレゴンのコレクターへのピアの BGP セッションは、そのプロジェクトが観測しようとしているのと同じ公衆インターネットに依存する可能性がある。もしイベントがピアとコレクターの間の到達可能性を妨害した場合、セッションは消え、経路が変化したのか、ピアが故障したのか、それとも測定システムへのパスが壊れたのかについての曖昧さが残る。地理的な距離はまた、遠くのプロバイダーを通じて決して伝搬しないかもしれないローカルな相互接続の可視性も制限した。

したがって、分布は、スケーリングと測定の両方の要件として浮上した。プロジェクトは、データを提供するネットワークにより近いコレクターを必要とした。特に、多くの自律システムがローカル BGP セッションを確立できるインターネットエクスチェンジでは。地域のコレクターは、すべての寄与がオレゴンへの長いマルチホップパスを横断することを要求することなく、エクスチェンジのルートサーバーとバイラテラルピアを観測できた。

この移行は、繰り返し現れる基盤パターンの初期の例である。中央ツールはアクセスを簡素化するために人気を博す。成長は、その後、ワークロード、障害、解釈の集中を露呈させる。解決策は、中央の価値を否定することではなく、収集、ストレージ、アクセスを分割し、中央がシステムそのものを体現しているふりをするのではなく、分散システムを調整することである。

なぜプロジェクトはインターネットエクスチェンジファブリックに移行したのか

RouteViews は2003年5月に IPv6 フィードの受け入れを開始し、同年7月に WIDE プロジェクトの支援を受けて東京の DIX-IE に最初の文書化されたインターネットエクスチェンジコレクターを展開した。コレクターは、2003年10月に ISC/PAIX、2004年3月にロンドンの LINX、2004年5月に Equinix Ashburn に続いた。これらの展開は、現在プラットフォームの多くを定義するモデルを生み出した。すなわち、エクスチェンジファブリックに直接接続され、そこに存在するネットワークからローカル eBGP セッションを受信する RouteViews コレクターである。

IXP コレクターにはいくつかの利点がある。BGP アジャセンシーは、公衆インターネットを介したマルチホップセッションではなく、共有されたローカルファブリックを介して確立され得る。コレクターは、ある一つのサイトに既に集中している複数のネットワークを勧誘できる。また、多くの参加者からの経路を代表し得るエクスチェンジルートサーバーからフィードを受信できる。また、グローバルなトランジットプロバイダーを介しては可視でないローカルまたは地域の相互接続を観測できる。

この利点は、魔法のようなものではなく情報上のものである。エクスチェンジにあるコレクターも、そのピアがエクスポートするものしか見ることができない。ネットワークは、完全なテーブル、選択されたカスタマー経路、ローカル経路、あるいはより限定されたビューを送るかもしれない。ルートサーバーフィードは、そのサーバーのポリシーとメンバーシップを表し、エクスチェンジでのすべてのバイラテラルな関係ではない。IXP に物理的に存在することは、RouteViews をエクスチェンジの運営者や接続されたネットワークの所有者にするわけではない。

分散モデルはまた、ホストに依存する。RouteViews は通常、エクスチェンジやネットワークに、仮想マシンまたはサーバー、エクスチェンジポート、トランジットまたは管理接続、電源、冷却、およびローカル支援の提供を依頼する。中央チームは、構成、自動化、統合、運用サポートを提供する。この取り決めは、RouteViews がすべての地域に企業所有の施設を建設することなく、グローバルな展開を経済的に可能にする。

現物提供モデルは、特定の依存関係を生み出す。ホストが優先度を変更したり、ポートを削除したり、トランジットの提供を停止したり、仮想マシンを退役させたりすると、コレクターは消滅し得る。ハードウェア、ハイパーバイザー、ローカルネットワーク環境は多様であり得る。したがって、中央の自動化は、オレゴン大学によって完全には所有されておらず、物理的に制御されてもいない基盤の全体にわたって、一貫した振る舞いを生み出さなければならない。

最近の拡張は、なぜエクスチェンジへの配置が戦略的に重要なままなのかを示している。2025年、RouteViews は、コスタリカ、フィリピン、香港、インドネシア、ルーマニア、ナイジェリア、スウェーデン、デンマークにコレクターを追加した。場所には、CRIX、マニラ・セブ・ダバオの GetaFIX サイト、HKIX、ジャカルタの IIX、ブカレストの InterLAN、ラゴスの IXPN、ストックホルムとコペンハーゲンの Netnod サイトが含まれる。NSRC は、2026年2月にフランクフルトの DE-CIX に新しいコレクターを報告した。

これらの追加は、単に世界地図上の点ではない。それらはインターネットトポロジーの変化に対応している。大規模なコンテンツプラットフォーム、CDN、地域ネットワークは、ますますローカルでトラフィックを交換するようになっている。階層的なトランジット経路のみを見るコレクターは、エッジ近くに留まる関係性やポリシーを見逃す可能性がある。RouteViews の2025年の選択的ピアリングポリシーは、追加のセッションすべてを等しく価値あるものとして扱うのではなく、独特の可視性を追加する地域やネットワークを明示的に優先する。

このプロジェクトがマルチホップコレクターも運用し続けるのは、有用なピアがすべて AS6447 と IXP を共有しているわけではないからである。二つのモデルは異なる目的を果たす。ローカル IXP セッションは地域とエクスチェンジの可視性を改善する。マルチホップセッションは、他の場所の主要なバックボーン、研究ネットワーク、専門の事業者への参加を拡張する。完全な戦略は両方を必要とし、同時にそれぞれのパス依存性と解釈上の限界を認識する。

RouteViews コレクターが実際に記録するもの

RouteViews のピアは BGP セッションを確立し、自身のポリシーとプロジェクトのピアリング要件に従って経路をエクスポートする。コレクターは、それらの経路を BGP ルーティング情報ベースに受信する。テーブルの状態と変更を記録するが、それらの経路に対して通常の転送の役割は持たない。コレクターがパスを学習したからといって、一般のユーザーからのパケットがコレクターを通じて送られることはない。

「ルート」という言葉は、いくつかの種類の情報を隠す可能性がある。あるプレフィックスについて、BGP レコードは、起点の自律システム、AS パス、ネクストホップ情報、コミュニティ、その他の属性を含み得る。更新は、アナウンス、撤回、または変更を記録する。コレクターは、メッセージをピアと時刻に関連付ける。アナリストはその後、異なるピアが何をエクスポートしたか、可視性がどのように変化したかを比較できる。

レコードは、基礎となる基盤に関するすべての事実を明らかにするわけではない。AS パスは物理的なファイバーマップではない。各自律システム内のすべてのルーターを示したり、横断する施設を特定したりはしない。リンクの容量、トラフィック量、商用契約の条件を開示しない。パスは、到達可能性を選択するために使用されるコントロールプレーン情報を表し、BGP 属性はポリシーによって変換され得る。

フルルートとすべてのパスの区別は特に重要である。RouteViews は、完全なルーティングビュー、すなわち、最もグローバルに到達可能なプレフィックスをカバーする経路を送信するピアを好む。標準的な BGP エクスポートは通常、各プレフィックスについて選択されたベストパスを送信し、内部で知られているすべての代替経路ではない。RouteViews は現在のポリシーの下では Add-Path を受け付けない。したがって、フルルートフィードは、ピアの完全な内部決定セットを露出することなく、プレフィックスとトポロジーのカバレッジを改善する。

ルートサーバーセッションは別の層を導入する。エクスチェンジでは、ルートサーバーは多くの参加者から経路を受信し、自身のポリシーの下で再配信する。そのサーバーへの単一の RouteViews セッションは、多くのネットワークからローカル経路を明らかにできる。それでもセッションのピアはルートサーバーであり、表現されたパスは他の場所で発信されている。アナリストは、データ内の ASN の存在を、RouteViews との直接の商用関係、あるいはエクスチェンジでのバイラテラルピアリング契約の証拠として解釈してはならない。

これが、RouteViews の現代の内部ツールが、バイラテラルとルートサーバーの観測を区別する理由である。選択的ポリシーの下では、プロジェクトは、既存のルートサーバーフィードを超える意味のある情報を追加しないバイラテラルセッションを断ることがある。目的は可能な限り最大のアジャセンシー数ではない。それは、運用コストを正当化するのに十分な多様性、安定性、地域的価値を持つ、有用な視点のセットである。

コレクターの受動性はまた、セキュリティ境界を定義する。RouteViews は、予期しない起点を持つ経路がピアから可視であったことを示すことができる。より具体的なアナウンスや、無効な経路の拡散を、RPKI データと組み合わせたときに露呈させることができる。経路が別のネットワークから削除されなければならないと決定することはできない。強制は、フィルター、経路起点検証、プレフィックス制限、インシデント手順を適用する事業者にローカルなままである。

結果として得られるデータセットは、稼働中の現実に近いが、慎重に境界づけられているために強力である。本番ネットワークからのプロトコルメッセージを記録する。それは、契約上の真実のレジストリでも、ユーザートラフィックのパケットトレースでも、中央のルーティングオラクルでもない。すべての有効な分析は、その境界を尊重することから始まる。

コレクター、セッション、自律システム、観測点は交換可能ではない

RouteViews の現在の規模は、しばしば異なる問いに答えるいくつかの数字によって表現される。2026年1月の運用レビューは、277のユニークな自律システムからフルルートを受信する883のセッションを報告した。2026年2月のプレゼンテーションは、40以上のコレクターのネットワークを説明したが、一部のスライドは2025年5月の更新日付を持っていた。PeeringDB は、2026年7月29日時点で AS6447 の26の公開エクスチェンジ接続をリストしていた。これらの数字はすべて真実であり得る。なぜなら、それらはプラットフォームの異なる層を説明しているからである。

コレクターは、BGP セッションを受信するルーターまたはルーティングソフトウェアインスタンスである。セッションは、ピアアドレスとコレクターの間の一つのアジャセンシーである。一つの自律システムが、複数の場所で、IPv4 と IPv6 を介して、あるいはルートサーバーとバイラテラルの両方の関係を通じて、複数のセッションを提供し得る。観測点は、セッションまたは寄与するルーターによって生成される観測的視点である。エクスチェンジ接続は、特定のファブリック上での AS6447 のプレゼンスである。これらの単位はどれも相互に一対一でマッピングされない。

この区別は分析上の独立性にとって重要である。異なるエクスチェンジでの同じ ASN からの二つのセッションは、真に異なるポリシーとパスを明らかにする可能性がある。それらはまた、非常に冗長であるかもしれない。ルートサーバーセッションは、何百もの参加者の起点を露出し得るが、依然として一つのエクスチェンジポリシーのコンテキストを表す。多くのピアを持つコレクターは広範なローカル画像を生成できる一方、一風変わったピアを一つだけ持つコレクターは、特定の研究課題にとってより多くのユニークな情報を提供するかもしれない。

したがって、RouteViews の2025年におけるフルルートセッションの報告された20%の成長は、グローバルな可視性の20%の改善と翻訳されるべきではない。50以上の既存のピアが、フルルートを送信するためにエクスポートポリシーを変更し、28の新しいフルルートピアが追加された。これは使用可能なテーブルデータの量を増加させるが、増分価値は、それらのピアがどこに存在し、何をエクスポートし、どのパスが既に他の場所で可視であるかに依存する。

「最も価値ある点」問題に関する研究は、このタスク依存性を明示的にしている。ハイジャック検出を改善する観測点は、AS 関係推論に最も貢献するものと同じではないかもしれない。ピアをランダムに削除したりサンプリングしたりすることは、不均衡な方法で精度を低下させ得る。したがって、プロジェクトの選択的ポリシーは、フィードを数えることから、各フィードが何を追加するかを評価することへの移行である。

正確な日付が揃った現在のコレクターの在庫は、公開記録には見つからなかった。40以上という数字、8つの追加、26の PeeringDB エクスチェンジ接続は、作られた合計に組み合わせられるべきではない。これは小さな報告の問題ではない。運用状況、場所、セッションタイプ、アーカイブの連続性を含む公開在庫があれば、利用者は特定の分析に利用可能な視点を理解することができるだろう。

しかし、これらの規模の数字は、正しく使用されれば意味がある。それらは RouteViews がもはや単一の大学のルーターではないことを示している。それは、何百ものフルルートセッション、何百もの寄与する ASN、数十のコレクター、地域にわたるエクスチェンジプレゼンスを持つ分散システムである。分析上の規律は、すべての数字に付随する単位を保持することである。

RIB スナップショット、更新ストリーム、ルーティング状態の再構成

RouteViews のアーカイブは、二つの補完的な証拠の形式を中心に構築されている。RIB スナップショットは、ある特定の時点でコレクターが保持する経路を記録する。更新ファイルは、スナップショットの間に観測されたアナウンスと撤回を記録する。現在の文書は、2時間の RIB 周期と、15分間隔にグループ化された更新ファイルを説明している。

これらの間隔は、パッケージングの慣習であり、すべてのイベントがそれらの境界で発生するという保証ではない。BGP 更新は継続的に到着する。コレクターは配信のためにそれらをグループ化する。RIB エクスポートも、特にテーブルが成長するにつれて、生成に時間がかかり得る。アナリストは、各ファイル名を完全な瞬間のサンプルとして扱うのではなく、タイムスタンプ、コレクターの振る舞い、ファイルの完全性を理解する必要がある。

状態の再構成は、通常、RIB から始まり、その後の更新を順番に適用する。これにより、アナリストは、あるプレフィックスの起点が変化したか、アナウンスがどのように伝搬したか、あるいは撤回がどのくらいの間可視のままであったかを問うことができる。この方法はまた、コレクターのイベントがインターネットのイベントと誤認され得るかを明らかにする。

BGP セッションリセットは典型的な例である。セッションが再確立されると、ピアは再び自身のテーブルを転送するかもしれない。その結果生じる更新のバーストは、基礎となるグローバルトポロジーが同じようには変化しなかったとしても、広範なルーティング変更のように見える可能性がある。ルーティングテーブル転送を識別する研究は、明示的なセッションログが不完全な場合にこれらのパターンを区別する方法を発展させてきた。

黙ってデータの送信を停止するピアは、別の問題を提示する。コレクターは稼働し続けるかもしれないが、一つの観測点が陳腐化するか欠落する。ファイルは存在しても、期待よりも少ない情報を含み得る。逆に、ピアは、フラッピング、属性変更、ディスアグリゲーション、ソフトウェアの欠陥、または繰り返されるテーブルの再転送を通じて、極端な量の更新を生成する可能性がある。

これらの振る舞いは、忠実度とフィルタリングの間の未解決の選択を生み出す。観測されたメッセージをすべて保存することは、不安定性と設定ミスの証拠を保持する。それはまた、ストレージ、処理負荷、そして単純な分析が反復的なノイズを意味のあるインターネット全体の変化として数えるリスクも増加させる。ノイズをフィルタリングすることは、別の研究者が研究したいと思うまさにその証拠を削除しながら、使い勝手を改善し得る。

RouteViews の2025年レビューは、ピアごとの影響を監視し、プラットフォームの安定性を脅かすセッションを無効化する能力について説明した。それは必要な運用制御であるが、ガバナンスと文書化の問いを導入する。すなわち、フィードはいつ価値ある証拠であることをやめ、容認できない基盤リスクになるのか？普遍的な公開ルールは、その判断を排除できない。なぜなら、答えは量、原因、分析上の価値、サービスの健全性に依存するからである。

したがって、プロジェクトの価値は、メッセージを収集する以上のものにかかっている。それは、十分なメタデータの記録、セッションの健全性の監視、ファイルの保存、変更の文書化、そして利用者がルーティングイベントを測定アーティファクトから区別するのを助けることにかかっている。アーカイブは器具である。他のどの器具とも同様に、それは校正され、解釈されなければならない。

現代のバックエンド： FRRouting、BMP、Bimper、Kafka

RouteViews の歴史的アイデンティティは MRT ファイルと直接のルーターアクセスに結びついているが、現在のプラットフォームはより広範なソフトウェアとストリーミングアーキテクチャを含む。2026年のプレゼンテーションでは、標準のコレクターオペレーティングシステムとして Ubuntu Server 24.04が、ソフトウェアコレクター上では FRRouting 10.5が説明され、一台の Cisco ASR1004 が保持されつつ、物理アプライアンスから仮想マシンへの移行が続けられている。

ソフトウェアコレクターへの移行は、運用モデルを変える。標準的な仮想マシンは、エクスチェンジやネットワークによって、より専門的でないハードウェアでホストされることができ、設定はサイト間で自動化され得る。RouteViews の公開されたホスト仕様は、少なくとも16GB、望ましくは32GB のメモリ、4つの仮想 CPU、100GB のストレージ、管理またはトランジットインターフェース、およびエクスチェンジに面したインターフェースを要求する。これらの要件は、中央アーカイブやストリーム処理の領域ではなく、収集ノードを説明する。

コレクターは、歴史的アーカイブのための MRT ファイルを生成し、BGP Monitoring Protocol を介して BGP 状態をエクスポートすることもできる。BMP は、監視システムを経路選択の参加者にすることなく、ルーターからルーティング情報を露出するように設計されている。RouteViews のアーキテクチャでは、Bimper がコレクターから BMP レコードを受信し、互換性のある生メッセージを Kafka に転送し、Prometheus を介して運用メトリクスをエクスポートする。bimperctl ツールは、スタッフが接続とサービス状態を調査することを可能にする。

Bimper は、OpenBMPd が RouteViews の負荷の下で安定性の問題に遭遇したために開発された。この詳細は、それが RouteViews を、単に既存のツールの利用者ではなく、ソフトウェア基盤の運用者として示すために重要である。プロジェクトは、ライブデータパスに本番のボトルネックを抱え、自身のスケールと可観測性の要件を処理することを意図したコンポーネントを構築した。

Kafka は、収集と消費者の間の配信層を提供する。そのような層なしには、すべての下流システムがコレクターに直接問い合わせるか、個別のセッション処理ロジックを維持するかもしれない。ストリームプラットフォームは、ファンアウト、バックプレッシャー、消費者の独立性をより効率的に処理できるが、それは自身の信頼性、順序付け、保持、運用上の依存関係を生み出す。

アーカイブとライブストリームは、異なるニーズに応える。歴史的研究は、完全性、再現性、新しい方法で期間を再処理する能力を重視する。ライブモニタリングは、低遅延と継続的な配信を重視する。ストリームは再接続し不完全に再開できる。アーカイブは後から到着し得るが、安定したファイルを保存する。RouteViews は両方を必要とする。なぜなら、運用上の利用者と研究者は、同じ基礎となる観測に対して異なる問いを投げかけるからである。

このバックエンドはまた、監視の重要性を増大させる。コレクターは健全でありながら、その BMP 接続が故障するかもしれない。Kafka はデータを受け入れながら、消費者が遅れるかもしれない。MRT ファイルは書き込まれながら、ライブストリームが遅延するかもしれない。Prometheus メトリクスとサービス制御ツールは、これらの内部状態を、プラットフォームを維持しなければならない運用者に可視にする。プロジェクトの核心的な産出物は可観測性であり、したがって、その自身の基盤も同様に可観測でなければならない。

API と Looking Glass がユーザーをコレクターから分離する

RouteViews が管理可能な数の人間の運用者にサービスしていたとき、直接の telnet アクセスは適切だった。時が経つにつれ、自動化されたスクリプトがコレクターインターフェースに対して何千ものコマンドを発行し始めた。BGP セッションを維持し経路を記録するために設計されたルーターが、制限のないクエリエンジンになった。結果は、アクセス層において元の中央ルーター問題を繰り返した。有益な開放性が、データを提供するシステムを脅かす負荷を生み出したのである。

RouteViews は、ブラウザベースの Looking Glass と構造化された API を構築することで対応した。Looking Glass は2025年5月に立ち上げられ、選択されたノードから一般的なプレフィックス、パス表現、サマリー、RPKI 指向のクエリをサポートする。立ち上げ時点では、そのバックエンドは依然としてウェブリクエストを telnet インターフェースを通じて実行されるコマンドに変換していた。意図された方向性は、カバレッジが拡大するにつれて、より多くのクエリを API に移行することだった。

API は現在、10のコレクターをカバーしている。アムステルダムの AMS-IX、ロンドンの LINX、ヨハネスブルグの NAPAfrica、シンガポールの Equinix SG1、シドニーの Equinix SYD1、サンパウロの IX.br、そしてオレゴン大学の4つのマルチホップコレクターである。コレクターのメタデータ、RIB 情報、ピア情報、隣接 AS 情報、指定されたセッションから学習されたプレフィックスを露出する。メタデータは2分ごとにリフレッシュされる。

API は、深い歴史的研究ではなく、現在のデータのために明示的に設計されている。その分離は、よくある製品の間違いを防ぐ。現在のクエリサービスと数十年にわたるバルクアーカイブは、異なるインデックス付け、ストレージ、コスト構造を持つ。一つのインターフェースに両方の役割を果たさせようとすることは、それぞれを劣化させ得る。RouteViews は縦断的分析を MRT ファイルに向けつつ、頻繁な現在状態の問い合わせに対して構造化されたアクセスを提供する。

API は内部運用もサポートする。RouteViews は、見込みピアの発信プレフィックス、既存のバイラテラルとルートサーバーの観測、地域への貢献、コレクターのカバレッジを比較するツールを開発してきた。一部のツールは、コレクター設定を生成または修正し得る。これは手作業とエラーを減らすが、正確な PeeringDB レコードと安全な自動化への新たな依存を生み出す。

Looking Glass と API は、直接の CLI アクセスではできない方法でワークロードを制約する。クエリタイプを制限し、繰り返される応答をキャッシュし、認証やレート制御を適用し、構造化された結果を返すことができる。また、MRT ファイルを解析したりルーターのコマンド構文を学びたくない利用者にとって、アクセスを容易にする。

2026年7月のカットオフ時点では、移行は不完全だった。API カバレッジはプラットフォームのサブセットを表し、Looking Glass はまだレガシーインターフェースに部分的に依存していた。あまりにも早く telnet を廃止することは、数十年にわたって構築されたスクリプトやワークフローを壊す可能性がある。無期限に保持することは、近代化が解決しようとしている負荷とセキュリティの問題を維持する可能性がある。

重要な戦略的ポイントは、RouteViews がアーカイブを放棄することなく、ルーター中心のアクセスからサービス中心のアクセスへと移行していることである。コレクターは収集すべきである。アーカイブは保存すべきである。API は構造化された現在のクエリに答えるべきである。Looking Glass は人間の診断をサポートすべきである。Kafka はライブデータを配信すべきである。これらの機能を分離することが、プロジェクトの現在のスケール管理の形態である。

自発的なピアからグローバルビューを構築する

RouteViews は、いかなる自律システムにも寄与を強制しない。そのカバレッジは、自発的な BGP セッション、ホスト関係、ルーティング情報を露出するネットワークの意欲から生まれる。これは、ローカルな決定を通じて公共財を生み出す。各ピアは何をエクスポートするかを選択し、各ホストはどのような基盤を提供するかを選択し、各利用者はデータをどのように消費するかを選択する。

このモデルは、すべてのコレクターの場所を所有する場合と比較して、低い中央資本要件を持つが、その成功は社会的および運用上の関係に依存する。RouteViews のスタッフは、ピアを勧誘し、技術的な準備状況を検証し、エクスチェンジ接続を調整し、セッションをトラブルシューティングし、信頼を維持しなければならない。NSRC の、事業者、研究教育ネットワーク、エクスチェンジコミュニティとのグローバルな関係は、その作業に適した制度的環境を提供する。

2025年のピアリングポリシーは、広範な受け入れから選択的な成長への移行を公式化した。好ましいピアは、安定したフルテーブル、有用な地域的またはエッジの可視性、独特のパス、本番品質の運用を提供する。応募者は、最新の PeeringDB 情報を維持し、公開アドレス空間と公開 ASN を使用し、特別用途の経路をフィルタリングし、デフォルトルートの送信を避け、可能であれば IPv4 と IPv6 をサポートすることが期待される。RouteViews は Add-Path を受け付けない。

選択性は、コストの認識である。すべてのセッションがメモリ、処理、監視、スタッフの注意を消費する。すべての更新がストレージと、場合によってはライブストリームに入る。既存のルートサーバービューを複製するフィードは、ほとんど情報を追加しないかもしれない。ノイジーまたは不安定なピアは、プラットフォーム全体に不均衡な影響を及ぼし得る。

選択性はまた、裁量を生み出す。ピアリングコーディネーターは、ネットワークが安定しているか、地域的に価値があるか、あるいは十分に非冗長かどうかを評価する。公開ポリシーは例外を許容し、実験的ネットワークの受け入れの可能性を含むが、正式な不服申し立てや外部審査のプロセスは見つからなかった。柔軟性は運用上有用である。それでも、ガバナンスの表面は可視でなければならない。なぜなら、選択が研究者やセキュリティシステムによって使用されるデータセットを形作るからである。

現在の情報源には、役職の曖昧さも含まれている。Nina Bargisen は、2026年1月の運用レビューと2025年のポリシー公開において、RouteViews Peering Coordinator として特定されている。オレゴン大学の記録は、Owen Conway を RouteViews Network Engineer and Peering Coordinator として特定している。証拠は、これらの役割が補完的であるのか、移行を反映しているのか、あるいは異なる雇用関係から生じているのかを確立しない。責任あるプロフィールは、解決策をでっち上げることなく、両方を挙げる。

2026年のプレゼンテーションで特定されたより広範なチームには、Hans Kuhn、Nina Bargisen、Owen Conway、Philip Smith、Philip Paeps、Anton Berezin が含まれていた。大学の記録は、Steve Huter を NSRC Director として、Hans Kuhn を Senior Director for Research Infrastructure としてリストしている。2026年4月の RouteViews 基盤エンジニアの求人は、コレクターの保守、ツール開発、業界との関係、データの完全性、ルーティングセキュリティ、研究サポートにわたる責任を説明していた。

これらの記録は、プラットフォームが寄贈されたマシンと同様に、専門化された人々に依存していることを示している。グローバルな BGP 収集は、ピアリングの判断、ルーティング運用、自動化、分散システム、ストレージ管理、ユーザーサポートを必要とする。小規模な専門家チームは効率性と継続性を生み出すが、それはまた、キーパーソンと採用のリスクも生み出す。

ルーティングセキュリティは RouteViews の証拠を使用するが、RouteViews の制御の外にある

経路リークやハイジャックは、しばしば予期しないルーティングの変化として可視になる。プレフィックスが新しい起点 ASN とともに現れたり、より具体的な経路が拡散したり、AS パスが突然変化したり、以前の経路が撤回されたりするかもしれない。RouteViews は、監視システムやインシデントアナリストがこれらのパターンを検出または再構成できるところから、観測を提供する。

このプロジェクトは、自動的な検出を保証しない。イベントは、少なくとも一つの関連する観測点に伝搬しなければならず、ピアがそれをエクスポートし、収集パスが健全でなければならない。ローカライズされたインシデントは、どの寄与するネットワークもそれを見たり報告したりしない場合、不可視であり得る。広範なイベントは、多くのセッションから迅速に可視になり得るが、悪意のある行動を設定ミスや正当なポリシー変更から区別するために、やはり文脈を必要とする。

RPKI は外部の検証層を追加する。経路起点認可は、観測された起点アナウンスと比較されて、有効、無効、または見つからないと分類され得る。RouteViews の Looking Glass は、RPKI 指向のチェックをサポートする。RouteViews 自身は、ROA を発行したり、どのネットワークが経路起点検証を強制しなければならないかを決定したり、グローバルテーブルから無効な経路を削除したりはしない。

証拠と強制の区別は、運用上重要である。セキュリティプラットフォームは、RouteViews データに基づいて警告できる。事業者はフィルターや ROV を設定できる。レジストリと資源保有者は ROA を管理できる。対応チームはネットワークに連絡できる。RouteViews は、それらのアクターが調整するのを助ける共有された観測ストリームを供給するが、彼らの権威や責任を吸収しない。

同じデータは、トポロジーと関係の研究もサポートする。AS パスは、研究者がプロバイダー・カスタマー関係、ピアリング、カスタマーコーン、トランジット依存を推論する証拠を提供する。CAIDA は、プレフィックス対 AS マッピング、AS ランク、および関連製品において RouteViews データを使用する。これらの出力は、方法論を通じて導出される。それらは、直接の契約記録ではなく、すべてのアジャセンシーが特定のビジネスアレンジメントを表す証拠でもない。

プレフィックス対起点のマッピングも同様に時間的かつ観測的である。それはアドレスを、ある時点でルーティングデータに可視な起点 AS と関連付ける。それはセキュリティ、パフォーマンス、ポリシー研究に有用であるが、法的な所有権のレジストリではない。より具体的な経路、エニーキャスト展開、一時的なイベント、または複数起点の取り決めがマッピングを複雑にし得る。

したがって、セキュリティへの RouteViews の関連性は、基盤上の位置と歴史的な連続性から来る。多くのネットワークからのコントロールプレーン信号を記録し、それを外部視点を必要とするシステムが利用できるようにする。その限界は同様に構造的である。つまり、自身に送信された経路のみを見て、観測を普遍的な準拠に変換することはできない。

研究の依存と CAIDA との関係

RouteViews データは、公開され、長期間にわたり、広くサポートされたフォーマットで表現されているために、インターネット測定の基盤となった。研究者はこれを使用して、ルーティングテーブルの成長、AS トポロジー、パス変化、プレフィックスのディスアグリゲーション、回復力、ハイジャック、リーク、セキュリティメカニズムの採用を研究する。2019年のプレゼンテーションでは約500の論文が引用されたが、独立して重複排除された最新の総数は検証されなかった。安全な結論は、正確な現在の論文数ではなく、広範な研究利用である。

CAIDA は、最も重要な下流機関の一つである。RouteViews の観測からプレフィックス対 AS マッピングや AS レベルの製品を導出し、研究者が RouteViews および RIPE RIS データを処理するのを助ける BGPStream などのツールを提供する。CAIDA、MIT CSAIL、UO NSRC はまた、2021年10月から2025年9月まで、インターネットセキュリティのためのグローバル測定基盤プロジェクトで協力した。

CAIDA が主導し、2027年3月まで予定されている ILANDS プロジェクトは、ルーティングとストレージの課題を含む、スケーリングと長期的なネットワークデータ基盤に取り組む。これらの協力は、RouteViews が孤立した大学のサービスとしてではなく、より広範な測定エコシステムに組み込まれていることを示している。それでもなお、助成金の金額と目的は慎重に割り当てられなければならない。CAIDA 主導または NSRC 全体の賞は、RouteViews だけの予算ではない。

RIPE RIS との関係は補完的である。RIS は、RIPE NCC を通じて自身の分散 Remote Route Collectors と公開ルーティングサービスを運用する。また、アクティブルーティングビーコンも使用しており、これは RouteViews の一般的に受動的なコレクターのアイデンティティとは異なる特徴である。二つのプラットフォームは、冗長性とグローバルな可視性を向上させるために調整する一方で、異なる観測点とインターフェースを持つ別個のシステムのままである。

研究者は一般的に RouteViews と RIS を組み合わせる。なぜなら、単一のプラットフォームが完全であることはないからである。重複は相互検証を可能にし、回復力を改善する。違いは、測定結果がコレクターの選択にどのように依存するかを明らかにする。Isolario や他のプラットフォームはさらなる視点を追加し、商用モニターは独自の観測点、アラート、サポートで公開データを豊かにする。

代替手段の存在は、RouteViews の価値を減じない。それは正しい使用法を明確にする。堅牢な分析は、問いに従って情報源を選択し、観測点を文書化し、データセットの変更によって結論が生き残るかを検証する。RouteViews はすべてのピアプラットフォームに対して普遍的に優れているわけではない。その独特の強みは、アーカイブの深さ、事業者の親しみやすさ、公開 MRT データ、IXP とマルチホップコレクターの組み合わせ、そしてオレゴン大学における制度的な連続性である。

プロジェクトの DOI、10.7264/1y7v-2d90 は、学術的な利用をより可視的かつ再現可能にすることを意図した引用メカニズムを提供する。引用は持続可能性の一部である。なぜなら、基盤への貢献が認識されることを可能にするからである。それ自体は、どれだけ多くの製品、論文、運用システムがデータに依存しているかを明らかにするものではない。

バイアス、冗長性、自発的ビューの限界

RouteViews のピアは、インターネットのランダムサンプルではない。それらは、プロジェクトのポリシーの下で BGP セッションを確立する意欲と能力のあるネットワークであり、しばしば RouteViews がコレクターを持つエクスチェンジで、あるいはマルチホップの取り決めを通じてである。コレクターの配置は、部分的に寄贈されたホスティングに依存する。結果として得られる観測点のセットは、事業者の関係、相互接続の成熟度、戦略的な選択を反映する。

地理的なバイアスは、大規模でよく組織された IXP を持つ地域が観測しやすいために生じ得る。ネットワークタイプのバイアスは、トランジットプロバイダー、研究ネットワーク、技術的に関与する事業者が、クローズドアクセスネットワークや企業よりも、より寄与する意欲があるかもしれないために生じ得る。トポロジカルなバイアスは、AS グラフの一部が多くの観測点を持つのに対し、他が全く持たないために生じ得る。

これらのバイアスはデータを無効にしない。それらはデータが代表し得る母集団を定義する。RouteViews を使用するグローバルルーティングの研究は、どのコレクターとピアが選択されたかを特定し、アーカイブからの不在を、経路がどこにも存在しなかった証拠として扱うことを避けるべきである。

冗長性は、広範な収集の対応するコストである。多くのピアが同一または密接に関連するベストパスをエクスポートする。冗長性は回復力を改善し、不一致を明らかにし得るが、ストレージと計算を増加させる。新しいフィードの限界価値はタスクに依存する。グローバルなプレフィックスカバレッジにとって冗長なパスも、地域的なインシデントにとっては依然として価値があるかもしれない。

ルートサーバーフィードは、一つのセッションが多くのエクスチェンジ参加者を露出し得るために、解釈を複雑にする。バイラテラルフィードはそれらの経路を複製するかもしれない。ルートサーバーは、その設計に従ってパス表現を変更するかもしれない。アナリストは、ソースの関係を区別し、すべての代表される ASN を直接のピアとして扱うことを避けるメタデータを必要とする。

ベストパスエクスポートは、別の盲点を生み出す。ピアは複数のパスを知っているかもしれないが、RouteViews に送信するのは選択された経路だけである。隠れた代替手段は、ポリシーまたは到達可能性が変化したときにのみ可視になり得る。したがって、アーカイブは、使用またはエクスポートされたパスを明らかにするが、各ネットワーク内部で利用可能な完全なオプションセットではない。

物理トポロジーも隠されている。分離して見える二つの AS パスが、ファイバー、施設、電力、あるいは上流の組織を共有しているかもしれない。ルーティングデータは、コントロールプレーンの多様性を理解するために不可欠であるが、追加の証拠なしに物理的な独立性を証明することはできない。

規律ある結論は、RouteViews は既知のサンプリング特性を持つ測定器具であり、全知への失敗した試みではないということである。より多くのコレクターがカバレッジを改善し得るが、有限の自発的セットがすべてのバイアスを取り除くことはない。科学的な義務は、器具を記述し、推論を限定することである。

ノイジーなピア、ストレージの成長、すべてを保存する経済性

RouteViews は、2025年中に RIB と更新に割り当てられたストレージが11.1TB から67TB に成長したと報告した。同じレビューでは、最大のフルルートピアが約110万の IPv4 プレフィックスと253,000の IPv6 プレフィックスを供給していると説明された。別のプレゼンテーションでは、約50TB の圧縮されたものに言及し、おそらくより古い日付か異なるストレージ定義を反映している。

成長は部分的に予想される。ルーティングテーブルは拡大し、より多くのピアがフルルートを送信し、より多くのコレクターが並行するビューを生み出す。RIB サイズは、プレフィックス数と収集頻度から合理的にモデル化され得る。更新量は、振る舞いに依存するためより難しい。

一つの不安定なピアが非常に大量のメッセージを生成し得る。経路フラッピング、繰り返される属性変更、セッションリセット、ソフトウェアの欠陥、ディスアグリゲーションは、ストレージを支配する更新のバーストを生み出し得る。そのノイズの一部は運用上意味がある。不安定性を研究する研究者は、まさに別の利用者がフィルタリングしたいと望むメッセージを評価するかもしれない。

したがって、ストレージ問題は、重複を無差別に削除することでは解決されない。アーカイブの目的は証拠を保存することである。あらゆるフィルタリングポリシーは、器具を変更する。同時に、すべての繰り返されるメッセージを保存することは、アクセスを遅くし、クラウドと複製のコストを増加させ、生のメッセージ数に基づく誤解を招く分析を助長し得る。

現代のバックエンドは、RouteViews にこの緊張を管理するためのより多くのツールを与える。Bimper と Prometheus は、影響の大きいピアを識別できる。Kafka は消費者を隔離できる。設定ポリシーは、安定性を脅かすセッションを無効にできる。クラウドストレージと BigQuery の作業は、追加の配信と分析能力を提供し得る。

RouteViews-Google リポジトリは、同期、チェックサム、gRPC 転送、Google Cloud への保存、分析テーブルへの変換を説明している。開発活動は2026年7月に継続した。公開リポジトリは、完全な本番カバレッジ、アーカイブのパリティ、保持ポリシー、コスト配分、サービス保証を確立しない。それは、クラウドミラーがオレゴン大学のアーカイブを置き換えたという証拠ではなく、積極的な実装の証拠である。

長期的な保存は、ディスクを追加する以上のことを必要とする。ファイルは、チェックサム、複製、災害復旧、メタデータ、アクセス可能なフォーマットを必要とする。数十年にわたるアーカイブはまた、解釈可能でなければならない異質な歴史的構造を蓄積する。クラウド配信は、一つの配信システムの負担を軽減し、大規模分析への障壁を低くし得るが、プロバイダー依存と経常コストも導入し得る。

中心的な経済的問いは、どの観測が保存する価値があり、誰がその継続的な利用可能性に対して支払うのかである。RouteViews の回答は歴史的に開放性と幅広さを好んできた。持続可能性の課題は、その回答を、アーカイブの意味を黙って変えることなく、運用上可能なものにすることである。

制度モデル：大学のホスティング、NSRC の運用、コミュニティのサポート

RouteViews はオレゴン大学によってホストされ、Network Startup Resource Center を通じて管理されている。現在の大学の記録は、NSRC を UO Libraries の中に位置づけている。Steve Huter は NSRC Director として、Hans Kuhn は Senior Director for Research Infrastructure として、Owen Conway は RouteViews Network Engineer and Peering Coordinator としてリストされている。プロジェクトの運用レビューとプレゼンテーションは、追加のチームメンバーと Nina Bargisen のピアリングの役割を特定している。

この制度的な拠点は、独立した企業体を作ることなく、RouteViews に法的、雇用、助成金、行政上のサポートを与える。この取り決めはまた、RouteViews の財政状況がプロジェクトの収益や会計から再構成できないことを意味する。なぜなら、独立した会計監査を受けた予算、給与、準備金、貸借対照表が公開されていないからである。

資金調達モデルは、大学と助成金のサポート、直接の寄付、現物ホスティング、技術協力、ボランティアピアを組み合わせている。歴史的なサポートには、Oregon Route-Views プロジェクトのための NSF 賞0323769、DARPA NETPATH の副賞、オレゴン大学、Cisco、Juniper、Sprint が含まれていた。2025年のサポーターリストには、Amazon、Catchpoint、Google、ICANN、Internet Society、Internet Society Foundation、MaxMind、NSF、Verisign、財団、個人ドナーが含まれていた。

これらの寄付の金額と制限は、RouteViews のみの形では公開されていない。NSRC は、Google が相当な資金とハードウェアサポートを提供してきたと述べており、オレゴン大学は NSRC への$3,732,343の NSF 賞を発表した。これらの数字はより広範な制度的環境をサポートするものであり、直接の RouteViews の収入として提示されてはならない。

現物ホスティングは、現金の予算に現れない場合でも、経済的に重要である。コレクターのホストは、仮想マシン、ポート、トランジット、電源、冷却、スタッフの時間を提供できる。ボランティアピアは、サービスが依存するデータを提供する。したがって、プラットフォームの真の資源基盤は、機関やネットワークに分散している。

このモデルは公共アクセスを最大化する。RouteViews はそのデータが自由に利用可能であると言い、サイトは CC BY 4.0ライセンスを表示する。データセット固有の条件や歴史的アーティファクトは、一つのフッターがあらゆるアクセスパスを支配していると仮定するのではなく、依然としてチェックされるべきである。API の容量制御と帰属表示の期待は、自由なアクセスと共存し得る。

商用製品も RouteViews データを使用していると報告されている。プロジェクトのプレゼンテーションは、ネットワーク監視とインテリジェンスにおける例を挙げている。開かれた商用再利用は影響を示し、ルーティング運用を改善し得るが、フリーライダー問題を生み出す。企業は、その利用に比例した義務的なライセンス料なしに、公開アーカイブに基づいて収益を生むサービスを構築できる。

RouteViews は、成功した商用ユーザーにプロジェクトを認識しサポートするよう求めることで対応してきた。強制的な商用価格やサポート契約は特定されなかった。これは、持続可能性を自発的な寄付、助成金、制度的なコミットメントに依存させたまま、開放性を保持する。

したがって、ガバナンスの表面は公的には同様に非公式である。専用の RouteViews 理事会、独立した諮問委員会、サービスレベル目標、ピア削除の不服申し立てプロセス、公開された保持ポリシー、あるいは後継者計画は見つからなかった。ガバナンスは、大学と NSRC の管理、助成金の義務、スタッフの判断、ピアやホストとの関係を通じて実行されるように見える。

これは、機関が信頼され、チームが安定している場合にはうまく機能し得る。依存が成長するにつれて、疑問も生じる。商用ユーザー、研究者、事業者は、保持、アクセス、回復力の優先順位を設定する正式な役割を持たずに、基盤として RouteViews に依存し得る。独立した企業の不在は、ある種の官僚主義を避ける。それは、共有されたサービスの透明なスチュワードシップの必要性を排除しない。

RouteViews の影響メカニズム

RouteViews の影響は、権威の主張としてではなく、連鎖として辿ることができる。第一に、自律システムが自発的に BGP 経路をコレクターにエクスポートする。第二に、コレクターが選択されたコントロールプレーンのビューを RIB 状態と更新として記録する。第三に、RouteViews がファイル、ストリーム、サービスを通じてデータを保存し配信する。第四に、事業者、研究者、ベンダーが観測を分析する。第五に、それらのユーザーが、監視、インシデント対応、フィルタリング、トポロジーモデル、ポリシー、投資を変更するかもしれない。

すべてのリンクに別個の意思決定者が存在する。寄与するネットワークがエクスポートを制御する。RouteViews は、そのシステム内で収集と公開を制御する。下流のユーザーが分析を制御する。事業者がルーティングポリシーを変更するかどうかを制御する。セキュリティチームが警告するかどうかを制御する。研究者が方法論を制御する。プロジェクトの影響は、これらの決定の相互運用性から生まれる。

この分割は強みである。なぜなら、データが有用になるために中央の承認が必要ないからである。ネットワークは選択するから寄与する。研究者はアーカイブが開かれているからダウンロードする。ベンダーはフォーマットが再利用可能だから統合する。事業者は証拠が自身の文脈で説得力があるから行動する。

それはまた、因果的主張の限界でもある。RouteViews は、ハイジャック調査中に使用された証拠を供給できるが、最初にインシデントを検出したり修正した組織である必要はない。CAIDA は、RouteViews から派生データセットを構築できるが、RouteViews を方法論に対して責任あるものにしない。商用製品は、自身の出力のどれだけが RouteViews から来ているかを開示することなく、アーカイブに依存し得る。

プロジェクトの最も強力な形態の力は認識論的である。それは、ドメイン間ルーティングについて何が知られ得るか、そしてどのような歴史的な問いが問われ得るかを形作る。それは重大である。なぜなら、基盤の決定は利用可能な証拠によって制約されるからである。決して観測されなかった経路は調査がより難しい。長いアーカイブは、一つの事業者のログでは不可視なパターンを明らかにし得る。

認識論的な力は、事実の完全性と混同されるべきではない。器具は、ピアの参加、ポリシーのエクスポート、コレクターの配置、ストレージの決定を通じて現実を選択する。RouteViews は、それらの境界が文書化されている場合に信頼に値し、グローバルビューの主張の背後に隠されている場合ではない。

Lu Heng の編集フレームワークは、RouteViews についての事実の情報源としてではなく、規律としてここで有用である。関連する分離は、稼働状態と制度的な主張の間である。RouteViews の価値は、経路を受信するコレクター、記録を保存するアーカイブ、それらに依存するユーザーによって実証される。プロジェクトは、ルーティングの真実の所有権を主張する必要はない。その信頼性は、交換可能で、調査可能で、境界のある観測レイヤーであり続けることから来る。

BTW が RouteViews を追跡する理由

BTW が RouteViews を追跡するのは、ルーティングの可観測性が基盤だからである。トラフィックを運ぶルーターは、運用上のインターネットの一部に過ぎない。事業者はまた、自身のネットワークの外で到達可能性がどのように表現されているかを示し、インシデント中に証拠を保存し、長期的な比較を可能にするシステムも必要とする。

RouteViews が特に重要なのは、BGP への本番接続と、1997年まで遡る歴史的アーカイブを組み合わせているからである。その深さは、後に構築された商用ダッシュボードでは答えられない問いに対してプロジェクトを有用にする。また、地域的な違いを露出するのに十分なほどグローバルに分散している一方で、完全なカバレッジの不可能性について透明であり続ける。

このプロジェクトは、より広範な基盤の原則を示している。共有された可視性は、運用上の制御を中央集権化することなく創出され得る。RouteViews は、ピアのために経路を決定しない。それは、彼らが開示することを選択したものを記録する。結果として得られるデータセットは、ローカルに受け入れ、拒否し、解釈する権限を保持しつつ、独立したアクター間の調整をサポートできる。

その弱点も同様に示唆的である。自発的な参加はバイアスを生み出す。オープンアクセスは資金調達の圧力を生み出す。寄贈されたホスティングは依存を生み出す。レガシーインターフェースは技術的負債を生み出す。小規模な専門家チームは継続性のリスクを生み出す。ストレージの成長は未解決の保存問題を生み出す。商用の依存の増大は、ガバナンスと貢献を上回り得る。

したがって、RouteViews は、インターネットの完全な地図として美化されるべきでもなければ、学術的なアーカイブとして退けられるべきでもない。それは、その出力が研究、監視、セキュリティに埋め込まれるようになった本番の測定システムである。その重要性は中間の位置にある。運用上の証拠を提供するのに十分なほどライブルーティングに近く、すべての利用者が証拠が含まないものを理解しなければならないほど十分に限定されている。

主要な証拠と未解決の問い

このプロフィールの主要な証拠は、提供された RouteViews の詳細調査パックであり、これはさらに、RouteViews の2026年1月の2025年レビュー、公式ピアリングポリシーと API 文書、オレゴン大学と NSRC の記録、歴史的な APNIC と NANOG のプレゼンテーション、PeeringDB、IETF 仕様、RIPE RIS 文書、CAIDA のプロジェクトとリソースのページ、観測点の価値と測定バイアスに関する学術研究、そしてプロジェクトの公開リポジトリを利用している。

記録は、1995年の起源、Randy Bush の初期の MAE-WEST への貢献、David Meyer の主要な初期の役割、1997年11月のアーカイブ、2001年の2時間周期、2003年の IXP コレクターモデル、IPv6 収集、現在の大学と NSRC のホスティング、AS6447、現在のアーカイブ間隔、2026年1月のセッションとストレージの数字、API、Looking Glass、Kafka、Bimper アーキテクチャ、2025年のコレクター拡張を支持している。

いくつかの重要な事実は未解決のままである。正確な日付が揃ったアクティブなコレクター数は見つからなかった。50TB と67TB のアーカイブの数字は異なる日付や定義を使用している。Nina Bargisen と Owen Conway はともに公的にピアリング調整に関連付けられている。PeeringDB のルートサーバーメタデータは、ルートサーバーの経路を受け入れる公式ポリシーと矛盾している。Google Cloud アーカイブの完全性と本番パリティは確立されていない。RouteViews は、独立した予算、スタッフ数、商用ユーザー登録、正式なアップタイム履歴、あるいはアーカイブの完全性ダッシュボードを公開していない。

したがって、本稿はいくつかの主張を避けている。RouteViews は、キャリア、インターネットエクスチェンジ、独立した企業、グローバルルーティングの完全なビュー、自動的なハイジャック強制サービス、あるいはすべてのコレクターの所有者として扱われていない。フルルートは、すべてのパスとして説明されない。セッション数はコレクター数に変換されない。NSRC や CAIDA 協力の助成金総額は、すべて RouteViews に割り当てられない。

プロフィールを最も直接的に支持する情報源は以下を含む：

中心的な未解決の問いは、RouteViews に価値があるかどうかではない。アーカイブ、コレクターネットワーク、下流での利用がそれを確立している。問いは、プロジェクトがより大きく、より速く、よりサービス指向のデータプラットフォームになりながら、歴史的な開放性と方法論的な誠実さを保持できるかどうかである。その結果は、ストレージ、複製、API カバレッジ、スタッフの継続性、ホスト関係、透明なメタデータ、そしてシステムから抽出される商業的価値と同様に学術的価値を反映する資金調達モデルにかかっている。

RouteViews とインターネットのルーティングシステムを可観測にする基盤