- Published on
BGPインターネットルーティング完全ガイド 2025: AS、Peering、Path Selection、RPKI、Anycast — インターネットの本当の仕組み
- Authors

- Name
- Youngju Kim
- @fjvbn20031
はじめに: インターネットは実は一つではない
あなたが「インターネット」と呼ぶものは単一のネットワークではなく、約75,000以上の独立ネットワークが緩く連携した連合体である。それぞれを AS (Autonomous System) と呼ぶ。
- Google = AS 15169
- Facebook = AS 32934
- AT&T = AS 7018
- Cloudflare = AS 13335
- SK Telecom = AS 9318
家のWi-FiからGoogleにアクセスするとき、パケットは数十のASを横断する。各ASが次のASに「このIPはこちらへ」と伝える。これが BGP (Border Gateway Protocol) 上で起きる。
BGPの重要性
- インターネット全体のルーティングがBGPに依存。
- BGPが30分止まれば世界のインターネットは事実上停止。
- 2021年Facebook障害(6時間): BGPが原因。
- 2019年Cloudflare障害: VerizonのBGPミス。
BGPはTCP/IPと同じくらい重要だが、はるかに知られていない。
1. Autonomous System: インターネットの構成単位
AS は単一の管理主体が運用するIPネットワークの集合。
- 固有の ASN (AS Number)。
- 独立したルーティングポリシー。
- 他のASと BGP で通信。
- 一つ以上の IP prefix を管理。
例: ISP (Comcast、KT、NTT)、大企業 (Google、Amazon)、大学、CDN (Cloudflare、Akamai)。
ASN割り当て
IANA がASNを管理し、地域RIRに委任:
- ARIN (北米)、RIPE NCC (欧州・中東)、APNIC (アジア太平洋)、LACNIC (南米)、AFRINIC (アフリカ)。
16-bit ASN (0-65535、ほぼ枯渇) と 32-bit ASN (2007年拡張)。
Prefix割り当て
Google の prefix 例:
- 8.8.8.0/24 (DNS)
- 74.125.0.0/16
- 142.250.0.0/15
/24 = 256アドレス、/16 = 65536アドレス。各ASが自分のprefixをBGPで広告する。
2025年の規模
- AS数: 約75,000+
- IPv4 prefix: 約100万
- IPv6 prefix: 約20万
- BGP full table: 約100万経路 (ルータごとに数GBのメモリ)
2. BGPの基本: Path Vector Protocol
BGPはルーティングプロトコルとして特殊:
- Path vector: 各経路にAS経路全体を含む。
- Policy-based: 最短経路ではなくポリシーで選択。
- TCP上で動作 (port 179)。
- 差分更新。
- ステートフルなセッション。
BGPメッセージ
- OPEN: セッション確立と機能交渉。
- UPDATE: 経路情報 (NLRI + path attributes + withdrawn)。
- KEEPALIVE: セッション維持 (既定30秒)。
- NOTIFICATION: エラー + 切断。
Path Attributes
- AS_PATH (必須): 通過したASの順序。例
[65001, 7018, 15169]。 - NEXT_HOP (必須): 次ルータのIP。
- ORIGIN (必須): IGP / EGP / Incomplete。
- LOCAL_PREF (iBGPのみ): 内部優先度、高いほど優先。
- MED: 同一ASの複数入口での優先度、低いほど優先。
- COMMUNITIES: ポリシータグ。
BGP UPDATE 例
UPDATE from 10.0.0.1:
Withdrawn: []
Attributes:
ORIGIN = IGP
AS_PATH = [65001, 7018, 15169]
NEXT_HOP = 10.0.0.1
LOCAL_PREF = 100
MED = 50
NLRI: [8.8.8.0/24, 8.8.4.0/24]
セッション状態
Idle → Connect → OpenSent → OpenConfirm → Established (経路交換開始)。
3. Peering と Transit
ASの接続関係は2種類:
Transit (顧客-プロバイダー):
- Customerが代金を支払い、インターネット全体への到達性を得る。
- Providerはcustomerのトラフィックをどこへでも運ぶ。
Peering (対等交換):
- 両ASが直接トラフィックを交換。
- 通常無料。
- 互いの顧客のトラフィックのみ。
Tier 1, 2, 3
Tier 1 (約12社): Transitを購入せず、他のTier 1と settlement-free peering のみ。Level3、Cogent、AT&T、NTT、Telia、Deutsche Telekom、Tata。
Tier 2: 一部Transit購入 + 多数のPeering。大多数のISP。
Tier 3: Transit主体、Peeringは限定的。
現代のhyperscaler (Google、Microsoft、Facebook) は自前のグローバルバックボーンを持ち、事実上Tier 1相当。
Peeringの種類
- Private Peering: 専用のcross-connect、高帯域・低遅延。
- Public Peering (IXP): DE-CIX、LINX、AMS-IX などのIXで多数のASが相互接続。
4. BGP Path Selection: 経路選択
BGPはポリシーベースで選ぶ。理由は金・政治・性能・信頼。
標準の決定順序:
- 最大の LOCAL_PREF
- 最短の AS_PATH
- 最小の ORIGIN (IGP < EGP < Incomplete)
- 最小の MED (同一隣接ASから受けた場合)
- eBGP over iBGP
- NEXT_HOP までの IGP コスト最小
- 最古の経路
- 最小の Router ID
ほとんどは 1〜3 段階で決まる。
LOCAL_PREF の経済学
Customer route: LOCAL_PREF = 200 (収益)
Peer route: LOCAL_PREF = 100 (無料)
Transit route: LOCAL_PREF = 50 (コスト)
AS_PATH Prepending
自ASNを繰り返して経路を長く見せるテクニック:
通常: AS_PATH = [65001, 7018, 15169]
Prepend: AS_PATH = [65001, 65001, 65001, 7018, 15169]
Traffic Engineering用途 (バックアップ経路、負荷分散)。
5. iBGP vs eBGP
- eBGP: 異なるAS間。AS_PATHにASNを追加、既定TTL=1。
- iBGP: 同一AS内。AS_PATHにASN追加せず、full meshが必要。
Full Mesh 問題
N台のiBGPルータは N(N-1)/2 セッション必要。100台 → 4950セッション。
解決策:
- Route Reflector: 中央ルータが client からの経路を他 client に反射。
- Confederation: ASを sub-AS に分割。
iBGP Next-Hop の罠
iBGPは NEXT_HOP を書き換えない。内部ルータが外部peerのIPに到達できないと経路は invalid。解決: エッジで next-hop-self。
6. Convergence と安定性
- ローカル変化: 数秒。
- Tier 1経路変化: 数分。
- Route Flap Damping: 頻繁に fluctuate する経路を一定時間無視 (最近は保守的運用)。
- Hold timer: 既定180秒。
- BFD: サブミリ秒の障害検知、BGPタイマーとは独立。
7. BGP Hijacking と RPKI
BGPは信頼ベース。誰でも「このprefixは自分のもの」と広告できる。
代表的事例
- 2008 Pakistan / YouTube: Pakistan Telecomが
/24を誤って全世界に漏らし、YouTubeが数時間ダウン。 - 2017 Russia: Visa、MasterCard のprefixを短時間hijack。
- 2018 Amazon Route 53: 攻撃者がDNSのprefixをhijack、暗号資産ウォレットを偽サイトへ誘導し数十万ドル窃取。
RPKI: 解決策
- RIRがASに証明書発行。
- ASが prefix ごとに ROA (Route Origin Authorization) を生成。
- ROA = 「AS 15169 は 8.8.8.0/24 を originate する権限がある」。
- BGPルータがROAをリアルタイム検証。
- 権限のない広告は拒否。
採用状況 (2025)
- 全prefixの約50%が ROA 対象。
- Cloudflare、Google、Microsoft が強力に enforce。
限界
- Origin のみ検証、経路中間の改竄は検出不可。
- BGPsec (経路全体の署名) は設計されたが展開はほぼゼロ。
- ROA の記述ミスで正当経路が invalid になる事故も (Cloudflare 2019)。
8. Anycast: 一つのIP、複数の場所
同じIPを複数箇所から BGP で広告。各ユーザーは最も近い場所へ自動ルーティング。
1.1.1.1 (Cloudflare DNS)
広告元: US East / US West / London / Tokyo / ... 300+ POP
利点
- 低遅延 (物理的に近いサーバ)。
- 自動 failover。
- DDoS が複数 POP に分散。
- クライアントは単一 endpoint だけ知ればよい。
ユースケース
- DNS (1.1.1.1、8.8.8.8)。
- CDN (Cloudflare、Akamai、Fastly)。
- NTP、DDoS scrubbing、QUIC/HTTP/3。
限界
- TCP セッションは経路変化で切れる。
- 設定が複雑、デバッグ困難 (どの POP に当たっているか不明確)。
- UDP (DNS、QUIC) の方が親和性が高い。
HTTPS は従来 Anycast と相性が悪かったが、sticky routing や QUIC (HTTP/3) の connection migration で解決。
9. 歴史的な BGP 障害
- 2008 Pakistan / YouTube: 誤った広告の全世界漏洩。
- 2010 China Telecom: 18分間、全世界トラフィックの約15%が中国経由。
- 2014 Indosat: 数千prefixの誤広告。
- 2019 Verizon / Cloudflare / DQE: VerizonがBGP最適化サービスのリークをそのまま伝播、数時間の障害。教訓は route filtering。
- 2021 Facebook (6時間): 自らをインターネットから切断 (Q5参照)。
- 2023 Cloudflare: 自社BGP設定ミスでの障害。
共通教訓: BGPは脆い、自動化はミスを増幅、peer広告の検証必須、RPKI拡大、out-of-band管理維持。
10. BGP運用の実践
Full Table vs Default Route
- 小規模: ISP から default route のみ。
- 中規模以上: full table、multi-homed。
Multi-homing
Your AS
/ \
ISP A ISP B
冗長性・負荷分散・交渉力。
Route Filtering (Cisco 例)
ip prefix-list FILTER-IN deny 0.0.0.0/0 le 7
ip prefix-list FILTER-IN deny 0.0.0.0/0 ge 25
ip prefix-list FILTER-IN permit 0.0.0.0/0 le 32
Bogon (RFC 1918 他) や martian のブロック。
RPKI 検証
rtr client rpki-server 192.0.2.10
route-map RPKI-CHECK permit 10
match rpki valid
set local-preference 200
route-map RPKI-CHECK permit 20
match rpki not-found
set local-preference 100
route-map RPKI-CHECK permit 30
match rpki invalid
drop
Looking Glass
公開 BGP ビューア: bgp.he.net、looking-glass.nl。自分の広告が外から見えるか検証。
デバッグコマンド
show bgp summaryshow bgp ipv4 unicastshow bgp ipv4 unicast 8.8.8.0/24show bgp ipv4 unicast neighbor 10.0.0.1 received-routes
11. 現代のトレンド
- SDN + BGP: BGPをSDNのdata planeとして利用、BGP Flowspec でfirewall ルール配布。
- Segment Routing: SR-MPLS、SRv6。BGP-LU、BGP-LS で情報伝搬。
- BGP EVPN: MACアドレスをBGPで広告、VXLAN で L2 over L3。データセンター標準。
- Hyperscaler バックボーン: Google B4、Facebook Express Backbone、Microsoft Azure Network — 公衆インターネット経由をバイパス。
- CDN エッジ: 数百の Anycast POP。
クイズ
Q1. BGPが最短経路ではなくポリシーベースを採用する理由は?
A. IGP (OSPF、IS-IS) は単一管理ドメイン向けで最短経路で十分。BGPは数万のASが各自の利害で動くため、単純な最短では破綻する。
経済: Transit は有料、Peering は無料。安い経路を選ぶ。LOCAL_PREF で表現: customer (200) > peer (100) > transit (50)。
性能: 3 hop でも混雑した peering より 5 hop でも余裕ある専用線の方が速いことがある。
信頼と政治: 特定ASの回避、規制対応、監視リスクの低い経路選択。
Traffic Engineering: AS_PATH prepending、MED、community で主/副経路と負荷分散を制御。
Valley-Free Routing: peering契約は「自社顧客経路のみを互いに広告」が前提で、最短経路では表現不能。
結果としてBGPは技術的最適ではなく経済的・政治的に受容可能な経路を探す。これは欠陥ではなく、75,000組織が自発協力するための必須機能。
Q2. Peeringと Transitの違いと、Tier 1が Peeringのみを行う理由は?
A. Transit = 顧客がプロバイダーに代金を支払い、インターネット全体への到達性を得る。Peering = 両ASが互いの顧客間トラフィックを直接交換、通常無料。
Transit: メトロで 1 Gbps あたり月 2,000〜10,000。Peering: IXPポート月 $500〜5,000、private は cross-connect 料金のみ、トラフィックは無料。
Tier 1 = 「Transit を購入せず全インターネットへ到達できるAS」。AT&T、Verizon、Lumen (Level3)、Cogent、NTT、Telia、Deutsche Telekom、Tata など約12〜20社。
Peeringのみの理由:
- 定義上、Transitを買えば Tier 1 でなくなる。
- Settlement-free peering が相互の対等性を担保。支払いは従属を意味する。
- 自社バックボーンと顧客基盤で既に全インターネットに到達している。
- ビジネスは他社へのTransit販売。購入すれば利益が削れる。
Peeringには対称的なトラフィック・地理・規模が要求される。非対称な要求 (Netflix が大量送信) は拒否またはpaid peeringに変換される (2014 Netflix / Comcast)。
Tier 1の関係は脆い。2005 Cogent vs Level 3 では Level 3 が Cogent を depeer し、3週間インターネットが分断された。「一つのインターネット」は政治的合意に依存している。
Hyperscaler (Google、Facebook、Netflix、Amazon) が自社グローバル網を持ち、事実上 Tier 1 と対等に。伝統的 Tier 1 よりコンテンツ網の影響力が増した。
Q3. BGP Hijackingはどう起き、RPKIはどう防ぐのか?
A. BGPは1980年代設計で暗黙の信頼を前提。広告された prefix が本当にそのASのものか検証しない。
Prefix Hijacking: 攻撃者が他者のprefixを自分のものとして広告。BGPはより具体的な prefix を優先するため、8.8.8.0/25 を出せば Google の 8.8.8.0/24 に勝つ。
AS Path Manipulation: 偽の AS_PATH を広告し、被害ASとの接続を偽装。
Route Leak: peer の経路を誤って transit へ流す (2019 Verizon)。
事例: 2008 Pakistan / YouTube、2018 Amazon Route 53 の暗号資産ウォレット詐取、2021 Twitter。
RPKI (2011):
- RIRがprefixとASNの対応に証明書を発行。
- 所有者が ROA を公開。
- Validator が RPKI リポジトリを取得しルータへ供給。
- ルータは BGP UPDATE を ROA と照合: Valid / Invalid / NotFound。
- Invalid は拒否。
限界:
- Origin のみ検証、経路中間の改竄は検出不可。
- 2025年時点で prefix カバー率は約50%。
- ROA 記述ミスで正当経路が invalid になる事故 (Cloudflare 2019)。
BGPsec は経路全体を署名するが、CPU・メモリコストと全ルータ更新の必要性からほぼ未展開。
補完策: IRR フィルタリング、BGPStream / RIPE RIS / Cloudflare Radar などのモニタリング、MANRS (2025年で800+ AS がベストプラクティスに参加)。
結論: BGPは長く不完全なまま残る。重要システムは暗号化・認証・モニタリングによる多層防御が必須。
Q4. Anycastはどうやって「一つのIP、複数の場所」を実現するのか?
A. 同じ prefix を複数拠点から BGP で広告。各クライアントの ISP は通常の BGP Path Selection で最寄りを選ぶ (通常はAS hop 最短)。
Cloudflare: 1.1.1.0/24 を同一 AS 13335 の 300+ POP から広告。
韓国ユーザー → Tokyo POP
英国ユーザー → London POP
米国ユーザー → Virginia POP
BGP の「近さ」はAS hop基準で物理距離とは限らない。ローカル ISP の peering 選択により意外な POP に行くこともある。
用途: DNS (1.1.1.1、8.8.8.8)、CDN、DDoS吸収、NTP、QUIC/HTTP/3。
TCPは歴史的に難しかった。経路がセッション中に変われば RST。解決策: sticky routing (短命フローなら問題小)、session sync (高コストで稀)、L4 LB を anycast VIP 背後に配置、QUIC の connection ID で IP 変化に耐性。
Cloudflare 設計: すべての顧客が同じ anycast IP 帯、すべての POP がすべての顧客を処理、POP追加で自動負荷分散。効果: 平均 50ms 未満のグローバル遅延、自動 failover、エッジ全体で DDoS 吸収。
トレードオフ: ルーティングが非決定的でデバッグ困難、BGP専門性が必要、全 POP にデータ同期が必要、国際経路が奇妙になることも。
Anycast は「複数箇所から広告する」だけで、40年前のプロトコルを現代グローバルサービスの基盤に変える小さな発想の大きな成果。ユーザーには 1.1.1.1 しか見えず、BGP が裏で最適 POP を選ぶ。
Q5. 2021年 Facebook 6時間障害の詳細な原因は?
A. 2021-10-04 15:40 UTC、Facebook のエンジニアがバックボーン容量評価のコマンドを実行。設定検証システムのバグで危険なバリアントが通過し、Facebook の DNS サーバへ到達する BGP 経路がすべて削除された。
DNS サーバには安全機構が組み込まれていた: バックボーンとの接続が切れると古い応答を漏らさないよう、自身の BGP 広告を withdraw する。平時は正しい挙動だったが、全 DNS サーバが同時に隔離されて同時に withdraw した結果、Facebook、Instagram、WhatsApp、Messenger の DNS が解決不能に。
連鎖的影響:
- 社内ツール (VPN、SSO、メール、Workplace) が全部 facebook.com 上で動いており、エンジニアはリモートでログインできず。
- データセンターのカードキーが Facebook 認証 API 依存で、物理的にも入れず。
- エンジニアは Twitter と Discord で調整。
復旧には現地派遣、ルータ手動再構成、トラフィック雪崩を避けるための段階的 BGP 再広告が必要。全面復旧は 21:05 UTC、約6時間。
Facebook の post-mortem による改善: 設定検証の強化、BGP非依存の out-of-band 管理、段階的な DNS withdraw、バッジシステムの本番認証からの分離、社内ツールの公開ドメインからの独立。
業界の教訓:
- Blast radius — 一つのコマンドが組織全体を破壊してはならない。
- 依存循環 — 復旧ツールが壊れたサービスに依存すると直せない。
- BGP == 存在 — BGP が落ちれば物理的に健全でもインターネットから消える。
- 変更が原因 — 大規模障害のほとんどは直近の変更。
- Post-mortem 文化 — Facebook が公開したからこそ業界全体が学べた。
類似例: AWS S3 2017 (タイポ)、Slack 2022 (ネットワーク設定)、Google Cloud 2020 (認証)。パターンは共通、自動化が小さなミスを世界規模の障害に拡大する。
BGPはインターネットで最も本質的かつ最も脆い層の一つ。
まとめ
要点
- AS: 75,000+ のインターネット構成単位。
- BGP: ポリシーベース Path Vector プロトコル。
- Peering vs Transit: インターネットの経済構造。
- Path Selection: 多段の意思決定。
- RPKI: Route Origin の暗号学的検証。
- Anycast: BGPによるグローバル分散。
- Hijacking: 信頼ベース BGP の脆弱性。
- Outages: BGPミスの甚大な影響。
BGPが教えるもの
BGPは分散システムの極限例:
- 75,000の独立組織が自発的に協力。
- 中央権限なし。
- 経済と政治が技術を支配。
- コンセンサスアルゴリズムなしで収束。
- セキュリティは後付け。
40年以上動作していること自体が奇跡。BGPを理解することは、「インターネット」が実は数万の契約、十数のTier 1、数百のIXP、数百万のprefix、毎秒数千のBGP更新を、合意だけで結びつけた存在だと理解することである。
次にパケットが画面に届くとき、その経路の各ホップには金と政治とポリシーの決定がある。BGPはこの奇跡を当たり前の速度で実現し、同時に脆さも抱えている。