ちらりんブログ ロゴ ちらりんブログ
STUDY · NETWORK GUIDE

3-6 BGP — path vector と AS_PATH、ベストパス選定 8 ステップ

BGP の path vector としての性質、neighbor 6 状態遷移、ベストパス選定 8 ステップ、iBGP next-hop-self、経路集約を整理する。AS100 / AS200 / AS300 の 3 AS・5 ルータ構成で実機検証する。

1. IGP から EGP へ — 同一管理組織から世界規模へ

3-3 で RIP、3-4 で EIGRP、3-5 で OSPF と、ここまで 3 つのルーティングプロトコルを見てきました。これらはいずれも IGP (Interior Gateway Protocol) に分類され、同一の管理組織が運用する範囲の中で経路情報を交換するプロトコルです。一企業のネットワーク、一大学のキャンパスネットワーク、一データセンター内部、いずれも IGP の世界となります。

これに対し、本節で扱う BGP (Border Gateway Protocol、現バージョン 4) は EGP (Exterior Gateway Protocol) に分類されます。EGP の役割は 異なる管理組織のネットワーク同士を接続することです。インターネットを構成する数万の組織 (Tier 1 ISP、Tier 2 ISP、企業、クラウド事業者、IX) は、それぞれが 自分のネットワーク = AS (Autonomous System) として外界と接続されます。AS と AS を結ぶプロトコルが BGP4 であり、BGP が運ぶ経路情報の総量が、いま「インターネットのフルルートテーブル」と呼ばれるものになります。

AS は 16-bit (0〜65535) または 32-bit の整数で識別されます。16-bit のうち AS 0 (RFC 7607) や AS 65535 (RFC 7300) のほか、documentation 用 (64496〜64511、RFC 5398)・private 用 (64512〜65534、RFC 6996)・AS_TRANS 23456 (RFC 6793) などが予約されており、公衆インターネット向けにグローバル割り当てされるのはこれらを除いた範囲です。割り当ては IANA / 地域 RIR (APNIC / ARIN / RIPE NCC / LACNIC / AFRINIC) がグローバルに一意となるよう管理します。private AS 番号として 64512〜65534 (16-bit private) と 4200000000〜4294967294 (32-bit private) が予約されており、対外接続しない企業内 BGP やラボでは private AS を使います。本節のラボ (AS100 / AS200 / AS300) は本来 public AS 番号帯ですが、外部から到達できないラボ環境のためそのまま使います。

インターネット BGP テーブルの規模感としては、IPv4 のフルルートで 100 万 prefix 前後、IPv6 で 20 万 prefix 超に達しています (この値は年々増え続ける時点依存の数字なので、最新値は CIDR Report などで都度確認してください)。1 つのプロトコルで百万規模の経路をやり取りするため、BGP は IGP とは設計思想が大きく異なります。本節ではこの設計差を 1 つずつ整理します。

2. path vector 型の本質 — 距離ベクトル / リンクステートとの根本的な違い

これまで扱った IGP は、3-3 RIP と 3-4 EIGRP が 距離ベクトル型 (Distance Vector)、3-5 OSPF が リンクステート型 (Link State) という分類でした。距離ベクトル型は「隣接が広告するメトリックを信じて経路を選ぶ」、リンクステート型は「全員で同じトポロジ DB を持って各自ダイクストラで計算する」という構造をそれぞれ持ちます。

BGP はこの両者とは別の 第三の系譜、path vector 型 (Path Vector) に属します。path vector の核心は、経路情報にメトリックだけでなく 経路そのもの (どの AS を通ってきたかのリスト = AS_PATH) を載せて運ぶ点にあります。距離ベクトル型は「コスト N」のみを伝え、リンクステート型は「リンクの状態」だけを伝えます。これに対し path vector 型は「コスト相当の属性 + どの AS を経由してきたか」という 事実の蓄積 を運びます。

この差は 3 つの帰結を生みます。

第一に、AS 間のループ防止が AS_PATH の検査だけで完結する点。受信側が AS_PATH に自分の AS 番号を見つけたら、その経路は破棄します。RIP のような split horizon / poison reverse の細工も、EIGRP の Feasibility Condition も、OSPF の Area 単位の Type 制約も不要です。AS_PATH を見るだけで AS 間ループが判定できる仕組みで、AS 単位の粒度に最適化されています (AS 内 = iBGP のループ防止は別系統で、3-7 Route Reflector で扱います)。

第二に、ベストパス選定がメトリック比較ではなく属性の優先順位による「判断」になる点。これは後述する 8 ステップの選定ロジックにつながります。BGP のベストパス選定は「演算」ではなく「ルール照合」です。

第三に、ポリシーを表現できる点。「最短」が常に最適とは限らないのが AS 間ルーティングです。Tier 1 ISP A への顧客契約と Tier 1 ISP B への顧客契約の料金差、特定 prefix のセキュリティ要件、メンテナンス時の迂回経路、といったビジネス都合や運用都合を「最短より優先する」表現が必要になります。BGP は属性 (LOCAL_PREF / MED / community など) を route-map などのポリシー機構で操作してこれを表現でき、IGP のような「常に最短」の世界とは設計の出発点が違います。

BGP の性質をまとめると、「事実 (経路) を運び、ルールで判断し、ポリシーで歪める」プロトコルとなります。「速さ」「短さ」「ループ防止」を IGP のように内部演算でこなすのではなく、運用者が表現したい意図を BGP の属性で記述する、という運用面の比重が大きいプロトコルです。

3. eBGP と iBGP — 同じ BGP プロトコルだが性質が違う

BGP は 1 つのプロトコルですが、ピアリング (Peering) の相手によって 役割が変わります。

eBGP (external BGP) は 異なる AS 同士のピアリングです。AS100 のルータと AS200 のルータが BGP セッションを張れば eBGP となります。TCP 179 で接続する点は同じですが、デフォルトの TTL=1 で動作します。これは隣接 AS のルータが 直結している前提 を意味します。物理的に 1 ホップ離れていれば eBGP セッションは張れず、この場合は ebgp-multihop オプションで TTL を上げる必要があります。

iBGP (internal BGP) は 同じ AS 内のピアリングです。AS100 の R1 と R2 が BGP セッションを張れば iBGP となります。こちらは TTL=255 がデフォルトで、ピアが何ホップ離れていても問題ありません。ただし iBGP には 重要な制約 があります。

iBGP の制約とは、iBGP の学習経路は、他の iBGP ピアに再広告されないこと。これは IGP の split horizon を AS 規模に拡張したもので、AS 内でループを防ぐための設計です。結果として、AS 内のすべてのルータが BGP で動く必要があるなら、iBGP は全ノード間で full-mesh に張る必要があります。n 台のルータがあれば n×(n-1)/2 セッション、10 台で 45 セッション、100 台で 4950 セッションとなります。これが §13 で扱う「iBGP full-mesh 問題」であり、次節 (3-7) の Route Reflector が解決を目指す問題でもあります。

eBGP と iBGP のもう 1 つの差は、ピアリングに使う IP アドレスです。eBGP は隣接 AS のルータと直結している前提のため、その直結リンクの IP でピアリングします (R1 Gi2 = 10.0.15.1 ↔ R5 Gi2 = 10.0.15.2 のような直結 P2P)。iBGP は AS 内なので、Loopback アドレスでピアリングする運用が一般的です。AS 内では IGP (OSPF / EIGRP) が動作しており、Lo0 同士の到達は IGP で確保されます。Lo0 ピアリングなら物理リンク 1 本が落ちても別経路で iBGP セッションが維持されるため、可用性が高くなります。

ただし Lo0 ピアリングには 1 つだけ注意点があります。eBGP で学習した経路を iBGP で再広告するとき、経路の next-hop が eBGP 隣接のアドレスのまま で iBGP ピアに伝わる点です。iBGP ピア側は「next-hop = eBGP 隣接の IP」への経路を IGP で知っている必要があり、知らなければ経路として成立しません。これが §12 で詳述する next-hop-self の話となります。

本ラボでは設計の単純化のため iBGP も 直結リンク IP でピアリング します。Lo0 ピアリング + IGP 連動は注意書きとして触れる程度に留め、本節の主題 (path vector とベストパス選定) に集中します。

4. TCP/179 と 4 種のメッセージ

BGP は TCP 179 ポート の上で動作します。これは過去の IGP との大きな違いで、RIP は UDP/520、OSPF は IP protocol 89 (raw)、EIGRP は IP protocol 88 (raw) と、いずれも TCP のような信頼性のあるトランスポートを使いません。このうち OSPF と EIGRP は信頼性が要る更新のために retransmit / sequence / ack の仕組みをプロトコル自身で実装しています (EIGRP の RTP、OSPF の LSAck 等)。一方 RIP は UDP/520 上で request / response を周期的にやり取りする単純な距離ベクトルで、ACK・sequence・retransmit 型の信頼性制御は持たず、定期送信と保持タイマーで整合を取る設計です。

BGP は TCP に任せたので、基本メッセージは至ってシンプルな 4 種類です (RFC 4271)。なお現代の BGP では RFC 2918 の ROUTE-REFRESH (type 5) が標準拡張として加わり、ポリシー変更時に経路を再送させる用途で広く使われます。ここでは基礎として中核の 4 種類を押さえます。

OPEN はセッション確立時に交換するメッセージで、BGP version (4 のみが現役)、自身の AS 番号、hold-time、BGP Identifier (= router-id) が乗ります。両端で OPEN を交換して合意できればセッションが Established に進みます。

UPDATE は経路の通知メッセージで、本体は 2 つに分かれます。1 つは withdrawn routes (取り消す prefix)、もう 1 つは NLRI (Network Layer Reachability Information、新しく広告する prefix) と path attributes (AS_PATH / next-hop / LOCAL_PREF / MED / origin / community などの属性群) です。1 つの UPDATE の Path Attributes は、その NLRI フィールドに並ぶ複数の prefix に 共通して 適用される構造なので、同じ属性セットを共有する prefix 群を 1 メッセージにまとめられます (属性が異なる prefix は別 UPDATE に分かれます)。初回の Established 時はテーブル全体が複数の UPDATE に分けて流れます。

KEEPALIVE はピアの生存確認で、デフォルトで hold-time の 1/3 間隔 で送信されます。hold-time のデフォルトが 180 秒なので KEEPALIVE は 60 秒間隔となります。hold-time 内に KEEPALIVE (または UPDATE) が来なければセッション切断となります。

NOTIFICATION はエラー時の通知で、エラーコードを乗せてセッションを切断します。AS 番号の不一致、hold-time の合意失敗、不正な属性、TCP リセット相当の状況などで発火します。

メッセージが 4 種類だけで済むのは、経路の交換は UPDATE だけ という設計の単純さによります。距離ベクトル型のような周期 Update も、OSPF のような Hello + DBD + LSR + LSU + LSAck の 5 種類のパケットも、BGP には存在しません。TCP に乗せることで信頼性と順序性を委譲した結果、BGP プロトコル自身は「OPEN で握手、UPDATE で経路、KEEPALIVE で生存、NOTIFICATION でエラー」のミニマルな構成に絞れています。

5. neighbor 6 状態遷移 — Established に至るまで

BGP セッションが確立するまでには、6 状態の有限ステートマシン を通過します。

snippet 
Idle → Connect → Active → OpenSent → OpenConfirm → Established
BGP neighbor 6 状態遷移 — 各状態にホバーで詳細表示

各状態の意味は以下のとおりです。

Idle はセッション初期化前の状態。neighbor remote-as 設定が投入されると、まず Idle に入ります。RFC 4271 の FSM では、Idle で ManualStart / AutomaticStart イベントを受けると BGP リソースを初期化し、ConnectRetryTimer を起動した上で TCP 接続を開始して Connect に遷移します。ConnectRetryTimer (デフォルト 120 秒) は接続失敗時の再試行間隔を司るタイマーで、Idle → Connect 遷移そのものの発火源ではない点に注意します (エラーで切断された場合も Idle 復帰となります)。

Connect は TCP 接続の確立を待つ状態。3-way handshake の SYN を投げて、SYN-ACK が返ってくるのを待ちます。TCP 確立に成功すれば OpenSent に進み、失敗したら Active に遷移します。

Active は TCP 接続が失敗したため積極的に再試行している状態 で、名前と挙動が直感に反する点に注意が必要です。「Active = 動いている = 良い」と読めてしまうものの、実際は「Established に到達できていない」状態を表します。show ip bgp summary で長く Active のままなら、TCP 179 が通っていないか、対向 IP に到達できないかを疑います。

OpenSent は自身の OPEN メッセージを送信し、相手の OPEN を待つ状態。相手の OPEN が来て、AS 番号と hold-time が合意可能なら OpenConfirm に進みます。AS 番号不一致なら NOTIFICATION を送って Idle に戻ります。

OpenConfirm は相手の OPEN を受け取り、初回 KEEPALIVE の交換を待つ状態。比較的早く Established に進む短い状態となります。

Established がゴールであり、ここで初めて UPDATE メッセージの交換が始まります。show ip bgp summary の State/PfxRcd 欄が数字 (受信 prefix 数) になっているのが Established を示します。Established 中は KEEPALIVE と UPDATE が流れ続け、hold-time 内に何も来なければ切断、再度 Idle から始まります。

実機での観察手段としては、debug bgp ipv4 unicast (または debug ip bgp) を入れると状態遷移のメッセージがコンソールに出力されます。本ラボでは Phase A で 5 台のルータが一斉に BGP を起動し、数秒〜十数秒で全 6 セッションが Established に到達する様子を show ip bgp summary で観察します。

6. ラボトポロジ — 3 AS / 5 ルータ / 6 BGP セッション

本ラボは AS100 / AS200 / AS300 の 3 AS、ルータ 5 台 (R1〜R5) で構成します。

3-6 BGP ラボトポロジ — AS100 (R1/R2) + AS300 (R5 transit) + AS200 (R3/R4)
  • AS100 = R1 / R2 (iBGP セッション 1 本)
  • AS200 = R3 / R4 (iBGP セッション 1 本)
  • AS300 = R5 (transit AS、eBGP のみ 4 本)

eBGP セッションは 4 本:

eBGP セッション接続
R1 ↔ R5AS100 ↔ AS300
R2 ↔ R5AS100 ↔ AS300
R3 ↔ R5AS300 ↔ AS200
R4 ↔ R5AS300 ↔ AS200

iBGP セッションは AS 内に 2 本 (R1-R2 / R3-R4) です。

各エッジルータの Loopback10 から 10.10.x.0/24 (AS100) / 10.20.x.0/24 (AS200) を advertise します。R5 (AS300) は自身では prefix を持たず、AS100 と AS200 の経路を相互に中継する transit AS として動作します。

設定の骨子は IOS-XE の標準的な BGP config であり、R1 を例にすると以下のとおりです。

snippet 
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.12.2 remote-as 100
 !
 address-family ipv4
  network 10.10.1.0 mask 255.255.255.0
  neighbor 10.0.15.2 activate
  neighbor 10.0.12.2 activate
 exit-address-family

router bgp 100 で AS100 として起動、bgp router-id 1.1.1.1 で BGP ID を Lo0 に固定、neighbor ... remote-as ... で 2 つの隣接 (R5 への eBGP と R2 への iBGP) を定義します。address-family ipv4 の中で network で広告 prefix を明示し、neighbor ... activate で IPv4 unicast の交換を有効化します。

IGP の redistribute connected のような自動広告と異なり、BGP に 自分の経路を起源生成する (originate) には network / redistribute / aggregate-address で 明示的に指定 する必要があります (network は対象 prefix と完全一致する経路が RIB にあるときに広告候補とする指定)。学習済みの BGP 経路は best path を選んで隣接ポリシーに従い再広告されますが (R5 transit AS が AS100/AS200 の経路を中継するのがその例)、「自分発の prefix を BGP に載せる」ところは意図的な指定が要る、という点がポリシー駆動の世界観の表れです。本ラボでは各エッジが自身の Loopback10 のみを network で advertise する単純な設計を採用します。

セッション確立は show ip bgp summary で確認します。Phase A の capture で実際に R5 (AS300 transit) を見ると、以下のとおりです。

snippet 
R5#show ip bgp summary
BGP router identifier 5.5.5.5, local AS number 300
BGP table version is 5, main routing table version 5
4 network entries using 992 bytes of memory
8 path entries using 1088 bytes of memory
...
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.15.1       4          100       8       7        5    0    0 00:01:58        2
10.0.25.1       4          100       8      11        5    0    0 00:01:53        2
10.0.35.1       4          200       7      11        5    0    0 00:01:46        2
10.0.45.1       4          200       8      11        5    0    0 00:01:45        2

State/PfxRcd 欄が 2 (数値、Established + 受信 2 prefix) になっており、4 セッションすべてが確立できています。MsgRcvd / MsgSent はメッセージ数で、Established 後の KEEPALIVE が積まれていきます。

R5 の BGP テーブルは以下のとおりです。

snippet 
R5#show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *    10.10.1.0/24     10.0.25.1                              0 100 i
 *>                    10.0.15.1                0             0 100 i
 *    10.10.2.0/24     10.0.25.1                0             0 100 i
 *>                    10.0.15.1                              0 100 i
 *    10.20.3.0/24     10.0.45.1                              0 200 i
 *>                    10.0.35.1                0             0 200 i
 *    10.20.4.0/24     10.0.45.1                0             0 200 i
 *>                    10.0.35.1                              0 200 i

4 prefix それぞれに 2 つの経路があります (R5 は AS100 / AS200 の両方の AS から、それぞれ 2 つのエッジルータ経由で同じ prefix を学習しているため)。*> がベストパス、* だけ付いているのが代替経路。Path 欄に 100 i / 200 i と AS_PATH と origin (i = IGP) が出力されています。AS_PATH は AS100 / AS200 のいずれも長さ 1 (自AS から直接) なので、両経路は §11 で見るベストパス選定の 8 ステップ中 AS_PATH 長 (④) までは勝負がつきません。eBGP 同士のこの同点を Cisco がどう決着させるかは、既定では 先に受信した経路 (oldest path) が優先され、それも同条件なら router-id の小さい方、という後続 tie-breaker の順序によります (詳細は §11)。本ラボではセッション確立順により安定したベストパスが選ばれており、bgp bestpath compare-routerid を明示しない限り「router-id だけで決まる」わけではない点に注意します。

show ip route bgp で見ると、テーブルには各 prefix のベストパスのみが入り、Administrative Distance 20 (eBGP のデフォルト) が表示されます。

snippet 
B        10.10.1.0/24 [20/0] via 10.0.15.1, 00:02:07
B        10.10.2.0/24 [20/0] via 10.0.15.1, 00:02:07
B        10.20.3.0/24 [20/0] via 10.0.35.1, 00:01:55
B        10.20.4.0/24 [20/0] via 10.0.35.1, 00:01:55

iBGP 学習経路は AD=200、eBGP 学習経路は AD=20 という値がこの場面で使われます。3-3 RIP の AD=120、3-4 EIGRP の AD=90、3-5 OSPF の AD=110 に対し、BGP は外部 (eBGP) は 20 で 最も優先、内部 (iBGP) は 200 で 最も低い という設計です。これは「外部から来た経路は IGP 計算結果より信頼すべき (設計者の意図)」「内部の BGP 経路は同じ AS 内 IGP の方が信頼できる」という運用観の表れです。

7. ベストパス選定の起点 — weight (Cisco 独自属性)

BGP のベストパス選定属性は多く (§11 で全 8 ステップを整理)、ここから先は 1 つずつ順に 意味と効果を確認します。最初に扱うのが weight です。

weight は Cisco 独自の属性 であり、他ベンダー (Juniper / Arista / Nokia) では利用できません。CCIE 試験では「Cisco only である」という事実そのものが頻出ポイントです。値は 0〜65535 の整数で、大きいほど優先 されます。デフォルト値は経路の由来によって以下のように決まります。

  • 自身が network / aggregate-address で広告した経路: 32768
  • BGP 隣接 (eBGP / iBGP 問わず) から学習した経路: 0

weight は locally significant という性質を持ちます。「設定したルータ自身でのみ有効、隣接には伝わらない」という意味です。BGP の UPDATE メッセージで運ばれる属性 (AS_PATH / LOCAL_PREF / MED / community) とは異なり、weight は隣接からも経路にも乗ってこず、自身が再広告するときも乗りません。

使いどころは「このルータから見たベストパスをローカル判断で固定したい」場面です。「ローカル判断で」とは、AS 全体のポリシーを共有する必要がなく、1 台のルータの中だけで完結する判断のことを指します。例として「R5 で AS100 への経路を R1 経由で固定したい (R2 経由は使いたくない)」という運用判断を R5 1 台で表現するには、weight が最も素直な手段となります。

設定は neighbor <ip> weight <value> で、neighbor 単位に効きます。route-map ... set weight ... でより細かく prefix 単位の設定も可能です。本ラボの Phase B では、R5 から見た 10.10.1.0/24 (R1 が広告、R2 経由でも届く) のベストパスを R2 経由側に weight 200 を付けて反転させました。show ip bgp 10.10.1.0/24 の実機出力は以下のとおりです。

snippet 
BGP routing table entry for 10.10.1.0/24, version 6
Paths: (2 available, best #1, table default)
  100
    10.0.25.1 from 10.0.25.1 (2.2.2.2)
      Origin IGP, localpref 100, weight 200, valid, external, best
  100
    10.0.15.1 from 10.0.15.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external

weight 200, valid, external, best の行が R2 経由側に付いており、R1 経由側は best が外れています。Phase A の baseline では *> が R1 (10.0.15.1) 側にあったものが、weight 200 投入で R2 (10.0.25.1) 側に切り替わりました。R1 経由側に weight 表示が出ていない (デフォルト 0) のと、R2 側に明示 200 が乗っているのがベストパス選定の根拠であり、best の論拠が weight であることが実機出力から読み取れます。

注意点として、weight は ベストパス選定の一番上 に位置するため (LOCAL_PREF や AS_PATH 長より優先)、不用意な weight 設定で意図せず変な経路が選ばれる場合があります。「本来は LOCAL_PREF で AS 全体が合意した経路を、1 台だけ weight で勝手に切り替えてしまう」事故が典型例です。運用としては「weight は必ず該当ルータの責任範囲内のみで使う」「AS 全体に伝えたい意図は LOCAL_PREF を使う」と棲み分けるのが定石となります。

8. LOCAL_PREF — AS 内の出口選好

LOCAL_PREF (Local Preference) は AS 内で共有される属性で、iBGP セッションで隣接に伝わります。値は 0〜4294967295 の整数で、大きいほど優先 されます。デフォルトは 100 です。

LOCAL_PREF の意図は「AS 全体で同じ出口を使いたい」という運用判断です。例として AS100 がインターネットに 2 つの ISP A・B を通じて接続している場合、「A の方が安いので普段は A を使う、B はバックアップ」というポリシーを AS100 内部の全ルータで共有したいケースがあります。AS100 のエッジで A 経由経路に LOCAL_PREF 200、B 経由経路に LOCAL_PREF 100 (デフォルト) を付けておけば、AS100 内のどのルータから出ても A を選ぶようになります。

設定は neighbor <ip> route-map LP_HIGH in のような形で inbound 方向に route-map を適用 し、route-map 内で set local-preference 200 を指定します。LOCAL_PREF はそのルータが受信した時点で経路に張り付き、iBGP で AS 内に伝播します。eBGP では伝わりません (隣接 AS には自AS 内のポリシーを漏らさない設計)。

ベストパス選定では LOCAL_PREF は 2 番目 (weight の次) に評価されます。weight が同点 (全部デフォルト 0) なら LOCAL_PREF で勝負がつきます。これは「LOCAL_PREF は AS 内のポリシー、weight は 1 台のローカル判断」という設計の表れであり、AS 全体に効く LOCAL_PREF が weight より下位に置かれているのは「1 台の意図的判断 (weight) は AS のポリシー (LOCAL_PREF) より優先したい」という Cisco の運用観に基づきます。

LOCAL_PREF が iBGP で伝播する様子を実機で観察する (Phase G)

LOCAL_PREF の本質は「1 台で付与した出口選好が iBGP 経由で AS 内に伝わり、別のルータの best まで動かす」ことです。これは AS 内に iBGP ピアが 2 台以上あって初めて観察できます。本ラボの AS100 (R1 ↔ R2 の iBGP) がちょうどその構成なので、ここで伝播を実機で見ます。

題材は 10.20.3.0/24 (AS200 R3 の Loopback10) です。R1 も R2 もこの prefix を R5 経由の eBGP で学習しています。ここで R1 が R5 から受け取る経路に inbound route-map で LOCAL_PREF 200 を付与 し、あわせて iBGP 向けに next-hop-self を入れます (next-hop-self を入れないと、後述のとおり iBGP 経路の next-hop が外部 IP のままで到達不能 = best になれないため)。

snippet 
route-map LP-HIGH-IN permit 10
 set local-preference 200
exit
router bgp 100
 address-family ipv4
  neighbor 10.0.15.2 route-map LP-HIGH-IN in
  neighbor 10.0.12.2 next-hop-self

付与する 前 の R2 視点 (show ip bgp 10.20.3.0/24) は以下のとおりで、R2 は自身の eBGP 経路 (LOCAL_PREF 100) を best にしています。R1 から iBGP で来た経路も LOCAL_PREF 100 で並んでいます。

snippet 
  300 200
    10.0.15.2 (inaccessible) from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal
  300 200
    10.0.25.2 from 10.0.25.2 (5.5.5.5)
      Origin IGP, localpref 100, valid, external, best

付与した 後 の R2 視点は以下のとおりです。R1 から iBGP で伝播した経路が localpref 200, valid, internal, best となり、best が R1 経由 (iBGP) に切り替わりました。next-hop も 10.0.12.1 (R1 の iBGP リンク IP) に書き換わって到達可能になっています。

snippet 
  300 200
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 200, valid, internal, best
  300 200
    10.0.25.2 from 10.0.25.2 (5.5.5.5)
      Origin IGP, localpref 100, valid, external

ここで重要なのは、R2 は自分では何の設定もしていない点です。R1 が付けた LOCAL_PREF 200 が iBGP セッションを越えて R2 に届き、R2 の best 選定を動かしました。ベストパス選定の 8 ステップ (§11) で言えば、LOCAL_PREF はステップ ② で、eBGP > iBGP のステップ ⑦ より上位にあります。だから R2 自身の eBGP 経路 (LP100・⑦ なら勝てる側) よりも、R1 経由の iBGP 経路 (LP200) が先に勝ってしまうわけです。

一方、LOCAL_PREF は eBGP 境界を越えません。R1 が AS100 内で付けた LP200 は、隣接 AS の R5 には伝わりません。R5 から見た 10.20.3.0/24 (R5 は AS200 の R3/R4 から直接学習) を見ると、LOCAL_PREF は default の 100 のままです。

snippet 
  200
    10.0.35.1 from 10.0.35.1 (3.3.3.3)
      Origin IGP, metric 0, localpref 100, valid, external, best
  200
    10.0.45.1 from 10.0.45.1 (4.4.4.4)
      Origin IGP, localpref 100, valid, external

R5 のこの経路は AS200 から来た別系統の経路 (AS_PATH 200) であり、AS100 内で付けた LP200 がそもそも乗っていません。「iBGP では伝わる (R1 → R2)、eBGP では伝わらない (R1 → R5 に乗らない)」という LOCAL_PREF の性質が、同じ prefix の 2 つの視点から読み取れます。

9. AS_PATH 長 — ループ防止と「短い方が善」のメトリック

AS_PATH は BGP の中心的な属性で、ループ防止とベストパス選定の両方を担います。

AS_PATH は経路がここまで通ってきた AS 番号のリストです (より正確には AS_SEQUENCE と AS_SET の 2 タイプがあり、後者は集約時に発生)。経路が eBGP セッションを 1 つ越えるたびに、送信側 AS の AS 番号がリストの先頭に追加されます。受信側は AS_PATH を見て、自AS の番号が既に含まれていたら経路をループとして破棄します。これだけで AS 間 (eBGP) のループ防止が完結します (AS 内 = iBGP では自 AS を AS_PATH に積まないため、iBGP の「学習経路を他 iBGP に再広告しない」規約や、Route Reflector の Originator ID / Cluster list が別途ループ防止を担います。3-7 で扱います)。

ベストパス選定では AS_PATH の 長さが短い方を優先 します。これは「経由する AS が少ない方が近い (= 良い経路) だろう」という直感に近いものですが、実際には AS のサイズはまちまちであり、「AS_PATH 短い = 実際の距離短い」とは限りません。AS_PATH 長はあくまで BGP 内部のメトリック的な代用 であって、IGP のメトリックのような物理現実の反映ではありません。

この「AS_PATH 長で勝負する」挙動を 人為的に歪める 手段が AS_PATH prepend です。自AS の AS 番号を outbound 方向で複数回繰り返して入れることで、受信側から見ると「経路が長く見える」状態を作り出します。これにより、本来選ばれるはずだった経路を意図的に不利にして、別経路を選ばせる、というポリシー操作が可能となります。

設定例 (R1 が R5 への outbound で AS_PATH に 100 を 3 回追加で挿入) は以下のとおりです。

snippet 
route-map PREPEND-OUT permit 10
 set as-path prepend 100 100 100
exit
router bgp 100
 address-family ipv4
  neighbor 10.0.15.2 route-map PREPEND-OUT out
 exit-address-family

これで R5 から見た AS100 由来経路の AS_PATH は [100 100 100 100] (1 + 3 prepend = 4 個) になり、R2 経由 ([100] 1 個) より圧倒的に長くなります。R5 のベストパスは weight や LOCAL_PREF が同点なら R2 経由に切り替わります。

本ラボの Phase C ではこの prepend の効果を観察します。R1 で prepend を投入する前後で、R5 の show ip bgp 10.10.1.0/24 の AS_PATH 表示が 100 から 100 100 100 100 に変化しました。実機出力 (Phase B の weight を Phase C 開始時にクリアしてから観察) は以下のとおりです。

snippet 
     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.10.1.0/24     10.0.25.1                              0 100 i
 *                     10.0.15.1                0             0 100 100 100 100 i

R1 経由側 (10.0.15.1) の Path が 100 100 100 100 i で 4 要素に伸びています (元 100 i 1 要素 + prepend 100 100 100 3 要素)。一方 R2 経由側 (10.0.25.1) は 100 i のままで AS_PATH 長 1。これにより 8 ステップ判定の ④ AS_PATH 長 (短い方) で R2 経由が勝ち、ベストパスマーカー *> が R2 経由側に移りました。Phase B の weight でも同じ R2 経由への切り替えが見られましたが、根拠となる属性が違う (weight = ステップ ①、AS_PATH = ステップ ④) ことが show ip bgp <prefix> の詳細出力から区別できます。

10. origin / MED — 由来と隣接 AS への hint

origin は経路の出自を表す属性で、3 つの値しか取りません。

  • IGP (i): network 文で BGP 内部で明示広告した経路。標準の出自。
  • EGP (e): 古い EGP プロトコル経由で学習した経路。現代では実質ゼロ。
  • Incomplete (?): redistribute 文で別プロトコル (OSPF / EIGRP / static など) から BGP に流し込んだ経路。出自不明扱い。

ベストパス選定では i < e < ? の順 (IGP が最も望ましく、Incomplete が最も望ましくない) です。これは BGP 設計者の「意図的に広告した経路を、ありもの再配送経路より優先する」という運用観の表れであり、network で明示した経路は「広告主が責任を持って出している」と推定される設計です。

実機では show ip bgp <prefix> の出力に Origin: IGP などと表示されます。本ラボでは全エッジが network で広告するため、すべての経路の origin は i (IGP) で揃います。redistribute で別プロトコルから流し込むシナリオは扱いません (3-5 OSPF で EIGRP redistribute を扱った経験で代用)。

MED (Multi-Exit Discriminator) は origin と並んで紛らわしい属性で、用途と挙動が独特です。MED は「隣接 AS に対して、自AS の中で どの入口を使ってほしいか」を伝えるヒントとなります。具体的には、自AS が隣接 AS と複数の eBGP セッションを張っているとき、それぞれの eBGP セッション outbound で「こちらの方が望ましい」「こちらは予備」という MED 値を付けて広告します。

MED の値は 0〜4294967295 で、小さい方を優先 (これだけ他属性と逆向き)。デフォルトは 0 です。

注意点として、MED は 同じ隣接 AS から学習した経路間でしか比較されません。AS100 から MED 100 で来た経路と、AS200 から MED 50 で来た経路は、MED で勝負しません (デフォルト。bgp always-compare-med を入れると比較するようになる)。MED は「隣接 AS が自AS の中で望ましい入口を表現する手段」のため、別 AS 経由とは比較する意味がない、という設計に基づきます。

本ラボでは MED の動作確認は触れる程度にとどめます。同じ隣接 AS から複数の eBGP セッションが来ているのは R5 ↔ AS100 (R1 / R2) と R5 ↔ AS200 (R3 / R4) のペアですが、デフォルトでは MED 0 同点になりやすく、weight や LOCAL_PREF を被せた効果の方が見やすくなります。

11. ベストパス選定の完全ロジック — 8 ステップ判定

ここまで個別に見てきた属性を BGP がどの順序で評価するか、それが ベストパス選定 8 ステップ です。上から順に評価し、勝負がついた時点で停止します。下のステップに進むのは、上で同点だったときだけです。なお 8 ステップの比較対象になれるのは next-hop が到達可能 (reachable) など基本条件を満たした候補だけ です。next-hop が解決できない経路は属性比較に入る前に脱落します (§12 の (inaccessible) がその例)。

BGP ベストパス選定 8 ステップ判定フロー
  1. weight 大きい方: Cisco 独自、locally significant。
  2. LOCAL_PREF 大きい方: AS 内で共有、iBGP で伝わる。
  3. locally originated を優先: 自身がローカル生成した経路 (network / aggregate-address に加え、IGP 等から BGP へ redistribute した経路も含む) を、隣接から学習した経路より優先する。
  4. AS_PATH 長 短い方: prepend で人為的に長くできる。
  5. origin: IGP (i) < EGP (e) < Incomplete (?)。
  6. MED 小さい方: 同一隣接 AS 経由間でのみ比較 (bgp always-compare-med で全比較に)。
  7. eBGP > iBGP: eBGP 学習経路を iBGP 学習経路より優先 (外部経路を優先)。
  8. shortest IGP cost to next-hop: next-hop までの内部 IGP コストが短い方を優先。

Cisco の BGP ベストパスはこの 8 ステップで終わりではなく、同点ならさらに後続の tie-breaker が続きます。代表的な順序は、⑨ 両経路が eBGP なら「先に受信した古い経路 (oldest path)」を優先 → ⑩ router-id (BGP Identifier) が小さい方 → ⑪ cluster-list が短い方 → ⑫ neighbor address が小さい方、です。つまり eBGP 同士の同点を素朴に「router-id で決まる」と覚えるのは不正確で、既定では先に oldest path が効きます (bgp bestpath compare-routerid を入れると oldest path より router-id 比較を優先させられます。bgp deterministic-med 等でも挙動が変わります)。本ラボのように複数 eBGP 経路が AS_PATH 長まで同点になる場合、既定の決着要因は oldest path であり、router-id はその次の段、という関係を押さえておきます。

実機で「どこで勝負がついたか」を確認するには show ip bgp <prefix> を使います。出力の Best Path 表示と、隣接候補それぞれの属性値を見比べることで、どの属性で差がついたかが読み取れます。慣れてくると show ip bgp <prefix> の出力を 1 行ずつ追って 8 ステップを当てはめるだけで、ベストパス選定の判定が再現できます。

CCIE 試験ではこの 8 ステップを暗記しているだけでは足りず、「現在のテーブル状態でこの prefix を新しく学習したら、どの経路が選ばれるか」というシナリオ問題が頻出します。本ラボの Phase B / C は、まさにこの「8 ステップを実機で 1 つずつ歪めてベストパスを切り替える」ことを目的とした構成です。

eBGP 同士の同点を「何が決めているか」を実機で分離する (Phase F)

8 ステップを全部すり抜けた eBGP 同士の同点が、実際に何で決着しているのかを実機で確かめます。R5 は 10.10.1.0/24 を R1 (10.0.15.1) と R2 (10.0.25.1) の両方から eBGP で学習しており、両経路は weight 0 / LOCAL_PREF 100 / AS_PATH 長 1 / origin i / MED 0 まで完全に同点です。

同点の baseline (show ip bgp 10.10.1.0/24) は次のとおりで、R1 経由 (1.1.1.1) が best です。注目すべきは各経路の Updated on ... 時刻で、R1 経由のほうが古い (先に受信した) 経路になっています。

snippet 
  100
    10.0.25.1 from 10.0.25.1 (2.2.2.2)
      Origin IGP, localpref 100, valid, external
      Updated on Jun 12 2026 08:18:39 UTC
  100
    10.0.15.1 from 10.0.15.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Updated on Jun 12 2026 08:18:32 UTC

ここで「best が R1 なのは router-id (1.1.1.1) が小さいから」と考えたくなりますが、それは確かめないと分かりません。そこで 現在 best の R1 セッションだけを R5 で clear ip bgp 10.0.15.1 し、R1 経由経路を「新しく受信し直した経路」にします。router-id は何も変えていません。結果は以下のとおりです。

snippet 
  100
    10.0.15.1 from 10.0.15.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external
      Updated on Jun 12 2026 08:19:28 UTC
  100
    10.0.25.1 from 10.0.25.1 (2.2.2.2)
      Origin IGP, localpref 100, valid, external, best
      Updated on Jun 12 2026 08:18:39 UTC

best が R2 (2.2.2.2) に移りました。R1 は router-id が小さい (1.1.1.1) にもかかわらず、新しく受信し直した = oldest でなくなった瞬間に best を失っています。つまり既定では router-id ではなく oldest path (先に受信した経路) が決着要因 であることが、router-id を一切動かさずに分離できました。

次に、bgp bestpath compare-routerid を投入してから、もう一度 R1 セッションを clear して R1 をいちばん新しい経路にした 状態を撮ります。

snippet 
BGP routing table entry for 10.10.1.0/24, version 15
BGP Bestpath: compare-routerid
Paths: (2 available, best #1, table default)
  100
    10.0.15.1 from 10.0.15.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Updated on Jun 12 2026 08:21:03 UTC
  100
    10.0.25.1 from 10.0.25.1 (2.2.2.2)
      Origin IGP, localpref 100, valid, external
      Updated on Jun 12 2026 08:18:39 UTC

冒頭に BGP Bestpath: compare-routerid というマーカーが出ています。そして best は R1 (1.1.1.1) に戻りました。R1 のほうが新しい (08:21:03 > 08:18:39) のに best になっている点が決定的です。oldest path だけなら古い R2 が勝つはずですが、compare-routerid 下では age を無視して router-id の小さい R1 が勝つ ようになっています。

同じ「R1 を新しい経路にする」操作をしても、既定では R1 が負け (oldest path)、compare-routerid では R1 が勝つ (router-id) という逆向きの結果が出ました。これで「eBGP 同士の同点を素朴に router-id で決まると覚えるのは不正確で、既定の決着要因は oldest path」という §11 の説明が実機で裏付けられます。

12. iBGP next-hop-self — eBGP 学習経路を iBGP に渡すときの罠

§3 で触れた next-hop-self の話を、ここで実機で扱います。

R1 (AS100) が eBGP 経由で R5 (AS300) から 10.20.3.0/24 (AS200 R3 の Loopback10) を学習したとします。R1 がこの経路を iBGP で R2 (AS100) に再広告するとき、next-hop は元のまま (R5 の interface IP) が乗っていきます。R2 から見ると「10.20.3.0/24 の next-hop は 10.0.15.2 (R5 の Gi2)」となります。

問題は R2 が 10.0.15.2 への経路を持っているか です。AS100 内で IGP が動作しており、AS100 内のすべての P2P リンクの prefix が IGP で広告されているなら、10.0.15.2 (AS100-AS300 直結リンクなので AS100 側からは到達可能) を R2 も知っている可能性があります。しかし本ラボでは AS100 内で IGP を動かしていません (BGP のみ)。R2 にとって 10.0.15.2 は未知の next-hop となり、経路は inactive (テーブルにあるが使われない) となります。

解決は R1 で neighbor <iBGP> next-hop-self を入れることです。これにより R1 が iBGP で広告する経路の next-hop が「R1 自身の iBGP セッション IP」に書き換わります。R2 にとっては「next-hop = R1 (直結リンク IP)」となり、自身が直接知っている IP なので経路が active になります。

iBGP next-hop-self の効果 — before / after の比較

設定の文法は以下のとおりです。

snippet 
router bgp 100
 address-family ipv4
  neighbor 10.0.12.2 next-hop-self
 exit-address-family

適用は clear ip bgp 10.0.12.2 soft out で行います。

本ラボの Phase D では、next-hop-self 投入前後の show ip bgp 10.20.3.0/24 の next-hop 表示を見比べました。

Before (next-hop-self なし、R2 視点):

snippet 
BGP routing table entry for 10.20.3.0/24, version 4
Paths: (2 available, best #2, table default)
  300 200
    10.0.15.2 (inaccessible) from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal
  300 200
    10.0.25.2 from 10.0.25.2 (5.5.5.5)
      Origin IGP, localpref 100, valid, external, best

R1 経由 iBGP 経路の next-hop が 10.0.15.2 (inaccessible) と表示されている点が注目箇所です。R5 のインターフェース IP がそのまま乗ってきており、R2 はその IP への経路を持っていません (show ip route 10.0.15.2 で % Subnet not in table)。BGP テーブルには「2 available」と入っているものの、片方 (iBGP 経由) は inaccessible で実際の forwarding には使えません。

After (R1 で next-hop-self 投入後) は以下のとおりです。

snippet 
BGP routing table entry for 10.20.3.0/24, version 4
Paths: (2 available, best #2, table default)
  300 200
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal
  300 200
    10.0.25.2 from 10.0.25.2 (5.5.5.5)
      Origin IGP, localpref 100, valid, external, best

R1 経由 iBGP 経路の next-hop が 10.0.12.1 (R1 自身の iBGP リンク IP) に書き換わりました。(inaccessible) も消えています (R1-R2 直結リンクなので到達可能)。

best はどちらの状態でも R2 自身が eBGP で学習した経路 (10.0.25.2 ... external, best) のままです。これは AS_PATH 長同じ + 他属性同点で ⑦ eBGP > iBGP で勝負がついているためです。next-hop-self 投入の本質的な効果は 「iBGP 経路の next-hop が到達可能になり forwarding に使える状態になる」 ことであって、必ずしもベストパスが切り替わるわけではありません。なお valid フラグ自体は Before の出力 (... localpref 100, valid, internal) でも付いており、next-hop-self で変わったのは valid の有無ではなく next-hop が 10.0.15.2 (inaccessible) から 10.0.12.1 に書き換わって到達性が解決された点です。BGP のベストパス候補では next-hop 到達性が前提条件なので、到達不能な next-hop の経路は valid 表示であっても best / RIB 採用には進めません。この next-hop の書き換わりが、show ip bgp <prefix> の詳細出力で読み取れます。

ここで誤解しやすい点を整理します。iBGP を Loopback ピアリング (Lo0 同士で iBGP セッションを張る) する設計で AS 内 IGP が担保するのは、あくまで Lo0 間の到達性 = iBGP セッションの確立条件であって、それだけで eBGP 由来 next-hop (= 外部隣接の IP) への到達性まで自動的に確保されるわけではありません。eBGP 学習経路を iBGP に渡すと next-hop は原則として外部リンクの IP のまま伝わるため、内部ルータがその外部 IP への経路を IGP / static で別途持っているか、エッジで next-hop-self を使って next-hop を自分の Lo0 に書き換える必要があります。実務では外部リンクのアドレスを IGP に載せたくないことが多く、その場合は Lo0 ピアリングでも next-hop-self を併用するのが一般的です。本ラボのように直結リンク IP でピアリングし、かつ AS 内 IGP を動かさない構成では next-hop-self が必須となります。

next-hop-self が best を切り替える様子を「片肺」構成で見る (Phase H)

上の Phase D では best が変わりませんでした。これは R2 が同じ prefix を自分の eBGP セッションでも直接学習しており、⑦ eBGP > iBGP で eBGP 経路が固定的に勝っていたためです。next-hop-self が best を 切り替える 様子をはっきり見せるには、R2 がその prefix を iBGP 経由でしか学習していない構成 (片肺) にする必要があります。

そこで 10.20.4.0/24 (AS200 R4 の Loopback10) を題材に、R2 の eBGP inbound に prefix-list を当てて、この prefix だけ R5 からの受信を落とします。これで R2 は 10.20.4.0/24 を R1 経由の iBGP からしか学ばなくなります。

snippet 
ip prefix-list NO-R4 seq 5 deny 10.20.4.0/24
ip prefix-list NO-R4 seq 10 permit 0.0.0.0/0 le 32
router bgp 100
 address-family ipv4
  neighbor 10.0.25.2 prefix-list NO-R4 in

next-hop-self を入れる 前 の R2 視点 (show ip bgp 10.20.4.0/24 と show ip route 10.20.4.0 255.255.255.0) は以下のとおりです。

snippet 
BGP routing table entry for 10.20.4.0/24, version 18
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 1
  300 200
    10.0.15.2 (inaccessible) from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal
snippet 
% Subnet not in table

経路は 1 本 (iBGP 経由) しかなく、その next-hop が 10.0.15.2 (inaccessible) です。R2 はこの next-hop への到達性を持たないため、唯一の経路でありながら no best path = best にすらなれず、show ip route でも % Subnet not in table で RIB に載りません。Phase D では eBGP 経路が best を肩代わりしてくれましたが、片肺ではそれが無いので「best が無い = forwarding できない」状態が露わになります。

R1 で neighbor 10.0.12.2 next-hop-self を投入した 後 の R2 視点は以下のとおりです。

snippet 
BGP routing table entry for 10.20.4.0/24, version 19
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     4         
  Refresh Epoch 1
  300 200
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
snippet 
Routing entry for 10.20.4.0/24
  Known via "bgp 100", distance 200, metric 0
  Tag 300, type internal
  Last update from 10.0.12.1 00:00:53 ago
  Routing Descriptor Blocks:
  * 10.0.12.1, from 10.0.12.1, 00:00:53 ago

next-hop が 10.0.12.1 (R1 の iBGP リンク IP) に書き換わって到達可能になり、no best path だった経路が best #1 になりました。show ip route にも Known via "bgp 100", distance 200 (iBGP の AD 200) で RIB に載っています。Phase D の「next-hop-self で best は変わらない (forwarding 可否だけ変わる)」と、この Phase H の「片肺なら next-hop-self で best が生まれる」は矛盾しません。best が動くかどうかは、その prefix を他の経路でも学習しているかに依存する という条件分けが、2 つのケースの対比から読み取れます。

13. iBGP full-mesh 問題 — n×(n-1)/2 セッションの爆発

§3 で触れた iBGP の特性「iBGP 学習経路は他の iBGP に再広告されない」は、ネットワーク規模が大きくなると深刻な問題を生みます。

AS 内に n 台のルータがあれば、iBGP セッションは n×(n-1)/2 本必要になります。これは無向グラフの完全グラフ K_n の辺数と同じ式です。

ルータ数 niBGP セッション数
510
1045
20190
501225
1004950

100 台規模になるとセッション数が 5000 近くに達し、TCP セッションの管理 / 設定の複雑さ / メモリ消費 / 障害時の影響範囲のすべてが現実的でなくなります。

この問題に対する解は 2 系統あります。

Route Reflector (RR) は階層構造を導入する手法で、AS 内の一部のルータ (RR) が「iBGP の中継ノード」として動き、自身が iBGP で学習した経路を他の iBGP クライアントに再広告します。RR を頂点とするスター型構造になり、フルメッシュが不要となります。

Confederation は AS をさらに sub-AS に分割する手法で、sub-AS 間は eBGP のように振る舞いつつ、外部から見れば 1 つの AS として見せます。

どちらが優れているかではなく用途が違います。RR は実装が単純で大規模 ISP 内部に向きます。Confederation は AS の分割が論理的に明確で、企業合併など組織変更を伴うネットワーク再編に向きます。

本節ではこれら 2 系統の解の 存在と必要性 を述べるにとどめ、RR の構成と設定は次節 (3-7) で改めて扱います。BGP 本体の理解と、RR / Confederation を入れた構成の理解は分けた方が学習しやすいためです。

14. ポリシー表現 — route-map / prefix-list / AS-PATH ACL

ここまで weight / LOCAL_PREF / MED / next-hop-self / AS_PATH prepend と、属性を操作するシナリオを断片的に見てきました。これらを統一的に表現する道具が route-map です。

route-map は BGP に限らず Cisco IOS-XE の汎用ルーティングポリシー記法であり、条件 (match) と 動作 (set) の組を順序付きで列挙する仕組みです。BGP では neighbor <ip> route-map <name> in/out で隣接単位に inbound / outbound 方向に適用します。

snippet 
route-map AS200-PREF permit 10
 match ip address prefix-list AS200-PREFIXES
 set local-preference 200
exit
route-map AS200-PREF permit 20    ! 残り全部 (catch-all)
exit

このルールは「prefix-list AS200-PREFIXES にマッチする経路には LOCAL_PREF 200 を付与、それ以外はそのまま」という意味です。permit 10 の 10 はシーケンス番号 (順序評価)、permit は通過 (動作実行)、deny は破棄 (route-map で deny は経路を捨てるという意味であり、ACL の deny より強い)。

route-map の match で使える基本道具は以下のとおりです。

  • prefix-list: IP プレフィックス範囲のマッチ。ip prefix-list AS200 permit 10.20.0.0/16 le 24 で「10.20.0.0/16 の範囲内、prefix 長 16〜24」のような幅指定が可能。
  • AS-PATH ACL (Access Control List): AS_PATH を正規表現でマッチ。ip as-path access-list 1 permit ^200$ で「AS_PATH がちょうど AS200 (AS200 から直接学習) のみ」、_200_ で「AS_PATH 中に AS200 を経由したもの全部」など。
  • community: BGP community 属性 (RFC 1997 の標準 community は 32-bit の値で、慣習的に ASN:value の 16-bit + 16-bit 形式で表記する) を使ったマッチ。64-bit のラベルは RFC 4360 の拡張 community で別物。community は本節では深入りしない。

ポリシー記述の典型例は以下のとおりです。

  1. 特定 AS からの経路のみ受け入れ — match as-path で正規表現で許可。
  2. 自社の prefix のみ広告 — outbound で match ip address prefix-list MY-PREFIXES で許可、それ以外を deny。顧客から学習した prefix が意図した範囲を越えて伝播する 経路リーク (route leak、RFC 7908) を防ぐ。
  3. 特定 prefix に LOCAL_PREF / MED / community を付与 — inbound で set local-preference、outbound で set metric (MED) / set community。
  4. AS_PATH prepend — outbound で set as-path prepend 100 100 100。§9 で見た例。

CCIE 入口の範囲では、これらの基本ツールを組み合わせて「契約レベルのポリシー (P1 顧客の経路は他より優先、P2 顧客はベストエフォート、特定 ISP からの経路は dropped にする)」を記述する練習が要求されます。本節ではここまで深入りせず、Phase D の next-hop-self、Phase C の prepend、Phase E の aggregate-address で route-map を使う実例を見せる程度にとどめます。

15. 経路集約 と Atomic Aggregate

BGP テーブルの肥大化を抑える基本手段が aggregate-address による経路集約です。複数の /24 prefix を 1 つの /16 などで丸めて広告することで、隣接 AS のテーブルサイズを削減します。

設定の基本形は以下のとおりです。

snippet 
router bgp 100
 address-family ipv4
  aggregate-address 10.10.0.0 255.255.0.0 summary-only
 exit-address-family

aggregate-address 10.10.0.0 255.255.0.0 で「10.10.0.0/16 の集約 prefix を新規生成」、summary-only で「集約された個別経路 (10.10.1.0/24 / 10.10.2.0/24) は隣接に広告しない (集約後の /16 のみ広告)」という意味になります。summary-only を付けないと個別と集約の両方が広告されます。

集約には 1 つ重要な副作用があります。集約後の /16 経路は、もとになった個別経路たちの AS_PATH を すべて統合 して新しい AS_PATH を作る必要があります。複数の個別経路がそれぞれ違う AS_PATH を持っていたら、集約結果はそれらをどう表現するかが問題となります。

Atomic Aggregate はこの問題を表現する BGP フラグで、「この経路は集約であり、もとの経路情報の一部が失われた可能性がある」という宣言です。show ip bgp <prefix> の出力に Atomic-aggregate という行が現れます。

AS_SET はもう一つの表現方法で、集約のもとになった AS_PATH をすべて含んだ集合 (順序のない braces {...} 表記) を作ります。aggregate-address ... as-set オプションで生成されます。例として、もとが [100] と [200] の経路を集約すると、AS_PATH は [{100, 200}] となります。集約してもループ防止情報 (どの AS を経由したか) が保たれる利点があります。なおベストパス選定上、AS_SET セグメントは 中に含む AS の数に関係なく長さ 1 として数えられます ({100, 200, 300} でも 3 ではなく 1)。AS_SET の有無自体が AS_PATH 長を 1 増減させるため、ベストパス選定で意図しない挙動を生むことがあります。

AS_SET は 現在の公共インターネット運用では使いません。RFC 9774 (2025、RFC 4271 を更新) は AS_SET / AS_CONFED_SET セグメントを含む UPDATE の生成・広告を禁止 (MUST NOT) し、受信側はそれらを RFC 7606 の treat-as-withdraw で扱うことを要求しています。したがって AS_SET は「歴史的仕様・ラボでの観察用」と位置づけ、実運用の集約は AS_SET を生成しない summary-only で行うのが標準です。本ラボの Phase E では学習目的で R1 に aggregate-address 10.10.0.0 255.255.0.0 summary-only as-set を投入し、R5 から見た BGP テーブルの変化を観察しました (as-set の挙動は §17 で詳述)。

snippet 
R5#show ip bgp
     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.10.0.0/16     10.0.25.1                              0 100 i
 *                     10.0.15.1                0             0 100 100 100 100 i
 *>   10.10.2.0/24     10.0.25.1                0             0 100 i
 *    10.20.3.0/24     ...
  • 10.10.0.0/16 が出現: 集約 prefix が R5 で見える。
  • 10.10.1.0/24 が消えた: R1 が summary-only で自身が広告する個別経路を抑制した。
  • 10.10.2.0/24 は残っている: R2 が aggregate 未投入のため、R2 が広告する prefix は影響を受けない。summary-only は宣言したルータ自身が広告する経路にしか効かない。
  • AS_PATH に prepend 残存: R1 経由側に 100 100 100 100 の prepend が依然乗っている (Phase C の route-map がそのまま残存)。R5 のベストパスは prepend 長 (4) より R2 経由の短い (1) を選ぶ。

集約 prefix の詳細 (show ip bgp 10.10.0.0/16) を見ると、Cisco IOS-XE 17.x では aggregated by 100 1.1.1.1 という表記が AS_PATH 文字列の後ろに付きます。これは「AS100 の router-id 1.1.1.1 が集約した」という出自表記です。一方、as-set オプションを付けたにもかかわらず AS_SET の {...} 表記は出現しませんでした。as-set は「集約のもとになった more-specific 経路の AS_PATH 属性を集約 prefix に継承する」指定ですが、本ラボの集約元は R1 自身が network で生成した Lo10 (10.10.1.0/24) のローカル経路で、R1 の BGP テーブル上では AS_PATH が空です (R5 から見える 100 は eBGP 広告時に送信側 AS が prepend されたもの)。継承すべき外部 AS_PATH が無いため AS_SET は生成されません。{...} を観察したいなら、異なる AS から学習した複数の more-specific を 1 台で集約する構成 (例: 300 {200, 100}) が必要です。本節ではここまで深入りせず、summary-only の効果と prepend との共存を観察するにとどめます。

16. CML 実機検証の総括 — Phase A-H で見えたもの

3-3 RIP、3-4 EIGRP、3-5 OSPF と同じく、本節も実機検証フェーズを進めました。属性操作の基本 (Phase A-E) に加え、eBGP 同点の決着・LOCAL_PREF の iBGP 伝播・片肺での next-hop-self を Phase F-H で追加検証しています。それぞれの観察ポイントを総括します。

Phase A: BGP セッション確立

R5 (AS300 transit) から見て 4 つの eBGP セッションが全 Established に到達するまで数十秒で完了しました。show ip bgp summary の State/PfxRcd 欄が数値 (2 prefix 受信) になっているのが目印で、Idle / Active のままなら TCP 179 または対向到達不能を疑う段階に入ります。本ラボでは 5 ノード並列起動 + iBGP の追加で 6 セッションが同時に張られましたが、いずれも 60 秒以内に Established に到達しました。

R5 の BGP テーブルには 4 prefix × 2 経路 = 8 path entries が並び、ベストパスは AS_PATH 長同点 (両方 1) + 他属性同点となり、eBGP 同士の後続 tie-breaker (既定では oldest path、その次に router-id) で安定側に決着しました (§11 参照)。show ip route bgp で AD=20 (eBGP デフォルト) が確認できます。

Phase B: weight でベストパス切替

R5 で R2 経由経路に weight 200 を設定すると、ベストパスが R1 経由 → R2 経由に切り替わりました。show ip bgp 10.10.1.0/24 の詳細出力で weight 200, ... best の組み合わせが見え、勝負がついた属性が weight (8 ステップの ①) であることが明示されます。

Phase C: AS_PATH prepend

R1 で route-map ... set as-path prepend 100 100 100 を outbound 方向に投入すると、R5 から見た R1 経由経路の AS_PATH が 100 から 100 100 100 100 に伸びました。R2 経由 (100 単独) より長くなり、ベストパスが R2 経由に移動しています。Phase B と Phase C で同じ「R2 経由ベスト」という結果に至りましたが、勝負がついた属性が weight (①) と AS_PATH 長 (④) で違うことが、show ip bgp <prefix> の詳細出力で区別できます。

Phase D: iBGP next-hop-self

R2 (AS100) は R1 経由で iBGP 学習した経路の next-hop が 10.0.15.2 (inaccessible) と表示され、forwarding に使えない状態でした。これは AS100 内に IGP がなく、R5 の interface IP への経路を R2 が持っていないためです。R1 で neighbor 10.0.12.2 next-hop-self を投入すると、next-hop が 10.0.12.1 (R1 自身の iBGP リンク IP) に書き換わり、(inaccessible) 表記が消えました。

best が変わらなかった (R2 自身の eBGP 学習経路がそのまま best) のは注目点であり、next-hop-self の効果は 「iBGP 経路が forwarding 可能になる」 ことであって、必ずしも best 切り替えではないことが確認できました。

Phase E: aggregate-address + summary-only + as-set

R1 で aggregate-address 10.10.0.0 255.255.0.0 summary-only as-set を投入すると、R5 から見た 10.10.1.0/24 (R1 が広告していた) が消え、10.10.0.0/16 が出現しました。R2 が広告する 10.10.2.0/24 は影響を受けず残りました (集約は宣言したルータ自身の広告にしか効かないため)。

集約後の AS_PATH に (aggregated by 100 1.1.1.1) 表記が付き、出自が明示されました。as-set を付けたが AS_SET 表記 {...} は出現しませんでした (理由は §17 で詳述)。

Phase F: eBGP 同点の決着要因を分離

R5 が R1 / R2 の両方から全属性同点で学習した 10.10.1.0/24 で、現 best の R1 セッションを clear して R1 を「新しい経路」にしたところ best が R2 (oldest) に移り、既定の決着は router-id でなく oldest path であることを router-id 固定のまま分離できました。続いて bgp bestpath compare-routerid を入れて R1 を再度 newest にすると、今度は新しいはずの R1 (低 router-id) が best になり、compare-routerid 下では age を無視して router-id で決まることを対照で確認しました (§11)。

Phase G: LOCAL_PREF の iBGP 伝播

AS100 の R1 で eBGP 学習した 10.20.3.0/24 に LOCAL_PREF 200 を inbound 付与すると、それが iBGP で R2 に伝わり、R2 が自分では何も設定していないのに best が R1 経由 (LP200) に切り替わりました。一方 R5 (eBGP の向こう) では同 prefix が LP100 のままで、LOCAL_PREF が iBGP では伝わり eBGP では伝わらないことを 2 視点で確認しました (§8)。R5 が 1 台だけの AS300 では観察できなかった iBGP 伝播を、2 台 iBGP の AS100 で見せています。

Phase H: 片肺での next-hop-self による best 切替

R2 の eBGP inbound を prefix-list で絞って 10.20.4.0/24 を iBGP からしか学ばない片肺にすると、next-hop-self を入れる前は唯一の経路が (inaccessible) で no best path (RIB 不採用)、R1 で next-hop-self を入れると next-hop が R1 の IP に書き換わって best #1 + RIB 採用に変わりました。Phase D で best が動かなかったのは R2 が eBGP でも直接学習していたためで、片肺なら next-hop-self が best を生むという条件分けを実機で示しました (§12)。

8 つのフェーズを通じて、BGP のベストパス選定 8 ステップと後続 tie-breaker が教科書通りに動き、属性操作が直接ベストパスに反映される様子が観察できました。3-3 RIP / 3-4 EIGRP / 3-5 OSPF が「収束時間」「メトリック」「LSA Type」など計算系の挙動に焦点があったのに対し、BGP は 「属性をどう操作するか」 が学習の中心であることが実機を通じて確認できました。

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

3-3 RIP の Route Poisoning による即時収束、3-4 EIGRP の対称トポロジで FS が立たない、3-5 OSPF の Cisco Loopback /32 デフォルト広告と、各節で「教科書通りに動かない実機ギャップ」を 1 つずつ拾ってきました。本節 BGP でも 2 つ拾えています。

ギャップ 1: as-set オプションを付けても AS_SET 表記 {...} が現れなかった

Phase E で aggregate-address 10.10.0.0 255.255.0.0 summary-only as-set を投入したものの、show ip bgp 10.10.0.0/16 の AS_PATH 欄は 100 (single AS) のままで、教科書的な {100, 200} のような AS_SET 表記は出ませんでした。

原因はシンプルで、集約のもとになる more-specific が R1 自身の Lo10 (10.10.1.0/24) で、しかも network 由来のローカル経路 (AS_PATH が空) だけ だったためです。as-set は集約元 more-specific の AS_PATH 属性を集約 prefix に継承する指定ですが、継承すべき外部 AS_PATH が無ければ集合化する対象が無く、AS_SET は生成されません (R5 から見える 100 は eBGP 広告時に AS100 が prepend された結果で、集約元の AS_PATH ではありません)。as-set の効果を見たいなら、異なる AS から学習した複数 more-specific を集約する構成が要ります。

この罠は CCIE 試験では「複数の AS から学習した prefix を集約した時の AS_PATH 表記」として頻出します。本ラボの構成 (R1 が単独で AS100 内 prefix を集約する) では再現しませんでした。{100, 200} を観察したい場合は、たとえば「R5 が AS100 由来の 10.10.x.0/24 と AS200 由来の 10.20.x.0/24 をまとめて集約する」シナリオに組み替える必要があります。本ラボの目的 (ベストパス選定の 8 ステップ + next-hop-self) から外れるため、AS_SET の完全な観察は将来の RR 節 (3-7) か policy 専用節で扱います。

ギャップ 2: next-hop-self を入れても best は変わらなかった

§12 / §16 でも触れましたが、Phase D で next-hop-self 投入による best 切替を期待していた場合は、実機では best は変わらず、next-hop が 10.0.15.2 (inaccessible) から 10.0.12.1 に書き換わって到達性が解決しただけでした (valid フラグは Before から付いており、変わったのは next-hop の到達性です)。

教科書では「next-hop-self を入れないと iBGP 経路が forwarding できない」「next-hop-self を入れて iBGP 経路が使えるようになる」と並置されることが多く、入れた結果として何かが変わる印象を持たれやすい構造です。実際の効果は 「forwarding 可能性が変わる」 ことであって、「ベストパスの結論が変わる」 こととは別です。

本ラボの R2 はもともと自身の eBGP セッション (R2 ↔ R5) で同じ prefix を直接学習しており、AS_PATH 長同点で ⑦ eBGP > iBGP のステップが効いてしまうため、iBGP 経路が valid になったところで best は eBGP 側のまま動きません。next-hop-self を入れた効果を「best 切替」で実感するには、R2 が当該 prefix を iBGP からしか学習していない 片肺構成にする必要があります。これを §12 の Phase H で実機化しました — R2 の eBGP inbound を prefix-list で絞って 10.20.4.0/24 を iBGP からしか学ばないようにすると、next-hop-self 投入前は (inaccessible) で no best path (RIB 不採用)、投入後は next-hop が R1 の IP に書き換わって best #1 + RIB 採用に変わります。Phase D (best 不変) と Phase H (best が生まれる) の対比が、「best が動くかは他経路の有無に依存する」という条件分けを示しています。

これも 3-3 / 3-4 / 3-5 と同じ系譜で、「教科書の図示と実機の動作の認識ズレ」 を 1 件記録した格好になります。読者には「BGP コマンドの効果は属性表記 (show ip bgp <prefix> 詳細) で読み取るのが確実」というメッセージとして伝わるはずです。

18. 次節

3-3 RIP、3-4 EIGRP、3-5 OSPF、そして本節の 3-6 BGP で、第 3 章 L3 編の前半 4 ルーティングプロトコルを通りました。第 3 章は全 16 節構成で、ここまでで 6/16 を消化したことになります。

ここまでで見えた構造を整理すると、ルーティングプロトコルは次の 3 軸で性質が分かれます。

  • 隣接管理: 周期 Hello (OSPF / EIGRP) / TCP セッション + KEEPALIVE (BGP。Hello メッセージは持たず KEEPALIVE で Hold Timer 失効を防ぐ) vs 周期 update のみ (RIP)
  • メトリック計算: 距離ベクトル (RIP / EIGRP) vs リンクステート (OSPF) vs path vector (BGP)
  • 適用範囲: IGP (RIP / EIGRP / OSPF) vs EGP (BGP)

BGP は EGP として「インターネット規模の AS 間ルーティング」を担い、ポリシー駆動 / 属性ベースのベストパス選定 / 明示的な広告と集約という、IGP とはまったく違う設計の世界を持っています。

本節で扱いきれなかった話は以下のとおりで、いずれも次節以降で展開します。

  • iBGP full-mesh の解 — Route Reflector の構成と Cluster ID、Confederation の sub-AS 設計 → 3-7 で扱う
  • BGP community 属性 — RFC 1997 の標準 community (no-export / no-advertise / local-AS) と、ISP 間で広く運用される 拡張 community → 3-7 または 3-8 で扱う
  • BGP graceful restart — セッション再起動時にデータプレーン経路を残す機構、現代 ISP では標準装備
  • MP-BGP (Multiprotocol BGP) の世界 — IPv6 / VPNv4 / EVPN 等、address-family 別の BGP

次節 3-7 Route Reflector では、本節のラボ構成 (AS100 / AS200 / AS300、5 ルータ) を拡張して、AS 内のルータ数を増やしたときに iBGP full-mesh がいかに苦しいか、Route Reflector を 1 台導入することで何セッションが何セッションに減らせるかを実機で見ていきましょう。