ある日のグローバルBGPテーブル
(articles.foletta.org)- 1日のあいだにフルBGPテーブルを持つピアから受信した 464,673件のBGP UPDATE を通じて、長期的な成長傾向ではなく、グローバルルーティングテーブルの短時間スケールの変動を観察
- ピアリング直後には、全経路とNLRIが約5秒以内に一気に到着し、初期経路に紐づくルート数は 949,483件 だった
- その後のUPDATEは 30秒のRoute Advertisement Interval 単位でまとめて到着し、IPv4では30秒ごとに約50件、IPv6では約47件の経路更新が観測された
- IPv4では経路数とアドレス空間の変化の両方に約 40分周期 の相関が見られたが、その原因は未解明のまま残された
- 過剰なAS path prepending、予約された path attribute 255、特定NLRIの激しいフラッピングは、グローバルBGP運用の複雑さと回復力の両方を示している
1日単位のBGPテーブル観測
- グローバルBGPテーブルの分析は通常、ルーティングテーブルの成長やIPv6導入のような 数か月・数年単位のトレンド に注目する
- この分析では、ルーターが変化し続けるインターネットのBGPアップデートを直接受信する状況で、1日のあいだにどのような短期変動が現れるかを見ている
- 観測対象は3つに分かれる
- 1日のあいだの一般的なUPDATEの流れ
- 特異な path attribute
- 頻繁に変化する flappy path
データ収集とbgpsee
- ルーターのデバッグ出力を直接パースするのではなく、以前に作りかけだったBGPデーモンを動作可能な状態に整えて bgpsee を使用
- bgpseeはCLI向けのマルチスレッドBGPピアリングツールで、ほかのルーターとピアリングした後、BGPメッセージをパースしてJSONで出力する
- 処理対象はOPEN、KEEPALIVE、UPDATEメッセージ
- UPDATEにはNLRI、withdrawn routes、ORIGIN、AS_PATH、NEXT_HOP、AS4_PATHのようなpath attributeが含まれる場合がある
- データセットは2024年1月6日から2024年1月7日まで収集され、フルBGPテーブルを持つピアから受信した 464,673件のBGP UPDATE で構成される
初期フル転送と経路数
- BGPピアリングを最初に確立すると、ルーターのBGPテーブルにあるすべての経路と関連NLRIが大きなUPDATEのまとまりとして送信される
- この初期のまとまりは、ピアリング開始後およそ 5秒 以内に受信された
- その後は、変更された経路や、もはや経路が存在しない withdrawn routes に関するUPDATEだけが届く
- この初期のまとまりとその後のUPDATEは構造的には同じで、違いは受信時点と範囲にある
- ここで重要な区別は 経路(path) とルート(route) である
- 経路は、path attribute の組み合わせとそれに結び付いたNLRIを持つ1つのBGP UPDATE単位
- 1つの経路には1件または1,000件のルートが結び付くことがある
- 初期のまとまりの全経路に結び付いたルート数は 949,483件 だった
30秒単位のUPDATEフロー
- 初期フル転送後のUPDATEはリアルタイムのストリームのようには来ず、Route Advertisement Interval タイマーに従ってまとめて送信される
- このピアリングでのRoute Advertisement Intervalは 30秒 だった
- 観測された平均UPDATE数は次のとおり
- IPv4: 30秒ごとに約 50件の経路更新
- IPv6: 30秒ごとに約 47件の経路更新
- 平均は近かったが、変動幅はIPv4のほうが大きかった
- IPv4の標準偏差: 64.3
- IPv6の標準偏差: 43
- 単純なUPDATE数の代わりに、30秒ごとに変化したIPアドレス空間の総量も計算した
- 各UPDATEに含まれるIPアドレス数をすべて合計したうえで
log2()を適用 - 例としては、
/22、/23、/24をそれぞれアドレス数に換算して合計し、その後ログを取る方式
- 各UPDATEに含まれるIPアドレス数をすべて合計したうえで
- IPv4アドレス空間ベースでは、平均すると30秒ごとに約 2^16個のアドレス、つまり
/16程度がグローバルルーティングテーブルで経路変更している - 95%区間で変化したIPv4アドレス空間は約 2^20.75 から 2^13.85 のあいだだった
- おおよそ
/11から/18に相当する
- おおよそ
IPv4アップデートの40分周期
- 経路数の変化とIPアドレス空間の変化の両方で、IPv4 UPDATEは 循環的な動作 を示した
- 周期を確認するために自己相関関数(ACF)を使用
- UPDATEは1分単位でまとめ、1 lagは1分を意味する
- 現在時点の経路数と、過去の各lag時点の経路数との相関を計算した
- 最初のおよそ7 lagで強い相関が現れた
- 経路変化が世界中へ伝播し、別の経路変化を生み出しうることとも整合する
- lag 40と41でも強い相関が現れ、約 40分周期 の動作が確認された
- この40分周期の原因は答えの出ない疑問として残っている
過剰なAS path prependingの事例
- ネットワーク管理者は、トラフィックが自分のASNに流入する方法を調整するために複数の手段を使える
- より長いネットワークプレフィックスを使う方法はスケーラビリティが低く、BGPの観点からも望ましくない
- MED attribute は non-transitive なので、複数ASとピアリングする際には限界がある
- 一般的には、特定のピアに対して自分のASを複数回先頭に付ける AS path prepending により経路選好度を下げる
- データセット内で最長のIPv4 AS path長は 105 だった
- prependingなしの最長経路長が14だったことを考えると大きな値である
- このIPv4経路は、インドネシアのAS149381 “Dinas Komunikasi dan Informatika Kabupaten Tulungagung” に由来する
- 当該NLRI
103.179.250.0/24は2024年1月6日 06:31:18 にAS path長105として見え、その約 6.84時間 後の13:21:35には長さ4へ更新された
- IPv6では最長のAS path長が 599 に達した
- AS pathは1つ以上の AS setまたはAS sequence で構成される
- 各AS sequenceの最大長は255のため、この経路には3つのAS sequenceが必要だった
- 最長のIPv6経路では、originatorではなくウクライナのISPであるAS8772 NetAssist LLC が prepending を行っていた
- 対象は、インドネシアのAS203868、Rifqi Arief Pamungkas への経路だった
- AS8772がその経路をより非優先にするために prepending した形だった
- 上位50件の最長経路の全位置にあるASN数を見ると、IPv4とIPv6の大きな違いは特定ASNの反復使用と結び付いている
Path attributeに見られた予約値255
- 各BGP UPDATEはネットワーク到達性情報と path attribute で構成される
- 例としてAS_PATH、NEXT_HOPなどがある
- RFC4271 Section 5 はBGP attributeの種類を次のように分けている
- well-known mandatory
- well-known discretionary
- optional transitive
- optional non-transitive
- IPv4経路全体でattribute数を見ると、well-known mandatory attributeであるORIGIN、NEXT_HOP、AS_PATHはすべてのUPDATEに存在し、同じ件数で現れる
- AGGREGATORのような一般的なattributeや、AS_PATHLIMIT、ATTR_SETのような比較的まれなattributeも観測された
- 一部のASは attribute 255 をUPDATEに付加していた
- この値は reserved for development な attribute である
- 当時のbgpseeは、このようなまれなpath attributeの値を保存していなかった
- routeviews.org を通じて、一部のASがいまもこのattributeを付けて経路広報していることが確認でき、raw byte値も観測された
- AS265999、AS10429、AS52564でattribute 255が見られた
- 3つのISPのraw byte値は互いによく似た構造を持っていた
- どのベンダーが開発用に予約されたattributeを使っているのか、また何のために使っているのかは確認できなかった
最も激しくフラップしたNLRI
- 1日のあいだに経路が変化したり完全にwithdrawされた route のうち、UPDATEに最も多く含まれた上位NLRIが集計された
- 上位10件のactive NLRIとUPDATEへの出現回数は次のとおり
140.99.244.0/23: 2,596107.154.97.0/24: 2,58345.172.92.0/22: 2,494151.236.111.0/24: 2,312205.164.85.0/24: 2,18941.209.0.0/18: 2,069143.255.204.0/22: 2,048176.124.58.0/24: 1,584187.1.11.0/24: 1,582187.1.13.0/24: 1,580
140.99.244.0/23はこの日もっとも激しく変動した事例で、このアドレス空間は EpicUp が所有している- 全30秒ブロックは 2,879件 あり、このrouteは別経路または withdrawn route の形で 2,637ブロック に登場した
- 登場比率: {p:93}
- 実際の比率は 92.8%
フラッピング経路が示したピアリング多様性
140.99.244.0/23のフラッピングの仕方を見るため、このネットワークへのすべてのpathのASNをノード、ASペアをエッジとするグラフが使われた- 主要経路はNTT AS2914 と Lumen/Level3 AS3356 を通る中心的な経路として見える
- 経路はこれらの tier 1 ISP と他のISPのあいだを移動する
- 例としてArelion AS1299、PCCW AS3419 が含まれる
- このデータだけでフラッピングの正確な原因を特定するのはほぼ不可能である
- ありうる原因として、劣悪なリンク、停電、ルータークラッシュのような状況が挙げられている
- 同時にこの事例は、現代のグローバルネットワークにおける ピアリング多様性 と、33年続くルーティングプロトコルの回復力を示している
さらに多くの疑問を残すデータセット
- このデータセットには見るべきテーマが多すぎるため、分析は一部の事例に焦点を当てている
- グローバルBGPテーブルのUPDATEには、政治的不安定、地震や火災のような自然現象、ネットワーク管理者のミスといった現実世界の出来事が反映されうる
- インターネットピアリングの経済性や、能力の異なる運用者たちの人間的要素も、小さなBGP UPDATEの中に一緒に含まれている
- グローバルBGPはほとんどの時間で動作し、多くの現実世界の変化を小さなアップデートストリームとしてノートPCにまで届けている
1件のコメント
Hacker Newsのコメント
25年前に小さなISPで働いていて、当時は上位ISPが1社しかなかったので、マルチホーム構成を担当することになった。
Avi Freedmanが書いたチュートリアルを見て学び、そのおかげでARINから/20を取得して、2つのピアに経路を広告できるようになった。
仕組みを学ぶのは本当に興味深く、知れば知るほど、インターネットがどうにか動いているという事実そのものに驚かされた。
(1) http://avi.freedman.net/
Avi
特に動画や通話ではなおさらで、コンテンツが役に立ったとのことで嬉しいです。
avi.netには、当時のチュートリアルや昔のBoardwatch記事へのリンクをいくつかまとめてあります。
動機は純粋に当時の資料へのもどかしさでしたが、良い文章で人を助けると、「T1は買えますか?」とか「うちの大きなグローバルネットワークを運用してくれませんか?」といった形で報われることにもすぐ気づきました。
だから今でも、わかりにくくてもどかしいテーマについて書くよう、ずっと勧めています。
コメントが切れたのか、コピー&ペーストを間違えたのか気になる。
他の人も見たことがあるのか、生成コメントや特定ツール利用の痕跡だったりするのかも気になる。
主にHNで見かけ、Redditでも一度くらい見た気がするが、単なる偶然やミスにしては思ったより頻繁に見える。
良い記事だが、EpicUpの140.99.244.0/23プレフィックスのフラッピングは経路ダンピング(route dampening)の対象であるべきだった。
普通はISPがすべてのピアに対して、ピアごとまたはプレフィックスごとのレート制限をかけ、単一プレフィックスが世界全体のBGP変動の大きな割合を占めることを防ぐ。
著者が連鎖効果として見た更新同士の相関は、説得力が弱い。
他の自律システムのプレフィックスへの経路、しかも不安定な経路に基づいて自分の広告を変えるのは、かなり雑な設計だ。
40分周期性があるとも思わない。少なくとも8年前にBGPを深く扱っていた頃にはそんなものはなく、データセットがたまたまそう見えたか、著者がBGPフィードを受けていたネットワークの特性によるように感じる。
実データでどのASやプレフィックスが変化しているかを見ると、あちこちに散らばっていて大きなパターンはほとんどない。
どの日でも、回線障害や設定ミスで騒がしいISPがいくつかあり、新サービスの立ち上げでプレフィックスが出たり引っ込んだり、通常のドレイニング保守で経路が変わったりするものが混ざっている。
カンザスの小さなISPでバックホウが光ファイバーを切断した出来事がパースのルーターに見えるというのは魅力的で少し怖くもあり、同時に無数の手作業ポリシーのおかげで世界全体の更新頻度が10Hz未満に保たれている。
多くの設定がひどく誤っていて、昔のように大半のルーターがCPUに極端に余裕がないわけでもなくなったからだ。
もちろん完全に消えたわけではなく、私がBGP Battleships(https://blog.benjojo.co.uk/post/bgp-battleships)をやったときは、3356が当時経路ダンピングをしていたので、少しの間プレイを止める必要があった。
BGPを学びたいなら、特にピアリング環境の日常的な運用を知りたいなら、University of OregonのNetwork Startup Resource Centerの動画シリーズが良い。
https://learn.nsrc.org/bgp
ざっと調べた限りでは、0xff予約BGP属性はHuawei特有の挙動である可能性が高い。
bgp.toolsで見える0xffの大半は記事に出てきたものと同じ形式に従っており、その一部のネットワークではHuawei機器を使っているようだ。
この記事でBGPについて知らなかったことをかなり多く学べたし、特にこうした混沌とした形で回っていることがいちばん興味深かった。
もっと深く掘り下げる続編も読んでみたい。
以前、ボルネオ一帯に現地事務所を持つ米国の大口顧客向けに、衛星・マイクロ波ハイブリッドネットワークを設計して設定したことがある。
Jakartaで専用線の引き継ぎ作業をしていたことが忘れられない。
こうした経験がまったくなかったので調べてみたところ、自分たちのOSPF/UBNTネットワークと顧客のIGRP/Cisco企業WANをつなぐにはBGPを使うのだとわかった。
Tata側の担当者にルーターへのBGP設定を頼むと、「自分たちがAT&Tだとでも思っているのか?」という反応だった。
雷の多い1シーズンでAirFiberの大半が落ちるまでは、こちらもちょっとそんな気分ではあった。
[1]のBGP経路入りMRTファイルからデータを抽出してNeo4jに取り込み、探索するPythonスクリプトを作った。
このファイルには重複が非常に多い経路が約5,600万件入っていて、Neo4jはこうしたデータを「マージ」して扱うのに向いている。
[1] https://data.ris.ripe.net/rrc00/
普通の人がBGPデータに直接アクセスする一番簡単な方法は何だろう? ISPに知り合いはいないが、似たような分析をしてみたい。
https://www.ripe.net/analyse/internet-measurements/routing-i...
https://lukasz.bromirski.net/post/bgp-w-labie-3/
興味があればメールを送ってくれれば、今週中に一度立ち上げてみる。
時間がたつにつれて、経路とIP空間の変化の両方にIPv4更新の周期的な振る舞いが見えるなら、それはインターネットにも潮汐のようなものがあるということだろうか?
中核インターネットインフラのセキュリティと安全性をRustで再実装して扱うMemory Safetyイニシアチブには、BGPサーバー実装も担当してほしい。
[1] https://www.memorysafety.org/