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

3-11 ルーティングポリシー総括 — route-map / prefix-list / AS-PATH ACL / community-list

route-map・prefix-list・AS-PATH ACL・community-list の 4 部品を 1 つの体系として束ね、適用点を俯瞰する総括節。暗黙 deny による経路消失や複数 match の AND を、CML2.9 IOS-XE 17.x で実機検証する。

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

3-3 から 3-10 まで、IGP (Interior Gateway Protocol) と BGP (Border Gateway Protocol)、そして再配送を個別に扱ってきました。そのなかで route-map / prefix-list / AS-PATH ACL / community-list という 4 つの制御部品が、それぞれの節で「目的のための道具」として断片的に登場しています。3-6 §14 で route-map と prefix-list の概要、3-8 で community の付与と伝搬、3-10 で route-map + tag によるループ防止を扱いました。

本節 3-11 は第 3 章の 総括節です。これらの 4 部品を焼き直すのではなく、1 つの体系 (ルーティングポリシーの語彙) として束ねることが主題です。新しいプロトコルは導入しません。既出の 4 部品を統一文法 (match / set + 順序評価) として再整理し、適用点 (BGP neighbor in/out・再配送・PBR) の地図を描きます。「いつ・どこで・どう組み合わせるか」を整理して、第 3 章前半の IGP と後半の BGP を横断する締めとします。

実機検証では、Cisco IOS-XE 17.x が教科書通りに動く部分と、直感に反する部分の両方を別物として並べて記録します。特に、route-map 末尾の暗黙 deny で経路が静かに消える挙動、prefix-list の ge / le が forwarding の最長一致ではなく prefix 長の範囲を表す挙動、同一 entry 内の複数 match が AND として評価される挙動を、CML2.9 上の R2 の RIB と BGP テーブルで観察します。

2. ルーティングポリシーとは — 経路に対する条件付き制御

ルーティングポリシーは、ルータが学習・広告する経路に対して、条件を付けて取捨選択や属性操作を行う仕組みです。ルーティングプロトコルが「経路を計算する」役割を担うのに対し、ルーティングポリシーは「計算された経路のうち、どれを通すか・落とすか・どう加工するか」を運用者の意図で制御します。経路を機械的に流すプロトコルの上に、運用者の判断を載せる層と位置づけられます。

ルーティングポリシーは、3 つの層で構成されます。第一の層が route-map で、ポリシーの本体となる制御構造です。route-map は「条件に合えば〜する」という if-then を、シーケンス番号付きの entry で表現します。第二の層が match の道具で、prefix-list / AS-PATH ACL / community-list の 3 部品が、route-map の match 句から呼び出される条件部品として機能します。第三の層が 適用点で、同じ route-map 文法が BGP neighbor の in/out・再配送・PBR (Policy-Based Routing) という複数の場所で共通して使われます。

この 3 層構造を 1 枚に俯瞰すると、以下のとおりです。中核の route-map に、左から match の道具が条件を供給し、右へ適用点が広がります。

ルーティングポリシーの全体地図 — 中核の route-map に、① match の道具 (prefix-list / AS-PATH ACL / community-list) が条件を供給し、② 適用点 (BGP neighbor route-map in / out・redistribute route-map・PBR) で使われる。同じ match / set 文法が 3 つの適用点で共通する

3-6〜3-9 の BGP ポリシーは、この体系を AS (Autonomous System) 間の経路制御に適用した例でした。3-10 の再配送は、同じ体系をプロトコル間の経路制御に適用した例です。適用点が変わっても route-map / match / set という語彙は共通で、部品を理解すれば適用点が変わっても応用が利きます。本節は、その共通の語彙を整理することを目的とします。

3. route-map の処理モデル — permit/deny × match/set とシーケンス順序評価

route-map は、シーケンス番号の小さい entry から順に評価し、最初に match した entry で確定する制御構造です。各 entry は permit または deny の動作を持ち、match 句で条件を、set 句で属性操作を記述します。経路は entry を上から順に試し、match にヒットした最初の entry で処理が確定して、それ以降の entry は評価されません。

permit / deny と match / set の組み合わせが、経路に対して 3 種類の結果を生みます。第一に、permit entry に match した経路は通り、その entry の set が適用されます (属性が書き換わる)。第二に、deny entry に match した経路は落ちます (set があっても適用されず破棄)。第三に、どの match にもヒットしなかった match 句なしの entry は、全経路にヒットする catch-all として機能します。match 句を書かない entry は「無条件にヒット」と解釈されるため、permit の catch-all は「残りを全部通す」、deny の catch-all は「残りを全部落とす」となります。

ここで最も事故が起きやすいのが、route-map の末尾には暗黙の deny があるという点です。明示的に書いた entry のどれにも match しなかった経路は、末尾の暗黙 deny で落ちます。この挙動は ACL (Access Control List) の末尾の暗黙 deny と同じ発想です。BGP の inbound に route-map を適用したとき、match にヒットしない経路を通したいなら、末尾に match 句なしの permit entry (catch-all) を必ず置く必要があります。catch-all を置き忘れると、フィルタするつもりのなかった経路まで暗黙 deny で消えます。

route-map の処理モデル — 入力経路はシーケンスの小さい entry から順に評価され、permit 10 で match すれば set 適用済みで通過、miss なら次の entry へ。permit 20 (catch-all) が残りを通すが、catch-all が無いと末尾の暗黙 deny で経路が消失する。同一 entry 内の複数 match は AND、entry をまたぐと OR

複数の match を組み合わせるとき、評価のルールは AND と OR の 2 通りに分かれます。同一 entry 内に複数の match 句を書くと AND で、すべての条件を満たした経路だけがその entry にヒットします。一方、match の異なる entry を複数並べると OR で、シーケンス順に評価して最初にヒットした entry で確定します。「prefix 範囲 A かつ community B」は同一 entry に 2 つの match を書いて AND で、「prefix 範囲 A または community B」は別 entry に分けて OR で表現します。この AND / OR の区別は §8 で実機確認します。

4. 本ラボのトポロジ — 3 AS / R2 をポリシー適用点に

検証ラボは、3 つの AS を eBGP で直列につなぎ、中央の R2 (AS65020) をポリシー適用点にする構成です。route-map / prefix-list / AS-PATH ACL / community-list の 4 部品が最も自然に同時登場する適用点が BGP neighbor の in/out であるため、BGP を主舞台にします。ノード数を 3 ルータに抑え、host CPU の飽和を回避します。

各ルータの役割は以下のとおりです。

ルータASRouter-ID広告する prefix役割
R1650101.1.1.110.10.0.0/16・10.10.8.0/24・10.10.9.0/26複数 prefix を origin。10.10.8.0/24 に community 65010:100 を付与
R2650202.2.2.210.20.2.0/24ポリシー適用点。4 部品を集約する境界ルータ
R3650303.3.3.310.30.3.0/24・10.30.40.0/24複数 prefix を origin。AS_PATH のバリエーションを作る

R1 は prefix 長の異なる 3 経路 (10.10.0.0/16・10.10.8.0/24・10.10.9.0/26) を広告し、prefix-list の ge / le 範囲指定の効果を見せます。R3 は、10.30.3.0/24 を AS_PATH 65030 (隣接 origin) で、10.30.40.0/24 を set as-path prepend 65040 で AS_PATH 65030 65040 (経由を擬似) で広告し、AS-PATH ACL の ^65030$ と _65040_ を見分ける材料にします。65040 は実在ノードを置かず、R3 の prepend で AS_PATH を見せかけます。

3 AS の eBGP 直列 (AS65010 R1 - AS65020 R2 - AS65030 R3)。中央の R2 がポリシー適用点で、R1 からの inbound に route-map FROM-R1、R3 への outbound に route-map TO-R3 を適用する。prefix-list / community-list が FROM-R1 の match に、AS-PATH ACL が TO-R3 の match に動員される

ポリシーを投入する前のベースラインでは、R2 の BGP テーブルに R1 由来の 3 prefix と R3 由来の 2 prefix が素のまま並びます。R3 由来の 10.30.40.0/24 が AS_PATH 65030 65040 になっている点が、prepend による擬似の表れです。

snippet 
show ip bgp
BGP table version is 7, 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.0.0/16     10.0.12.1                0             0 65010 i
 *>   10.10.8.0/24     10.0.12.1                0             0 65010 i
 *>   10.10.9.0/26     10.0.12.1                0             0 65010 i
 *>   10.20.2.0/24     0.0.0.0                  0         32768 i
 *>   10.30.3.0/24     10.0.23.2                0             0 65030 i
 *>   10.30.40.0/24    10.0.23.2                0             0 65030 65040 i

R1 が 10.10.8.0/24 に付けた community も、ベースラインで確認できます。本ラボは ip bgp-community new-format を投入済みのため、community が decimal ではなく 65010:100 という AS:value 形式で表示されます。3-8 では new-format 未投入で同じ値が decimal 4260495460 と表示された挙動を記録しましたが、本節は new-format を投入してタグを読みやすくしています。

snippet 
show ip bgp 10.10.8.0/24
BGP routing table entry for 10.10.8.0/24, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  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: 65010:100
      rx pathid: 0, tx pathid: 0x0
      Updated on Jun 3 2026 00:47:08 UTC

5. prefix-list — ge/le による prefix 長範囲のマッチ

prefix-list は、IP プレフィックスを、ネットワークアドレスと prefix 長の範囲でマッチする条件部品です。ACL でもアドレスのマッチはできますが、prefix-list は ge (greater than or equal) と le (less than or equal) で prefix 長の幅を指定できる点が ACL にない機能です。ip prefix-list NAME permit A.B.C.D/L ge X le Y は、「A.B.C.D/L に含まれ、かつ prefix 長が X 以上 Y 以下」の経路を許可します。

本ラボの ip prefix-list LONGER-ONLY permit 10.10.0.0/16 ge 24 le 26 は、「10.10.0.0/16 に含まれ、かつ prefix 長 24〜26」を許可します。R1 の 3 経路に当てはめると、10.10.8.0/24 (prefix 長 24) と 10.10.9.0/26 (prefix 長 26) は範囲内で通り、10.10.0.0/16 自身は prefix 長 16 で ge 24 を満たさず落ちます。10.10.0.0/16 が落ちる点が直感に反しますが、これは「10.10.0.0/16 という枠の中の、prefix 長 24〜26 のものだけ」という条件であり、枠そのもの (長 16) は対象外です。

prefix-list の ge/le 範囲指定 — permit 10.10.0.0/16 ge 24 le 26 は prefix 長 24〜26 だけ通す。10.10.0.0/16 (prefix 長 16) は ge 24 を満たさず落ち、10.10.8.0/24 (長 24)・10.10.9.0/26 (長 26) は通る。ge/le は prefix 長の範囲であり、forwarding の最長一致とは別

この prefix-list を R2 で neighbor の inbound に 直接 適用します。route-map に包まず neighbor 10.0.12.1 prefix-list LONGER-ONLY in として適用すると、prefix-list 末尾の暗黙 deny で 10.10.0.0/16 が落ちます。prefix-list の定義と適用は以下のとおりです。

snippet 
show ip prefix-list LONGER-ONLY
ip prefix-list LONGER-ONLY: 1 entries
   seq 5 permit 10.10.0.0/16 ge 24 le 26
R2#show running-config | section router bgp
router bgp 65020
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 10.0.12.1 remote-as 65010
 neighbor 10.0.23.2 remote-as 65030
 !
 address-family ipv4
  network 10.20.2.0 mask 255.255.255.0
  neighbor 10.0.12.1 activate
  neighbor 10.0.12.1 send-community
  neighbor 10.0.12.1 soft-reconfiguration inbound
  neighbor 10.0.12.1 prefix-list LONGER-ONLY in
  neighbor 10.0.23.2 activate
  neighbor 10.0.23.2 send-community
  neighbor 10.0.23.2 soft-reconfiguration inbound
 exit-address-family

prefix-list 適用後の R2 の BGP テーブルからは 10.10.0.0/16 が消え、10.10.8.0/24 と 10.10.9.0/26 が残ります。soft-reconfiguration inbound を入れているため、フィルタされた経路と通った経路が (received-only) と (received & used) という表示で分かれて観察できます。

snippet 
show ip bgp
BGP table version is 8, 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.8.0/24     10.0.12.1                0             0 65010 i
 *>   10.10.9.0/26     10.0.12.1                0             0 65010 i
 *>   10.20.2.0/24     0.0.0.0                  0         32768 i
 *>   10.30.3.0/24     10.0.23.2                0             0 65030 i
 *>   10.30.40.0/24    10.0.23.2                0             0 65030 65040 i
R2#show ip bgp 10.10.0.0/16
BGP routing table entry for 10.10.0.0/16, version 8
Paths: (1 available, no best path)
  Not advertised to any peer
  Refresh Epoch 2
  65010, (received-only)
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0
      Updated on Jun 3 2026 00:59:19 UTC
R2#show ip bgp 10.10.8.0/24
BGP routing table entry for 10.10.8.0/24, version 3
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1         
  Refresh Epoch 2
  65010, (received & used)
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 65010:100
      rx pathid: 0, tx pathid: 0x0
      Updated on Jun 3 2026 00:59:19 UTC

10.10.0.0/16 は (received-only) かつ no best path で、R1 から受信はしているものの prefix-list でフィルタされて best にならず、Not advertised to any peer となっています。一方 10.10.8.0/24 は (received & used) かつ best で、prefix-list を通過して使われています。ge / le が prefix 長そのものを選別している実機証跡が、この 2 経路の表示の差として読み取れます。prefix-list の ge / le は forwarding 時の最長一致とは無関係で、あくまで「prefix 長が条件範囲に入るか」を判定する点が、混同しやすい注意点として §10 で整理します。

6. AS-PATH ACL — 正規表現による AS_PATH のマッチ

AS-PATH ACL は、経路の AS_PATH 属性を正規表現でマッチする条件部品です。AS_PATH は経路が通過した AS 番号の並び (例: 65030 65040) で、これを文字列として正規表現でフィルタします。Cisco の AS-PATH 正規表現で押さえるべきメタ文字は 3 つです。^ は AS_PATH の先頭 (行頭)、$ は AS_PATH の末尾 (行末)、_ は AS 番号の境界 (スペース / 行頭 / 行末 / 括弧) にマッチします。

代表的な 3 パターンを整理すると、以下のとおりです。^65030$ は「AS_PATH がちょうど 65030」で、R3 が隣接で origin した経路だけにマッチします。_65040_ は「AS_PATH 中に 65040 を含む」で、65040 を経由した経路にマッチします。^$ は「空の AS_PATH」で、自 AS で origin した経路 (AS_PATH が空) だけにマッチします。

AS-PATH ACL の正規表現アンカー — ^ は行頭、$ は行末、_ は AS 番号の境界。^65030$ は AS_PATH がちょうど 65030 (隣接 origin) で 10.30.3.0/24 に、_65040_ は 65040 を含む (経由) で 10.30.40.0/24 にヒット、^$ は空の AS_PATH (自 AS origin)。^65030$ と _65030_ は別物

アンカーの効果は、ACL に適用する前に show ip bgp regexp で確認できます。show ip bgp regexp ^65030$ は AS_PATH がちょうど 65030 の 10.30.3.0/24 だけを、show ip bgp regexp _65040_ は 65040 を含む 10.30.40.0/24 だけを返します。R2 の実機出力は以下のとおりです。

snippet 
show ip bgp regexp ^65030$
BGP table version is 9, 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.30.3.0/24     10.0.23.2                0             0 65030 i
R2#show ip bgp regexp _65040_
BGP table version is 9, 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.30.40.0/24    10.0.23.2                0             0 65030 65040 i

^65030$ は 10.30.3.0/24 (AS_PATH 65030) のみ、_65040_ は 10.30.40.0/24 (AS_PATH 65030 65040) のみにヒットしており、アンカーが意図どおり経路を選別しています。この挙動を AS-PATH ACL として固定したものが、ip as-path access-list です。本ラボでは 2 つの ACL を定義し、番号 10 が ^65030$、番号 20 が _65040_ です。

snippet 
show ip as-path-access-list
AS path access list 10
     permit ^65030$
AS path access list 20
     permit _65040_
R2#show route-map TO-R3
route-map TO-R3, deny, sequence 10
  Match clauses:
    as-path (as-path filter): 20 
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map TO-R3, permit, sequence 20
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes

AS-PATH ACL 20 (_65040_) を route-map TO-R3 の deny 10 で参照し、permit 20 を catch-all として R3 への outbound に適用します。これにより「AS_PATH に 65040 を含む経路は R3 へ広告しない」というポリシーになります。^65030$ (番号 10) と _65030_ は別物で、前者は 65030 単独だけ、後者は 65030 を含むすべてにマッチする点が、AS-PATH ACL を組むときの注意点です。

7. community-list — community 値による経路選別

community-list は、経路の community 属性 (タグ) でマッチする条件部品です。3-8 では R1 が set community 65010:100 で community を付与し、それが AS をまたいで伝搬する様子を観察しました。本節は、付与された community を list で選別する側を扱います。community-list には 2 種類あり、standard は community 値そのもの (65010:100) を列挙し、expanded は正規表現でマッチします。値が確定しているなら、高速な standard を使います。

本ラボでは ip community-list standard CUST permit 65010:100 を定義し、community 65010:100 を持つ経路を選別します。show ip bgp community 65010:100 で、この community を持つ経路だけを取り出すと、R1 が community を付けた 10.10.8.0/24 のみがヒットします。

snippet 
show ip bgp community 65010:100
BGP table version is 9, 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.8.0/24     10.0.12.1                0             0 65010 i

community 65010:100 を持つ経路が 10.10.8.0/24 だけであることが、この出力で確認できます。community-list を route-map の match community から参照すると、「この community を持つ経路に〜する」というポリシーが書けます。community-list 自体は経路の取捨選択や属性操作を行わず、あくまで route-map に「どの経路が条件に合うか」を判定する条件を供給する部品です。経路を実際に動かすのは、次の §8 で扱う route-map の set 句です。

community-list の standard と expanded の違いと、3-8 の付与と本節の選別の関係は、§10 の落とし穴で改めて整理します。

8. 4 部品の連携 — 1 つの route-map に複数 match/set を束ねる

ここまで個別に見た 4 部品を、1 つの route-map に複数の match と set を束ねた複合ポリシーで連携させます。題材は「特定の prefix 範囲を持ち、かつ特定の community を持つ経路にだけ LOCAL_PREF を付与する」という条件です。R2 の inbound に適用する route-map FROM-R1 の permit 10 に、prefix-list と community-list の 2 つの match を AND で並べ、set local-preference 200 を付けます。

route-map の構造は以下のとおりです。permit 10 が 2 つの match を AND で評価し、両方を満たした経路に LOCAL_PREF 200 を付けます。permit 20 が catch-all で、残りを LOCAL_PREF 既定 (100) のまま通します。

snippet 
show route-map FROM-R1
route-map FROM-R1, permit, sequence 10
  Match clauses:
    ip address prefix-lists: LONGER-ONLY 
    community (community-list filter): CUST 
  Set clauses:
    local-preference 200
  Policy routing matches: 0 packets, 0 bytes
route-map FROM-R1, permit, sequence 20
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes

この route-map を inbound に適用した結果、R2 の BGP テーブルでは 10.10.8.0/24 だけが LOCAL_PREF 200 になり、他の経路は既定 100 のままです。

snippet 
show ip bgp
BGP table version is 10, 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.0.0/16     10.0.12.1                0             0 65010 i
 *>   10.10.8.0/24     10.0.12.1                0    200      0 65010 i
 *>   10.10.9.0/26     10.0.12.1                0             0 65010 i
 *>   10.20.2.0/24     0.0.0.0                  0         32768 i
 *>   10.30.3.0/24     10.0.23.2                0             0 65030 i
 *>   10.30.40.0/24    10.0.23.2                0             0 65030 65040 i

3 経路の差が、複数 match の AND を端的に示します。10.10.8.0/24 は prefix 長 24 で LONGER-ONLY の範囲内、かつ community 65010:100 を持つため、2 つの match を両方満たして LOCAL_PREF 200 になります。10.10.9.0/26 は prefix 範囲は満たすものの community を持たないため、permit 10 の AND を満たさず catch-all permit 20 へ進んで LOCAL_PREF 既定 100 のままです。10.10.0.0/16 は prefix 長 16 で範囲外のため、こちらも catch-all へ進んで LOCAL_PREF 100 です。LOCAL_PREF 200 になったのは 2 条件を両方満たした 1 経路だけという結果が、同一 entry 内の複数 match が AND として評価されることを実機で裏付けます。

なお、ここでは prefix-list を route-map の match に包んでいるため、10.10.0.0/16 は permit 10 に match しなくても catch-all permit 20 を通って残ります (§5 のように prefix-list を直接適用したときの暗黙 deny で落ちる挙動とは別物)。route-map に包んだ prefix-list は「LOCAL_PREF を付ける経路を選ぶ」属性操作の条件として働き、prefix-list を直接適用したときの「経路を落とす」フィルタとは役割が異なります。この使い分けは §10 で整理します。

LOCAL_PREF が変わった経路の詳細では、localpref 200 が確認できます。(received-only) の側に元の localpref 100 が残り、best の側に書き換え後の localpref 200 が並びます。

snippet 
show ip bgp 10.10.8.0/24
BGP routing table entry for 10.10.8.0/24, version 10
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 2
  65010
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 200, valid, external, best
      Community: 65010:100
      rx pathid: 0, tx pathid: 0x0
      Updated on Jun 3 2026 01:06:19 UTC
  Refresh Epoch 2
  65010, (received-only)
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external
      Community: 65010:100
      rx pathid: 0, tx pathid: 0
      Updated on Jun 3 2026 00:59:19 UTC

「prefix 範囲 A かつ community B」のように複数条件を AND で組むなら同一 entry に並べ、「prefix 範囲 A または community B」のように OR で組むなら別 entry に分けます。1 つの route-map に複数の match と set を束ねることで、4 部品が連携した複合ポリシーが表現できます。

9. 適用点の地図 — BGP in/out・再配送・PBR

ここまで R2 で組んだ route-map は、BGP neighbor の in/out という適用点に紐付けていました。route-map / match / set という同じ文法は、BGP neighbor in/out・再配送・PBR という 3 つの適用点で共通して使われます。部品を覚えれば、適用点が変わっても応用が利きます。

第一の適用点が BGP neighbor route-map in / out です。隣接単位に inbound / outbound で route-map を適用し、受信する経路や広告する経路を選別・加工します。本節の FROM-R1 in (受信時に LOCAL_PREF を付与) と TO-R3 out (広告時に AS_PATH で選別) がこの例です。R2 の最終 running-config で、2 つの route-map が neighbor に紐付いていることが確認できます。

snippet 
show running-config | section route-map
  neighbor 10.0.12.1 route-map FROM-R1 in
  neighbor 10.0.23.2 route-map TO-R3 out
route-map TO-R3 deny 10 
 match as-path 20
route-map TO-R3 permit 20 
route-map FROM-R1 permit 10 
 match ip address prefix-list LONGER-ONLY
 match community CUST
 set local-preference 200
route-map FROM-R1 permit 20

第二の適用点が 再配送 (redistribute ... route-map) です。3-10 で扱ったとおり、再配送文に route-map を紐付けて、注入する経路をフィルタしたり、set tag で出自を刻んでループ防止に使ったりします。match の対象が AS_PATH や community から tag や ip address に変わるだけで、route-map の構造は BGP の場合と同じです。

第三の適用点が PBR (Policy-Based Routing) です。PBR は、宛先ベースの通常ルーティングを上書きして、送信元アドレスやアプリケーションに応じて転送先を変える仕組みで、ip policy route-map でインタフェースに route-map を紐付けます。本節では適用点の 1 つとして地図上に位置づけるに留め、深掘りはしません。

3 つの適用点を、4 部品との対応で整理すると以下のとおりです。

適用点設定match で使う主な道具本節 / 関連節での例
BGP neighbor in/outneighbor X route-map NAME in/outprefix-list / AS-PATH ACL / community-listFROM-R1 in (LP 付与)・TO-R3 out (AS_PATH 選別)
再配送redistribute P route-map NAMEprefix-list / tag3-10 の tag ループ防止・prefix 選別
PBRip policy route-map NAME (IF 単位)ACL (送信元アドレス等)(本節はスコープ外、地図上の言及のみ)

同じ route-map 文法が 3 つの適用点で共通する点が、ルーティングポリシーを 1 つの体系として捉える意義です。route-map の処理モデル (§3)、match の道具 (§5〜7)、複数 match の連携 (§8) を押さえれば、適用点が BGP から再配送・PBR に変わっても、同じ語彙で設計できます。

10. 落とし穴・補足

本節で整理すべき論点と、教科書 / Web 解説の記述との差を 5 件まとめます。3-3〜3-10 と同じ「正直記録」枠で、Cisco IOS-XE 17.x の実装の振る舞いを優先します。

落とし穴 1: route-map 末尾の暗黙 deny で経路が静かに消える

route-map の末尾には暗黙の deny があり、どの permit entry にも match しない経路は落ちます。BGP inbound に route-map を適用したとき、catch-all permit を付け忘れると、フィルタするつもりのなかった経路まで暗黙 deny で消えます。本ラボの route-map FROM-R1 から catch-all permit 20 を一時的に外すと、permit 10 の AND 条件 (prefix 範囲 + community) を満たさない経路が消えます。permit 10 に match する 10.10.8.0/24 だけが残り、10.10.0.0/16 と 10.10.9.0/26 が消えた状態が以下です。

snippet 
show ip bgp
BGP table version is 12, 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.8.0/24     10.0.12.1                0    200      0 65010 i
 *>   10.20.2.0/24     0.0.0.0                  0         32768 i
 *>   10.30.3.0/24     10.0.23.2                0             0 65030 i
 *>   10.30.40.0/24    10.0.23.2                0             0 65030 65040 i

catch-all を戻すと、消えていた 10.10.0.0/16 と 10.10.9.0/26 が復活します。「LOCAL_PREF を付けたかっただけ」のつもりで catch-all を書かないと、対象外の経路が全部落ちる事故になります。BGP inbound に属性操作目的の route-map を適用するときは、末尾の catch-all permit を必ず置きます。

落とし穴 2: prefix-list の ge/le は prefix 長であって最長一致ではない

prefix-list の ge / le は prefix 長の範囲を指定するもので、forwarding 時のロンゲストマッチ (最長一致) とは無関係です。10.10.0.0/16 ge 24 は「10.10.0.0/16 に含まれ、prefix 長 24 以上」であり、10.10.0.0/16 自身 (長 16) を落とします (§5)。この「枠を指定したのに枠そのものが落ちる」挙動が直感に反するため、prefix 集約の経路を意図せず落とす原因になります。ge / le を省くと完全一致 (長 16 そのもの) のみ許可、ge のみは「指定長以上」、le のみは「指定長以下」と読みます。

落とし穴 3: prefix-list を直接適用するか route-map に包むかで挙動が変わる

prefix-list を neighbor in に直接適用 すると、末尾の暗黙 deny で範囲外の経路が落ちます (§5 で 10.10.0.0/16 が落ちた)。一方、prefix-list を route-map の match に包む と、match しない経路は catch-all permit を通って残り、暗黙 deny で落ちません (§8 で 10.10.0.0/16 が LOCAL_PREF 100 のまま残った)。同じ prefix-list でも、直接適用は「経路を落とすフィルタ」、route-map に包むのは「属性を付ける経路を選ぶ条件」として役割が変わります。「経路を落としたい」なら直接適用、「特定経路に set したい」なら route-map に包む、と使い分けます。route-map に包んだうえで範囲外も落としたいなら、catch-all を deny にするか、明示的な deny entry を追加します。

落とし穴 4: AS-PATH ACL の ^$ (空) と _ (任意境界) は別物

AS-PATH ACL の ^65030$ と _65030_ は意味が異なります。^65030$ は「AS_PATH がちょうど 65030」(隣接 origin のみ)、_65030_ は「AS_PATH 中に 65030 を含む」(65030 を経由するすべて) です (§6)。さらに ^$ は「空の AS_PATH」で、自 AS で origin した経路だけにマッチします。.* でも any にできますが、空 AS_PATH (自 AS origin) を狙うときは ^$ を使います。_ は数字ではなく「AS 番号の境界」(スペース / 行頭 / 行末 / 括弧) を表すメタ文字で、_65040_ は 65040 という AS 番号を 1 つの単位として切り出します。650 のような部分一致を避けるために、AS 番号は _ で囲うのが定石です。

落とし穴 5: community-list の standard / expanded と community の表示形式

community-list には standard と expanded があり、standard は community 値そのもの (65010:100) を列挙、expanded は正規表現でマッチします。値が確定しているなら高速な standard を使い、_65010:_ のようなパターンマッチが必要なときだけ expanded を使います。3-8 では community の付与と伝搬を扱い、list での選別は本節が初出です。

community の表示形式は、ip bgp-community new-format の有無で変わります。本ラボは new-format を投入済みのため 65010:100 という AS:value 形式で表示されますが、3-8 では new-format 未投入で同じ値が decimal 4260495460 (= 65010 × 65536 + 100) と表示されました。community-list を組むときは、表示形式に合わせて値を記述する必要があります。new-format が有効なら permit 65010:100、無効なら permit 4260495460 と書きます。AS:value 形式で扱いたいなら、グローバルに ip bgp-community new-format を投入しておくのが運用上わかりやすい設定です。

11. 次節

3-1 から本節 3-11 まで、第 3 章 L3 編では IP ルーティングの基礎 (3-1〜3-2)、距離ベクトル型とリンクステート型の IGP (3-3 RIP / 3-4 EIGRP / 3-5 OSPF)、パスベクトル型の BGP とその応用 (3-6〜3-9)、プロトコル間の再配送 (3-10)、そして本節のルーティングポリシー総括を扱いました。本節では、route-map を中核に prefix-list / AS-PATH ACL / community-list を 1 つの体系として整理し、BGP neighbor in/out・再配送・PBR の適用点を俯瞰しました。route-map の暗黙 deny、prefix-list の ge/le 範囲指定、複数 match の AND を実機で確認し、第 3 章で断片的に登場した制御部品が同じ文法で束ねられることを示しました。

次節 3-12 からは、ここまでの「経路をどう選び、どう制御するか」から視点を移し、ルーティングの可用性と適用範囲の拡張を扱います。3-12 FHRP (First Hop Redundancy Protocol) でデフォルトゲートウェイの冗長化 (HSRP / VRRP / GLBP) を、3-13 〜 3-15 で IPv6 (アドレス体系 / NDP・SLAAC / OSPFv3・MP-BGP)、3-16 以降でマルチキャストルーティング (PIM-SM / RP / IGMP) を扱い、第 3 章 L3 編を締めくくります。まずは複数のルータで 1 つの仮想ゲートウェイを構成し、片方が落ちても通信が途切れない仕組みを見ていきましょう。

次節