ルーティングポリシー一致条件におけるポリシーサブルーチンの理解
別のルーティングポリシーから呼び出されたルーティングポリシーを、一致条件として使用できます。このプロセスにより、呼び出されたポリシーが サブルーチンになります。
Junos OSポリシーフレームワークは、ある意味でプログラミング言語に似ています。この類似性には、ポリシーをポリシーサブルーチンに入れ子にするという概念が含まれます。ソフトウェアプログラムのサブルーチンは、定期的に参照するコードのセクションです。ポリシー サブルーチンは、既存のポリシーを別のポリシーの一致条件として参照する場合と同様に機能します。ルーティングデバイスは、まずサブルーチンを評価し、次にメインポリシーを評価します。サブルーチンの評価は、真または偽のブール結果をメインポリシーに返します。サブルーチンを一致条件として参照しているため、真の結果は、メインポリシーが一致しており、設定されたアクションを実行できることを意味します。ただし、サブルーチンからの誤った結果は、メインポリシーが一致しないことを意味します。
サブルーチンの設定
あるルーティング・ポリシー内のサブルーチンを別のルーティング・ポリシーから呼び出すように設定するには、サブルーチンを作成し、別のルーティング・ポリシーの from ステートメントまたは to ステートメントで policy 一致条件を使用してその名前を指定します。
ルーティング・ポリシーをそれ自体で評価しないでください。その結果、ルーティング ポリシーに一致するプレフィックスがなくなります。
サブルーチンで指定されたアクションは、呼び出し元のポリシーに一致する条件を提供するために使用されます。サブルーチンが accept のアクションを指定した場合、呼び出し元のポリシーはルートを一致と見なします。サブルーチンが拒否のアクションを指定した場合、呼び出し元のポリシーはルートが一致していないと見なします。サブルーチンが経路特性を操作するアクションを指定すると、変更が行われます。
サブルーチンでの終了アクションの考えられる結果
特定のステートメントを持つサブルーチンは、同じステートメントを含むルーティング・ポリシーとは異なる動作をする可能性があります。サブルーチンでは、サブルーチンまたはデフォルト・ポリシーによって指定された accept または reject の終了アクションが、予期される結果に大きく影響する可能性があることに注意してください。
特に、サブルーチンで指定されたルートとの一致が発生しない場合や、実行されるデフォルトのポリシーアクションが期待どおりのアクションである場合に何が起こるかを考慮する必要があります。
たとえば、あなたが顧客Aにサービスを提供するインターネットサービスプロバイダー(ISP)のネットワーク管理者であるとします。顧客Aがさまざまなリンクで提示する異なるクラスのネイバーに対して、いくつかのルーティングポリシーを設定しました。顧客Aのルーティングポリシーを維持する時間を節約するために、以下に示すように、顧客Aのルートと、そのサブルーチンを呼び出すさまざまなルーティングポリシーを識別するサブルーチンを設定しました。
[edit]
policy-options {
policy-statement customer-a-subroutine {
from {
route-filter 10.1/16 exact;
route-filter 10.5/16 exact;
route-filter 192.168.10/24 exact;
}
then accept;
}
}
policy-options {
policy-statement send-customer-a-default {
from {
policy customer-a-subroutine;
}
then {
set metric 500;
accept;
}
}
}
policy-options {
policy-statement send-customer-a-primary {
from {
policy customer-a-subroutine;
}
then {
set metric 100;
accept;
}
}
}
policy-options {
policy-statement send-customer-a-secondary {
from {
policy customer-a-subroutine;
}
then {
set metric 200;
accept;
}
}
}
protocols {
bgp {
group customer-a {
export send-customer-a-default;
neighbor 10.1.1.1;
neighbor 10.1.2.1;
neighbor 10.1.3.1 {
export send-customer-a-primary;
}
neighbor 10.1.4.1 {
export send-customer-a-secondary;
}
}
}
}
この構成では、次の結果が発生します。
グループレベルの
exportステートメントは、すべての BGP ルートをネイバー 10.1.1.1 と 10.1.2.1 にアドバタイズするときに、サブルーチンルートフィルタに一致するルートだけではなく、メトリックを 500 に リセットします。ネイバーレベルの
exportステートメントは、すべての BGP ルートをネイバー 10.1.3.1 と 10.1.4.1 にアドバタイズするときに、サブルーチンルートフィルタに一致する BGP ルートだけではなく、メトリックをそれぞれ 100 と 200 にリセットします。
このような予期しない結果は、サブルーチン ポリシーがルート フィルターに一致しないルートの終了アクションを指定しないため、すべての BGP ルートを受け入れるというデフォルトの BGP エクスポート ポリシーが採用されるためです。
この特定のサブルーチンに含まれるステートメントが呼び出し元のポリシー自体に含まれていた場合、目的のルートのみがメトリックをリセットされます。
この例は、ルーティングポリシーとサブルーチンの違い、およびサブルーチンにおける終了アクションの重要性を示しています。ここでは、サブルーチンのデフォルトのBGPエクスポートポリシーアクションは慎重に検討されていませんでした。この特定の例の解決策は、ルート フィルターに一致しない他のすべてのルートを拒否する条件をもう 1 つサブルーチンに追加することです。
[edit]
policy-options {
policy-statement customer-a-subroutine {
term accept-exact {
from {
route-filter 10.1/16 exact;
route-filter 10.5/16 exact;
route-filter 192.168.10/24 exact;
}
then accept;
}
term reject-others {
then reject;
}
}
}
一般的なサブルーチンの終了アクション方針には、以下のものがあります。
他のすべてのルートを処理するデフォルトのポリシーアクションに依存します。
他のすべてのルートを受け入れる条件を追加します。
他のすべてのルートを拒否する条件を追加します。
選択するオプションは、サブルーチンで何を実現したいかによって異なります。サブルーチンは慎重に計画してください。