Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

ルーティングポリシーの検索条件でコミュニティと拡張コミュニティーを評価する方法について説明します。 BGP

BGP コミュニティと拡張コミュニティーをルーティングポリシーの条件に応じて使用すると、ポリシーフレームワークソフトウェアは以下のように評価します。

  • 各ルートは、ルーティングポリシー fromステートメント内の各名前付きコミュニティーに対して評価されます。ルートがfromステートメント内の名前の付いたコミュニティの1つと一致した場合、現在の用語の評価は続行されます。ルートが一致しない場合は、現在の用語の評価が終了します。

  • ルートは、名前付きコミュニティの各メンバーに対して評価されます。すべてのメンバーの評価を成功させるには、名前付きコミュニティの評価が成功する必要があります。

  • 名前付きコミュニティの各メンバーは、リテラルコミュニティー値または正規表現のいずれかによって識別されます。各メンバーは、ルートに関連付けられている各コミュニティーに対して評価されます。(コミュニティーはルートの順序付けられていないプロパティです。たとえば、1:2 3:4 は 3:4 1:2 と同じです)このルートから提供される 1 つのコミュニティーだけが、メンバーの評価を成功に収められるまで一致するために必要です。

  • コミュニティーの正規表現は、文字単位で評価されます。たとえば、ルートにコミュニティ 1234:5678 が含まれている場合、正規表現にはコロンで区切られた 2 つの数字セット(1234 と 5678)ではなく、コロン(:))を含む 9 つの独立した文字が表示されます。たとえば、以下のように記述します。

    コミュニティーメンバーが正規表現である場合、数字による照合ではなく文字列が一致します。

    たとえば、以下のように記述します。

    コミュニティ値が1100:100 のルートが指定された場合、 community example2このルートexample1は一致しますが、それにはマッチしません。

  • ルーティングポリシー oneを照合するにcomm-oneは、ルートがまたcomm-twoはに一致している必要があります。

  • 一致comm-oneさせるためには、ルートには1:2 と、4:5 または4:6 に一致するコミュニティーが対応している必要があります。

  • 一致comm-twoさせるためには、ルートは7:8 と一致するコミュニティーと9:10 に一致するコミュニティーを持つ必要があります。

複数の一致

複数の一致が見つかった場合、ラベルアグリゲーションは行われません。以下の構成について検討します。

たとえば、2つのルートがコミュニティー属性target:65000:1000 origin:65200:2000を使用して受信され、コミュニティー名"5...:.*"が指定されているとします。この例では、拡張されたコミュニティー target:65000:1000属性origin:65200:2000の両方で、コミュニティー名の正規表現と一致しています。この場合、ラベルアグリゲーションは行われません。次の例では、 Label operationフィールドはラベルが集約されていないことを示しています。

この問題を解決するには、以下のいずれかの方法があります。

  • サイト内の拡張されたコミュニティー属性がターゲット1と重ならない場合、正規表現の中でより具体的なものにしてください。

  • コミュニティー名における起点サイトを指定します。

どちらの方法についても、以下の例で示します。

正規表現でより具体的に指定する必要があります。

コミュニティー名における起点サイトの指定

コミュニティの対戦の反転

一致community条件は正規表現を定義し、受信したプリフィックスのコミュニティー属性と一致する場合、JUNOS OS は真の結果を返します。存在しない場合、Junos OS は偽の結果を返します。このinvert-match文によって、Junos OS の動作が逆になります。一致した場合、Junos OS は FALSE を返します。一致するものがない場合、Junos OS は真の結果を返します。コミュニティーの expression 照合の結果を反転するには、 invert-matchその文をコミュニティー構成に含めます。

拡張コミュニティータイプ

正規表現では、拡張されたコミュニティータイプが考慮されることはありません。たとえば、次のようなコミュニティー属性とコミュニティー名があるとしましょう。

商取引

  • 5200:1000

  • target:65000:1000

  • origin:65200:2000

コミュニティー属性:

  • コミュニティー名メンバー "5...:. *"

この場合、[拡張コミュニティー] 属性5200:1000と [拡張コミュニティー] 属性origin:65200:2000の両方を、コミュニティー名の正規表現に一致させます。そのため、次のようなラベルアグリゲーションは発生しません。

この問題を解決するには、より具体的な正規表現を使用します。たとえば、アンカー文字 (^) を使用して、次に示すように数字の位置を連結できます。

Ex または論理を使用して複数のコミュニティに対応

これは、BGP の非拡張コミュニティーに使用される AND 照合ロジックとは異なります。

たとえば、2セットのコミュニティー属性を使用して4つのルートを受信する場合は、正規表現が両方のコミュニティー属性と一致する可能性があります。次の例について考えてみます。

  • Communities—5200:1000 target:65000:1000

  • Communities—target:65000:1000 origin:65200:2000

  • コミュニティー属性 — コミュニティーコミュニティー名メンバー ["^5.....*" origin:65.*::*]

以下に示すように、両方のラベルが集約されます。

コミュニティー値の詳細な例を以下に示します。

この正規表現は、1、3、または4で始まるコミュニティー値と一致し、その管理値が2、3、または6で始まるタイプオリジンの拡張コミュニティー値と一致します。

ルーティングポリシーの照合条件による BGP コミュニティと拡張コミュニティーの提供

コミュニティーまたは BGP拡張コミュニティーを ルーティング ポリシー条件に含めるには、ポリシー条件のステートメントに条件 communityfrom を含める:

さらに、オプションを使用して、BGP のnoneコミュニティー情報を静的ルートで明示的に除外することもできます。部分に指定されてroutedefaultsいるコミュニティーオプションを上書きするように、部分のルートを個別に構成する場合は、このオプションを含めます。

community検索条件には、複数のコミュニティの名前を含めることができます。このようにした場合、一致させる必要があるのは1つのコミュニティのみとなります (照合は論理的または運用に適しています)。