3-7 Route Reflector — iBGP full-mesh の解と Cluster ID / Originator ID

1. 前節の振り返りと本節の内容

3-6 BGP では path vector 型の本質、neighbor 6 状態遷移、weight / LOCAL_PREF / AS_PATH / origin / MED から始まる 8 ステップのベストパス選定、iBGP next-hop-self の必要性、経路集約までを 3 AS 5 ルータの実機ラボで確認しました。その §13 で 1 つだけ未解決のまま残した論点が iBGP full-mesh 問題 です。iBGP は「学習した経路を他の iBGP 隣接に再広告しない」という規約のため、AS 内のルータ数 n が増えると n×(n-1)/2 本 の TCP セッションを張る完全グラフ構成が必要となります。100 台規模で 4950 本に達する組合せ爆発であり、本物の ISP やデータセンター内 iBGP では成立しません。

本節ではこの問題の解として広く採用されている Route Reflector (RR、RFC 4456) を扱います。RR は iBGP の「再広告しない」規約を 1 ヶ所だけ意図的に破る装置であり、RR 1 台がスター型のハブとして全クライアントの経路を反射することで、n×(n-1)/2 本必要だったセッションを n 本に圧縮します。同時に「規約を破ったらどうやって iBGP ループを防ぐか」という新しい課題が発生するため、本節では reflection rule (反射規約)、Cluster ID、Originator ID の 3 点を順に整理します。

スコープ外の論点は次のとおりです。Confederation (AS を sub-AS に分割して eBGP 的に扱う発想) は RR とは別系統の解として §最終節で 1 段落だけ触れ、構成は次節以降の選択肢として残します。BGP community 属性 (RFC 1997) と MP-BGP (Multiprotocol BGP) も本節では扱いません。本節 §13 では教科書記述と IOS-XE 17.x 実装の差を「落とし穴・補足」として整理する予定で、§1 で予告しておきます。

本節の構成は次のとおりです。§2 で iBGP full-mesh の組合せ爆発を数値で見せ、§3 で Route Reflector の概要、§4 で reflection rule、§5 で Cluster ID と Originator ID、§6 で CML2.9 上のラボトポロジを設計し、§7〜§10 で Phase A-D の実機検証、§11 で next-hop を整えた標準構成 (Phase E)、§12 で二重 RR と Cluster ID の対照 (Phase F)、§13 で教科書ギャップ、§最終節で 3-8 以降の予告を扱います。

2. iBGP full-mesh の組合せ爆発

iBGP full-mesh が必要となる理由は 3-6 §3 で扱った iBGP の規約に由来します。すなわち 「iBGP で学習した経路は他の iBGP 隣接に再広告しない」 という規約です。この規約はループ防止のために設計されており、AS 内のルータ A → B → C → A のような iBGP セッション経路で経路情報が無限に回ることを単純な仕掛けで防いでいます。

この規約のもとで AS 内の任意のルータが任意のルータの経路を学習するためには、全ルータが互いに iBGP セッションを張る必要が出てきます。n 台のルータでの完全グラフ K_n の辺数は n×(n-1)/2 であり、これがそのまま必要な iBGP セッション数となります。

人手で設定を書ける限界は経験的に 10 台前後、TCP セッションの保守とメモリ消費まで含めると 20 台が実質的な上限となります。100 台規模のセッション数 4950 は、セッション管理 / 設定の冗長性 / 障害時の波及範囲のいずれも現実的でない数字です。

この組合せ爆発を回避する解として標準化されたのが Route Reflector (RFC 4456、初版 RFC 2796) と Confederation (RFC 5065、初版 RFC 3065) です。本節は前者を扱います。

3. Route Reflector の概要

Route Reflector は 「iBGP 学習経路を他の iBGP に再広告しない」という iBGP の規約を 1 つだけ意図的に破る装置 です。RR と指定したルータは、自身が iBGP で学習した経路を他の iBGP 隣接に反射 (reflect、再広告) する権限を持ちます。RR を頂点とするスター型構造を組むことで、AS 内の全ルータが直接 iBGP セッションを張る必要がなくなります。

RR は RFC 4456 (Route Reflection - An Alternative to Full Mesh IBGP) で標準化されており、Cisco IOS-XE / IOS / Junos いずれも実装しています。RR を導入した時点で AS 内の iBGP 隣接は次の 2 種類に分類されます。

• Client (RR-Client): RR が route-reflector-client として指定した iBGP 隣接。RR が学習した経路を反射する対象。
• Non-Client: それ以外の iBGP 隣接。route-reflector-client を付けない通常の iBGP 隣接で、RR にとっては従来の iBGP 隣接として扱われる。Non-Client 同士は依然として直接の iBGP セッションを張る必要がある。

n 台のクライアントを RR 1 台に収容した場合、AS 内の iBGP セッション数は n (RR ↔ 各クライアント) となります。100 台のクライアントを 1 台の RR に収容すると、4950 本必要だったセッションが 100 本まで圧縮されます。

ただしこの設計はループ防止の前提を変えます。従来の iBGP は「再広告しない」規約だけでループを防いでいましたが、RR は規約を破るため別のループ防止機構が必要となります。RFC 4456 はこのために Originator ID と Cluster list という 2 つの新属性を追加しました。Originator ID は経路の発生源となったクライアントの Router ID を一意に記録する属性、Cluster list は経路が通過したクラスタの ID を記録する属性で、§5 で詳しく扱います。

iBGP full-mesh の解として、RR とは別系統に Confederation という発想もあります。Confederation は AS を複数の sub-AS (member-AS) に分割し、sub-AS 間は eBGP のように振る舞いつつ、外部から見れば 1 つの AS として見せる手法です。RR がスター型構造で iBGP 規約の破りどころを最小化するのに対し、Confederation は AS 分割でループ防止の枠組みごと eBGP に寄せます。実装の単純さで RR が大規模 ISP 内部に広く採用される一方、組織分割や合併など論理的境界が必要な構成では Confederation も使われます。本節は RR に絞り、Confederation の構成は §最終節で言及する程度に留めます。

4. Reflection rule — 受け取った経路を誰に反射するか

Route Reflector が iBGP peer から受け取った best path を誰に反射するかは、受信元の種別によって変わります。RFC 4456 §6 が定める reflection rule (反射規約) は、あくまで iBGP peer (Client / Non-Client) を対象とした規則です。次の 2 通りに整理されます。

整理すると次の構造になります。Client から受け取った経路は、iBGP 規約 (「iBGP 学習経路を他の iBGP に再広告しない」) を破って 他の全 iBGP peer (Client + Non-Client) に反射 されます。これが Route Reflector の機能の核です。Non-Client から受け取った経路は 全 Client には反射されますが、他の Non-Client には反射されません。Non-Client 同士は従来の iBGP 規約のとおり直接セッションを張っているはずで、RR が中継する必要がないためです。

ここで重要な注意点があります。reflection rule に「EBGP peer への反射」は含まれません。RFC 4456 Appendix B は、初版 (RFC 2796) にあった EBGP routes / peers への言及を削除したと明記しています。RR が自身の EBGP peer に経路を広告するのは、route reflection ではなく 通常の BGP 広告処理 (iBGP / eBGP で学習した best path を eBGP peer へ広告する標準動作) です。同様に、eBGP で学習した経路を AS 内の iBGP peer に渡すのも、eBGP → iBGP の標準的な再広告であって reflection rule の対象ではありません。

本節のラボでは Non-Client を配置しないため、Client → Client の反射だけが純粋な reflection rule として観察できます。具体的には次の 2 つが見えます。1 つ目は EBGP peer (R5) → R1a が eBGP 学習 → R1a が iBGP で RR1 に渡す → RR1 が R1a (Client) から受信 → R1b / R1c (他の Client) に反射 という経路で、AS200 / AS300 の prefix が AS100 内全体に伝わる挙動です (R1a → RR1 の部分は eBGP→iBGP の標準再広告、RR1 → R1b/R1c の部分が reflection)。2 つ目は R1b (Client) → RR1 が受信 → R1a / R1c (他の Client) に反射 という、Client から Client への横方向の反射です。これらを Phase B と Phase C で観察します。

反射規約は RR が自動で適用するため、各クライアント側に追加の設定は不要です。クライアント側からは「通常の iBGP 隣接」としてセッションを張るだけで、反射経路は自動的に受信できます。逆に言うと、クライアント側からは自分が RR-Client として扱われていることを設定では把握できず、受信経路の Originator ID / Cluster list の有無で間接的に判断する形となります。

5. Cluster ID と Originator ID — ループ防止のメカニズム

Route Reflector は iBGP 規約を破るため、従来とは異なるループ防止機構が必要となります。RFC 4456 はこのために Originator ID (Type 9、Optional Non-Transitive) と Cluster list (Type 10、Optional Non-Transitive) という 2 つの BGP path attribute を新設しました。両属性とも eBGP には伝わらない non-transitive 属性で、AS 境界を越えると剥がれます。

Originator ID は 経路を AS 内で最初に発生させた (originate した) ルータの Router ID を記録する属性です。経路の発生源を一意に特定するためのもので、RR が経路を反射する時点で、まだ Originator ID が付いていなければ発生源ルータの Router ID を載せて作成します (Client から受信したものに限らず、Non-Client から受信して Client へ反射する場合も同様)。受信側のルータは Originator ID を見て、自分の Router ID と一致する経路を受け取った場合は「自分が出した経路が反射されて戻ってきた」と判断して破棄します。これが基本的なループ防止です。

Cluster list は 経路が通過した RR クラスタの Cluster ID を追記していく属性 です。Cluster ID は RR とその配下のクライアント群を 1 つの単位として識別する値で、明示設定がなければ RR 自身の Router ID がそのまま Cluster ID として使われます。Cluster list の使い方は次のとおりです。経路が RR を通過するごとに、その RR の Cluster ID が Cluster list の先頭に追加されます。別の RR が経路を受け取った時、Cluster list に自分の Cluster ID が既に含まれていればループとみなして破棄します。

Cluster list の真価が出るのは RR を二重化した構成 です。可用性のために 1 つのクラスタに 2 台の RR (RR1 と RR2) を置き、両方を全クライアントの隣接として張る運用があります。この時、RR1 と RR2 の Cluster ID を 一致させる ことで、片方の RR が反射した経路をもう片方の RR が受け取った時に Cluster list 重複として破棄され、RR 間で同じ経路を持ち合うことが防げます。逆に Cluster ID を別々にすると、同一クラスタとしての抑止が効かず、別 RR 由来の反射コピーを受け入れて重複した反射経路を持つ状態になり得ます。

Phase A-D のラボでは RR が 1 台 (RR1) のみのため、Cluster ID 一致時の反射抑止はこの段階では観察できません。まず Phase D の検証では Cluster list の 既定値 (RR1 の Router ID = 100.100.100.100) が経路に乗っていることを show ip bgp <prefix> で確認します。そのうえで §12 (Phase F) では既存クライアントの 1 台を 2 台目の RR (RR2) に役割変更して二重 RR を組み、Cluster ID を一致させた場合と別々にした場合で Cluster list ループ判定の破棄 / 採用がどう変わるかを実機で対照 します。

Cluster ID を明示設定すべき場面は次の 2 つに整理されます。第一に RR を二重化する構成 では Cluster ID を bgp cluster-id <id> で明示設定し、両 RR で一致させます。第二に 同一クラスタの RR と他のクラスタの RR を区別したい構成 では、クラスタごとに別の Cluster ID を割り当てます。それ以外の場合 (RR 1 台、または冗長性不要な構成) では既定値 (Router ID 流用) で十分です。

6. ラボトポロジ — 3-6 の AS100 を R1a / R1b / R1c + RR1 に拡張

本節のラボは 3-6 BGP のラボ (AS100 = R1 / R2、AS200 = R3 / R4、AS300 = R5) を出発点とします。AS100 の R1 / R2 を撤去し、R1a (eBGP edge + iBGP client) + R1b / R1c (iBGP client only) + RR1 (Route Reflector) の 4 ルータに置換します。AS200 (R3 / R4 の iBGP full-mesh) と AS300 (R5 単独 transit) は 3-6 のまま維持し、iBGP full-mesh と RR 構成の対比として残します。

トポロジは次のとおりです。

ノード総数は csr1000v 7 台 + unmanaged_switch 1 + external_connector 1 の計 9 ノードで、CML2.9 (60 GB RAM / 8 cores) で並列起動可能な範囲です。

アドレッシングは次のとおりとします。

RR1 の Router ID は意図的に 100.100.100.100/32 という他 AS と明確に区別できる値を選び、show 出力中で Originator ID (1.1.1.x) と Cluster list (100.100.100.100) を視覚的に分離できるようにしています。

day0 config の骨子は次のとおりです。R1a は eBGP edge と iBGP client を兼ね、AS200 / AS300 経路を AS100 内に持ち込む役割を担います。

! R1a (AS100、eBGP edge + iBGP client)
router bgp 100
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 10.0.15.2 remote-as 300
 neighbor 10.0.15.2 description eBGP_to_R5
 neighbor 10.0.100.2 remote-as 100
 neighbor 10.0.100.2 description iBGP_to_RR1
 !
 address-family ipv4
  network 10.10.1.0 mask 255.255.255.0
  neighbor 10.0.15.2 activate
  neighbor 10.0.100.2 activate
  neighbor 10.0.100.2 next-hop-self
 exit-address-family

RR1 は AS100 内の Route Reflector で、3 つのクライアントすべてに route-reflector-client を付与する点が肝となります。

! RR1 (AS100、Route Reflector)
router bgp 100
 bgp router-id 100.100.100.100
 bgp log-neighbor-changes
 neighbor 10.0.100.1 remote-as 100
 neighbor 10.0.100.1 description iBGP_R1a_client
 neighbor 10.0.100.1 route-reflector-client
 neighbor 10.0.100.6 remote-as 100
 neighbor 10.0.100.6 description iBGP_R1b_client
 neighbor 10.0.100.6 route-reflector-client
 neighbor 10.0.100.10 remote-as 100
 neighbor 10.0.100.10 description iBGP_R1c_client
 neighbor 10.0.100.10 route-reflector-client
 !
 address-family ipv4
  neighbor 10.0.100.1 activate
  neighbor 10.0.100.6 activate
  neighbor 10.0.100.10 activate
 exit-address-family

R1b / R1c は通常の iBGP クライアントで、RR1 1 台とだけ iBGP セッションを張ります。route-reflector-client はクライアント側には設定不要です (RR 側が付与する設定)。

! R1b (AS100、iBGP client only。R1c は network 文と隣接 IP のみ差分)
router bgp 100
 bgp router-id 1.1.1.2
 bgp log-neighbor-changes
 neighbor 10.0.100.5 remote-as 100
 neighbor 10.0.100.5 description iBGP_to_RR1
 !
 address-family ipv4
  network 10.10.2.0 mask 255.255.255.0
  neighbor 10.0.100.5 activate
 exit-address-family

本ラボには 2 つの設計上の落とし穴があり、§11 で詳述しますが先に予告しておきます。

第一に R1a での next-hop-self が必須 です。R1a は eBGP で R5 から AS200 経路を学習しますが、その next-hop は R5 の P2P アドレス (10.0.15.2) です。R1a が next-hop-self を付けずに iBGP で RR1 に渡すと、RR1 や R1b / R1c は next-hop = 10.0.15.2 を IGP で解決できず経路を使えません。RR は 属性をそのまま反射する だけで next-hop を書き換えないため、R1a 側で next-hop-self を投入する設計が必要となります。「RR があれば next-hop-self は不要」という誤解は教科書記述でもしばしば見られるギャップで、§11 (Phase E) で標準構成を実機投入して解消する様子を、§13 落とし穴 3 で教科書ギャップとして整理します。

第二に AS100 内の IGP を static で代用している 点です。本来 R1b / R1c は R1a の Lo0 (1.1.1.1、next-hop-self 投入後の next-hop) を IGP で知る必要があり、実運用では OSPF / IS-IS を流すのが標準です。本ラボは検証の焦点を Route Reflector の動作に絞るため、R1b / R1c に ip route 1.1.1.1 255.255.255.255 10.0.100.5 (R1c は 10.0.100.9) の static 経路を 1 本ずつ書く設計としています。

! R1b 側 static
ip route 1.1.1.1 255.255.255.255 10.0.100.5

! R1c 側 static
ip route 1.1.1.1 255.255.255.255 10.0.100.9

RR1 は R1a と直結 (10.0.100.0/30 が connected) のため static 不要です。

検証フェーズは Phase A-F の 6 段階で進めます。

• Phase A: 全 7 ルータの BGP セッション確立、AS100 内の iBGP セッション数 = 3 を show ip bgp summary で確認
• Phase B: AS200 / AS300 経路の R1a → RR1 → R1b / R1c への反射、Originator ID と Cluster list の自動付与
• Phase C: R1b の Lo10 = 10.10.2.0/24 が RR1 経由で R1a / R1c に届く挙動 (Client → Client 反射)
• Phase D: Cluster ID の既定値が RR1 の Router ID (100.100.100.100) であることの確認、教科書ギャップの観察
• Phase E (§11): next-hop を整えた標準構成 (AS100 内 OSPF + Lo0 ピアリング + eBGP edge での next-hop-self) を投入し、最小構成で (inaccessible) だった反射経路が best + RIB 採用に変わる before / after を対照
• Phase F (§12): 既存クライアント 1 台を 2 台目の RR (RR2) に役割変更して二重 RR を組み、Cluster ID 同一 / 別々で Cluster list ループ判定の破棄 / 採用の差を対照

7. Phase A: BGP セッション確立と iBGP セッション数

Phase A では全 7 ルータの BGP セッションが Established になり、AS100 内の iBGP セッション数が 3 (RR1 ↔ R1a / R1b / R1c) で済んでいることを show ip bgp summary で確認します。同時に RR1 の各クライアントに対する Route-Reflector Client 表記が show ip bgp neighbors 詳細出力に表示されることを観察し、設定が RR 側だけに必要であることを実機で裏付けます。

各ルータの BGP セッション数は以下のとおりです。AS100 ではスター型構造により RR1 のみが 3 セッションを保持し、3 クライアントは RR1 への 1 セッションのみを張ります。AS200 は 3-6 のまま iBGP full-mesh (R3 ↔ R4) を維持し、対比として残してあります。

AS100 の iBGP セッション総数は 3 です。§2 で扱った n×(n-1)/2 の式に当てはめると、4 ルータの full-mesh では 6 セッションが必要となり、RR 導入により半分に圧縮されています。n が増えるほど削減効果が顕著となり、n=10 では 45 セッションが 10 セッション、n=100 では 4950 セッションが 100 セッションまで圧縮されます。

RR1 視点の show ip bgp summary は以下のとおりです。

RR1#show ip bgp summary
BGP router identifier 100.100.100.100, local AS number 100
BGP table version is 6, main routing table version 6
5 network entries using 1240 bytes of memory
5 path entries using 680 bytes of memory
2/2 BGP path/bestpath attribute entries using 576 bytes of memory
1 BGP AS-PATH entries using 40 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 2536 total bytes of memory
BGP activity 5/0 prefixes, 5/0 paths, scan interval 60 secs
5 networks peaked at 16:06:10 May 28 2026 UTC (00:01:22.018 ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.100.1      4          100      13      14        6    0    0 00:07:20        3
10.0.100.6      4          100      10      15        6    0    0 00:06:18        1
10.0.100.10     4          100       9      14        6    0    0 00:05:10        1

RR1 は 3 つの iBGP 隣接 (10.0.100.1 = R1a、10.0.100.6 = R1b、10.0.100.10 = R1c) を保持し、すべて Established (State/PfxRcd 列が数値表示) となっています。受信 prefix 数は R1a から 3 経路、R1b と R1c からは各 1 経路で、AS100 と AS200 / AS300 の経路が一通り RR1 に集まっていることが分かります。

各クライアントが Route Reflector Client として扱われていることは show ip bgp neighbors の詳細出力で確認できます。

RR1#show ip bgp neighbors | include BGP neighbor|BGP state|Route-Reflector
BGP neighbor is 10.0.100.1,  remote AS 100, internal link
  BGP state = Established, up for 00:08:22
  Route-Reflector Client
BGP neighbor is 10.0.100.6,  remote AS 100, internal link
  BGP state = Established, up for 00:07:20
  Route-Reflector Client
BGP neighbor is 10.0.100.10,  remote AS 100, internal link
  BGP state = Established, up for 00:06:12
  Route-Reflector Client

3 つの neighbor すべてに Route-Reflector Client の表記が付与されており、RR1 側で route-reflector-client 設定が効いていることが分かります。この表記は RR 側 の show ip bgp neighbors でのみ表示され、クライアント側 (R1b / R1c) の同コマンドには現れません。クライアント自身は自分が RR-Client として扱われていることを設定情報だけからは把握できず、受信経路の Originator ID / Cluster list の有無で間接的に判断する形となります。

クライアント側の BGP テーブルも全 5 prefix が見えていることを確認します。R1b 視点の show ip bgp は以下のとおりです。

R1b#show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 * i  10.10.1.0/24     10.0.100.1               0    100      0 i
 *>   10.10.2.0/24     0.0.0.0                  0         32768 i
 * i  10.10.3.0/24     10.0.100.10              0    100      0 i
 * i  10.20.3.0/24     10.0.100.1               0    100      0 300 200 i
 * i  10.20.4.0/24     10.0.100.1               0    100      0 300 200 i

R1b は自身が広告する 10.10.2.0/24 を *> (valid / best、weight=32768) で local origination として保持し、他の 4 prefix は * i で iBGP 由来の経路として受信しています。注目すべきは *> (best) が付いているのは 10.10.2.0/24 のみで、他の 4 prefix は * (valid) のみで best 取得に至っていない点です。この現象は next-hop が IGP で解決できないことに起因します。後段の Phase B / Phase C で経路の流れを辿りながら、属性詳細と best 落選の原因を明らかにします。

8. Phase B: AS200 経路の R1a → RR1 → R1b / R1c への反射

Phase B では AS200 の prefix が AS100 内に伝搬する経路を辿ります。経路の流れは R3 / R4 → R5 (eBGP) → R1a (eBGP) → RR1 (iBGP の RR-Client から受信) → R1b / R1c (RR1 が他クライアントへ反射) の順で、Reflection rule の「Client から受信した経路は他の全 iBGP peer (Client + Non-Client) に反射」が実機でどう見えるかを確認します (R1a が eBGP 学習経路を RR1 に渡す部分は eBGP→iBGP の標準再広告、RR1 → R1b/R1c が reflection)。

R1a 視点の AS200 prefix 学習状況は以下のとおりです。

R1a#show ip bgp 10.20.3.0/24
BGP routing table entry for 10.20.3.0/24, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  300 200
    10.0.15.2 from 10.0.15.2 (5.5.5.5)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

R1a は AS300 (R5) との eBGP セッションを通じて 10.20.3.0/24 を学習しています。AS_PATH は 300 200、next-hop は 10.0.15.2 (R5 Gi2 の P2P IP)、属性は valid, external, best で、R1a の BGP RIB 上で best path が確立しています。10.20.4.0/24 も同じ構造で学習されており、R1a が AS100 の eBGP 出口として AS200 経路を取り込んでいることが分かります。

R1a は次に iBGP で RR1 へこの経路を渡します。RR1 視点で同じ prefix を見ると以下のとおりです。

RR1#show ip bgp 10.20.3.0/24
BGP routing table entry for 10.20.3.0/24, version 5
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  300 200, (Received from a RR-client)
    10.0.100.1 from 10.0.100.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0

RR1 では 300 200, (Received from a RR-client) という表記が出ます。後段の (Received from a RR-client) は IOS-XE 17.x の実機出力で明示表示される文字列で、RR1 がこの経路を Route Reflector Client (= R1a) から受信したことを表します。next-hop は 10.0.100.1 (R1a Gi3 の P2P IP) に書き換わっており、R1a 側の neighbor 10.0.100.2 next-hop-self 設定が効いた結果です。RR1 上で valid, internal, best となり、best path が確立しています。

ここで重要な点が 2 つあります。第一に RR1 は next-hop を書き換えていない ことです。RR は属性をそのまま反射する設計のため、R1a が次段の R1b / R1c へ伝える時の next-hop は R1a が iBGP に渡した時の値 (= 10.0.100.1) のまま固定されます。第二に R1a の next-hop-self は R1a → RR1 ピアリングに対してのみ効く ことです。R1a の Lo0 (1.1.1.1) ではなく Gi3 の P2P IP (10.0.100.1) に書き換わるため、R1a が直結していない R1b / R1c は IGP でこのアドレスへの経路を持ちません。

この影響が R1b 視点で観察できます。

R1b#show ip bgp 10.20.3.0/24
BGP routing table entry for 10.20.3.0/24, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 2
  300 200
    10.0.100.1 (inaccessible) from 10.0.100.5 (100.100.100.100)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.1, Cluster list: 100.100.100.100

R1b では Paths: (1 available, no best path) となり、best path が確立していません。属性に (inaccessible) が付き、next-hop = 10.0.100.1 への IGP 経路が無いため forwarding できない経路として best 落選した結果です。経路自体は受信成立しており、Originator: 1.1.1.1 で発生源が R1a (Router ID 1.1.1.1) であること、Cluster list: 100.100.100.100 で経路が RR1 (Router ID 100.100.100.100) のクラスタを通過したことが記録されています。受信元 (from 10.0.100.5) が RR1、その Router ID が 100.100.100.100 と表示される点も R1a 直結ではなく RR1 経由の反射経路であることを裏付けます。

R1c 視点でも同じ構造です。

R1c#show ip bgp 10.20.3.0/24
BGP routing table entry for 10.20.3.0/24, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 2
  300 200
    10.0.100.1 (inaccessible) from 10.0.100.9 (100.100.100.100)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.1, Cluster list: 100.100.100.100

R1c は from 10.0.100.9 で受信しており、これは R1c が見る相手側 = RR1 Gi4 の IP (10.0.100.9) です (R1c 自身の Gi2 は 10.0.100.10)。Originator ID と Cluster list は R1b と同じ値で、AS100 内で経路の発生源とクラスタが一意に識別されている状態です。

R1b / R1c で best path が確立しない原因は R1a の next-hop-self が neighbor 10.0.100.2 next-hop-self という形式で、書き換え先が R1a の P2P IP (10.0.100.1) になる 設計に起因します。R1b / R1c は 10.0.100.1 への IGP 経路を持たないため (inaccessible) 扱いとなり、forwarding 不能のため best 選定から外れます。この設計上の落とし穴は本節末の「落とし穴・補足」節で詳細に整理します。

9. Phase C: R1b の Lo10 を RR1 → R1a / R1c に反射 (Client → Client 反射)

Phase C では Phase B と逆方向の反射、すなわち クライアントが広告した経路が同じ AS100 内の他クライアントに反射される 挙動を観察します。経路の流れは R1b (origin、network 10.10.2.0 mask 255.255.255.0) → RR1 (R1b = RR-Client から受信) → R1a / R1c (他の RR-Client へ反射) の順です。Reflection rule の Client → Client 反射規約が実機でどう動くかを確認する場となります。

R1b は自身の Lo10 = 10.10.2.0/24 を network 文で広告し、locally originated として保持します。

R1b#show ip bgp 10.10.2.0/24
BGP routing table entry for 10.10.2.0/24, version 2
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  Local
    0.0.0.0 from 0.0.0.0 (1.1.1.2)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best

Local 表記と weight 32768、next-hop=0.0.0.0 (自分自身) が local origination の典型的な目印です。Router ID は 1.1.1.2 (R1b の Lo0) で、これがこの後の反射経路で Originator ID として記録される値となります。

R1b は次に iBGP で RR1 にこの経路を渡します。RR1 視点では以下のとおりです。

RR1#show ip bgp 10.10.2.0/24
BGP routing table entry for 10.10.2.0/24, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  Local, (Received from a RR-client)
    10.0.100.6 from 10.0.100.6 (1.1.1.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

RR1 は Local, (Received from a RR-client) 表記で R1b から受信したことを記録し、valid, internal, best で best 取得しています。next-hop は 10.0.100.6 (R1b Gi2 の P2P IP) のままで、RR は属性をそのまま反射する設計のため書き換えは発生しません。RR1 はこの経路を他の RR-Client (R1a と R1c) に反射します。

R1c 視点では以下のとおりです。

R1c#show ip bgp 10.10.2.0/24
BGP routing table entry for 10.10.2.0/24, version 0
Paths: (1 available, no best path)
  Flag: 0x4100
  Not advertised to any peer
  Refresh Epoch 2
  Local
    10.0.100.6 (inaccessible) from 10.0.100.9 (100.100.100.100)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.2, Cluster list: 100.100.100.100

R1c では Originator: 1.1.1.2 で発生源が R1b (Router ID 1.1.1.2) であること、Cluster list: 100.100.100.100 で経路が RR1 のクラスタを通過したことが記録されています。受信元は from 10.0.100.9 (R1c から見た相手側 = RR1 Gi4 の IP。R1c 自身の Gi2 は 10.0.100.10) で、その Router ID = 100.100.100.100 と表示されており、RR1 経由の反射経路として識別できます。Phase B と同じく next-hop=10.0.100.6 (R1b Gi2) は IGP で解決できないため (inaccessible)、best 落選という結果です。

R1a でも同じく反射経路として見えます。

R1a#show ip bgp 10.10.2.0/24
BGP routing table entry for 10.10.2.0/24, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.0.100.6 (inaccessible) from 10.0.100.2 (100.100.100.100)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.2, Cluster list: 100.100.100.100

R1a は RR1 と直結 (10.0.100.0/30 connected) で IGP 補助なしに next-hop=10.0.100.6 を解決できないため、こちらでも (inaccessible) で best 落選しています。RR1 が R1a に反射した経路は受信成立しており、Reflection rule の「Client から受信した経路は他の Client に反射」が実機で動作していることが確認できます。

R1c の Lo10 = 10.10.3.0/24 も同じシンメトリで反射されます。R1a 視点では以下のとおりです。

R1a#show ip bgp 10.10.3.0/24
BGP routing table entry for 10.10.3.0/24, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  Local
    10.0.100.10 (inaccessible) from 10.0.100.2 (100.100.100.100)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.3, Cluster list: 100.100.100.100

Originator ID = 1.1.1.3 (R1c の Router ID)、Cluster list = 100.100.100.100 (RR1) と、Originator だけが Phase の経路 origin に応じて変わる構造です。

ここで、AS100 内で反射された R1b / R1c の prefix が AS の外 (AS300 の R5) まで広告されるか を確認します。ここで注意したいのは、R5 は RR1 の eBGP peer ではなく R1a の eBGP peer である点です。したがってこれは「RR が EBGP peer に反射するか」(そもそも reflection rule に EBGP 反射は含まれない) の検証ではなく、R1a が iBGP (RR 経由) で受け取った経路を自身の eBGP peer R5 に標準の BGP 広告として再広告できるか の検証になります。

R5#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:
     1         
  Refresh Epoch 1
  100
    10.0.15.1 from 10.0.15.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
R5#show ip bgp 10.10.2.0/24
% Network not in table
R5#show ip bgp 10.10.3.0/24
% Network not in table

R5 は R1a の locally originated 経路である 10.10.1.0/24 は受信しているものの、10.10.2.0/24 と 10.10.3.0/24 は受信していません (Network not in table)。R1a が iBGP (RR 経由) で受け取った R1b / R1c の経路を、自身の eBGP peer R5 へ再広告できていない、という観察結果です。

この理由は本ラボの設計に起因します。RR1 は R1b / R1c の経路を R1a に反射していますが、R1a が R5 (eBGP peer) へ再広告する時点で next-hop の到達性が問題となります。R1a が iBGP から受信した経路を eBGP に再広告する仕組み自体は機能しますが、next-hop が forwarding 不能 ((inaccessible)) と判定された経路は best 取得に至らず、eBGP 再広告の対象から外れます (BGP は best path のみを peer へ広告するため)。next-hop 解決を整えれば R1a は標準の BGP 広告処理として R5 へこれらの経路を渡せます。この事実も本節末の「落とし穴・補足」節で整理します。

10. Phase D: Cluster ID と Originator ID の実機観察

Phase D では Cluster ID の既定値、Originator ID の自動付与、bgp cluster-id の明示設定の有無、AS 境界を越えた時の挙動を整理します。Phase B / C で個別に観察した属性を、Cluster ID と Originator ID という 2 つの軸でまとめ直す位置付けです。

10.10.2.0/24 を RR1 視点で詳細表示すると Cluster list の値が確認できます。

RR1#show ip bgp 10.10.2.0/24
BGP routing table entry for 10.10.2.0/24, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  Local, (Received from a RR-client)
    10.0.100.6 from 10.0.100.6 (1.1.1.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

RR1 視点では Cluster list 表記がまだ付与されていない (RR1 自身が反射元のため自分の Cluster ID を追加する直前の状態) ことが分かります。RR1 が他のクライアントへ反射する時点で Cluster list の先頭に RR1 の Cluster ID が追加され、受信側 (R1a / R1c) で観測可能になります。

同じ経路を R1c 視点で見ると Cluster list が確認できます。

R1c#show ip bgp 10.10.2.0/24
BGP routing table entry for 10.10.2.0/24, version 0
Paths: (1 available, no best path)
  Flag: 0x4100
  Not advertised to any peer
  Refresh Epoch 2
  Local
    10.0.100.6 (inaccessible) from 10.0.100.9 (100.100.100.100)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.2, Cluster list: 100.100.100.100

R1c では Cluster list: 100.100.100.100 という値が記録されています。この 100.100.100.100 は RR1 の Router ID と一致しており、RR1 で bgp cluster-id を明示設定していないため Router ID が既定値として Cluster ID に流用された結果です。Originator ID = 1.1.1.2 (R1b の Router ID) と組み合わせることで、経路が「R1b で origin、RR1 のクラスタ (100.100.100.100) を 1 回通過した」という履歴が一意に追跡可能となります。

RR1 の running-config で BGP セクションを確認すると、Cluster ID の明示設定が無いことが分かります。

RR1#show running-config | section router bgp
router bgp 100
 bgp router-id 100.100.100.100
 bgp log-neighbor-changes
 neighbor 10.0.100.1 remote-as 100
 neighbor 10.0.100.1 description iBGP_R1a_client
 neighbor 10.0.100.6 remote-as 100
 neighbor 10.0.100.6 description iBGP_R1b_client
 neighbor 10.0.100.10 remote-as 100
 neighbor 10.0.100.10 description iBGP_R1c_client
 !
 address-family ipv4
  neighbor 10.0.100.1 activate
  neighbor 10.0.100.1 route-reflector-client
  neighbor 10.0.100.6 activate
  neighbor 10.0.100.6 route-reflector-client
  neighbor 10.0.100.10 activate
  neighbor 10.0.100.10 route-reflector-client
 exit-address-family

bgp cluster-id の行が一切存在しません。それでも実機の Cluster list には 100.100.100.100 が記録されているため、IOS-XE 17.x が Router ID を Cluster ID として自動的に流用していることが確認できます。この既定値は RR を 1 台で運用する場合は十分 ですが、RR を二重化 (RR1 + RR2) して Cluster ID を一致させたい構成では bgp cluster-id <id> での明示設定が必要となります。

クライアント側の show ip bgp neighbors では Route-Reflector Client 表記が出ないことも確認しておきます。

R1c#show ip bgp neighbors | include BGP neighbor|BGP state|Route-Reflector
BGP neighbor is 10.0.100.9,  remote AS 100, internal link
  BGP state = Established, up for 00:09:11

R1c の出力には Route-Reflector Client 表記が含まれていません。R1c 自身は Client であって RR ではないため、自身の neighbor (= RR1) に対する関係は通常の internal link 扱いとして表示されます。Route-Reflector Client 表記は RR 側 の show ip bgp neighbors でのみ表示される非対称な情報で、設定対称性が成り立たないことを示しています。

AS 境界を越えると Originator ID と Cluster list がどう扱われるかは R5 (eBGP peer、AS300) 視点で確認できます。R5 が AS100 内の唯一見えている prefix である 10.10.1.0/24 の詳細を見ると以下のとおりです。

R5#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:
     1         
  Refresh Epoch 1
  100
    10.0.15.1 from 10.0.15.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best

AS_PATH は 100 単一表記で、Originator ID や Cluster list の行は出力されていません。これは Originator ID と Cluster list が Optional Non-Transitive 属性 として定義されており、eBGP 境界を越える時点で剥がれる規約に基づきます。AS 100 内部の反射構造は隣接 AS (AS300) から見ると完全に不可視となり、AS の内部設計を漏らさない設計となっています。10.10.2.0/24 と 10.10.3.0/24 が R5 に届かない事実は Phase C で触れたとおり、next-hop 解決失敗による best 落選が原因です。

iBGP のループ防止が AS_PATH ではなく Originator / Cluster list に依存している事実も整理します。3-6 BGP §2 で「path vector 型の核心は AS_PATH によるループ防止」と扱いましたが、これは eBGP 越境時の話です。iBGP 広告では自 AS 番号を AS_PATH に prepend しないため、AS 内で経路が回っても AS_PATH 長は伸びず、AS_PATH を見ても AS 内のループは検出できません (本来 iBGP は「internal peer から受けた経路を他の internal peer に再広告しない」という規約自体でループを防いでいました)。RR はこの再広告禁止を意図的に破るため、別系統のループ防止として Originator ID による発生源照合 (自分の Router ID と一致する経路を破棄) と Cluster list によるクラスタ重複検出 (自分の Cluster ID が既に含まれていれば破棄) の 2 つを使います。AS_PATH と Originator / Cluster list は適用範囲が異なるループ防止機構で、両者が組み合わさることで AS 内外のループが防がれます。

11. Phase E: 標準 RR 構成で反射経路を best + RIB 採用に (next-hop 整備)

Phase A-D で使った最小構成 (P2P 直結 iBGP + static + next-hop-self) では、反射経路の next-hop が R1a の Gi3 P2P IP (10.0.100.1) のままで、R1b / R1c はその IP への IGP 経路を持たず (inaccessible) で best 落選していました。本節では実運用での標準構成 (AS100 内 OSPF + Lo0 ピアリング + eBGP edge での next-hop-self) を実機に投入し、最小構成との before / after を対照 します。

標準構成は次の 3 点です。

• (a) AS100 内に OSPF を流す — OSPF process 1 (area 0) を R1a / RR1 / R1b / R1c の Lo0 と AS100 内 Gi リンクに有効化し、全ルータの Lo0 を IGP で reachable にします。R1a の eBGP リンク (Gi2 → R5) は OSPF に含めません (AS300 へ IGP を漏らさないため)。
• (b) iBGP を Lo0 ピアリングに張り替える — Gi P2P アドレスではなく Lo0 同士で iBGP セッションを張ります (neighbor <Lo0> update-source Loopback0)。最小構成で使っていた static 経路は OSPF が代替するため撤去します。
• (c) R1a で next-hop-self を投入する — R1a は eBGP edge として AS200 / AS300 経路を eBGP で学習し、それを iBGP で RR1 に広告します。この eBGP 由来経路 に対しては、R1a の neighbor <RR1-Lo0> next-hop-self (通常形) が next-hop を R1a 自身の Lo0 (1.1.1.1) に書き換えます。Lo0 は (a) の OSPF で全 client から到達可能なので、反射経路の next-hop も解決できるようになります。なお next-hop-self には all キーワード を付けた形 (next-hop-self all) もありますが、これは RR が iBGP で受け取って反射する経路 (= iBGP 由来) の next-hop も自分に書き換えたい場合 に使う RR 側のオプションです。R1a は RR ではなく eBGP edge で、自身が eBGP 学習した経路を渡すだけなので、通常の next-hop-self で目的を果たせます (本ラボでは R1a に all 付きを投入していますが、AS200 / AS300 経路の next-hop 書き換えという観点では通常形と同じ結果になります)。

まず before として、最小構成のままの R1b 視点を再掲します。

R1b#show ip bgp 10.20.3.0/24
BGP routing table entry for 10.20.3.0/24, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 2
  300 200
    10.0.100.1 (inaccessible) from 10.0.100.5 (100.100.100.100)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.1, Cluster list: 100.100.100.100
      rx pathid: 0, tx pathid: 0
      Updated on Jun 12 2026 12:06:30 UTC
R1b#show ip route 10.20.3.0 255.255.255.0
% Subnet not in table

no best path、next-hop 10.0.100.1 (inaccessible)、% Subnet not in table (RIB に載らない) の 3 点が最小構成の限界を示しています。反射自体は成立しており、Originator: 1.1.1.1 と Cluster list: 100.100.100.100 も乗っていますが、next-hop が forwarding 不能のため best に至りません。

(a) の OSPF を投入すると、AS100 内の隣接が FULL になり全 client の Lo0 が IGP で見えます。RR1 視点で確認します。

RR1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.3           1   FULL/BDR        00:00:33    10.0.100.10     GigabitEthernet4
1.1.1.2           1   FULL/BDR        00:00:34    10.0.100.6      GigabitEthernet3
1.1.1.1           1   FULL/DR         00:00:32    10.0.100.1      GigabitEthernet2
RR1#show ip route ospf
      1.0.0.0/32 is subnetted, 3 subnets
O        1.1.1.1 [110/2] via 10.0.100.1, 00:04:20, GigabitEthernet2
O        1.1.1.2 [110/2] via 10.0.100.6, 00:02:51, GigabitEthernet3
O        1.1.1.3 [110/2] via 10.0.100.10, 00:01:53, GigabitEthernet4

RR1 は 3 client すべてと OSPF FULL になり、各 Lo0 (1.1.1.1 / 1.1.1.2 / 1.1.1.3) を O ... [110/2] で学習しています。これで R1a の Lo0 (1.1.1.1) が AS100 内のどこからでも IGP で到達可能になりました。

(b) の Lo0 ピアリング張り替えと (c) の next-hop-self を投入後、同じ prefix の R1b 視点出力は after として次のとおりです。

R1b#show ip bgp 10.20.3.0/24
BGP routing table entry for 10.20.3.0/24, version 19
Paths: (1 available, best #1, table default)
  Flag: 0x100
  Not advertised to any peer
  Refresh Epoch 2
  300 200
    1.1.1.1 (metric 3) from 100.100.100.100 (100.100.100.100)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 1.1.1.1, Cluster list: 100.100.100.100
      rx pathid: 0, tx pathid: 0x0
      Updated on Jun 12 2026 12:20:33 UTC
R1b#show ip route 10.20.3.0 255.255.255.0
Routing entry for 10.20.3.0/24
  Known via "bgp 100", distance 200, metric 0
  Tag 300, type internal
  Last update from 1.1.1.1 00:03:50 ago
  Routing Descriptor Blocks:
  * 1.1.1.1, from 100.100.100.100, 00:03:50 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 300
      MPLS label: none

before との差分は 3 点です。第一に next-hop が 10.0.100.1 (inaccessible) から 1.1.1.1 (metric 3) に変わりました。これは R1a の Lo0 で、R1a の next-hop-self が eBGP 学習経路を渡す際に書き換えた値です。(metric 3) は OSPF コストで到達可能であることを示します。第二に Paths: (1 available, best #1) で best 取得 に転じました。第三に show ip route 10.20.3.0 が Known via "bgp 100", distance 200 で RIB に載った ことです (% Subnet not in table から変化)。Originator: 1.1.1.1 と Cluster list: 100.100.100.100 は反射経路の証跡として after でも維持されています。受信元 from 100.100.100.100 も RR1 経由のままです。R1c 視点でも同じ構造で best + RIB 採用に変わります。

§9 で観察した「AS100 内の client 経路が R5 (eBGP peer) に届かない」現象も標準構成では解消します。next-hop 解決後、R5 視点では次のとおりです。

R5#show ip bgp 10.10.2.0/24
BGP routing table entry for 10.10.2.0/24, version 17
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  100
    10.0.15.1 from 10.0.15.1 (1.1.1.1)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Jun 12 2026 12:20:33 UTC
R5#show ip bgp 10.10.3.0/24
BGP routing table entry for 10.10.3.0/24, version 18
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 1
  100
    10.0.15.1 from 10.0.15.1 (1.1.1.1)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Jun 12 2026 12:21:31 UTC

§9 で % Network not in table だった 10.10.2.0/24 と 10.10.3.0/24 が、R5 で valid, external, best、AS_PATH 100、from 10.0.15.1 (1.1.1.1) で受信できています。next-hop が解決して R1a 上でこれらの反射経路が best に立ったため、R1a が標準の BGP 広告処理として自身の eBGP peer R5 へ再広告できるようになった結果です。

iBGP セッションが Lo0 で張られていることも RR1 の summary で確認できます。

RR1#show ip bgp summary
BGP router identifier 100.100.100.100, local AS number 100
BGP table version is 28, main routing table version 28
5 network entries using 1240 bytes of memory
5 path entries using 680 bytes of memory
2/2 BGP path/bestpath attribute entries using 576 bytes of memory
1 BGP AS-PATH entries using 40 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 2536 total bytes of memory
BGP activity 12/7 prefixes, 18/13 paths, scan interval 60 secs
5 networks peaked at 12:06:30 Jun 12 2026 UTC (00:18:38.090 ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4          100      12      15       28    0    0 00:05:40        3
1.1.1.2         4          100      10      15       28    0    0 00:04:34        1
1.1.1.3         4          100       9      13       28    0    0 00:03:36        1

Neighbor 列が Gi P2P アドレス (10.0.100.1 / 10.0.100.6 / 10.0.100.10) から client の Lo0 (1.1.1.1 / 1.1.1.2 / 1.1.1.3) に変わっており、Lo0 ピアリングが成立しています。Lo0 ピアリングは物理リンクが 1 本死んでも IGP が別経路を見つければ iBGP セッションが切れないという冗長性の利点もあり、実運用での標準的な張り方です。

ここまでで、最小構成では届かなかった反射経路を、標準構成では届かせられることを実機で確認しました。RR1 は属性をそのまま反射するだけで next-hop を書き換えないため、RR の導入と next-hop 解決 (IGP による Lo0 到達性 + eBGP edge での next-hop-self) は 別系統の課題 として両方を整える必要がある、という設計判断が浮き彫りになります。

12. Phase F: 二重 RR と Cluster ID — Cluster list ループ判定の破棄 / 採用

§5 で扱った Cluster list の真価は RR を二重化した構成 で出ます。Phase D までの単一 RR では Cluster list は属性として経路に乗るだけで、ループ判定による経路の破棄 / 採用の差を観察できませんでした。本節では Phase E の標準構成を土台に 二重 RR を組み、Cluster ID を同一にした場合と別々にした場合で挙動がどう変わるかを実機対照します。

ノードを増やさずに 2 台目の RR を用意するため、本ラボでは 既存のクライアント R1c を 2 台目の RR (RR2) に役割変更 します。構成は次のとおりです。

• RR1 のクライアント = R1a / R1b。RR2 (= R1c) のクライアント = R1a / R1b。R1a と R1b は 両方の RR のクライアント として両 Lo0 と iBGP を張ります。
• RR1 と RR2 は相互に iBGP を張りますが、互いを route-reflector-client にはしません (RR 同士は Non-Client iBGP)。
• Cluster ID を bgp cluster-id <id> で明示設定し、同一 (RR1 = RR2 = 10.0.0.7) と 別々 (RR1 = 10.0.0.71 / RR2 = 10.0.0.72) の 2 ケースを作ります。

ここで観察のポイントとなるのは Cluster list のループ判定が「RR の側」で起きる という点です。R1a が origin した 10.10.1.0/24 を RR1 と RR2 が各々クライアント R1a から直接受け取り、互いに反射し合います。一方の RR が「もう一方の RR が反射したコピー」を受信した時に、Cluster list に自分の Cluster ID が含まれているかどうかでループ判定が走ります。したがって破棄 / 採用の差は RR2 (= R1c) 視点 で観察します。

まず同一 Cluster ID (RR1 = RR2 = 10.0.0.7) の場合の RR2 視点です。

R1c#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:
     7          8         
  Refresh Epoch 2
  Local, (Received from a RR-client)
    1.1.1.1 (metric 3) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Jun 12 2026 12:32:05 UTC

RR2 は 10.10.1.0/24 を 1 経路だけ 保持しています。それは (Received from a RR-client) 表記のとおり クライアント R1a (1.1.1.1) から直接受信した経路 です。RR1 が反射したコピー (Cluster list に 10.0.0.7 が乗っている) は UPDATE として届きますが、RR2 自身の Cluster ID も 10.0.0.7 のため Cluster list 重複としてループ判定され破棄 されます。破棄された経路は BGP テーブルに取り込まれないため show ip bgp には現れず、出力には残った 1 経路だけが表示されます。これが Cluster ID を一致させた二重 RR でループが抑止される仕組みで、RFC 4456 §7 が定める Cluster list の本来の役割です。

次に別々の Cluster ID (RR1 = 10.0.0.71 / RR2 = 10.0.0.72) にした場合の RR2 視点です。

R1c#show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 2
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     10         11        
  Refresh Epoch 1
  Local
    1.1.1.1 (metric 3) from 100.100.100.100 (100.100.100.100)
      Origin IGP, metric 0, localpref 100, valid, internal
      Originator: 1.1.1.1, Cluster list: 10.0.0.71
      rx pathid: 0, tx pathid: 0
      Updated on Jun 12 2026 12:36:29 UTC
  Refresh Epoch 2
  Local, (Received from a RR-client)
    1.1.1.1 (metric 3) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      rx pathid: 0, tx pathid: 0x0
      Updated on Jun 12 2026 12:35:38 UTC

同じ RR2 が今度は 2 経路 を保持しています。1 つはクライアント R1a 直受け、もう 1 つは RR1 (100.100.100.100) が反射したコピー で、Cluster list: 10.0.0.71 (RR1 の Cluster ID) が乗っています。RR2 自身の Cluster ID は 10.0.0.72 でこの Cluster list には含まれないため、ループ判定されず採用 されます。Cluster ID を別々にすると RR 間で反射経路を持ち合う状態になり、情報が重複する (冗長になる) ことが分かります。同一 Cluster ID の 1 経路と並べると、Cluster list ループ判定が破棄 (同一) と採用 (別々) を分ける様子が対照できます。

RR1 視点の summary でも二重 RR の構成が読めます。

RR1#show ip bgp summary
BGP router identifier 100.100.100.100, local AS number 100
BGP table version is 30, main routing table version 30
5 network entries using 1240 bytes of memory
9 path entries using 1224 bytes of memory
2/2 BGP path/bestpath attribute entries using 576 bytes of memory
2 BGP rrinfo entries using 80 bytes of memory
1 BGP AS-PATH entries using 40 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 3160 total bytes of memory
BGP activity 12/7 prefixes, 23/14 paths, scan interval 60 secs
5 networks peaked at 12:06:30 Jun 12 2026 UTC (00:24:05.767 ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4          100      18      22       30    0    0 00:11:08        3
1.1.1.2         4          100      16      22       30    0    0 00:10:02        1
1.1.1.3         4          100      13      12       30    0    0 00:05:03        5

2 BGP rrinfo entries (Route Reflector 関連属性のエントリ) が出ており、neighbor 1.1.1.3 (= RR2) からの受信 prefix 数が 5 になっています。RR2 が反射経路を RR1 にも返している (RR 同士が経路を交換している) ことが読み取れます。RR1 の running-config を見ると Cluster ID の明示設定が確認できます。

RR1#show running-config | section router bgp
router bgp 100
 bgp router-id 100.100.100.100
 bgp cluster-id 10.0.0.71
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 description iBGP_R1a_client_Lo0
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 1.1.1.2 remote-as 100
 neighbor 1.1.1.2 description iBGP_R1b_client_Lo0
 neighbor 1.1.1.2 update-source Loopback0
 neighbor 1.1.1.3 remote-as 100
 neighbor 1.1.1.3 description iBGP_R1c_client_Lo0
 neighbor 1.1.1.3 update-source Loopback0
 !
 address-family ipv4
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 route-reflector-client
  neighbor 1.1.1.2 activate
  neighbor 1.1.1.2 route-reflector-client
  neighbor 1.1.1.3 activate
 exit-address-family

bgp cluster-id 10.0.0.71 が明示設定されています (Phase D の単一 RR では Router ID 流用の既定値でした)。注目すべきは address-family の neighbor 設定で、クライアント R1a (1.1.1.1) / R1b (1.1.1.2) には route-reflector-client が付いていますが、RR2 (1.1.1.3) には付いていません。RR 同士は Non-Client iBGP として張る、という設計が config に表れています。

最後に、この実機結果が示す重要な注意点を 1 つ整理します。クライアント R1b 視点で同じ prefix を見ると、同一 Cluster ID でも別々の Cluster ID でも 2 経路 が見えます。これは R1b が RR1 と RR2 の 両方の直接クライアント であり、各 RR がクライアント R1a 由来の経路を R1b に直接反射するためです。Cluster list によるループ抑止は「RR が別の RR の反射コピーを受けた時」に RR 層で完結する仕組みであって、クライアントが受け取る経路の本数を直接決めるものではありません。Cluster list は RR 間のループ防止 が本質であるという RFC 4456 の役割が、この観測点の違いから読み取れます。本節で破棄 / 採用の差を RR2 視点で観察したのはこのためです。

13. 落とし穴・補足 — 教科書とのギャップ

本節の実機検証で見えた事実と、教科書 / Web 解説の記述との差を 5 件整理します。3-3 / 3-4 / 3-5 / 3-6 と同じ「正直記録」枠で、実装の振る舞いを優先します。

落とし穴 1: (Received from a RR-client) 表記は IOS-XE 17.x で実機表示される

一部の書籍や Web 解説では「IOS-XE では Received from a RR-client の文字列は出ず、Originator ID と Cluster list の有無で間接判断する」と書かれることがあります。本ラボの IOS-XE 17.3.x 実機 (csr1000v) での show ip bgp <prefix> 詳細出力では、§8 の Phase B 確認のとおり 明示的に (Received from a RR-client) 表記が表示 されます。RR-Client から受信した経路かどうかの確認手段としては、この明示表記を直接読む方が最も信頼できます。

明示表記が出ない解説に遭遇した場合は、IOS バージョンや confederation との混在構成の差で挙動が分かれている可能性があります。確実な確認には show ip bgp <prefix> 詳細出力の 2 行目 (AS_PATH 行) に着目し、(Received from a RR-client) の末尾表記の有無で判断します。

落とし穴 2: Cluster ID の既定値 = RR Router ID が暗黙で使われる

Phase D の実機観察で確認したとおり、RR1 の running-config には bgp cluster-id の行が存在しません。それでも実機の Cluster list には RR1 の Router ID と同じ 100.100.100.100 が記録されており、明示設定なしでは Router ID が自動的に Cluster ID として流用される 仕様となっています。

RR 1 台で運用する構成では既定値で問題ありません。一方で RR を二重化 (RR1 + RR2 の 2 台で同じクラスタを構成) する場合は、両 RR で 同じ Cluster ID を bgp cluster-id <id> で明示設定する 必要があります (RFC 4456)。明示設定しないと RR1 と RR2 で別々の Cluster ID が使われ、片方の RR で反射された経路がもう片方の RR でループ判定されず相互交換される状態になり得ます。同一クラスタを複数 RR で構成する時点で Cluster ID の明示設定は必須事項として扱う設計判断が必要です。§12 (Phase F) で二重 RR を組み、Cluster ID を一致させた場合 (RR でループ判定され破棄・1 経路) と別々にした場合 (破棄されず採用・2 経路) の差を実機で対照済みです。

落とし穴 3: RR は next-hop を書き換えない (next-hop-self は依然として必要)

一部の教科書解説で「RR を導入すると iBGP の next-hop 問題が解決される」という記述を見かけることがあります。これは誤りで、RR は 反射経路の属性 (next-hop 含む) を既定では書き換えない 設計です (RFC 4456 §10 は NEXT_HOP 等を SHOULD NOT modify と規定。Cisco では RR 側で next-hop-self all を明示すると例外的に反射経路の next-hop を自分に書き換えられますが、既定動作ではありません)。したがって next-hop-self が必要な要件は RR 導入後も変わらず、適切な箇所で投入する必要があります。

本ラボでは R1a に neighbor 10.0.100.2 next-hop-self を投入しました。この設定は R1a が 自身の iBGP peer (= RR1) に対して next-hop を書き換える効果を持ち、書き換え先は R1a の Gi3 の P2P IP (= 10.0.100.1) となります。書き換え結果が R1a の Lo0 ではなく Gi3 IP になるため、RR1 経由で反射された経路を受信した R1b / R1c は 10.0.100.1 への IGP 経路を持たず (inaccessible) 扱いとなりました (Phase B / Phase C の実機観察で確認済み)。

実運用での標準構成は (a) AS 内で OSPF / IS-IS を流して全ルータの Lo0 を IGP で reachable にする、(b) iBGP ピアリングを Lo0 同士で張る、(c) eBGP edge ルータで neighbor <Lo0-IP> next-hop-self を投入し、eBGP 学習経路を渡す際に書き換え先を自身の Lo0 にする という設計です。Phase A-D は設計を単純化するため最小構成 (P2P 直結ピアリング + static 経路) を採用しましたが、結果として反射経路が forwarding できない状態となり、設計の落とし穴を浮き彫りにする構成になりました。§11 (Phase E) でこの (a)〜(c) を実機投入し、最小構成では (inaccessible) で best 落選していた反射経路が、標準構成では best + RIB 採用に変わることを before / after で確認済みです。 なお next-hop-self に all キーワードを付けた next-hop-self all は、RR が iBGP で受け取って反射する経路の next-hop も自分に書き換えたい場合 に RR 側で使うオプションで、eBGP edge での next-hop-self とは適用場面が異なります。RR と next-hop-self は 別系統の課題 であり、両方を適切に組み合わせる必要があります。

落とし穴 4: iBGP から eBGP への再広告は next-hop 解決可能な経路のみ

Phase C で R1a が iBGP (RR 経由) で受け取った R1b / R1c の経路を、自身の eBGP peer R5 へ再広告できるかを確認しましたが、実機では R5 で 10.10.2.0/24 と 10.10.3.0/24 が Network not in table となり、経路は届きませんでした (これは RFC 4456 の reflection rule とは別の話です。reflection rule に EBGP 反射は含まれず、ここで問われているのは R1a の通常の BGP 広告処理です)。

この理由は次のとおりです。R1a は RR1 経由で R1b / R1c の経路を受信しますが、next-hop=10.0.100.6 (R1b) / 10.0.100.10 (R1c) が IGP で解決できないため (inaccessible) 扱いとなり best 落選します (R1a 詳細出力で確認済み)。BGP は best path のみを peer へ広告するため、best 落選した経路は eBGP 再広告の対象から外れ、R1a が R5 へ伝える経路に含まれません。結果として R5 では Network not in table となります。

この事象は BGP の広告処理が破綻しているわけではなく、next-hop 解決ができない経路が結果的に best 落選し再広告対象から外れる 副次的な現象 です。落とし穴 3 で挙げた標準構成 (IGP による Lo0 到達性 + Lo0 ピアリング + eBGP edge での next-hop-self) を採用すれば、R1a / R1b / R1c のいずれの経路も全ルータで best 取得され、R1a からの eBGP 再広告も正しく動作します。§11 (Phase E) でこの標準構成を実機投入したところ、最小構成で Network not in table だった 10.10.2.0/24 と 10.10.3.0/24 が、R5 で valid, external, best として受信できることを確認済みです。

落とし穴 5: iBGP のループ防止は AS_PATH ではなく Originator ID / Cluster list が主役

3-6 BGP §2 で扱った「path vector 型の核心は AS_PATH によるループ防止」という整理は、eBGP 越境時 の話に限定されます。iBGP 広告では自 AS 番号を AS_PATH に prepend しないため、AS 内で経路が回っても AS_PATH は伸びず、AS_PATH だけでは AS 内のループを防げません (本来の iBGP は「internal peer から受けた経路を他の internal peer に再広告しない」という規約でループを防いでいました)。

RR を導入する以前の iBGP は「学習経路を他の iBGP に再広告しない」というシンプルな規約だけで AS 内のループを防いでいました。RR はこの規約を意図的に破るため、別系統のループ防止機構として Originator ID (Type 9、Optional Non-Transitive) と Cluster list (Type 10、Optional Non-Transitive) という 2 つの新属性が追加されています (RFC 4456)。

ループ防止の役割分担は以下のとおりに整理できます。

Originator ID と Cluster list は Non-Transitive 属性 のため eBGP 境界で剥がれます (Phase D の R5 視点で AS_PATH のみ表示される実観察)。これは AS 内部の反射構造を隣接 AS に漏らさないための規約で、AS 内部設計の独立性を保つ仕組みです。RR を運用する AS では、AS_PATH に頼らずに iBGP 内のループが防がれている事実を理解した上で属性の付与状況を読む必要があります。

14. 次節

3-3 RIP、3-4 EIGRP、3-5 OSPF、3-6 BGP、本節 3-7 Route Reflector を通して、第 3 章 L3 編の 7/18 を消化しました。全 18 節構成のうち、IGP (RIP / EIGRP / OSPF) と EGP (BGP) の主要プロトコルと、iBGP full-mesh 問題の解の 1 系統まで通したことになります。

ここまでで残るトピックは次のとおりです。

• BGP community 属性 (RFC 1997) — 標準 community (no-export / no-advertise / local-AS) と拡張 community、ISP 間のポリシー伝搬の語彙
• Confederation — 本節で扱った Route Reflector と並ぶ iBGP full-mesh 問題の解、sub-AS 設計による AS 分割
• FHRP (First Hop Redundancy Protocol) — HSRP (Hot Standby Router Protocol) / VRRP (Virtual Router Redundancy Protocol) / GLBP (Gateway Load Balancing Protocol)、デフォルトゲートウェイの冗長化
• ルーティングポリシー総括 — route-map / prefix-list / AS-PATH ACL の応用、属性操作シナリオ集
• マルチキャストルーティング — PIM Sparse Mode、RP (Rendezvous Point)、IGMP
• IPv6 ルーティング — OSPFv3、MP-BGP for IPv6、SLAAC と DHCPv6

3-8 の選択肢は 2 系統あります。本節の流れを引き継いで BGP community 属性 を扱うと、ISP 内ポリシーの語彙としての community と Confederation の比較がまとまり、BGP 系列の連載として一貫します。一方で IGP / EGP の集大成を一旦締めて FHRP (HSRP / VRRP / GLBP) に切り替えると、L3 編のスコープを「ルーティング」から「ファーストホップの冗長化」に広げる構成となります。どちらの順序にするかは次節執筆時に判断します。

第 3 章後半は引き続き、教科書記述と Cisco IOS-XE 17.x 実装のギャップを「落とし穴・補足」節で正直に記録する方針で進めます。CML2.9 上の実機 capture を主軸にして、Phase 別の検証を見ていきましょう。

次節

• 3-8 BGP community 属性 — 経路に付けるタグと no-export / no-advertise / route-map 連携