ルーティングポリシー一致条件でBGPコミュニティと拡張コミュニティがどのように評価されるか
BGP コミュニティと拡張コミュニティをルーティングポリシーの一致条件として使用する場合、ポリシーフレームワークソフトウェアはそれらを以下のように評価します。
各ルートは、ルーティングポリシー ステートメントで指定された各コミュニティに対して評価されます。
fromルートがステートメント内の 名前付きコミュニティのいずれかと一致する場合、現在の用語の評価が続行されます。fromルートが一致しない場合、現在の用語の評価は終了します。ルートは、指定されたコミュニティの各メンバーに対して評価されます。指名されたコミュニティの評価が成功するには、すべてのメンバーの評価が成功する必要があります。
名前付きコミュニティ内の各メンバーは、リテラルコミュニティ値または正規表現で識別されます。各メンバーは、ルートに関連付けられている各コミュニティに対して評価されます。(コミュニティは、ルートの順序指定されていないプロパティです。例えば,1:2 3:4は3:4 1:2と同じです。メンバーの評価を成功させるには、ルートから 1 つのコミュニティのみが一致する必要があります。
コミュニティの正規表現は、文字単位で評価されます。たとえば、ルートにコミュニティ 1234:5678 が含まれている場合、正規表現では、コロンで区切られた 2 組の数字(1234 と 5678)ではなく、コロン(:) を含む 9 つの個別の文字が表示されます。たとえば、以下のように表示されます。
[edit] policy-options { policy-statement one { from { community [comm-one comm-two]; } } community comm-one members [ 1:2 "^4:(5|6)$" ]; community comm-two members [ 7:8 9:10 ]; }コミュニティメンバーが正規表現の場合、数字の一致ではなく文字列の一致が行われます。
たとえば、以下のように表示されます。
community example1 members 100:100 community example2 members 100:1..
コミュニティ値が 1100:100 のルートを指定すると、このルートは一致しますが、 は一致 しません 。
community example2example1ルーティング・ポリシー に一致するには、ルートが または のいずれかに一致する必要があります。
onecomm-onecomm-twoを一致 させるには、ルートに 1:2 に一致するコミュニティと、4:5 または 4:6 に一致するコミュニティが必要です。
comm-oneを一致 させるには、ルートに 7:8 に一致するコミュニティと 9:10 に一致するコミュニティが必要です。
comm-two
複数の一致
複数の一致が見つかった場合、ラベルの集計は行われません。次の構成について考えてみます。
family inet-vpn {
unicast {
aggregate-label {
community community-name;
}
}
}
family inet-vpn {
labeled-unicast {
aggregate-label {
community community-name;
}
}
}
たとえば、コミュニティ属性 を持つ 2 つのルートを受信し、コミュニティ名 が .target:65000:1000 origin:65200:2000"5...:.*" この場合、拡張コミュニティ属性 と の両方が、コミュニティ名の正規表現に一致します。target:65000:1000origin:65200:2000 この場合、ラベルの集計は行われません。次の例では、 フィールドにはラベルが集計されていないことが示されています。Label operation
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101056
Push 101056
Communities: target:65000:1000 origin:65200:2000この問題は、次のいずれかの方法で解決できます。
起点サイト拡張コミュニティ属性がターゲット属性と重複しない場合は、正規表現でより具体的にします。
コミュニティ名で起点サイトを指定します。
両方の方法を次の例に示します。
正規表現でより具体的にする
user@host# set policy-options community community-name members "52..:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000コミュニティ名で起点サイトを指定する
user@host# set policy-options community community-name members "origin:65...:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000コミュニティマッチの反転
一致条件は 正規表現を定義し、受信したプレフィックスのコミュニティ属性と一致する場合、Junos OS は TRUE の結果を返します。community そうでない場合、Junos OSはFALSEの結果を返します。この ステートメントにより、Junos OSは反対の動作をします。invert-match 一致した場合、Junos OSはFALSEの結果を返します。一致するものがない場合、Junos OS は TRUE の結果を返します。コミュニティ式のマッチングの結果を反転するには、コミュニティ設定に ステートメントを含め ます。invert-match
[edit policy-options community name] invert-match;
拡張コミュニティタイプ
拡張コミュニティタイプは、正規表現では考慮されません。たとえば、次のようなコミュニティ属性とコミュニティ名について考えてみます。
コミュニティ：
-
5200:1000
-
target:65000:1000 -
origin:65200:2000
コミュニティ属性:
-
コミュニティ名のメンバー "5...:.*"
この場合、拡張コミュニティ属性と拡張コミュニティ属性 の両方が、 コミュニティ名の正規表現に一致します。5200:1000origin:65200:2000 そのため、次に示すように、ラベルの集計は行われません。
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: 5200:1000 target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101056
Push 101056
Communities: 5200:1000 target:65000:1000 origin:65200:2000この問題は、より具体的な正規表現を使用することで解決できます。たとえば、次に示すように、アンカー文字 () を使用して数字の位置をバインドできます。^
user@host# set policy-options community community-name members "^5...:.*" user@host# commit
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: 5200:1000 target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: 5200:1000 target:65000:1000 origin:65200:2000リリース17.3での大規模コミュニティ機能の実装により、Junos OSは、拡張または大規模コミュニティがベースBGPまたはベースBGP正規表現コミュニティとマッチングしないようにチェックします。言い換えれば、受け取ったコミュニティは、通常のコミュニティと単純な野生、拡張されたコミュニティと拡張された野生、大規模なコミュニティと大規模な野生のパターンのように、適切な野生のコミュニティパターンとのみ一致させることができます。たとえば、起点拡張コミュニティを伝送するルートのアドバタイズを許可するには、 式を使用します 。origin:*:65020
複数のコミュニティをex-ORロジックで照合
これは、BGP の非拡張コミュニティに使用される AND 一致ロジックとは異なります。
たとえば、2 セットのコミュニティ属性を持つ 4 つのルートを受信した場合、正規表現は両方のコミュニティ属性に一致する可能性があります。次の例を考えてみます。
コミュニティ—5200:1000 ターゲット:65000:1000
コミュニティ—ターゲット:65000:1000 発信元:65200:2000
コミュニティ属性—コミュニティコミュニティ名メンバー [ "^5...:.*" オリジン:65.*:.* ]
次に示すように、両方のラベルが集計されます。
user@host> show route table VPN detail | match "^10 | Communities | Push"
10.1.1.0/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
10.1.1.4/30 (1 entry, 1 announced)
Label operation: Push 101040
Push 101040
Communities: target:65000:1000 origin:65200:2000
10.1.1.16/30 (1 entry, 1 announced)
Label operation: Push 121104
Push 101104
Communities: 5200:1000 target:65000:1000
10.1.1.20/30 (1 entry, 1 announced)
Label operation: Push 121104
Push 101104
Communities: 5200:1000 target:65000:1000コミュニティ値のより完全な例を次に示します。
user@host> show policy-options community community-name members [ "(^1...:*)|(^3...:*)|(^4...:*)" origin:2.*:* origin:3.*:* origin:6.*:* ]
この正規表現は、1、3、または 4 で始まるコミュニティ値と一致し、管理値が 2、3、または 6 で始まる送信元タイプの拡張コミュニティ値と一致します。
ルーティングポリシー一致条件にBGPコミュニティと拡張コミュニティを含める
BGP コミュニティまたは拡張コミュニティをルーティング ポリシーの一致条件に含めるには、ポリシー条件の ステートメントに 条件を含めます。communityfrom
from {
community [ names ];
}
また、 オプションを使用することで 、静的ルートでBGPコミュニティ情報を明示的に除外することができます。none 部分で 個々のルートを設定し、その部分で 指定されているコミュニティオプションを上書きする場合、このオプションを含めます。routedefaults
一致条件には 、複数のコミュニティの名前を含めることができます。community これを実行すると、一致が発生するために一致する必要があるコミュニティは 1 つだけになります(一致は事実上、論理 OR 演算です)。