ルーティングポリシー一致条件でBGPコミュニティと拡張コミュニティがどのように評価されるか
BGP コミュニティと拡張コミュニティをルーティングポリシーの一致条件として使用する場合、ポリシーフレームワークソフトウェアはそれらを以下のように評価します。
各ルートは、ルーティングポリシー
fromステートメントで指定された各コミュニティに対して評価されます。ルートがfromステートメントの名前付きコミュニティの 1 つと一致する場合、現在の用語の評価は続行されます。ルートが一致しない場合、現在の用語の評価は終了します。ルートは、指定されたコミュニティの各メンバーに対して評価されます。指名されたコミュニティの評価が成功するには、すべてのメンバーの評価が成功する必要があります。
名前付きコミュニティ内の各メンバーは、リテラルコミュニティ値または正規表現で識別されます。各メンバーは、ルートに関連付けられている各コミュニティに対して評価されます。(コミュニティは、ルートの順序指定されていないプロパティです。例えば,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 example2一致しますが、example1とは一致しません。ルーティング ポリシー
oneに一致するには、ルートがcomm-oneまたはcomm-twoのいずれかに一致する必要があります。comm-oneを一致させるには、ルートに 1:2 に一致するコミュニティと、4:5 または 4:6 に一致するコミュニティが必要です。comm-twoを一致させるには、ルートに 7:8 に一致するコミュニティと 9:10 に一致するコミュニティが必要です。
複数の一致
複数の一致が見つかった場合、ラベルの集計は行われません。次の構成について考えてみます。
family inet-vpn {
unicast {
aggregate-label {
community community-name;
}
}
}
family inet-vpn {
labeled-unicast {
aggregate-label {
community community-name;
}
}
}
たとえば、コミュニティ属性が target:65000:1000 origin:65200:2000 のルートが 2 つ受信され、コミュニティ名が "5...:.*"であるとします。この場合、拡張コミュニティ属性である target:65000:1000 と origin: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コミュニティマッチの反転
community一致条件は正規表現を定義し、受信したプレフィックスのコミュニティ属性と一致する場合、Junos OSはTRUEの結果を返します。そうでない場合、Junos OSはFALSEの結果を返します。invert-matchステートメントは、Junos OSを反対に動作させます。一致した場合、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:1000 と拡張コミュニティ属性 origin: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 コミュニティまたは拡張コミュニティをルーティング ポリシーの一致条件に含めるには、ポリシー条件の from ステートメントに community 条件を含めます。
from {
community [ names ];
}
また、 none オプションを使用することで、静的ルートでBGPコミュニティ情報を明示的に除外することができます。route部で個々のルートを設定し、defaults部で指定したコミュニティオプションを上書きする場合、このオプションを含めます。
community一致条件には、複数のコミュニティの名前を含めることができます。これを実行すると、一致が発生するために一致する必要があるコミュニティは 1 つだけになります(一致は事実上、論理 OR 演算です)。