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

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

RFC 1997 の BGP community を「経路に付けるタグ」として整理する。well-known community の伝搬範囲と community-list による LOCAL_PREF 制御を、CML2.9 の eBGP transit chain で実機検証する。

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

3-6 BGP では path vector 型の本質、neighbor 6 状態遷移、weight / LOCAL_PREF / AS_PATH / origin / MED から続く 8 ステップのベストパス選定、iBGP next-hop-self、経路集約までを 3 AS 5 ルータの実機ラボで確認しました。3-7 Route Reflector では iBGP full-mesh 問題の解として RR を扱い、reflection rule と Cluster ID / Originator ID によるループ防止を整理しました。これらの節を通じて扱ってきた BGP 属性 (weight / LOCAL_PREF / AS_PATH / MED / next-hop / Originator ID / Cluster list) は、いずれも それ自体がベストパス選定や到達性に直接影響する 属性でした。

本節で扱う BGP community 属性 (RFC 1997) は、これらとは性質が異なります。community は 経路に付ける AS:value 形式のタグ (ラベル) であり、属性単体ではベストパス選定にも到達性にも影響しません。community が経路の扱いを変えるのは、route-map (community-list でマッチして set local-preference / weight / MED 等を実行する) と組み合わせたとき、または well-known community (no-export / no-advertise / local-AS) のように BGP 実装が伝搬範囲を規定で解釈するとき に限られます。「community を付けたら経路が変わる」という直感は正確ではなく、「community はタグであり、それを読んで動作を変えるのは別の仕組み」という関係を本節の軸とします。

本節の構成は次のとおりです。§2 で community 属性の位置づけを AS_PATH / LOCAL_PREF と対比して導入し、§3 で well-known community (no-export / no-advertise / local-AS) の伝搬範囲ルール、§4 で任意 community と route-map の連携、§5 で拡張 community (Extended Community) の概念を紹介します。§6 で CML2.9 上のラボトポロジを設計し、§7〜§10 で Phase A-D の実機検証 (community なし baseline / no-export の停止 / no-advertise の差 / community-list マッチによる LOCAL_PREF 制御)、§11 で教科書記述と IOS-XE 17.x 実装のギャップを「落とし穴・補足」として整理し、§最終節で 3-9 以降の予告を扱います。

2. BGP community 属性の概要

BGP community 属性は 経路に付与できる 32-bit のタグ で、RFC 1997 (BGP Communities Attribute) で標準化されています。Optional Transitive 属性に分類され、明示的に伝える設定 (後述の send-community) を入れた隣接には eBGP 境界を越えても伝わります。1 つの経路に複数の community を付けることもできます。

community の表記は AS:value 形式 が標準です。32-bit の値の上位 16-bit を AS 番号、下位 16-bit を任意の値として読み、例えば 65010:100 は「AS65010 が定義した 100 番の community」と解釈します。これは規約に過ぎず、AS:value のどちらにどの意味を持たせるかは付与する側の運用ポリシーが決めます。実際の ISP では「100 = 顧客経路」「200 = ピア経路」「300 = no-export 相当」のように community 番号に運用上の意味を割り当て、AS をまたいだポリシー伝達の語彙として使います。

community が AS_PATH や LOCAL_PREF と決定的に異なるのは、community 属性そのものはベストパス選定 8 ステップに登場しない 点です。AS_PATH はステップ ④ で長さが比較され、LOCAL_PREF はステップ ② で大小が比較されますが、community にはこうした比較項目がありません。community は経路に付いているだけで、それを読んだルータが route-map で「この community を持つ経路には LOCAL_PREF 200 を付ける」といった動作を記述して初めて、経路選択に影響します。

community 属性の位置づけ — 経路に付ける AS:value 形式のタグ。属性単体ではベストパスに効かず、route-map (community-list match → set local-preference/weight) を介して初めて経路選択を変える

この間接性が community の使い分けを生みます。LOCAL_PREF や AS_PATH prepend は「属性を操作して経路選択を直接変える」道具であるのに対し、community は「経路に意図のラベルを貼り、その解釈を受信側に委ねる」道具です。AS をまたいで「この経路は他社に再広告しないでほしい」「優先度を下げてほしい」という意図を伝える場合、送信側 AS が community でタグ付けし、受信側 AS がそのタグを読んで自分のポリシーで動作を決める、という分業が成立します。well-known community は「実装が共通解釈する予約済みタグ」、任意 community は「組織間で意味を取り決めるタグ」という位置付けになります。

3. well-known community

well-known community は RFC 1997 が予約した特定の値を持つ community で、BGP 実装が共通の意味で解釈します。任意 community のように受信側が route-map で解釈を定義する必要がなく、付与すれば実装が規定どおり伝搬範囲を制御します。代表的な 3 つが no-export、no-advertise、local-AS (no-export-subconfed) です。

それぞれの伝搬範囲ルールは次のとおりです。

well-known community意味伝搬範囲止まる境界
no-exportこの経路を AS の外に広告しない同一 AS 内 (iBGP) には伝わる。Confederation の sub-AS 間にも伝わるeBGP 境界 (AS の外) で停止
no-advertiseこの経路をどの隣接にも広告しない受信した隣接以外には一切広告しないすべての BGP 隣接 (iBGP / eBGP 問わず) で停止
local-AS (no-export-subconfed)この経路を sub-AS の外に広告しないsub-AS 内には伝わるConfederation の sub-AS 境界で停止
well-known community 早見表 — no-export / no-advertise / local-AS の 3 つの伝搬範囲ルール。iBGP / eBGP / Confederation 境界での停止位置の違い

no-export は最もよく使われる well-known community で、「この経路を AS の外に出さない」という意図を表します。経路は同一 AS 内の iBGP 隣接には伝わりますが、eBGP 境界を越えて隣接 AS に広告される時点で停止します。本ラボの構成では、R1 (AS65010) が付与した no-export 経路が AS65020 内 (R2a → R2b の iBGP) には届くものの、R2b → R3 の eBGP 境界で止まる挙動を §8 で観察します。ISP が顧客にバックアップ経路だけ受け取らせて他社へは再広告させない、といった運用で使われます。

no-advertise は no-export より強い制御で、「この経路をどの隣接にも広告しない」という意図を表します。受信したルータは、その経路を 受信元の隣接を除くすべての隣接 (iBGP / eBGP を問わず) に広告しません。no-export が「AS の外には出さないが AS 内には伝える」のに対し、no-advertise は「AS 内の他のルータにすら伝えない」点が決定的に異なります。本ラボでは、R1 が付与した no-advertise 経路が R2a では受信できるものの、R2a → R2b の iBGP すら越えないことを §9 で観察し、no-export との違いを明確にします。

local-AS (no-export-subconfed) は Confederation 構成専用の community で、「この経路を sub-AS の外に広告しない」という意図を表します。Confederation は AS を複数の sub-AS に分割し、sub-AS 間を eBGP 的に扱う構成 (3-7 §3 で RR と並ぶ iBGP full-mesh 問題の解として言及) で、local-AS はその sub-AS 境界で経路を止めます。本ラボは Confederation を組まない単純 AS 構成のため、local-AS の停止挙動は実機では観察せず、概念紹介に留めます。Confederation そのものの構成は 3-9 以降の候補として扱います。

4. 任意 community と route-map の連携

任意 community (AS:value 形式) は、well-known community のように実装が共通解釈する予約値ではなく、組織が意味を取り決めて使うタグ です。65010:100 のような値を経路に付与しても、それ自体では何の動作も起きません。受信側が community-list でその値にマッチし、route-map で動作 (set local-preference / weight / MED 等) を記述して初めて、経路選択に影響します。

任意 community を使う典型的な運用パターンは、送信側でタグを付け、受信側でタグを読んでポリシーを適用する 分業です。送信側 (本ラボの R1) では、route-map の set community で経路に任意 community を付与し、隣接への neighbor <ip> send-community で community を伝える設定を投入します。受信側 (本ラボの R3) では、ip community-list で特定 community にマッチする条件を定義し、route-map の match community でその条件にマッチした経路に set local-preference 200 を適用します。

送信側 R1 の設定骨子は次のとおりです。

snippet 
route-map SET_COMM permit 10
 set community 65010:100
!
router bgp 65010
 address-family ipv4
  neighbor 10.0.12.2 activate
  neighbor 10.0.12.2 send-community           ! community を隣接に伝えるのに必須
  neighbor 10.0.12.2 route-map SET_COMM out
 exit-address-family

受信側 R3 の設定骨子は次のとおりです。ip community-list standard で community 値を列挙し、route-map で match community した経路に LOCAL_PREF を設定します。

snippet 
ip community-list standard FROM_R1 permit 65010:100
!
route-map LP_BY_COMM permit 10
 match community FROM_R1
 set local-preference 200
route-map LP_BY_COMM permit 20            ! マッチしない経路はそのまま通す catch-all
!
router bgp 65030
 address-family ipv4
  neighbor 10.0.23.1 activate
  neighbor 10.0.23.1 send-community
  neighbor 10.0.23.1 route-map LP_BY_COMM in
 exit-address-family

この構成で重要なのは、経路選択を実際に変えているのは community ではなく route-map の set local-preference 200 という点です。community 65010:100 は経路に付いたタグに過ぎず、ベストパス選定 8 ステップには登場しません。R3 が community-list でマッチして LOCAL_PREF を 200 に書き換えた結果、LOCAL_PREF (ステップ ②) で経路選択が動きます。community はあくまで「どの経路に LOCAL_PREF を付けるか」を判定する条件として機能しているだけです。この因果関係は §10 の Phase D で実機観察し、§11 の落とし穴で改めて整理します。

route-map の permit 20 (空の catch-all) を忘れると、community-list にマッチしない経路がすべて暗黙の deny で破棄される点も注意が必要です。route-map の末尾には暗黙の deny があり、match community でマッチしなかった経路は明示的に通す節を置かないと落ちます。本ラボの R3 では route-map LP_BY_COMM permit 20 を空節として置き、マッチしない経路 (R4 からの経路など) を素通しさせています。

5. 拡張 community の概要

拡張 community (Extended Community) は、RFC 1997 の標準 community (32-bit) を拡張した 64-bit のタグ で、RFC 4360 で標準化されています。標準 community が AS:value の 32-bit しか持てないのに対し、拡張 community は type フィールドを持ち、用途別に構造化された値を表現できます。代表的な用途が Route Target (RT) と Site of Origin (SoO) です。

Route Target は MPLS VPN (BGP/MPLS IP VPN、RFC 4364) で VPN 経路の輸出入を制御するために使われる拡張 community です。VRF (Virtual Routing and Forwarding) ごとに「どの RT を付けて広告するか (export)」「どの RT を持つ経路を取り込むか (import)」を定義し、RT の一致で VPN メンバーシップを表現します。Site of Origin は経路が発生したサイトを識別する拡張 community で、マルチホーム VPN サイトでの経路ループ防止に使われます。

拡張 community の実機検証は本節の範囲外で、概念紹介に留めます。Route Target / Site of Origin は MPLS VPN (VPNv4 / MP-BGP) の文脈で初めて意味を持つ属性であり、その実機検証には VRF と MP-BGP (Multiprotocol BGP) の構成が必要となります。本ラボは標準 community (RFC 1997) を中心に組んでおり、拡張 community の実機観察は MP-BGP を扱う 3-12 以降の節に回します。「community には 32-bit の標準 community と 64-bit の拡張 community があり、後者は MPLS VPN の RT / SoO として使われる」という対応関係が、拡張 community の出発点となります。

6. ラボトポロジ

本節のラボは、community の伝搬・停止が AS 境界をまたぐ挙動 であることを軸に設計します。3-7 の RR スター型ではなく、eBGP 直列 transit chain を採用します。transit AS (AS65020) を R2a / R2b の 2 ルータで構成することで、「no-export は iBGP には届くが eBGP では止まる」という伝搬範囲の違いを 1 ラボ内で観察できるようにしています。

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

3-8 BGP community ラボトポロジ — AS65010 (R1 origin) → AS65020 (R2a/R2b transit, 内部 iBGP) → AS65030 (R3 edge) → AS65040 (R4 far-end) の eBGP 直列。R1 が 10.10.1.0/24 を広告し community を付与する起点

AS65010 (R1) が origin、AS65020 (R2a + R2b) が transit、AS65030 (R3) が edge、AS65040 (R4) が far-end という 4 AS の直列構成です。R1 が 10.10.1.0/24 を network 文で広告し、community を付与する起点となります。AS 番号はプライベート AS 番号 (RFC 6996、64512-65534) を使用し、実 AS 番号を出さない配慮も兼ねています。

ノード総数は csr1000v 5 台 + unmanaged_switch 1 + external_connector 1 の計 7 ノードで、3-7 と同じ規模です。CML2.9 (8 cores) で並列起動可能な範囲となります。

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

機器ASLo0 (Router ID)Lo10 (広告 prefix)Mgmt-vrf直結リンク
R1650101.1.1.1/3210.10.1.0/24172.16.1.211/24Gi2: 10.0.12.1/30 (→ R2a)
R2a650202.2.2.2/32—172.16.1.212/24Gi2: 10.0.12.2/30 (→ R1)、Gi3: 10.0.22.1/30 (→ R2b)
R2b6502022.22.22.22/32—172.16.1.222/24Gi2: 10.0.22.2/30 (→ R2a)、Gi3: 10.0.23.1/30 (→ R3)
R3650303.3.3.3/3210.30.3.0/24172.16.1.213/24Gi2: 10.0.23.2/30 (→ R2b)、Gi3: 10.0.34.1/30 (→ R4)
R4650404.4.4.4/3210.40.4.0/24172.16.1.214/24Gi2: 10.0.34.2/30 (→ R3)

R2a が AS65020 の eBGP 入口、R2b が eBGP 出口で、両者は Lo0 同士でピアリングする iBGP セッションを張ります (update-source Loopback0)。Lo0 への到達経路として、本ラボでは AS65020 内に最小の static /32 経路を 2 本だけ書く設計とします (R2a に ip route 22.22.22.22 255.255.255.255 10.0.22.2、R2b に ip route 2.2.2.2 255.255.255.255 10.0.22.1。IOS-XE の classic ip route 構文はプレフィックスとマスクを分けて書きます)。実運用では AS 内に OSPF / IS-IS を流して Lo0 を IGP で reachable にするのが標準ですが、本ラボは検証の焦点を community の伝搬に絞るため static で代用します。R2a / R2b は iBGP next-hop 問題対策として next-hop-self を投入します (3-6 / 3-7 で確立済みの定石)。next-hop-self は iBGP 隣接に対して 適用するコマンドである点に注意が必要で、本ラボでは eBGP 学習経路を相手側の iBGP peer (R2a→R2b、R2b→R2a の Lo0 ピア) へ渡すときに自分を next-hop にする目的で iBGP 隣接側に設定します (eBGP 隣接へは送信時にデフォルトで next-hop が書き換わるため別目的)。

R1 の day0 config 骨子は次のとおりです。Phase A では route-map なしで素の広告を行い、Phase B 以降で set community を段階投入します。

snippet 
! R1 (AS65010、community 付与の起点)
router bgp 65010
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 neighbor 10.0.12.2 remote-as 65020
 neighbor 10.0.12.2 description eBGP_to_R2a
 !
 address-family ipv4
  network 10.10.1.0 mask 255.255.255.0
  neighbor 10.0.12.2 activate
  neighbor 10.0.12.2 send-community           ! community を隣接に伝えるのに必須
 exit-address-family

R2a は AS65020 の eBGP 入口 + iBGP で、受信 community を保持し iBGP 隣接にも伝える設定が肝となります。

snippet 
! R2a (AS65020、eBGP 入口 + iBGP)
router bgp 65020
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 neighbor 10.0.12.1 remote-as 65010
 neighbor 22.22.22.22 remote-as 65020
 neighbor 22.22.22.22 update-source Loopback0
 !
 address-family ipv4
  neighbor 10.0.12.1 activate
  neighbor 10.0.12.1 send-community
  neighbor 22.22.22.22 activate
  neighbor 22.22.22.22 next-hop-self
  neighbor 22.22.22.22 send-community         ! iBGP 隣接にも community を伝える
 exit-address-family

R2b は AS65020 の eBGP 出口 + iBGP です。R3 への eBGP 隣接に send-community を投入しても、no-export 付き経路はこの境界で止まります。

snippet 
! R2b (AS65020、eBGP 出口 + iBGP)
router bgp 65020
 bgp router-id 22.22.22.22
 neighbor 2.2.2.2 remote-as 65020
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 10.0.23.2 remote-as 65030
 !
 address-family ipv4
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 send-community
  neighbor 10.0.23.2 activate
  neighbor 10.0.23.2 next-hop-self
  neighbor 10.0.23.2 send-community
 exit-address-family

R3 は AS65030 の edge で、Phase D で community-list マッチによる LOCAL_PREF 制御を投入します。R4 は AS65040 の far-end で、no-export 経路が AS65030 で止まるか AS65040 まで出るかを観察する遠端となります。R3 / R4 の community-list と route-map の骨子は §4 で示したとおりです。

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

  • Phase A: community 付与なしの baseline。全 AS に 10.10.1.0/24 が伝搬する素の状態を確認
  • Phase B: no-export community の伝搬と停止。AS65020 内 (iBGP) には届くが R2b → R3 の eBGP で止まる
  • Phase C: no-advertise community。受信隣接以外には一切広告しない (R2a → R2b の iBGP すら越えない)
  • Phase D: 任意 community + community-list マッチによる LOCAL_PREF 制御。R3 で LOCAL_PREF=200
  • Phase E: community の削除 (set community none) と複数 community (additive) の付与

7. Phase A: community 付与なしの baseline

Phase A では、community を一切付与しない素の状態で 10.10.1.0/24 が AS 境界をまたいで全 AS に伝搬することを確認します。R1 が network 10.10.1.0 mask 255.255.255.0 で広告した経路が、AS65020 → AS65030 → AS65040 と各 AS で AS_PATH を伸ばしながら R4 まで届くのが期待動作です。この baseline が、後続の Phase B / C で community を付与したときに「どこで止まるか」を比較する基準となります。

観察ポイントは 2 つです。第一に、各ルータの show ip bgp 10.10.1.0/24 で community 欄が空である ことを確認します。community を付与していないため、経路にはタグが乗っていません。第二に、R4 まで 10.10.1.0/24 が届いていること、すなわち community 制御がない状態では経路が全 AS に伝搬することを確認します。

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

snippet 
show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 65010
BGP table version is 2, main routing table version 2
1 network entries using 248 bytes of memory
1 path entries using 136 bytes of memory
1/1 BGP path/bestpath attribute entries using 288 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 672 total bytes of memory
BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs
1 networks peaked at 06:04:30 May 30 2026 UTC (00:07:52.567 ago)

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.12.2       4        65020      12      12        2    0    0 00:06:54        0

State/PfxRcd 欄が 0 (数値表示) で R2a (10.0.12.2) との eBGP セッションが Established に到達しています。R1 は自身が広告する 10.10.1.0/24 だけを持つため受信 prefix 数は 0 です。R1 の show ip bgp 10.10.1.0/24 は以下のとおりです。

snippet 
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
  Local
    0.0.0.0 from 0.0.0.0 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
      rx pathid: 0, tx pathid: 0x0
      Updated on May 30 2026 06:04:30 UTC

Local、weight 32768、next-hop=0.0.0.0 が R1 の locally originated 経路の目印です。注目すべきは Community: 行が一切出力されていない 点で、community を付与していないため経路にタグが乗っていません。

この経路を遠端の R4 視点で見ると、AS_PATH が伸びていることが確認できます。

snippet 
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 2
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 2
  65030 65020 65010
    10.0.34.1 from 10.0.34.1 (3.3.3.3)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0
      Updated on May 30 2026 06:10:37 UTC

R4 では AS_PATH が 65030 65020 65010 となり、AS65010 (origin) → AS65020 → AS65030 → AS65040 (R4) と eBGP を 3 回越えるごとに AS 番号が積み上がっています。ここでも Community: 行は出力されておらず、community 制御がない baseline であることが分かります。

R4 の BGP テーブル全体は以下のとおりです。

snippet 
show ip bgp
BGP table version is 4, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.10.1.0/24     10.0.34.1                              0 65030 65020 65010 i
 *>   10.30.3.0/24     10.0.34.1                0             0 65030 i
 *>   10.40.4.0/24     0.0.0.0                  0         32768 i

R4 のテーブルに 10.10.1.0/24 が *> (valid / best) で入っており、community 制御がない状態では R1 の経路が AS65010 → AS65020 → AS65030 → AS65040 の全 AS を越えて遠端まで伝搬することが確認できます。この baseline を基準として、Phase B 以降で community を付与したときに経路がどこで止まるかを比較します。

8. Phase B: no-export community の伝搬と停止

Phase B では、R1 で set community 65010:100 no-export を投入し、no-export 付き経路の伝搬範囲を観察します。期待動作は、経路が AS65020 内 (R2a → R2b の iBGP) には届くが、R2b → R3 の eBGP 境界で止まる ことです。no-export が「AS の外には出さないが AS 内には伝える」という伝搬範囲ルールに従うため、AS65020 の内部 (iBGP) では伝搬が続き、AS の出口 (R2b の eBGP) で停止します。

経路の旅を辿ると次のようになります。

Phase B 経路の旅 — no-export 付き 10.10.1.0/24 が R1 → R2a → R2b (AS65020 内 iBGP) には届くが、R2b → R3 の eBGP 境界で止まる。no-advertise なら R2a → R2b の iBGP すら越えない対比も併記

R1 が 65010:100 no-export を付与した経路は、まず eBGP で R2a (AS65020) に渡ります。R2a は no-export を持つ経路を受信し、iBGP 隣接である R2b に伝えます (no-export は iBGP 境界では止まらない)。R2b はこの経路を受信しますが、R3 (AS65030) への eBGP 境界で no-export が効き、R3 には広告されません。結果として、R3 / R4 では 10.10.1.0/24 が消えます。

観察ポイントは 2 つです。第一に、R2a / R2b で show ip bgp 10.10.1.0/24 の community 欄に 4260495460 no-export が表示され、no-export が iBGP 越境後も保持されていることを確認します。community 値が 65010:100 ではなく decimal 値 4260495460 で表示される点は、IOS-XE 17.x の表示形式に関する重要な実機挙動で、§11 の落とし穴 4 で詳しく整理します。第二に、R3 / R4 で 10.10.1.0/24 が % Network not in table となり、eBGP 境界で停止したことを確認します。R2b で send-community を設定していても no-export が優先される点が、設定と well-known community の関係を示します。

R2a が R1 から no-export 付き経路を eBGP で受信した状態は以下のとおりです。

snippet 
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 3
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Advertised to update-groups:
     3         
  Refresh Epoch 1
  65010
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: 4260495460 no-export
      rx pathid: 0, tx pathid: 0x0
      Updated on May 30 2026 06:14:47 UTC

Community: 4260495460 no-export の行が付き、任意 community 4260495460 (= 65010:100) と well-known community no-export が併記されています。1 行目の not advertised to EBGP peer 表記は、no-export を持つこの経路が eBGP 隣接には広告されないことを R2a が認識している証跡です。AS_PATH は 65010 で、R1 から eBGP を 1 回越えて R2a に届いています。

R2a はこの経路を iBGP で R2b に伝えます。R2b 視点では以下のとおりです。

snippet 
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 5
Paths: (1 available, best #1, table default, not advertised to EBGP peer)
  Not advertised to any peer
  Refresh Epoch 1
  65010
    2.2.2.2 from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Community: 4260495460 no-export
      rx pathid: 0, tx pathid: 0x0
      Updated on May 30 2026 06:14:47 UTC

R2b でも Community: 4260495460 no-export が保持されており、no-export が iBGP 境界 (R2a → R2b) を越えても剥がれない ことが確認できます。受信元は from 2.2.2.2 (R2a の Lo0)、属性は valid, internal, best で、R2b の BGP RIB 上で best path が成立しています。no-export を持つこの経路は AS65020 の内部 (iBGP) までは伝搬しており、伝搬範囲ルールの「AS の外には出さないが AS 内には伝える」が実機で裏付けられます。

R2b は AS65030 の R3 と eBGP セッションを張っていますが、no-export が効くため R3 へは広告されません。R3 視点では以下のとおりです。

snippet 
show ip bgp 10.10.1.0/24
% Network not in table
R3#show ip bgp
BGP table version is 5, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.30.3.0/24     0.0.0.0                  0         32768 i
 *>   10.40.4.0/24     10.0.34.2                0             0 65040 i

R3 では show ip bgp 10.10.1.0/24 が % Network not in table となり、BGP テーブルにも 10.10.1.0/24 が存在しません。R2b で neighbor 10.0.23.2 send-community を設定していても、no-export を持つ経路は eBGP 境界 (R2b → R3) で停止します。さらに遠端の R4 でも 10.10.1.0/24 は届かず、show ip bgp 10.10.1.0/24 は同じく % Network not in table となります。Phase A の baseline では R4 まで届いていた経路が、no-export の付与によって AS65020 の出口で止まったことが、baseline との対比で明確になります。

9. Phase C: no-advertise community

Phase C では、R1 で community を set community no-advertise に変更し、no-advertise の伝搬範囲を観察します。期待動作は、経路が 受信した隣接 (R2a) 以外には一切広告されない ことです。no-advertise は「どの隣接にも広告しない」という最も強い制御のため、R2a で受信できても R2a → R2b の iBGP すら越えません。no-export が iBGP 境界を越えたのに対し、no-advertise は iBGP 境界も越えない点が両者の決定的な違いです。

経路の旅を Phase B と対比すると次のようになります。Phase B の no-export では R1 → R2a → R2b (iBGP) まで届きましたが、Phase C の no-advertise では R1 → R2a で止まり、R2a → R2b の iBGP に進みません。R2a は R1 から経路を受信しますが、no-advertise を持つため R2b を含むどの隣接にも広告しません。

観察ポイントは 2 つです。第一に、R2a で show ip bgp 10.10.1.0/24 の community 欄に no-advertise が表示され、R2a が経路を受信できていることを確認します (R2a は R1 の直接隣接のため受信は成立する)。第二に、R2b で 10.10.1.0/24 が % Network not in table となり、no-advertise で R2a → R2b の iBGP が止まったことを確認します。この R2b での停止が、no-export (Phase B では R2b まで届いた) との違いを最も明確に示す観察点となります。

R2a が R1 から no-advertise 付き経路を受信した状態は以下のとおりです。

snippet 
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 4
Paths: (1 available, best #1, table default, not advertised to any peer)
  Not advertised to any peer
  Refresh Epoch 3
  65010
    10.0.12.1 from 10.0.12.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Community: no-advertise
      rx pathid: 0, tx pathid: 0x0
      Updated on May 30 2026 06:17:05 UTC

Community: no-advertise が付き、R2a は R1 の直接隣接のため経路自体は受信できています。ここで Phase B の no-export 経路 (Community: 4260495460 no-export) と表示形式が異なる点に注目が必要です。no-advertise は well-known community 単独で付与しているため、文字列 no-advertise のみが表示され decimal 値は出ません。一方 1 行目の not advertised to any peer 表記は、no-advertise を持つこの経路を R2a が どの隣接にも広告しない と認識していることを示します。Phase B の R2a が not advertised to EBGP peer (eBGP にだけ広告しない) だったのに対し、Phase C では not advertised to any peer (どの隣接にも広告しない) と表記が変わっている点が、no-export と no-advertise の制御範囲の違いを端的に表します。

R2a がどの隣接にも広告しないため、iBGP 隣接である R2b にも経路は届きません。R2b 視点では以下のとおりです。

snippet 
show ip bgp 10.10.1.0/24
% Network not in table
R2b#show ip bgp
BGP table version is 6, local router ID is 22.22.22.22
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, L long-lived-stale,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   10.30.3.0/24     10.0.23.2                0             0 65030 i
 *>   10.40.4.0/24     10.0.23.2                              0 65030 65040 i

R2b では show ip bgp 10.10.1.0/24 が % Network not in table となり、BGP テーブルにも 10.10.1.0/24 が存在しません。Phase B の no-export では R2b まで経路が届いていた (R2b の show ip bgp 10.10.1.0/24 に Community: 4260495460 no-export が出ていた) のに対し、Phase C の no-advertise では同じ R2b で経路が消えています。この R2b 視点の差が、no-export (iBGP 境界を越える) と no-advertise (iBGP 境界も越えない) の伝搬範囲の違いを最も明確に示す実機証跡となります。

10. Phase D: 任意 community + community-list マッチで LOCAL_PREF 制御

Phase D では、community を経路選択に役立てる実運用パターンを観察します。R1 が set community 65010:100 (well-known なしの任意タグ) を付与し、R3 が community-list でその値にマッチして LOCAL_PREF=200 を設定します。well-known community を外したため経路自体は全 AS に伝搬し、R3 が受信した時点で community を読んで LOCAL_PREF を書き換える、という分業を実機で確認します。

経路の旅と因果は次のようになります。

Phase D 経路の旅 — 任意 community 65010:100 を付けた経路を R3 が community-list FROM_R1 でマッチし、route-map で LOCAL_PREF=200 に設定。community 自体ではなく route-map の set local-preference が best 選定を動かす因果

R1 が 65010:100 を付与した 10.10.1.0/24 は、no-export を持たないため AS65020 → AS65030 と伝搬し、R3 に届きます。R3 は inbound 方向に適用した route-map LP_BY_COMM で、community-list FROM_R1 (permit 65010:100) にマッチした経路に set local-preference 200 を実行します。この結果、R3 上の 10.10.1.0/24 の LOCAL_PREF が既定の 100 から 200 に変わります。

ここで community の核心となる因果関係を確認します。経路選択を実際に動かしているのは community ではなく route-map の set local-preference 200 です。community 65010:100 はベストパス選定 8 ステップに登場せず、経路に付いたタグに過ぎません。R3 が community-list でマッチして LOCAL_PREF を 200 に書き換えた結果、LOCAL_PREF (ステップ ②) で経路選択が動きます。community は「どの経路に LOCAL_PREF を付けるか」を判定する条件として機能しているだけで、community 自体が best を決めているわけではありません。

観察ポイントは 3 つです。第一に、route-map 適用前の R3 で show ip bgp 10.10.1.0/24 の community 欄に 4260495460 (= 65010:100 の decimal 表示) が表示され、LOCAL_PREF が既定の 100 であることを確認します。第二に、route-map 投入 + soft clear 後に LOCAL_PREF が 200 に変わることを確認します。第三に、community を付けただけでは (route-map 適用前は) LOCAL_PREF が動かないこと、すなわち community 単体では best 選定に効かないことを確認します。

route-map 適用前の R3 視点は以下のとおりです。

snippet 
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 6
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 1
  65020 65010
    10.0.23.1 from 10.0.23.1 (22.22.22.22)
      Origin IGP, localpref 100, valid, external, best
      Community: 4260495460
      rx pathid: 0, tx pathid: 0x0
      Updated on May 30 2026 06:18:57 UTC

Community: 4260495460 (= 65010:100) を受信しており、no-export を外したため経路自体は AS65020 → AS65030 を越えて R3 まで届いています。この時点で localpref 100 は eBGP 受信の既定値のままで、community を受信しただけでは LOCAL_PREF が動いていないことが分かります。

R3 で neighbor 10.0.23.1 route-map LP_BY_COMM in を投入し clear ip bgp 10.0.23.1 soft in を実行した後の状態は以下のとおりです。

snippet 
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 7
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 2
  65020 65010
    10.0.23.1 from 10.0.23.1 (22.22.22.22)
      Origin IGP, localpref 200, valid, external, best
      Community: 4260495460
      rx pathid: 0, tx pathid: 0x0
      Updated on May 30 2026 06:20:42 UTC
R3#show ip community-list
Named Community standard list FROM_R1
    permit 4260495460
R3#show route-map LP_BY_COMM
route-map LP_BY_COMM, permit, sequence 10
  Match clauses:
    community (community-list filter): FROM_R1 
  Set clauses:
    local-preference 200
  Policy routing matches: 0 packets, 0 bytes
route-map LP_BY_COMM, permit, sequence 20
  Match clauses:
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes

localpref が 100 から 200 に変わりました。community 値 4260495460 自体は適用前後で変化しておらず、変わったのは LOCAL_PREF です。show ip community-list の FROM_R1 が permit 4260495460 で community 値にマッチし、show route-map LP_BY_COMM の sequence 10 が Match clauses: community FROM_R1 → Set clauses: local-preference 200 を実行した結果です。community-list も decimal 値 4260495460 で記録されている点に注目が必要です。

この before/after が本節の核心を実機で裏付けます。community 4260495460 を受信しただけでは LOCAL_PREF は 100 のまま (適用前) で、route-map で set local-preference 200 を実行して初めて LOCAL_PREF が 200 に動きます (適用後)。経路選択を変えているのは community ではなく route-map の set local-preference であり、community はマッチ条件として機能しているだけという因果が、適用前後の 2 つの出力の差として読み取れます。

参考として、Phase E で R1 が set community 65010:100 65010:200 additive で複数 community を付与した場合、R3 では以下のように複数 community が空白区切りで並びます。

snippet 
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 8
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 2
  65020 65010
    10.0.23.1 from 10.0.23.1 (22.22.22.22)
      Origin IGP, localpref 200, valid, external, best
      Community: 4260495460 4260495560
      rx pathid: 0, tx pathid: 0x0
      Updated on May 30 2026 06:21:55 UTC

Community: 4260495460 4260495560 の行に、4260495460 (= 65010:100) と 4260495560 (= 65010:200) の 2 つの community が空白区切りで並んでいます。1 つの経路に複数の community を付与でき、それぞれが独立したタグとして経路に乗ることが確認できます。

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

本節の実機検証で見えた事実と、教科書 / Web 解説の記述との差を 5 件整理します。3-3 / 3-4 / 3-5 / 3-6 / 3-7 と同じ「正直記録」枠で、実装の振る舞いを優先します。本節では特に 落とし穴 4 (community の表示形式) で、教科書の一般的な記述と IOS-XE 17.x csr1000v の実機デフォルトが食い違う重要なギャップが確認できました。

落とし穴 1: send-community を忘れると community が一切伝わらない

IOS / IOS-XE では、neighbor 単位で neighbor <ip> send-community を明示しないと、route-map で set community を投入しても community が隣接に伝搬しません。教科書のトポロジ図では set community だけが描かれ、send-community の投入が省略されがちですが、この 1 行を忘れると「community を付けたはずなのに隣接で見えない」という失敗に直結します。

本ラボでは R1 / R2a / R2b / R3 / R4 のすべての BGP 隣接に send-community を明示的に投入しました。この設定により、Phase B では R2a / R2b で Community: 4260495460 no-export が、Phase D では R3 で Community: 4260495460 が show ip bgp 10.10.1.0/24 に表示され、community が隣接で観察できています。送信側で set community を投入しても、send-community がなければ community は UPDATE メッセージに乗らず、受信側の show ip bgp <prefix> の community 欄は空のままとなります。教科書のトポロジ図で send-community が省略されている図を見たときは、隣接で community が見えるかどうかをこの 1 行の有無で確認する必要があります。

落とし穴 2: no-export の停止位置は「(Confederation を含む) AS の外」

no-export はしばしば「経路を AS の外に出さない」と要約されますが、より正確には「(Confederation を含む) AS の外に出さない」です。no-export は iBGP 隣接には伝わり、Confederation を組んでいる場合は sub-AS 間にも伝わります。停止するのは eBGP 境界 (Confederation の外部 eBGP) であり、AS 内部の iBGP / sub-AS 間 eBGP では止まりません。

本ラボは Confederation を組まない単純 AS 構成のため、no-export の停止位置は AS65020 の外 = R2b → R3 の eBGP 境界となります。Phase B の実機検証では、no-export 付き経路が R2a (eBGP 受信) → R2b (iBGP 受信、Community: 4260495460 no-export 保持) と AS65020 内の iBGP 境界を越えて伝搬し、R2b → R3 の eBGP 境界で % Network not in table となって停止しました。教科書の「AS の外に出さない」という要約が、iBGP 越境を含んだ「AS の出口 (eBGP) で止まる」という正確な意味であることが実機で裏付けられています。sub-AS 境界での挙動 (local-AS との違い) は Confederation 構成が必要なため、3-9 以降の Confederation 節で扱う候補とします。

落とし穴 3: community は best 選定に直接効かない

community 属性の中心的な性質ですが、改めて落とし穴として記録します。community 単体ではベストパスは変わりません。community がベストパス選定に影響するのは、route-map (community-list match → set local-preference / weight / MED) を介して 別の属性を書き換えたとき に限られます。「community を付けたら経路が変わる」という直感は正確ではなく、「community はタグであり、それを読んで LOCAL_PREF 等を変えるのは route-map」という関係が正しい理解です。

Phase D の実機検証では、community 4260495460 (= 65010:100) を付けた経路が、route-map 適用前は LOCAL_PREF 100 のまま (best 選定に影響なし)、route-map 適用後に LOCAL_PREF 200 に変わりました。community 値は適用前後で変化せず、変わったのは LOCAL_PREF だけです。community を受信しただけでは LOCAL_PREF が動かず、route-map の set local-preference 200 が実行されて初めて LOCAL_PREF が動く因果が、before/after の 2 つの show ip bgp 10.10.1.0/24 出力の差として確認できました。ベストパス選定 8 ステップに community が登場しない事実 (3-6 §11 で扱った 8 ステップを参照) と合わせて理解する必要があります。

落とし穴 4: csr1000v はデフォルトで community を decimal 表示する

community の表示形式について、教科書や Web 解説の多くは「IOS-XE は community を 65010:100 の new-format (AS:value 形式) で表示する」と記述します。しかし本ラボの IOS-XE 17.x csr1000v での実機検証では、任意 community がデフォルトで decimal (10 進数) 表示 されました。set community 65010:100 で設定した community は、show ip bgp 10.10.1.0/24 の Community 行に Community: 4260495460 という decimal 値で表示されます。65010:200 は 4260495560 です。これらの値は AS:value を 32-bit 値に変換したもので、65010 × 65536 + 100 = 4260495460、65010 × 65536 + 200 = 4260495560 という対応です。

この挙動は ip bgp-community new-format が デフォルトでは有効になっていない ことに起因します。R3 の running-config を確認すると、community に関する設定行が一切ありません。

snippet 
show ip bgp 10.10.1.0/24
BGP routing table entry for 10.10.1.0/24, version 8
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     2         
  Refresh Epoch 2
  65020 65010
    10.0.23.1 from 10.0.23.1 (22.22.22.22)
      Origin IGP, localpref 200, valid, external, best
      Community: 4260495460 4260495560
      rx pathid: 0, tx pathid: 0x0
      Updated on May 30 2026 06:21:55 UTC
R3#show running-config | include bgp-community
R3#

show running-config | include bgp-community の出力が 空 で、ip bgp-community new-format が設定されていないことが確認できます。AS:value 形式 (65010:100) で表示させるには、ip bgp-community new-format をグローバルコンフィグで 明示的に投入する必要があります。この点は「IOS-XE は new-format がデフォルト」という一般的な記述と逆で、本節の実機検証で最も重要なギャップとなりました。3-3 / 3-4 / 3-5 / 3-6 / 3-7 で拾ってきた教科書ギャップと同じ系譜で、実機の振る舞いを優先して記録します。

なお show ip community-list の表示も decimal です。Phase D の R3 で確認した community-list FROM_R1 は、set community 65010:100 を投入する側 (R1) では AS:value 形式で設定できますが、表示側 (R3) では permit 4260495460 と decimal で記録されます。community-list を読むときも 4260495460 という decimal 値で照合する点に注意が必要です。実運用で community を AS:value で読みたい場合は、ip bgp-community new-format を全ルータで投入してから運用を始めるのが定石となります。

落とし穴 5: well-known community は文字列、任意 community は decimal が併記される

no-export / no-advertise / local-AS は、RFC 1997 で予約された特定の 32-bit 値です。no-export は 0xFFFFFF01、no-advertise は 0xFFFFFF02、local-AS (no-export-subconfed) は 0xFFFFFF03 という予約値を持ちます。show ip bgp <prefix> では、これらの well-known community は文字列 (no-export 等) で表示されます。落とし穴 4 で見たとおり任意 community が decimal で表示されるのに対し、well-known community は文字列のまま表示される点が両者の表示上の違いです。

この違いは、任意 community と well-known community を同時に付与したときの表示で確認できます。Phase B で R1 が set community 65010:100 no-export を投入した経路は、R2a / R2b で Community: 4260495460 no-export と表示されました。任意 community 部分は decimal (4260495460)、well-known community 部分は文字列 (no-export) で、同じ Community 行に decimal と文字列が混在 します。一方 Phase C で no-advertise を単独で付与した経路は Community: no-advertise と文字列のみで表示され、decimal 値は現れません。

任意 community の AS:value 形式と well-known community の予約値は、いずれも 32-bit の community 属性として同じ枠に乗ります。well-known community は AS:value で書くと 65535:65281 (= 0xFFFFFF01、no-export) のような値に対応しますが、実装は文字列で表示・設定するため、運用上は予約された文字列名 (no-export 等) を直接使います。community 属性が 32-bit の単一空間であり、well-known community (文字列表示) と任意 community (csr1000v デフォルトでは decimal 表示) が同じ枠を共有している事実を理解しておくと、Community: 4260495460 no-export のような混在表示を読み解きやすくなります。

12. 次節

3-6 BGP、3-7 Route Reflector、本節 3-8 BGP community 属性を通して、第 3 章 L3 編の 8/16 を消化しました。BGP 系列としては、path vector の本質とベストパス選定 (3-6)、iBGP full-mesh 問題の解の 1 系統 (3-7)、AS をまたぐポリシー伝達の語彙としての community (3-8) まで通したことになります。community でタグを貼り、route-map で解釈してポリシーを適用する、という BGP の運用面の中核が一通り揃いました。

第 3 章の残りは 4 節です。トピックの候補は次のとおりです。

  • Confederation — 3-7 の Route Reflector と並ぶ iBGP full-mesh 問題の解。sub-AS 設計による AS 分割と、本節で概念紹介に留めた local-AS community の停止挙動を実機で扱える
  • ルーティングポリシー総括 — route-map / prefix-list / AS-PATH ACL / community-list の応用、属性操作シナリオ集として BGP 系列を締める
  • マルチキャストルーティング — PIM Sparse Mode、RP (Rendezvous Point)、IGMP
  • IPv6 ルーティング — OSPFv3、MP-BGP for IPv6、SLAAC と DHCPv6

3-9 は Confederation を扱います。本節で扱った community と Confederation の関係が深く、BGP 系列の連載として一貫するためです。本節で local-AS community を概念紹介に留めた論点も、Confederation の sub-AS 構成で実機検証できます。

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

次節