3-9 BGP Confederation — AS を sub-AS に分割する iBGP full-mesh 問題の解
iBGP full-mesh 問題のもう一つの解 RFC 5065 の BGP Confederation を扱う。AS を sub-AS に分割する仕組みと AS_PATH の confed-sequence を、CML2.9 の sub-AS 構成で実機検証する。
1. 前節の振り返りと本節の内容
3-7 Route Reflector では、3-6 BGP §13 で残した iBGP full-mesh 問題の解として Route Reflector (RR、RFC 4456) を扱いました。RR は「iBGP 学習経路を他の iBGP に再広告しない」という規約を 1 ヶ所だけ意図的に破る装置で、スター型構造により n×(n-1)/2 本必要だった iBGP セッションを n 本に圧縮し、Cluster ID / Originator ID でループを防ぐ手法でした。3-8 BGP community 属性では RFC 1997 の community を扱い、well-known community (no-export / no-advertise / local-AS) の伝搬範囲、任意 community と route-map の連携を実機検証しました。3-8 では local-AS (no-export-subconfed) の停止挙動を概念紹介に留めました。Confederation を組まない単純 AS 構成のラボだったため、local-AS の実機検証は Confederation を扱う節への宿題として残しています。
本節で扱う BGP Confederation (RFC 5065) は、RR と並ぶ iBGP full-mesh 問題のもう一つの解です。RR がスター型のハブで iBGP 規約の破りどころを最小化するのに対し、Confederation は 1 つの AS を複数の sub-AS (member-AS) に論理分割し、sub-AS 間を eBGP のように振る舞わせる ことで、AS 全体での full-mesh を回避します。外部から見れば全体が 1 つの AS に見える点が Confederation の本質で、この「外部には単一 AS、内部は複数 sub-AS」という二面性を、AS 番号設計と AS_PATH の挙動から整理します。
本節では 3-8 で宿題として残した local-AS community を、Confederation 構成で実機検証します。local-AS (no-export-subconfed) は「経路を sub-AS の外 (Confederation 内の他 member-AS や外部) に広告しない」well-known community で、sub-AS という単位が存在する Confederation 環境でこそ停止位置の違いが際立ちます。本節で Confederation を組むことにより、no-export (AS の外で停止) と local-AS (sub-AS の外で停止) の停止位置の違いを 1 つのラボで観察できるようになります。
本節の構成は次のとおりです。§2 で iBGP full-mesh 問題と Confederation の位置づけを RR との対比で導入し、§3 で Confederation の AS 番号設計 (親 ID と sub-AS の関係)、§4 で confederation peer と AS_PATH の confed-sequence、§5 で local-AS community を整理します。§6 で CML2.9 上のラボトポロジを設計し、§7〜§10 で Phase A-D の実機検証 (Confederation baseline と AS_PATH の観察 / local-AS の停止位置 / confed peer の属性扱い / 親 AS 番号の外部への見え方) を行います。続く §11 の Phase E で confed peer 越えの next-hop の既定挙動と next-hop-self の効果を before/after で分離し、§12 の Phase F で local-AS と no-export の停止位置を同一 Confederation 上で並列対照します。§13 で教科書記述と IOS-XE 17.x 実装のギャップを「落とし穴・補足」として整理し、§最終節で 3-10 以降の予告を扱います。
2. iBGP full-mesh 問題と Confederation の位置づけ
iBGP full-mesh 問題は 3-6 §13 / 3-7 §2 で扱ったとおり、iBGP が学習経路を他の iBGP 隣接に再広告しない という規約に由来します。この規約のもとで AS 内の全ルータが互いの経路を学習するには、n 台のルータで n×(n-1)/2 本の iBGP セッションを張る完全グラフ構成が必要となります。100 台規模で 4950 本に達する組合せ爆発であり、大規模 AS では成立しません。
この問題に対し、3-7 で扱った Route Reflector は AS 内に RR / Client の階層 (tier) を作る 解法でした。RR 1 台が全クライアントの経路を反射するスター型構造により、iBGP 規約の破りどころを RR 1 ヶ所に集約します。これに対し本節の Confederation は、AS を複数の sub-AS に論理分割し、sub-AS 間を eBGP 的に扱う 解法です。両者はどちらも iBGP full-mesh の組合せ爆発を避ける目的を共有しますが、解き方の方向が異なります。
組合せ爆発の緩和を数値で見ると次のとおりです。6 台のルータを 1 つの AS にまとめると、iBGP full-mesh は 6×5/2 = 15 本のセッションを必要とします。これを 2 つの sub-AS (3 台ずつ) に分割すると、各 sub-AS 内の full-mesh は 3×2/2 = 3 本ずつで計 6 本、sub-AS 間を confederation peer 1 本で繋いで合計 7 本まで減ります。sub-AS 内では依然として full-mesh が必要ですが、AS 全体を 1 つの full-mesh にする場合と比べてセッション数が大きく減少します。
Confederation と RR の使い分けは、論理的境界の必要性で説明できます。RR は実装が単純で大規模 ISP の内部に広く採用される一方、Confederation は AS 内に組織分割や合併などの論理的境界を持たせたい構成 で使われます。sub-AS という単位がそのまま運用部門やベンダー境界に対応する場合や、外部 BGP 隣接を変えずに内部トポロジを段階的に改造したい場合に、Confederation の AS 分割が役立ちます。RR と Confederation を組み合わせる構成 (sub-AS 内に RR cluster を置く) も実在しますが、本節の範囲外とします。
3. Confederation の AS 番号設計
Confederation では 3 種類の AS 番号 が登場し、その関係が初学者には混同されやすい設計です。3 種類とは、親 (公開) AS 番号 = bgp confederation identifier、自分の sub-AS 番号 = router bgp <sub-as> で指定する AS 番号、他の sub-AS 番号 = bgp confederation peers で列挙する番号です。
ここで最も重要な点は、sub-AS には親 AS とは独立した別の AS 番号を割り当てる ことです。本ラボでは親 (公開) AS 番号を 65020、2 つの sub-AS をそれぞれ 65001 / 65002 とします。sub-AS 番号 65001 / 65002 は、親 65020 とは無関係に、プライベート AS 番号の範囲 (RFC 6996、64512-65534) から別々に割り当てた独立した AS 番号です。
sub-AS を 65020.1 のような表記で「AS65020 の sub 1」と考えるのは誤りです。65020.1 のような表記は 4-byte AS 番号 (asdot 形式) を表すものであって、Confederation の sub-AS とは無関係 です。Confederation の sub-AS は親番号から派生した子番号ではなく、それぞれが独立した 1 つの AS 番号です。65001 と 65002 は番号として親 65020 と何の関係もなく、たまたま別々に選んだ private AS 番号に過ぎません。
各ルータの AS 番号設定は次のとおりとなります。Confederation の入口となる R2a は sub-AS 65001、出口となる R2b は sub-AS 65002 に配属し、両者が親 ID 65020 を共有します。
! R2a (sub-AS 65001)
router bgp 65001 ! ★ BGP プロセスは sub-AS 番号で起動
bgp confederation identifier 65020 ! ★ 親 (公開) AS 番号
bgp confederation peers 65002 ! ★ 他の sub-AS 番号! R2b (sub-AS 65002)
router bgp 65002 ! ★ BGP プロセスは sub-AS 番号で起動
bgp confederation identifier 65020 ! ★ 親 (公開) AS 番号 (R2a と同一)
bgp confederation peers 65001 ! ★ 他の sub-AS 番号router bgp には sub-AS 番号 (65001 / 65002) を書き、bgp confederation identifier には親 ID (65020) を書く、という対応が Confederation 設定の骨格です。R2a と R2b は異なる sub-AS 番号で BGP プロセスを起動しながら、同じ confederation identifier 65020 を共有することで、1 つの Confederation の構成員となります。この親 ID 65020 が、外部 AS から見たときの公開 AS 番号となります。
4. confederation peer と AS_PATH の confed-sequence
confederation peer (confed peer) は、同じ Confederation 内の異なる sub-AS に属する BGP 隣接です。本ラボでは R2a (sub-AS 65001) と R2b (sub-AS 65002) が confed peer の関係となります。confed peer は bgp confederation peers で相手の sub-AS 番号を宣言したうえで、通常の neighbor <ip> remote-as <相手の sub-AS> でピアリングします。
confed peer の設定は eBGP と同じ形を取ります。R2a から見た R2b は neighbor 10.0.22.2 remote-as 65002 で、相手の sub-AS 番号 65002 を remote-as に指定します。bgp confederation peers 65002 を宣言してあるため、IOS-XE はこの隣接を「外部 AS への eBGP」ではなく「Confederation 内の別 sub-AS への confed peer」として扱います。両者を見分けているのは confederation peers の宣言の有無です。
confed peer を経路が越えるとき、AS_PATH には confed-sequence と呼ばれる特別なセグメントが追加されます。通常の eBGP では AS 番号が AS_PATH に裸の数字で積まれますが、confed peer を越えるときは sub-AS 番号が 括弧で囲まれた 形 ((65001) のように) で AS_PATH に入ります。この括弧付きセグメントが confed-sequence で、「これは Confederation 内部の sub-AS を越えた記録であり、外部の AS 番号ではない」ことを表します。
経路 10.10.1.0/24 が R1 から各ルータへ伝わるときの AS_PATH の変化は次のとおりです。
- R1 (AS65010、origin): AS_PATH は空 (locally originated)
- R2a (sub-AS 65001): AS_PATH =
65010— 外部 eBGP で R1 から受信し、AS65010 が積まれる - R2b (sub-AS 65002): AS_PATH =
(65001) 65010— ★ confed peer (R2a → R2b) を越えて sub-AS 65001 が括弧付きで入る (confed-sequence) - R3 (AS65030): AS_PATH =
65020 65010— ★ Confederation を出る eBGP 境界で confed-sequence の(65001)が剥がれ、親 ID 65020 が積まれる - R4 (AS65040): AS_PATH =
65030 65020 65010— R3 から eBGP で受信し AS65030 が積まれる
ここで最も重要なのは、confed-sequence の括弧は Confederation 内部でだけ見え、Confederation を出る eBGP 境界で剥がれる 点です。R2b では (65001) 65010 と sub-AS 65001 が見えていますが、R2b → R3 の外部 eBGP 境界を越える瞬間に、内部の sub-AS 番号 (65001 / 65002) はすべて取り除かれ、代わりに親 ID 65020 が 1 つだけ AS_PATH に積まれます。結果として R3 以降では 65020 65010 となり、Confederation 内部に 2 つの sub-AS があったことは外部から一切見えません。これが「外部からは単一の AS65020 に見える」仕組みの実機証跡で、§7 の Phase A で観察します。
confed peer は「eBGP のように設定し、iBGP のように属性を扱う」ハイブリッドな性質を持ちます。設定面では remote-as に相手 sub-AS 番号を書く eBGP の形を取りますが、属性面では iBGP 寄りの扱いとなります。具体的には、Administrative Distance (AD) は通常の eBGP の 20 ではなく iBGP と同じ 200、LOCAL_PREF は通常の eBGP では隣接 AS をまたぐと消えるところを confed peer 越えでは保持され、MED も保持されます。この AD = 200 は本ラボの実機 RIB でも確認でき (§9 の Phase C で show ip route を引用)、Cisco IOS-XE が confederation-external 経路を internal 扱いとする挙動を示します。この二面性の詳細は §9 の Phase C で実機確認します。
5. local-AS community (no-export-subconfed)
local-AS community (no-export-subconfed) は、3-8 §3 で概念紹介に留めた well-known community です。RFC 1997 が予約した 32-bit 値 (0xFFFFFF03) を持ち、厳密には「この経路を external BGP peer に広告しない (その external peer には Confederation 内の他 member-AS の peer も含む)」という意味を持ちます。Confederation を組んだ環境では、これが「経路を sub-AS の外に出さない」挙動として最も分かりやすく観察できるため、本節の Confederation 構成で実機検証の対象とします (なお Confederation を組まない通常 AS でも、no-export-subconfed は eBGP peer への広告抑止として実質 no-export と同様に作用します。「sub-AS が無ければ全く無意味」というわけではなく、Confederation 環境でこそ停止位置の違いが際立つ、と理解するのが正確です)。
local-AS の停止位置を、3-8 で扱った no-export と対比すると次のとおりです。
| well-known community | 意味 | 止まる境界 | 伝搬する範囲 |
|---|---|---|---|
| no-export | AS の外に広告しない | eBGP 境界 (AS の外、Confederation の外部 eBGP) で停止 | 同一 AS 内の iBGP、Confederation の sub-AS 間にも伝わる |
| local-AS (no-export-subconfed) | sub-AS の外に広告しない | Confederation の sub-AS 境界で停止 | 同一 sub-AS 内には伝わる |
両者の違いは停止位置が一段ずれる点にあります。no-export は AS の外で止まるため、Confederation 内では sub-AS 間 (confed peer) を越えて伝搬し、Confederation を出る外部 eBGP 境界 (R2b → R3) で停止します。これに対し local-AS は sub-AS の外で止まるため、no-export より一段内側の sub-AS 境界 (R2a → R2b の confed peer) で停止します。no-export が「Confederation を出る最後の境界」で止まるのに対し、local-AS は「Confederation 内部の最初の sub-AS 境界」で止まる、という関係です。
本節の構成では、R1 (AS65010) が local-AS を付与した経路が R2a (sub-AS 65001) に届いた後、R2a → R2b の confed peer 境界で停止することを §8 の Phase B で観察します。IOS-XE 17.x では、local-AS が付いた経路は 経路自体が sub-AS 境界で止まります。community だけが剥がれて経路が伝搬するのではなく、R2a (sub-AS 65001) までで止まり、confed peer を越えて R2b に出ません。この実機挙動の詳細は §11 の落とし穴 4 に記録します。
6. ラボトポロジ
本節のラボは、3-8 の transit chain (AS65010 → AS65020 → AS65030 → AS65040) を改造し、AS65020 を Confederation 化して内部を 2 つの sub-AS に分割 する構成とします。Confederation の AS_PATH 挙動と local-AS の停止位置が、いずれも sub-AS 境界をまたぐ挙動 であることを軸に設計します。
トポロジは次のとおりです。
AS65010 (R1) が origin、Confederation AS65020 (R2a + R2b) が transit、AS65030 (R3) が edge、AS65040 (R4) が far-end という構成です。Confederation AS65020 の内部は 2 つの sub-AS に分かれ、R2a が sub-AS 65001 (Confederation の eBGP 入口)、R2b が sub-AS 65002 (Confederation の eBGP 出口) を担います。R2a と R2b は confed peer の関係で、直結 P2P リンク (10.0.22.0/30) でピアリングします。R1 が 10.10.1.0/24 を network 文で広告する起点となります。
外部の R1 / R3 は、Confederation の入口 / 出口を 親 ID 65020 としてピアリングします。R1 は R2a を neighbor 10.0.12.2 remote-as 65020、R3 は R2b を neighbor 10.0.23.1 remote-as 65020 で見ます。R1 / R3 からは sub-AS 番号 (65001 / 65002) は一切見えず、Confederation 全体が単一の AS65020 に見える点が Confederation の本質となります。
ノード総数は csr1000v 5 台 + unmanaged_switch 1 + external_connector 1 の計 7 ノードで、3-7 / 3-8 と同じ規模です。CML2.9 (8 cores) で並列起動可能な範囲となります。
アドレッシングは次のとおりとします。AS 番号のみを 3-8 から Confederation 化し (R2a / R2b が sub-AS 配属、親 ID = 65020)、Lo0 / 直結 /30 / Mgmt-vrf は 3-8 を踏襲します。
| 機器 | router bgp | confederation identifier | confederation peers | Lo0 (Router ID) | Lo10 (広告 prefix) | 直結リンク |
|---|---|---|---|---|---|---|
| R1 | 65010 | — | — | 1.1.1.1/32 | 10.10.1.0/24 | Gi2: 10.0.12.1/30 (→ R2a) |
| R2a | 65001 | 65020 | 65002 | 2.2.2.2/32 | — | Gi2: 10.0.12.2/30 (→ R1)、Gi3: 10.0.22.1/30 (→ R2b) |
| R2b | 65002 | 65020 | 65001 | 22.22.22.22/32 | — | Gi2: 10.0.22.2/30 (→ R2a)、Gi3: 10.0.23.1/30 (→ R3) |
| R3 | 65030 | — | — | 3.3.3.3/32 | 10.30.3.0/24 | Gi2: 10.0.23.2/30 (→ R2b)、Gi3: 10.0.34.1/30 (→ R4) |
| R4 | 65040 | — | — | 4.4.4.4/32 | 10.40.4.0/24 | Gi2: 10.0.34.2/30 (→ R3) |
R2a ↔ R2b は直結 /30 (10.0.22.0/30) でピアリングし、neighbor には相手の直結 IP を指定します。confed peer を直結 IP でピアリングするため ebgp-multihop は不要です。loopback でピアリングする場合は eBGP 的扱いのため ebgp-multihop が必要となりますが、本ラボは検証の焦点を Confederation の AS_PATH と local-AS に絞るため、直結 P2P でシンプルに保ちます。この設計判断は §11 の落とし穴で改めて言及します。
R1 の day0 config 骨子は次のとおりです。Phase A では route-map なしで素の広告を行い、Phase B で local-AS を投入します。R1 は外部 AS のため、相手 (R2a) を親 ID 65020 でピアリングします。
! R1 (AS65010、origin)
router bgp 65010
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor 10.0.12.2 remote-as 65020 ! ★ 外部からは Confederation = AS65020 に見える
neighbor 10.0.12.2 description eBGP_to_R2a
!
address-family ipv4
network 10.10.1.0 mask 255.255.255.0
neighbor 10.0.12.2 activate
neighbor 10.0.12.2 send-community
exit-address-familyR2a は sub-AS 65001 で、Confederation の eBGP 入口 + confed peer を担います。外部の R1 とは通常の eBGP、R2b とは confed peer でピアリングします。
! R2a (sub-AS 65001、eBGP 入口 + confed peer)
router bgp 65001
bgp router-id 2.2.2.2
bgp log-neighbor-changes
bgp confederation identifier 65020 ! ★ 親 (公開) AS 番号
bgp confederation peers 65002 ! ★ 他の sub-AS
!
neighbor 10.0.12.1 remote-as 65010 ! 通常の eBGP (外部 AS65010)
neighbor 10.0.12.1 description eBGP_to_R1
neighbor 10.0.22.2 remote-as 65002 ! ★ confed peer (相手 sub-AS 番号、直結 IP)
neighbor 10.0.22.2 description confed_peer_to_R2b
!
address-family ipv4
neighbor 10.0.12.1 activate
neighbor 10.0.12.1 send-community
neighbor 10.0.22.2 activate
neighbor 10.0.22.2 send-community
neighbor 10.0.22.2 next-hop-self ! confed peer への next-hop 扱いは Phase C で要否確認
exit-address-familyR2b は sub-AS 65002 で、confed peer + Confederation の eBGP 出口を担います。R2a とは confed peer、外部の R3 とは通常の eBGP でピアリングします。
! R2b (sub-AS 65002、confed peer + eBGP 出口)
router bgp 65002
bgp router-id 22.22.22.22
bgp confederation identifier 65020
bgp confederation peers 65001
!
neighbor 10.0.22.1 remote-as 65001 ! ★ confed peer (相手 sub-AS 番号、直結 IP)
neighbor 10.0.22.1 description confed_peer_to_R2a
neighbor 10.0.23.2 remote-as 65030 ! 通常の eBGP (外部 AS65030)
neighbor 10.0.23.2 description eBGP_to_R3
!
address-family ipv4
neighbor 10.0.22.1 activate
neighbor 10.0.22.1 send-community
neighbor 10.0.23.2 activate
neighbor 10.0.23.2 send-community
neighbor 10.0.23.2 next-hop-self
exit-address-familyR3 は AS65030 の edge で、R2b を親 ID 65020 でピアリングします。R4 は AS65040 の far-end で、Confederation を出た経路の AS_PATH を遠端で確認する役割を担います。R3 / R4 の骨子は次のとおりです。
! R3 (AS65030、edge)
router bgp 65030
bgp router-id 3.3.3.3
neighbor 10.0.23.1 remote-as 65020 ! ★ 外部からは Confederation = AS65020 に見える
neighbor 10.0.34.2 remote-as 65040
!
address-family ipv4
network 10.30.3.0 mask 255.255.255.0
neighbor 10.0.23.1 activate
neighbor 10.0.23.1 send-community
neighbor 10.0.34.2 activate
neighbor 10.0.34.2 send-community
exit-address-family検証フェーズは Phase A-F の 6 段階で進めます。
- Phase A: Confederation baseline と AS_PATH の confed-sequence 観察。各 sub-AS で 10.10.1.0/24 の AS_PATH を確認
- Phase B: local-AS community の停止位置。R1 で
set community local-ASを投入し sub-AS 境界での挙動を観察 - Phase C: confed peer の neighbor 種別と next-hop / AD の扱い。eBGP と iBGP のどちら寄りかを確認
- Phase D: Confederation identifier (親 AS) の外部への見え方。R3 視点で sub-AS が隠蔽されることを確認
- Phase E: confed peer 越えの next-hop の既定挙動 (unchanged) と
next-hop-selfの効果を、同一 prefix の before/after で分離 - Phase F: local-AS と no-export の停止位置を、同一 Confederation 上に 2 prefix を同時に流して並列対照
7. Phase A: Confederation baseline と AS_PATH の観察
Phase A では、local-AS を付与しない素の状態で 10.10.1.0/24 が Confederation を越えて R4 まで伝搬すること、および各ルータでの AS_PATH の変化を確認します。観察の核は confed peer (R2a → R2b) を越えると AS_PATH に confed-sequence の括弧が入り、Confederation を出る eBGP 境界 (R2b → R3) で剥がれて親 ID 65020 に統一される という挙動です。この baseline が §3〜§4 で整理した AS 番号設計と confed-sequence の理論を実機で裏付けます。
観察ポイントは 3 つです。第一に、各ルータの show ip bgp summary で全 BGP セッションが Established であり、R2a の neighbor 10.0.22.2 (R2b) が AS65002 (sub-AS) として、R1 / R3 の neighbor が AS65020 (親 ID) として表示されることを確認します。第二に、R1 / R2a / R2b / R3 / R4 で show ip bgp 10.10.1.0/24 の AS_PATH を辿り、R2b で (65001) 65010 の括弧が、R3 で 65020 65010 の親 ID への統一が現れることを確認します。第三に、R4 まで 10.10.1.0/24 が届き、AS_PATH が 65030 65020 65010 となることを確認します。
R2a 視点では、外部 eBGP で R1 から受信した経路の AS_PATH が 65010 となります。valid, external, best のマークが、これが外部 eBGP 由来の経路であることを示します。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
3
Refresh Epoch 1
65010
10.0.12.1 from 10.0.12.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on May 30 2026 17:10:18 UTC
R2a#R2b 視点では、confed peer (R2a → R2b) を越えた経路の AS_PATH に sub-AS 65001 が括弧付きで入り、(65001) 65010 となります。この括弧 (confed-sequence) が Confederation 内部での sub-AS 越えの証跡で、経路マークも external ではなく confed-external に変わっています。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
3
Refresh Epoch 1
(65001) 65010
10.0.22.1 from 10.0.22.1 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
rx pathid: 0, tx pathid: 0x0
Updated on May 30 2026 17:11:53 UTC
R2b#R3 視点では、Confederation を出る eBGP 境界を越えた経路の AS_PATH から confed-sequence が剥がれ、親 ID 65020 に統一されて 65020 65010 となります。R2b での (65001) 65010 と R3 での 65020 65010 を対比すると、Confederation 境界で sub-AS が隠蔽される瞬間が 2 つの出力の差として読み取れます。経路マークも confed-external から通常の external に戻ります。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
65020 65010
10.0.23.1 from 10.0.23.1 (22.22.22.22)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on May 30 2026 17:13:16 UTC
R3#遠端の R4 では、R3 から eBGP で受信し AS_PATH が 65030 65020 65010 となります。ここでも sub-AS 番号 (65001 / 65002) は現れず、Confederation が単一の AS65020 として AS_PATH に積まれていることを確認します。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 2
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 2
65030 65020 65010
10.0.34.1 from 10.0.34.1 (3.3.3.3)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on May 30 2026 17:14:49 UTC
R4#R2b の show ip bgp では、confed peer (R2a) 由来の経路の Path 列が (65001) 65010 i と表示され、括弧付きの confed-sequence を含みます。この経路マーク (詳細表示では confed-external) が、通常の eBGP / iBGP とは異なる confed peer 由来の経路であることを示します。一方、外部 eBGP で R3 から受信した 10.30.3.0/24 / 10.40.4.0/24 の Path 列には括弧がなく、両者の違いが Path 列の表記で読み分けられます。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
3
Refresh Epoch 1
(65001) 65010
10.0.22.1 from 10.0.22.1 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
rx pathid: 0, tx pathid: 0x0
Updated on May 30 2026 17:11:53 UTC
R2b#show ip bgp
BGP table version is 4, local router ID is 22.22.22.22
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.1.0/24 10.0.22.1 0 100 0 (65001) 65010 i
*> 10.30.3.0/24 10.0.23.2 0 0 65030 i
*> 10.40.4.0/24 10.0.23.2 0 65030 65040 i
R2b#8. Phase B: local-AS community の停止位置
Phase B では、R1 で set community local-AS を投入し、local-AS 付き経路が Confederation の sub-AS 境界で止まることを観察します。R1 に route-map を投入する設定骨子は次のとおりです。
route-map SET_COMM permit 10
set community local-AS ! sub-AS の外に広告しない well-known community
!
router bgp 65010
address-family ipv4
neighbor 10.0.12.2 activate
neighbor 10.0.12.2 send-community
neighbor 10.0.12.2 route-map SET_COMM out
exit-address-family期待動作は、local-AS 付き経路が sub-AS 65001 内 (R2a) には届くが、R2a → R2b の confed peer 境界 (sub-AS 境界) で止まる ことです。これは §5 で整理した「local-AS は sub-AS の外で停止する」という伝搬範囲ルールに従う挙動です。3-8 の no-export が AS の外 (R2b → R3 の eBGP 境界) で止まったのに対し、local-AS は一段内側の sub-AS 境界 (R2a → R2b) で止まる点が、両者の停止位置の違いとなります。
観察ポイントは 2 つです。第一に、R2a で show ip bgp 10.10.1.0/24 の community 欄に local-AS が表示され、sub-AS 65001 内では経路を受信できていることを確認します。第二に、R2b で 10.10.1.0/24 がどうなるかを確認します。ここで重要なのは、local-AS が 経路自体を sub-AS 境界で止めるのか、それとも経路は届くが community だけが剥がれるのか を実機で正確に観察する点です。IOS-XE 17.x では、経路自体が R2a (sub-AS 65001) で止まり、confed peer 境界を越えて R2b に出ません。community だけが剥がれて経路が伝搬するのではなく、経路そのものが sub-AS 境界で停止します。これは local-AS = no-export-subconfed の正確な挙動で、§11 の落とし穴 4 に記録します。
R2a が R1 から local-AS 付き経路を受信した状態は次のとおりです。sub-AS 65001 内のため受信は成立し、Community: local-AS が保持されます。注目すべきは 2 行目の not advertised outside local AS と 4 行目の Not advertised to any peer で、R2a がこの経路を confed peer (R2b) を含むどの隣接にも広告しないことが明示されています。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 3
Paths: (1 available, best #1, table default, not advertised outside local AS)
Not advertised to any peer
Refresh Epoch 1
65010
10.0.12.1 from 10.0.12.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: local-AS
rx pathid: 0, tx pathid: 0x0
Updated on May 30 2026 17:19:17 UTC
R2a#R2b 視点では、confed peer 境界 (sub-AS 65001 → 65002) を越えた状態を確認します。% Network not in table が示すとおり、10.10.1.0/24 は R2b の BGP テーブルに存在しません。R2b のテーブルには 10.30.3.0/24 と 10.40.4.0/24 のみが載り、local-AS 付き経路は R2a で止まって confed peer を越えていません。これが「経路は R2a (sub-AS 65001) までで止まり、R2b に出ない」ことの実機証跡です。
show ip bgp 10.10.1.0/24
% Network not in table
R2b#show ip bgp
BGP table version is 5, local router ID is 22.22.22.22
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.30.3.0/24 10.0.23.2 0 0 65030 i
*> 10.40.4.0/24 10.0.23.2 0 65030 65040 i
R2b#R3 視点でも、当然ながら 10.10.1.0/24 は届きません。R2b で既に止まっているため、その先の外部 eBGP 境界 (R2b → R3) より手前で経路が消えています。R3 のテーブルには自局の 10.30.3.0/24 と R4 由来の 10.40.4.0/24 のみが載ります。
show ip bgp 10.10.1.0/24
% Network not in table
R3#show ip bgp
BGP table version is 5, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.30.3.0/24 0.0.0.0 0 32768 i
*> 10.40.4.0/24 10.0.34.2 0 0 65040 i
R3#3-8 の no-export が AS の外 (R2b → R3 の eBGP 境界) で止まったのに対し、local-AS は一段内側の sub-AS 境界 (R2a → R2b の confed peer) で止まります。3-8 で宿題として残した local-AS の停止挙動は、この Phase B の実機 capture で「経路自体が sub-AS 境界で止まる」と確定しました。
9. Phase C: confed peer の neighbor 種別と属性の扱い
Phase C では、§4 で整理した confed peer の二面性 (eBGP のように設定し iBGP のように属性を扱う) を実機で確認します。観察対象は confed peer の neighbor 種別表示、next-hop の扱い、AD / メトリックの扱いの 3 点です。
観察ポイントは 4 つです。第一に、R2a で show ip bgp neighbors 10.0.22.2 (R2b との confed peer) を確認し、neighbor 種別が external link (eBGP 風) として表示されることを見ます。第二に、R2b で 10.10.1.0/24 の next-hop が、confed peer 越えで書き換わるか保持されるかを確認します。next-hop が保持されるか書き換わるかが、eBGP 寄りか iBGP 寄りかの判断材料となります。第三に、confed peer 由来経路の confed-external マークと LOCAL_PREF の保持を確認し、属性の扱いが iBGP 寄りであることを裏付けます。第四に、R2b の show ip route で confed peer 由来経路の AD が 200 (internal 扱い)、通常 eBGP 由来経路の AD が 20 となることを対比し、AD の面でも confederation-external が iBGP 側に倒れることを確認します。
R2a 視点の confed peer の neighbor 表示は次のとおりです。1 行目の remote AS 65002, external link が示すとおり、confed peer は neighbor 種別として external link (eBGP 風) に分類されます。下部の External BGP neighbor configured for connected checks (single-hop no-disable-connected-check) は、この隣接が直結リンク上の single-hop eBGP として扱われていることを表します。設定面では eBGP の形を取っている証跡です。
show ip bgp neighbors 10.0.22.2
BGP neighbor is 10.0.22.2, remote AS 65002, external link
Description: confed_peer_to_R2b
BGP version 4, remote router ID 22.22.22.22
Neighbor under common administration
BGP state = Established, up for 00:10:07
Last read 00:00:02, last write 00:00:41, hold time is 180, keepalive interval is 60 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 1 1
Notifications: 0 0
Updates: 4 4
Keepalives: 12 13
Route Refresh: 0 0
Total: 17 18
Do log neighbor state changes (via global configuration)
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
Session: 10.0.22.2
BGP table version 4, neighbor version 4/0
Output queue size : 0
Index 3, Advertise bit 1
3 update-group member
NEXT_HOP is always this router for eBGP paths
Community attribute sent to this neighbor
Slow-peer detection is disabled
Slow-peer split-update-group dynamic is disabled
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 1 2 (Consumes 272 bytes)
Prefixes Total: 2 2
Implicit Withdraw: 0 0
Explicit Withdraw: 1 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Used as secondary: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Well-known Community: 1 n/a
Total: 1 0
Number of NLRIs in the update sent: max 1, min 0
Current session network count peaked at 2 entries at 17:15:44 May 30 2026 UTC (00:06:17.623 ago)
Highest network count observed at 2 entries at 17:15:44 May 30 2026 UTC (00:06:17.623 ago)
Last detected as dynamic slow peer: never
Dynamic slow peer recovered: never
Refresh Epoch: 1
Last Sent Refresh Start-of-rib: never
Last Sent Refresh End-of-rib: never
Last Received Refresh Start-of-rib: never
Last Received Refresh End-of-rib: never
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 0 0
Refresh End-of-RIB 0 0
Address tracking is enabled, the RIB does have a route to 10.0.22.2
Route to peer address reachability Up: 1; Down: 0
Last notification 00:11:42
Connections established 1; dropped 0
Last reset never
External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
Interface associated: GigabitEthernet3 (peering address in same link)
Transport(tcp) path-mtu-discovery is enabled
Graceful-Restart is disabled
SSO is disabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.0.22.1, Local port: 23117
Foreign host: 10.0.22.2, Foreign port: 179
Connection tableid (VRF): 0
Maximum output segment queue size: 50
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x197A03):
Timer Starts Wakeups Next
Retrans 16 0 0x0
TimeWait 0 0 0x0
AckHold 17 14 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 6 5 0x197D47
DeadWait 0 0 0x0
Linger 0 0 0x0
ProcessQ 0 0 0x0
iss: 1726117603 snduna: 1726118073 sndnxt: 1726118073
irs: 4162609676 rcvnxt: 4162610169
sndwnd: 15915 scale: 0 maxrcvwnd: 16384
rcvwnd: 15892 scale: 0 delrcvwnd: 492
SRTT: 882 ms, RTTO: 1768 ms, RTV: 886 ms, KRTT: 0 ms
minRTT: 3 ms, maxRTT: 1000 ms, ACK hold: 200 ms
uptime: 608018 ms, Sent idletime: 2335 ms, Receive idletime: 2537 ms
Status Flags: active open
Option Flags: nagle, path mtu capable
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
Rcvd: 33 (out of order: 0), with data: 18, total data bytes: 492
Sent: 34 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 16, total data bytes: 469
Packets received in fast path: 0, fast processed: 0, slow path: 0
fast lock acquisition failures: 0, slow path: 0
TCP Semaphore 0x7F1EADBFF558 FREE
R2a#next-hop の扱いは、confed peer が eBGP と iBGP のどちら寄りかを示す観察点です。RFC 5065 では、Confederation 内の confed peer 越えでは next-hop は 既定では unchanged (書き換えない) でよいとされ、必要なら policy で調整します。ただし本ラボでは R2a の confed peer 設定に neighbor 10.0.22.2 next-hop-self を投入しているため、next-hop は R2a 自身の IP に書き換わっています。次の R2b の出力で next-hop が 10.0.22.1 (= R2a の confed peer 側リンク IP) になっているのがその結果で、R1 から受信した元の next-hop 10.0.12.1 ではありません。R2a の neighbor 詳細出力にも NEXT_HOP is always this router for eBGP paths と出ており、next-hop-self が効いていることが読み取れます。一方で localpref 100 は confed peer を越えても保持されており、LOCAL_PREF の扱いは iBGP 寄りです。整理すると、confed peer の next-hop は「既定は unchanged だが policy (next-hop-self) で書き換え可能」「LOCAL_PREF / MED は保持される」というハイブリッドな性質を持ちます。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 6
Paths: (1 available, best #1, table default)
Advertised to update-groups:
3
Refresh Epoch 1
(65001) 65010
10.0.22.1 from 10.0.22.1 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
rx pathid: 0, tx pathid: 0x0
Updated on May 30 2026 17:21:19 UTC
R2b#confed peer 由来経路は confed-external とマークされ、LOCAL_PREF が保持される点を show ip bgp 全体で確認できます。10.10.1.0/24 の Path 列は (65001) 65010 i、LocPrf 列は 100 で、confed peer を越えても LOCAL_PREF 100 が保持されています。neighbor 種別は external link (eBGP 風) でありながら、LOCAL_PREF と next-hop の扱いは iBGP 寄りという二面性が、この一連の出力に表れています。
show ip bgp
BGP table version is 6, local router ID is 22.22.22.22
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.1.0/24 10.0.22.1 0 100 0 (65001) 65010 i
*> 10.30.3.0/24 10.0.23.2 0 0 65030 i
*> 10.40.4.0/24 10.0.23.2 0 65030 65040 i
R2b#AD の扱いは、R2b の show ip route で confed peer 由来経路と通常 eBGP 由来経路を対比すると明確になります。confed peer (R2a → R2b) を越えてきた 10.10.1.0/24 は [200/0] かつ type internal で、AD は iBGP と同じ 200 です。一方、外部 eBGP で R3 から学習した 10.30.3.0/24 / 10.40.4.0/24 は [20/0] で、こちらは eBGP の AD 20 となります。同じ R2b の RIB に AD 200 (confed peer 由来) と AD 20 (外部 eBGP 由来) が並ぶことで、confederation-external 経路が internal 扱いになる挙動が読み取れます。
show ip route bgp
10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks
B 10.10.1.0/24 [200/0] via 10.0.22.1, 11:54:06
B 10.30.3.0/24 [20/0] via 10.0.23.2, 12:01:38
B 10.40.4.0/24 [20/0] via 10.0.23.2, 11:59:41
R2b#show ip route 10.10.1.0
Routing entry for 10.10.1.0/24
Known via "bgp 65002", distance 200, metric 0
Tag 65001, type internal
Last update from 10.0.22.1 11:54:11 ago
Routing Descriptor Blocks:
* 10.0.22.1, from 10.0.22.1, 11:54:11 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65001
R2b#Known via "bgp 65002", distance 200 と type internal が、confed peer 由来経路を Cisco IOS-XE が internal (AD 200) として RIB に載せる証跡です。confed peer は設定こそ eBGP 風 (external link) ですが、RIB 上の AD は iBGP 側に倒れる、という二面性がここに現れます。
10. Phase D: Confederation identifier の外部への見え方
Phase D では、§3 で整理した「外部からは親 ID 65020 の単一 AS に見える」という Confederation の本質を、外部 AS の R3 視点で確認します。Phase A で R2b 視点 (Confederation 内部) の AS_PATH を見たのに対し、Phase D では R3 視点 (Confederation 外部) の AS_PATH を対比し、Confederation 境界で sub-AS が隠蔽される瞬間を 2 つの出力で証明します。
観察ポイントは 3 つです。第一に、R3 の show ip bgp summary で R2b との neighbor AS が 65020 (親 ID) であり、sub-AS 番号 (65002) が現れないことを確認します。第二に、R3 で 10.10.1.0/24 の AS_PATH が 65020 65010 であり、sub-AS 65001 / 65002 が隠蔽されていることを確認します。第三に、R2b の AS_PATH ((65001) 65010、内部) と R3 の AS_PATH (65020 65010、外部) を対比し、confed-sequence が剥がれる境界を明示します。
R3 の show ip bgp summary では、neighbor 10.0.23.1 (R2b) が AS65020 (親 ID) として表示されます。Neighbor 列の 10.0.23.1 に対する AS 列は 65020 で、sub-AS 番号 (65002) は一切現れません。R3 からは Confederation 全体が単一の AS65020 に見えています。
show ip bgp summary
BGP router identifier 3.3.3.3, local AS number 65030
BGP table version is 6, main routing table version 6
3 network entries using 744 bytes of memory
3 path entries using 408 bytes of memory
3/3 BGP path/bestpath attribute entries using 864 bytes of memory
2 BGP AS-PATH entries using 64 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 2080 total bytes of memory
BGP activity 4/1 prefixes, 4/1 paths, scan interval 60 secs
3 networks peaked at 17:15:44 May 30 2026 UTC (00:06:50.321 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.23.1 4 65020 16 17 6 0 0 00:09:17 1
10.0.34.2 4 65040 15 18 6 0 0 00:07:44 1
R3#R3 の show ip bgp 10.10.1.0/24 では、AS_PATH が 65020 65010 であり、Confederation 内部の sub-AS が隠蔽されています。(65001) の confed-sequence は既に剥がれ、親 ID 65020 に統一されています。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 6
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
65020 65010
10.0.23.1 from 10.0.23.1 (22.22.22.22)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on May 30 2026 17:21:19 UTC
R3#R2b の内部視点 ((65001) 65010) と R3 の外部視点 (65020 65010) を並べると、Confederation 境界で confed-sequence の括弧が剥がれて親 ID に統一される瞬間が、2 つの出力の差として読み取れます。この対比が、Phase A で観察した confed-sequence の挙動を「内部 / 外部」の 2 視点から確定させます。R2b では sub-AS 65001 が括弧付きで残り経路マークが confed-external であるのに対し、R3 では括弧が消えて親 ID 65020 に置き換わり経路マークが通常の external に戻っています。
R2b (Confederation 内部視点) では confed-sequence の括弧が残ります。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 6
Paths: (1 available, best #1, table default)
Advertised to update-groups:
3
Refresh Epoch 1
(65001) 65010
10.0.22.1 from 10.0.22.1 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
rx pathid: 0, tx pathid: 0x0
Updated on May 30 2026 17:21:19 UTC
R2b#R3 (Confederation 外部視点) では括弧が剥がれ、親 ID 65020 に統一されます。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 6
Paths: (1 available, best #1, table default)
Advertised to update-groups:
2
Refresh Epoch 1
65020 65010
10.0.23.1 from 10.0.23.1 (22.22.22.22)
Origin IGP, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on May 30 2026 17:21:19 UTC
R3#参考として、Confederation の運用メリットを §2 の数値と合わせて整理します。sub-AS を追加 (例: 65003) しても、新しい sub-AS を既存の sub-AS に confed peer で繋ぐだけで、親 AS 番号 (65020) は不変です。外部の R1 / R3 から見える AS 番号は 65020 のまま変わらないため、外部 BGP 隣接の設定を一切変えずに、Confederation 内部のトポロジを段階的に改造できる ことが Confederation の運用上のメリットとなります。大規模 ISP や IXP で、内部の組織分割を外部に見せずに進める用途で使われます。
11. Phase E: confed peer 越えの next-hop — 既定挙動と next-hop-self の効果を分離する
§9 の Phase C で、confed peer 越えの next-hop が R2a の next-hop-self で書き換わることを見ました。ただしあの観察は next-hop-self を投入した状態だけ を撮ったもので、「confed peer 越えで next-hop が既定でどう扱われるか」と「next-hop-self という policy が何を変えるか」が 1 つの出力に混ざっていました。Phase E では、R2a の confed peer 設定から next-hop-self を 外した baseline と 投入後 を、同一 prefix (10.10.1.0/24) で対照し、既定挙動 (unchanged) と policy 効果を分離します。3-7 Route Reflector の Phase E で next-hop 不到達の baseline と標準構成を対照したのと同じ作法です。
観察ポイントは 2 つです。第一に、受信側 R2b の show ip bgp 10.10.1.0/24 で next-hop が R1 から受信した元の値のまま (既定 unchanged) か、R2a 自身の IP に書き換わる (next-hop-self) かを確認します。第二に、広告側 R2a の show ip bgp neighbors 10.0.22.2 advertised-routes を併記し、advertised-routes ビューが何を表示するかを正確に押さえます。
まず baseline として、R2a の confed peer 設定から next-hop-self を外し、clear ip bgp 10.0.22.2 soft out で再広告します。
! R2a (confed peer から next-hop-self を撤去)
router bgp 65001
address-family ipv4
no neighbor 10.0.22.2 next-hop-self
exit-address-family
!
clear ip bgp 10.0.22.2 soft outbaseline での受信側 R2b の next-hop は、R1 から受信した元の値 10.0.12.1 のまま です。confed peer (R2a → R2b) を越えても next-hop が書き換わらないのが既定挙動 (unchanged) で、R2b はこの 10.0.12.1 への到達経路を持たないため (inaccessible) となり、no best path でベストパスに選ばれていません。3-7 の Route Reflector で next-hop 不到達の反射経路が (inaccessible) で best 落選したのと同じ構図が、Confederation の confed peer 越えでも起きています。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 7
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
(65001) 65010
10.0.12.1 (inaccessible) from 10.0.22.1 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-external
rx pathid: 0, tx pathid: 0
Updated on Jun 13 2026 00:23:06 UTC
R2b#同じ baseline で、広告側 R2a が confed peer (R2b) に広告する経路を advertised-routes で見ると、next-hop は 10.0.12.1 と表示されます。
show ip bgp neighbors 10.0.22.2 advertised-routes
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.1.0/24 10.0.12.1 0 0 65010 i
Total number of prefixes 1
R2a#次に next-hop-self を投入し、再広告します。
! R2a (confed peer に next-hop-self を投入)
router bgp 65001
address-family ipv4
neighbor 10.0.22.2 next-hop-self
exit-address-family
!
clear ip bgp 10.0.22.2 soft out投入後の受信側 R2b の next-hop は、R2a 自身の confed peer 側リンク IP 10.0.22.1 に書き換わっています。R2b はこの 10.0.22.1 に直結で到達できるため (inaccessible) が解消し、best #1 でベストパスに選ばれます。baseline の 10.0.12.1 (inaccessible) / no best path と対比すると、next-hop-self が next-hop の書き換えを通じてベストパス選定を成立させたことが、同一 prefix の before/after として読み取れます。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 8
Paths: (1 available, best #1, table default)
Advertised to update-groups:
3
Refresh Epoch 1
(65001) 65010
10.0.22.1 from 10.0.22.1 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
rx pathid: 0, tx pathid: 0x0
Updated on Jun 13 2026 00:24:31 UTC
R2b#ここで advertised-routes の表示について 1 点注意が必要です。next-hop-self を投入した後の R2a の advertised-routes でも、next-hop は baseline と同じ 10.0.12.1 のまま表示されます。
show ip bgp neighbors 10.0.22.2 advertised-routes
BGP table version is 4, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.10.1.0/24 10.0.12.1 0 0 65010 i
Total number of prefixes 1
R2a#これは表示の仕様であり、矛盾ではありません。show ip bgp neighbors <peer> advertised-routes は、ローカルの BGP テーブルに格納された経路属性 (next-hop の書き換え前の状態) を表示 します。next-hop-self は 隣接へ実際に送出するパケット上の next-hop 値だけ を書き換える機能で、ローカル BGP テーブル上の属性表示には反映されません。したがって next-hop-self の 実際の書き換え結果は、受信側 R2b の show ip bgp で見た next-hop (baseline=10.0.12.1 / 投入後=10.0.22.1) で判断するのが正確です。広告側の advertised-routes は「どの prefix を広告しているか」の確認には使えますが、書き換え後の next-hop を読むには受信側の出力を見る必要があります。
整理すると、confed peer 越えの next-hop は次のように振る舞います。
| 状態 | R2b の next-hop (受信側、真の値) | ベストパス | advertised-routes (R2a 側の表示) |
|---|---|---|---|
| 既定 (next-hop-self なし) | 10.0.12.1 (inaccessible) | no best path | 10.0.12.1 |
| next-hop-self 投入後 | 10.0.22.1 (R2a 自身) | best #1 | 10.0.12.1 (書き換え前のまま) |
confed peer の next-hop は 既定では unchanged で、policy (next-hop-self) で書き換えられる という二面性を持ちます。既定の unchanged は「next-hop が保持される」だけでなく「保持された結果 next-hop が不到達だとベストパスに選ばれない」状態を生み得る点が、Phase E の実機 baseline で確認できます。本ラボは confed peer を直結 P2P でピアリングしているため、next-hop-self を入れずとも IGP で next-hop に到達できる構成にすれば best は成立しますが、ここでは next-hop の扱いを純化して見せるために next-hop-self の有無で best が動く状態を作っています。
12. Phase F: local-AS と no-export の停止位置を同一 Confederation で並べる
§8 の Phase B で local-AS が sub-AS 境界で止まることを観察しましたが、その対照となる no-export の停止挙動は 3-8 の別ラボ (Confederation を組まない構成) での観察に依存していました。Phase F では、同一の Confederation 上で local-AS 付き prefix と no-export 付き prefix を 1 本ずつ同時に流し、停止位置が一段ずれることを 1 つのラボの出力で並列観察します。
このために、R1 に Loopback11 (10.11.1.0/24) を新設し、no-export 対照用の prefix として広告します。route-map を prefix-list で 2 項に分け、10.10.1.0/24 には local-AS、10.11.1.0/24 には no-export を付与して、両 prefix を同時に R2a へ広告します。
! R1 (prefix ごとに community を出し分け)
interface Loopback11
ip address 10.11.1.1 255.255.255.0
!
ip prefix-list PL_LOCALAS permit 10.10.1.0/24
ip prefix-list PL_NOEXPORT permit 10.11.1.0/24
!
route-map SET_COMM permit 10
match ip address prefix-list PL_LOCALAS
set community local-AS
route-map SET_COMM permit 20
match ip address prefix-list PL_NOEXPORT
set community no-export
route-map SET_COMM permit 30
!
router bgp 65010
address-family ipv4
network 10.11.1.0 mask 255.255.255.0
neighbor 10.0.12.2 route-map SET_COMM out
exit-address-family期待動作は、§5 の伝搬範囲ルールに従い、local-AS (10.10.1.0/24) は R2a → R2b の sub-AS 境界で止まり、no-export (10.11.1.0/24) は sub-AS 境界を越えて R2b には届くが、Confederation を出る eBGP 境界 (R2b → R3) で止まる ことです。停止位置が一段ずれるのを 3 つの観測点で追います。
最初の観測点は sub-AS 65001 の入口 R2a です。両 prefix とも R2a には届いており、community 欄に local-AS / no-export が保持されています。重要なのは 2 つの prefix の広告状態の差で、local-AS の 10.10.1.0/24 は not advertised outside local AS / Not advertised to any peer とマークされ、R2a が confed peer (R2b) を含むどの隣接にも広告しません。一方 no-export の 10.11.1.0/24 は not advertised to EBGP peer (= 外部 eBGP には出さない) ですが Advertised to update-groups: 5 とあり、confed peer (R2b) には広告されます。この時点で「local-AS は confed peer (外部扱いの隣接) に出さない / no-export は confed peer には出す」の差が読み分けられます。なお厳密には local-AS (NO_EXPORT_SUBCONFED) が抑止するのは external BGP peer (confed peer を含む) への広告であり、同一 sub-AS 内の iBGP peer には伝搬し得ます。本ラボの R2a は sub-AS 65001 内に iBGP peer を持たず外部 eBGP と confed peer しか持たないため、結果として「どの隣接にも出ない」状態となって Not advertised to any peer が現れています。
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 7
Paths: (1 available, best #1, table default, not advertised outside local AS)
Not advertised to any peer
Refresh Epoch 5
65010
10.0.12.1 from 10.0.12.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: local-AS
rx pathid: 0, tx pathid: 0x0
Updated on Jun 13 2026 00:27:55 UTC
R2a#show ip bgp 10.11.1.0/24
BGP routing table entry for 10.11.1.0/24, version 6
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
Advertised to update-groups:
5
Refresh Epoch 5
65010
10.0.12.1 from 10.0.12.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-export
rx pathid: 0, tx pathid: 0x0
Updated on Jun 13 2026 00:27:55 UTC
R2a#次の観測点は confed peer を越えた sub-AS 65002 の R2b です。ここで停止位置の差が決定的に現れます。local-AS の 10.10.1.0/24 は % Network not in table で、R2a で止まって R2b に届いていません。これに対し no-export の 10.11.1.0/24 は R2b に届いており、(65001) 65010 の confed-sequence と confed-external マークが付いています。ただし R2b でも not advertised to EBGP peer / Not advertised to any peer とマークされ、この経路を次の eBGP 境界 (R2b → R3) には出さないことが予告されています。
show ip bgp 10.10.1.0/24
% Network not in table
R2b#show ip bgp 10.11.1.0/24
BGP routing table entry for 10.11.1.0/24, version 11
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
Not advertised to any peer
Refresh Epoch 1
(65001) 65010
10.0.22.1 from 10.0.22.1 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
Community: no-export
rx pathid: 0, tx pathid: 0x0
Updated on Jun 13 2026 00:27:51 UTC
R2b#最後の観測点は Confederation の外、AS65030 の R3 です。ここでは 両 prefix とも届きません。local-AS の 10.10.1.0/24 は既に R2a で止まっており、no-export の 10.11.1.0/24 は R2b までは届いたものの Confederation を出る eBGP 境界 (R2b → R3) で止まったため、R3 の BGP テーブルには自局の 10.30.3.0/24 と R4 由来の 10.40.4.0/24 のみが載ります。
show ip bgp 10.10.1.0/24
% Network not in table
R3#show ip bgp 10.11.1.0/24
% Network not in table
R3#show ip bgp
BGP table version is 11, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 10.30.3.0/24 0.0.0.0 0 32768 i
*> 10.40.4.0/24 10.0.34.2 0 0 65040 i
R3#3 つの観測点の結果を並べると、停止位置の差が一段ずれることが実機で確定します。
| 観測点 | 10.10.1.0/24 (local-AS) | 10.11.1.0/24 (no-export) |
|---|---|---|
| R2a (sub-AS 65001) | 受信・どの peer にも非広告 | 受信・confed peer には広告 |
| R2b (sub-AS 65002) | 不到達 (% Network not in table) | 到達 (confed-external)・eBGP には非広告 |
| R3 (Confederation 外) | 不到達 | 不到達 (eBGP 境界で停止) |
local-AS は sub-AS の外 (R2a → R2b の confed peer) で止まり、no-export は AS の外 (R2b → R3 の eBGP 境界) で止まります。R2a で local-AS が Not advertised to any peer なのに対し no-export が confed peer には広告される点、R2b で no-export が not advertised to EBGP peer と予告される点が、停止位置が一段ずれる仕組みの証跡です。3-8 では Confederation を組まない構成で no-export を観察し、本節 Phase B で local-AS を別個に観察していましたが、Phase F で 同一 Confederation の同一ラボに 2 prefix を同時に流す ことで、両者の停止位置の関係を直接対照できました。
13. 落とし穴・補足 — 教科書とのギャップ
本節の Confederation 構成で整理すべき論点と、教科書 / Web 解説の記述との差を 5 件整理します。3-3 〜 3-8 と同じ「正直記録」枠で、実装の振る舞いを優先します。実機 capture が必要な項目 (local-AS の挙動 / next-hop の扱い / confed-sequence の表示) は、該当する Phase との紐付けを明記します。
落とし穴 1: sub-AS 番号は asdot ではなく独立した AS 番号
Confederation の sub-AS について、初学者教材ではしばしば「親 AS65020 の中に sub-AS を作る」という説明に留まり、sub-AS 番号の正体が曖昧にされがちです。正確には、sub-AS には親 AS とは独立した別の AS 番号を割り当てます。本ラボの sub-AS 65001 / 65002 は、親 65020 と番号として何の関係もなく、プライベート AS 番号の範囲 (RFC 6996) から別々に選んだ独立した AS 番号です。
ここで紛らわしいのが 65020.1 のような表記です。この asdot 形式は 4-byte AS 番号 (RFC 5396) を表すもので、Confederation の sub-AS とは無関係です。65020.1 は「AS65020 の sub 1」ではなく、65020 × 65536 + 1 = 4261150721 という 1 つの 4-byte AS 番号を表します。Confederation の sub-AS を 65020.1 のように書くのは誤りで、router bgp 65001 のように親番号から独立した AS 番号で BGP プロセスを起動するのが正しい設定です。本節の §3 で AS 番号設計を明示的に整理したのは、この誤解を避けるためです。
落とし穴 2: AS_PATH の confed-sequence は括弧で表示され Confederation の内外を判別できる
Confederation 内部では、sub-AS を越えた記録が AS_PATH に 括弧付き ((65001) のように) で入ります。これが confed-sequence で、通常の AS_PATH (裸の数字) とは表記が区別されます。show ip bgp <prefix> の AS_PATH 列に括弧があれば「Confederation 内部の sub-AS 越え」、なければ「外部 AS 越え」と判別できます。
IOS-XE 17.x では、confed-sequence を 半角括弧 (65001) で表示します。confed-seq のような別表記ではなく、sub-AS 番号を括弧で囲む形です。経路マークも、Confederation 内部では confed-external、Confederation を出ると通常の external に変わります。confed-sequence は Confederation を出る eBGP 境界で剥がれ、親 ID に置き換わります。本ラボでは R2b で (65001) 65010 と見えていた AS_PATH が、R2b → R3 の外部 eBGP を越える瞬間に (65001) が取り除かれ、親 ID 65020 が積まれて 65020 65010 となります。この「内部では括弧で見え、外部に出ると剥がれて親 ID に統一される」挙動が、外部から Confederation が単一 AS に見える仕組みの実体です。Phase A (R2b の内部視点) と Phase D (R3 の外部視点) の AS_PATH の対比で確認できます。
落とし穴 3: confederation peer の AD / next-hop の扱いはハイブリッド
confed peer は「eBGP のように設定し、iBGP のように属性を扱う」ハイブリッドな隣接です。neighbor <ip> remote-as <相手 sub-AS> という eBGP の形で設定し、show ip bgp neighbors では remote AS 65002, external link と eBGP 風の neighbor 種別で表示されます。直結リンク上の single-hop eBGP として扱われ、External BGP neighbor configured for connected checks (single-hop no-disable-connected-check) のマークが付きます。一方で属性の扱いは iBGP 寄りで、Administrative Distance (AD) は eBGP の 20 ではなく iBGP と同じ 200、LOCAL_PREF は通常の eBGP では隣接 AS 越えで消えるところを confed peer 越えでは保持 されます。Phase C の R2b の show ip route で 10.10.1.0/24 (confed peer 由来) が [200/0] かつ type internal と表示され、同じ R2b の通常 eBGP 由来経路 10.30.3.0/24 / 10.40.4.0/24 が [20/0] であることと対比すると、confederation-external 経路だけが AD 200 (internal 扱い) になることが実機で読み取れます。LOCAL_PREF も Phase C の R2b で 10.10.1.0/24 の localpref 100 が confed peer を越えても維持されており、AD と LOCAL_PREF の双方で iBGP 寄りの扱いが裏付けられます。
next-hop の扱いについては、RFC 5065 上 confed peer 越えの next-hop は 既定では unchanged (書き換えない) で、policy で調整可能です。ここを正確に押さえる必要があります。本ラボでは R2a の confed peer 設定に next-hop-self を投入しているため、Phase C の R2b では 10.10.1.0/24 の next-hop が R2a 自身の IP 10.0.22.1 に 書き換わっています (R1 から受信した元 next-hop 10.0.12.1 ではない)。つまり「confed peer の next-hop は既定 unchanged だが、next-hop-self 等の policy で書き換えできる」のが正確な理解で、next-hop-self が効かないわけではありません。この既定 (unchanged) と policy (next-hop-self) の効果は、§11 の Phase E で next-hop-self の有無を切り替えた before/after として実機で分離しています。Phase E の baseline では next-hop が元の 10.0.12.1 (inaccessible) のまま残ってベストパスに選ばれず、next-hop-self 投入後に 10.0.22.1 へ書き換わって best が成立しました。一方で LOCAL_PREF / MED は confed peer 越えでも保持される点が iBGP 寄りで、neighbor 種別こそ external link (eBGP 風) という二面性が残ります。教科書では「confed peer は iBGP のように next-hop が常に保持される」あるいは逆に「eBGP のように必ず書き換わる」と単純化されがちですが、実機では「既定 unchanged + policy で上書き可」というのが正確です。なお show ip bgp neighbors <peer> advertised-routes は書き換え前の元 next-hop を表示するため、書き換え結果は受信側の show ip bgp で確認する点も Phase E で整理しています。
落とし穴 4: local-AS community の停止位置と挙動
local-AS (no-export-subconfed) は「経路を sub-AS の外に広告しない」well-known community です。3-8 の no-export (AS の外で停止) と対比すると、local-AS は一段内側の sub-AS 境界で停止 します。no-export が Confederation 内では sub-AS 間を越えて Confederation を出る eBGP 境界で止まるのに対し、local-AS は Confederation 内部の最初の sub-AS 境界 (本ラボでは R2a → R2b の confed peer) で止まります。
ここで実機で正確に観察したのは、local-AS が 経路自体を sub-AS 境界で落とすのか、それとも経路は届くが community だけが剥がれるのか です。IOS-XE 17.x では、経路自体が sub-AS 境界で止まります。community だけが剥がれて経路が伝搬するのではありません。Phase B の実機 capture では、R2a (sub-AS 65001) で受信した経路に Community: local-AS が保持され、table default, not advertised outside local AS および Not advertised to any peer とマークされて、R2a はこの経路をどの隣接にも広告しませんでした。その結果、R2b では % Network not in table となり、10.10.1.0/24 が BGP テーブルに存在しません。経路は R2a までで止まり、confed peer を越えて R2b に出ていません。これが local-AS = no-export-subconfed の正確な挙動で、3-8 の no-export が eBGP 境界 (AS の外) で止まったのに対し、local-AS は一段内側の sub-AS 境界 (confed peer) で経路自体を止めます。3-8 で宿題として残した local-AS の停止挙動は、この Phase B の実機 capture で確定しました。
この local-AS と no-export の停止位置の差は、§12 の Phase F で 同一の Confederation 上に 2 つの prefix を同時に流して 直接対照しています。Phase F では local-AS 付き prefix が R2a の sub-AS 境界で止まる一方、no-export 付き prefix は confed peer を越えて R2b には届くものの Confederation を出る eBGP 境界 (R2b → R3) で止まる、という一段ずれた停止位置を、R2a / R2b / R3 の 3 観測点の並列表で確定しています。
落とし穴 5: Confederation 内 loopback ピアリングには ebgp-multihop が必要
confed peer は eBGP 的に扱われるため、loopback アドレスでピアリングする場合は通常の eBGP と同様に neighbor <ip> ebgp-multihop <n> が必要となります。confed peer 同士を直結 IP ではなく loopback でピアリングすると、TTL の既定値 (eBGP は 1) では loopback 同士に届かず、セッションが Established に到達しません。
本ラボは R2a ↔ R2b を直結 P2P リンク (10.0.22.0/30) でピアリングし、neighbor に相手の直結 IP を指定することで ebgp-multihop を回避しています。検証の焦点を Confederation の AS_PATH と local-AS に絞るための設計判断です。実運用で sub-AS 内に複数ルータがあり loopback ピアリングが必要な場合は、ebgp-multihop の投入と、loopback への到達経路 (sub-AS 内の IGP または static) の確保が前提となります。この点は、3-8 で iBGP を loopback ピアリングするのに sub-AS 内の到達性を IGP / static で確保したのと同じ考え方で、confed peer では加えて ebgp-multihop が必要になる点が異なります。
14. 次節
3-6 BGP、3-7 Route Reflector、3-8 BGP community、本節 3-9 Confederation を通して、第 3 章 L3 編の 9/16 を消化しました。BGP 系列としては、path vector の本質とベストパス選定 (3-6)、iBGP full-mesh 問題の 2 つの解 (3-7 Route Reflector / 3-9 Confederation)、AS をまたぐポリシー伝達の語彙としての community (3-8) まで通したことになります。iBGP full-mesh 問題に RR と Confederation という 2 系統の解があり、前者がスター型の階層化、後者が AS の sub-AS 分割であるという対比が揃いました。3-8 で宿題として残した local-AS community も、本節の Confederation 構成で停止位置を実機検証する枠組みが整いました。
第 3 章の残りは 3 節です。続く 3-10 では、ここまで個別に扱ってきた OSPF / EIGRP / BGP を 1 台のルータで橋渡しする 経路の再配送 (Redistribution) を扱います。プロトコルの異なるドメイン境界に立つ ASBR で双方向 (相互) の再配送を行い、seed metric、外部経路の O E1 / O E2、相互再配送が生むループとその route-map + tag による防止までを CML2.9 上で実機検証します。
3-11 以降のトピックの候補は次のとおりです。
- ルーティングポリシー総括 — route-map / prefix-list / AS-PATH ACL / community-list の応用、属性操作シナリオ集として BGP 系列を締める
- マルチキャストルーティング — PIM Sparse Mode、RP (Rendezvous Point)、IGMP
- IPv6 ルーティング — OSPFv3、MP-BGP for IPv6、SLAAC と DHCPv6
第 3 章後半は引き続き、教科書記述と Cisco IOS-XE 17.x 実装のギャップを「落とし穴・補足」節で正直に記録する方針で進めます。CML2.9 上の実機 capture を主軸にして、Phase 別の検証を見ていきましょう。