最も一般的な8つのBGPコミュニティ
BGPコミュニティは、ネットワークエンジニアがトラフィック操作をきめ細かく制御できるようにするオプションのルートタグです。このガイドでは、最も一般的な8種類のコミュニティと、それらを効果的に使用する方法について説明します。
デントン千倉

クイックダウンロード:
BGPコミュニティは、ネットワークがシグナリング指示をプレフィックスに付加できるようにするルートタグであり、ピアごとのカスタム設定なしに、ピアリング関係全体にわたるスケーラブルなトラフィックエンジニアリングを可能にします。
-
コミュニティはオプションの推移的属性であり、明示的に削除されない限り下流のピアに渡されます。つまり、設定ミスのあるコミュニティが意図したよりも遠くまで伝播してしまう可能性があります。
-
NO_EXPORTやNO_ADVERTISEといったよく知られたコミュニティは標準化されています。大規模なコミュニティ(RFC 8092)は、より柔軟で衝突に強いタグ付けを提供します。
-
ブラックホールコミュニティ(RFC 7999)は、リモートからトリガーされるブラックホールルーティングを可能にし、これは重要なDDoS攻撃対策ツールである。
-
ASが各ピアリング境界で設定、受け入れ、削除するすべてのコミュニティを文書化してください。追跡されていないコミュニティは、ルーティング障害や診断が困難なトラフィック異常の頻繁な原因となります。
前回のBGP属性に関する記事では、ルーターがUpdateメッセージに含まれるBGP属性をどのように評価して、ルーティングテーブルにインストールする最適なパスを選択するかについて説明しました。その記事では、BGP機能について議論する際のコンテキストとなる重要な定義についても説明しました。
BGPコミュニティは、利用可能なBGP属性の1つに過ぎませんが、その機能には多くの利点があります。この記事では、どのような種類のBGPコミュニティが存在するのか、そしてそれらを使ってネットワークトラフィックを操作する方法について解説します。
BGPコミュニティとは何ですか?
BGPコミュニティは、オプションの推移的なBGP属性であり、認識されて他のBGPピアに渡されます。BGPコミュニティは、2つのBGPピア間で交換されるBGPルートに付加されるタグとして表示されることがあります。
まず、Update メッセージでルートに設定された BGP コミュニティがどのように見えるかを見てみましょう。このシンプルなネットワークを考えてみましょう。R111 は 10.10.10.0/24 ルートを AS 11 BGP ピアにアドバタイズします。R111 は、R11.g にアドバタイズするルートにコミュニティ 1:110 を設定します。

R111 (1.1.3.2) から R11 (1.1.3.1) への BGP Update メッセージを見ると、複数の BGP 属性とその値を確認できます。これらの BGP 属性の 1 つはコミュニティです。この属性はオプションであり、ルートがアドバタイズされる前に設定されているため表示されていることに注意してください。

R11でルートを確認すると(R11はルートを受け入れ、コミュニティに対して何の操作も実行しないため)、ルートに1:110のコミュニティがあることが確認できます。
R11#show ip bg 10.10.10.0/24
BGP routing table entry for 10.10.10.0/24, version 2
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
111
1.1.3.2 from 1.1.3.2 (10.10.10.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: 1:110
rx pathid: 0, tx pathid: 0x0
R11#
これで、Updateメッセージ内のBGPコミュニティがどのようなものかを確認できたので、この属性を取り巻くより高度な概念について見ていきましょう。
高度なBGPコミュニティの概念
コミュニティは、2つの16ビットセクションに分割された32ビットの値です。最初の16ビットは、コミュニティを生成したAS番号をエンコードし、最後の16ビットはASによって割り当てられた一意の番号を表します。各AS番号は一意であるため、インターネット上の各コミュニティも一意です。つまり、AS番号が9999(16進数では0x270F)のASは、0x270F0000~0x270FFFFFの範囲のコミュニティを持つことができます。
有名なBGPコミュニティ
以下は、コミュニティ認識型のBGP実装において必ず認識しておくべき、よく知られたコミュニティの例です。
1. 広告なしのコミュニティ
ノーアドバタイズコミュニティがルートに紐付けられている場合、BGPスピーカーは内部または外部のBGPピアに対してそのルートをアドバタイズしません。
次の例は、R1 がピア R11、R12、R111 にアドバタイズしない No-Advertise ルート (10.10.10.0/24) を示しています。

2. 輸出禁止コミュニティ
ルートに「No-Export」コミュニティが設定されている場合、ルーターはルートを外部ピアには通知せず、内部ピアにのみ通知します。
次の例は、R1、R11、またはR12が外部ピアであるR111にNo-Exportルート(10.10.10.0/24)をアドバタイズしていないことを示しています。

この場合、R1はR111にはルートをアドバタイズせず、R11とR12にのみアドバタイズします。これは、R11とR12が内部BGPピアであるためです。同様に、R11とR12もR111にはルートをアドバタイズしません。これは、R111が外部BGPピアであるためです。
3. ローカルASコミュニティ
BGPルーティングループを回避するために、内部BGPネイバーに関する重要なルールがあります。IBGPネイバーは、別のIBGPネイバーから受信したルートを、別のIBGPネイバーにアドバタイズすることはできません。
次の例は、ローカルAS内のIBGPネイバー(R11とR111)間でローカルASルート(10.10.10.0/24)がアドバタイズされていないことを示しています。

より正確に言うと、R11はR22にルートをアドバタイズしますが、上記のルールに基づき、R22はR111にルートをアドバタイズしません。R111がルートを取得するには、AS11のルーター間でIBGPセッションのフルメッシュを作成する、またはAS11をコンフェデレーション内のサブASに分割するなど、複数の解決策があります。

AS11の外部の世界は、AS1000とAS1001を認識していません。これにより、R111はフルメッシュBGPピアリングなしで10.10.10.0/24ルートを受信できます。ローカルASコミュニティは、サブAS外のルートをアドバタイズしません。
4. グレースフルシャットダウンコミュニティ
Graceful_SHUTDOWN (65535:0) コミュニティは、ルーターがピア ルーターを意図的にシャットダウンしようとしているときに、ルーターが使用する可能性のあるパスをスムーズにシャットダウンするために使用されます。例として、R111 が R11 を使用して 10.10.10.0/24 サブネットに到達しているが、R11 がアップグレードのために再起動される必要があるとします。

R11がこのコミュニティを宣伝すると、R111は最小限の影響でトラフィックをR12に切り替えることで対応します。

5. 拡大されたコミュニティ
拡張コミュニティは8バイトの値で、主に2つのセクションに分かれています。
- 最初の2バイトコミュニティの種類を指定します
- 最後の6バイトコミュニティの種類に特化した独自の情報を提供します
拡張コミュニティには、タイプ、管理者、割り当て番号の3つのフィールドがあります(タイプ:管理者:割り当て番号)。タイプフィールドの最上位バイトの値に基づいて、管理者フィールドにはAS番号またはIPアドレスを指定できます。
拡張コミュニティの最もよく知られた応用例はMPLS-VPNであり、これは2つの拡張コミュニティを利用します。
- ルートターゲットコミュニティ特定のルートセットを受信できるルーターを識別します。
- ルートオリジンコミュニティ: 特定のルートセットをBGPに注入するルーターを識別します。
仮想ルーティングおよび転送(VRF)とは、グローバルルーティングテーブルや他のVRFとは別に、独自のルーティングポリシーを持つことができる仮想ルーティングテーブルです。つまり、顧客の複数の拠点を接続し、その顧客専用のルーティングテーブル(VRF)をネットワーク全体に作成し、他の顧客とは異なるルーティングポリシーを実装することができます。
この分離は、マルチプロトコルBGP拡張機能とMPLSによって可能になります。
6. ルートターゲットコミュニティ
MPLS VPN環境では、次の図に示すように、ルートターゲットコミュニティを使用して2つの顧客のルーティングテーブルを分離します。

この特定のケースでは、VRF Customer REDはR1とR12にのみ存在し、VRF Customer BLUEはR11とR22にのみ存在しますが、4台すべてのルーターに存在していた可能性もあります。
VRF RedからBGP経由でルートがエクスポートされると、エクスポートされたルートにルートターゲット100:100が割り当てられます。ルートがR12に到達すると、R1からルートがインポートされるため、R1とR12に接続されているサイト間で通信が可能になります。
7. ルート発信元コミュニティ
MPLS VPN環境では、ルートオリジンコミュニティを使用してルートの発信元を特定し、そのサイトへの再アドバタイズを回避します。

この場合、PE1がCE1からルートを受信すると、(エクスポートを使用して)ルートに添付されるルートターゲットに加えて、ルートの発信元コミュニティも添付されます。
経路はPE2に到達するが、PE2はそれがサイトから来たことを認識しているため、CE2にその経路を通知しない。
8. 大規模コミュニティ
ラージコミュニティは、4バイトのASが割り当てられ始めた際に開発された12バイトのBGPコミュニティです。標準コミュニティと拡張コミュニティはそれぞれASに2バイトの値を使用するため、4バイトのASは標準の2バイトの値には収まりません。
ラージコミュニティは、32ビットASN:32ビット値:32ビット値として表示されます。
BGP最適パス選択アルゴリズム
ご覧いただいたように、BGPコミュニティには複数の用途があります。ルートのタグ付け、トラフィックの操作、特定のコミュニティに一致するルートのBGP属性に対する様々なアクションの実行などに重要です。
ルーターが特定の宛先への複数のパスの中からどのパスを選択するかを決定する必要があるときはいつでも、BGP属性を評価するBGP最適パス選択アルゴリズムに従う必要があります。BGP最適パス選択アルゴリズムの詳細については、以前の記事をご覧ください。 BGP属性.
BGPコミュニティの例
このセクションでは、ルートに紐づけられたBGPコミュニティが、そのプレフィックスからのホストへのアップロードおよびダウンロードトラフィックにどのように影響を与えるかを説明します。
アップロード
アップロードトラフィックの経路に影響を与える方法は複数ありますが、最も一般的なのはローカル設定を利用することです。 BGP属性に関する記事ローカルのルート優先度の値が高いほど、そのパスがBGPの最適パス選択アルゴリズムによって選択される可能性が高くなります。
次の図では、R11とR12は次のように設定されています。
- コミュニティ番号が1:205のルートを受信した場合は、ローカル優先度を205に設定します。
- コミュニティ番号が1:210のルートを受信した場合は、ローカル優先度を210に設定します。

これらのルーターは両方ともR1に経路を通知し、R1はどちらの経路を使用するかを決定する必要があります。この場合、R1はR11からの経路を使用するため、トラフィックは次のように流れます。

アップロード ルーター出力
R1#sh ip bgp 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 2
Paths: (2 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
111
1.1.3.2 (metric 20) from 1.1.1.2 (1.1.100.11)
Origin IGP, metric 0, localpref 210, valid, internal, best
Community: 1:210
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
111
1.1.4.2 (metric 20) from 1.1.2.2 (1.1.100.12)
Origin IGP, metric 0, localpref 205, valid, internal
Community: 1:205
rx pathid: 0, tx pathid: 0
R1#
ダウンロード
ダウンロードトラフィックの経路(または他のユーザーがあなたのASにトラフィックを送信する方法)に影響を与える一般的な方法は、AS_PATHを先頭に追加することです。AS_PATHが長くなるほど、最適な経路選択アルゴリズムによってその経路が選択される可能性は低くなります。
次の図では、AS 1 は AS 111 から転送されるトラフィックが R12 から送信されることを優先します。
AS 111 (R111 のため) には、AS 1 がコミュニティ 1:1 のプレフィックスをアナウンスする場合、AS_PATH の先頭に 1 回追加するというポリシーがあります。そのため、R111 はルートの AS_PATH を [1 1] に設定します。ルートがコミュニティ 1:3 で到着する場合は、AS_PATH の先頭に 3 回追加します ([1 1 1 1])。

R111は2つの経路を受け取り、それらの経路に紐づけられたコミュニティに基づいて動作する必要があります。R111はR12からの経路を優先するため、トラフィックの流れは次のようになります。

ルーターの出力をダウンロード
R111#sh ip bgp 10.10.10.0/24
BGP routing table entry for 10.10.10.0/24, version 4
Paths: (2 available, best #2, table default)
Advertised to update-groups:
6
Refresh Epoch 2
1 1 1 1
1.1.3.1 from 1.1.3.1 (1.1.100.11)
Origin IGP, metric 100, localpref 100, valid, external
Community: 1:3
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
1 1
1.1.4.1 from 1.1.4.1 (1.1.100.12)
Origin IGP, localpref 100, valid, external, best
Community: 1:1
rx pathid: 0, tx pathid: 0x0
R111#
製品概要
この記事では、BGPコミュニティ属性で使用できる最も一般的なBGPコミュニティと、それらを使用してトラフィックをルーティングする方法について説明しました。BGPコミュニティはオプションの属性ですが、内部トラフィックと外部トラフィックの両方のルーティングに非常に有効です。計画的な再起動やシャットダウンに備えて、トラフィックのリダイレクトを準備するためにも使用できます。
章
ニュースレター
最新情報のメール配信を登録
最新のブログ、ホワイトペーパー、電子ガイドなどを直接受信ボックスにお届けします。
シェア
BGPルーティングの状態をリアルタイムで監視します。
LogicMonitorのネットワーク監視機能により、BGPコミュニティの変更、ルート操作、ポリシーに基づくルーティングの変更などが本番トラフィックに影響を与える前に、チームはこれらの変更を可視化できます。
よくあるご質問
BGPコミュニティとは何ですか?
BGPコミュニティは、ルートアドバタイズメント(BGPアップデートメッセージ)に付加されるオプションの推移的属性であり、タグまたはラベルとして機能します。コミュニティを使用することで、ネットワークはルーティングポリシーシグナルをピア自律システムに伝達し、タグ付けされたルートの処理方法を指示できます。コミュニティはRFC 1997で定義され、大規模なコミュニティについてはRFC 8092で拡張されています。
NO_EXPORT BGPコミュニティとは何ですか?
NO_EXPORT (0xFFFFFF01) は、受信ルータに対し、タグ付きルートを外部 BGP ピア (eBGP ピア) にアドバタイズしないよう指示する、よく知られた BGP コミュニティです。ルートは AS 内では可視状態を維持し、iBGP ピアと共有できますが、コンフェデレーションを超えて伝播されることはありません。これは、特定のルートをプロバイダのネットワーク内に留めておくためによく使用されます。
大規模なBGPコミュニティは、標準的なコミュニティとどのように異なるのでしょうか?
標準BGPコミュニティ(RFC 1997)は32ビット形式(AS:値)を使用するため、値の範囲が制限され、複数のASが同じコミュニティ値を使用すると競合が発生する可能性があります。大規模BGPコミュニティ(RFC 8092)は96ビット形式(global_administrator:local_data1:local_data2)を使用するため、はるかに広い値の範囲が確保され、異なる組織のコミュニティ方式間の競合が解消されます。
BGPブラックホールコミュニティとは何ですか?また、どのように使用されますか?
BGPブラックホールコミュニティ(RFC 7999で標準化された65535:666)は、リモートトリガー型ブラックホール(RTBH)ルーティングに使用されます。ネットワークがDDoS攻撃を受けている場合、オペレーターは標的の宛先プレフィックスにブラックホールコミュニティをタグ付けし、アップストリームプロバイダに通知することができます。ポリシーが一致するプロバイダは、エッジでそのプレフィックス宛てのすべてのトラフィックを破棄し、攻撃トラフィックが標的ネットワークに到達する前に阻止します。
デントン・チクラは、テクニカルライターであり、長年にわたりオブザーバビリティを推進してきた人物です。彼は、サイト信頼性エンジニアやエンジニアリングチームがインターネットの回復力を強化するツールや機能を発見できるよう支援することに注力しています。監視、パフォーマンス、インフラストラクチャの交差点で活動し、複雑なシステムをより理解しやすく使いやすいものにすることで、高度な技術的詳細と実際の運用とのギャップを埋めています。彼の目標は、チームがより迅速に構築し、問題を早期に発見し、よりスマートに復旧できるよう支援し、最終的にはインターネットをすべての人にとってより良く、より信頼性の高い場所にすることです。
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。




