ルート フィルターのウォークアップの概要
複数のポリシー条件にまたがってルート フィルターが分割されることで、ポリシーのパフォーマンスに懸念がある場合は、ウォークアップ機能を使用します。ウォークアップ機能により、1つのポリシー条件にルート フィルターを統合できます。
デフォルトでは、Junosはポリシーステートメント条件内の複数のルートフィルターを評価します。まず、ロンゲストマッチのプレフィックスを見つけてから、ルートフィルターにアタッチされた条件(プレフィックス範囲など)を評価します。ルート フィルター条件が false の場合(例えば、プレフィックスが指定範囲内にない場合)、より短いルート フィルターのプレフィックスが真になる可能性がある場合でも、項全体が false になります。この動作が原因で、ルート フィルターが個々のポリシー ステートメント条件に分割されている場合、パフォーマンスの問題が発生する可能性があります。ウォークアップ機能は、デフォルトのルート フィルターの動作を変更します。
一部の自動化されたポリシー ツール(例えば、ボーダー ゲートウェイ プロトコル(BGP)の自律システム境界ルーターに使用されるツール)では、デフォルトのルート フィルターの動作により、ルート フィルターが複数の用語に分割されます。ルート フィルタは、BGP 以外のルーティング プロトコルでも使用されます。ウォークアップ機能は、BGP ルート フィルターに限定されません。
技術的には、BGPはOSPFやIS-ISと同じ方法でルートを処理することはありません。BGPの「ルート」は、より適切にはネットワーク層到達性情報(NLRI)更新と呼ばれています。ただし、"ルート" という用語はほとんどのドキュメントで使用されており、ここで使用されています。
ルート フィルターは、次の 3 つの主要部分で構成されます。
プレフィックスとプレフィックス長 (例:
10.0.0.0/8)一致条件 (
exactなど)前の両方の部分(プレフィックスと一致条件)が両方とも true と評価された場合に実行されるアクション(例:
accept)
したがって、 10.0.0.0/8 exact accept ルート フィルターは、考慮されたプレフィックスが正確に 10.0.0.0/8 場合にのみ成功します。このルート フィルターは、 10.0.0.0/10 などの長い他のすべてのプレフィックスが付いたルートを拒否しますが、ポリシー チェーン内に 10.0.0.0/10 ルートを受け入れる他のルート フィルター条件が存在する可能性があります。
10.0.0.0/8ルートとバリエーションは特にドキュメント用に予約されていませんが、このアドレス空間が提供する柔軟性と現実的なシナリオのため、このトピックではプライベート RFC 1918 10.0.0.0/8 アドレス空間を使用します。
ルート フィルターは、1 つのポリシー ステートメント条件に組み合わせることができます。その場合、評価はより複雑になります。以下のルーティング・ポリシーを考慮してください:
[edit policy-options]
policy-statement RouteFilter-A {
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
10.0.0.0/8 orlonger フィルターのスコープには、10.0.0.0/16 prefix-length-range /22-/24 フィルターが含まれていることに注意してください。つまり、プレフィックスが 8 ビット以上の 10.0.0.0 ルートは、プレフィックスが 22 ビットから 24 ビットの範囲のルートにもなり得ます。
デフォルトでは、複数のルート フィルターを使用したポリシー ステートメント条件の評価は、次の 2 段階のプロセスです。
ポリシー フレームワーク ソフトウェアは、プレフィックスとプレフィックス長の値に基づいて、リスト上で最長一致ルックアップを実行します。
ソフトウェアは、ルート フィルターの条件(
orlonger、exactなど)を考慮します。ルートは、ルート フィルター条件を満たしているか(成功)、ルート フィルター条件に一致しない(失敗)かのいずれかです。
これら2つのステップの結果に基づいて、一致または失敗によって決定されたアクションがルートに適用されます。Route-Filter-Aでは、これは、RouteFilter-1項で「真」であるルートはすべて受け入れられ、項で「偽」であるルートは拒否されることを意味します。このルートは非表示(フィルタリング)ルートになります。
例えば、ルート 10.0.0.0/18 がポリシーステートメント RouteFilter-Aによって評価されるとどうなるかを考えてみましょう。
まず、 10.0.0.0/18 ルートを RouteFilter-1 項で評価します。10.0.0.0/16 は 10.0.0.0/8 より長いため、10.0.0.0/18ルートはより長く、より具体的なルート プレフィックスと一致します。次に、 10.0.0.0/18 ルートが prefix-length-range /22-/24 条件に一致しないため、マッチングが失敗します。そのため、ルート一致は RouteFilter-1 項で失敗し、ポリシーは次の項(デフォルト項)を調べます。10.0.0.0/18ルートは、デフォルトの条件によって拒否されます。
その結果、 10.0.0.0/18 ルートは非表示(フィルタリング)されます。( 10.0.0.0/18 ルートは、 show route hidden コマンドで引き続き見つけることができます。
問題は、ユーザーが実際に 10.0.0.0/18 ルートを拒否するのではなく受け入れることを望んでいる可能性があることです。当然、 10.0.0.0/18 exact 構成のルート フィルターを追加できます。しかし、エントリー数が 100,000 以上のバックボーン ルーティング テーブルでは、すべてのルートまたはネットワークに追加されるすべての新規ルートにチューニングされたルート フィルターを構成することはできません。
ルーティング・ポリシーの例から適切な動作を得るためのデフォルトの回避策は、ルート・フィルターごとに個別の条件を設定することです。これは、次のように頻繁に行われます。
[edit policy-options]
policy-statement RouteFilter-A {
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
}
then accept;
}
term RouteFilter-2 {
from {
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
これで、RouteFilter-1一致条件には失敗するものの、新しいRouteFilter-2条件に一致するため、10.0.0.0/18ルートが受け入れられます(10.0.0.0/8 が最長一致で、orlonger条件は true です)。このアプローチの問題点は、複数のルート フィルターをグループ化した場合よりも、完全なルーティング ポリシーの評価に時間がかかることです。この方法では、メンテナンスもより複雑になります。
ルートフィルターごとに1項アプローチの問題は、ウォークアップステートメントと機能で解決されます。ウォークアップは、ルート フィルター評価のデフォルト動作をグローバルに変更するか、ポリシーごとに変更します。
ウォークアップ機能により、複数のルート フィルターを持つ条件では、最長一致のルートだけでなく、あまり限定的でないルートも含めて評価を「ウォークアップ」できます。つまり、ウォークアップ ノブは、デフォルトの動作を「1 つが失敗した場合は項が失敗する」から「1 つが一致する場合は項が一致する」に変更します。
ポリシーステートメントの例にウォークアップ機能を適用することを検討してください(設定されたすべてのポリシーにウォークアップをグローバルに適用することもできます)。
[edit policy-options]
policy-statement RouteFilter-A {
defaults {
route-filter walkup;
}
term RouteFilter-1 {
from {
route-filter 10.0.0.0/16 prefix-length-range /22-/24;
route-filter 10.0.0.0/8 orlonger;
}
then accept;
}
term default {
then reject;
}
}
これは、ルートプレフィックス 10.0.0.0/18 がポリシーステートメント RouteFilter-Aによって評価されると起こります。
デフォルトの動作は、ウォークアップノブによって変更されます。以前と同様に、10.0.0.0/16 は 10.0.0.0/8 よりも長いため、10.0.0.0/18ルートはより長く、より具体的なルート プレフィックスと一致し。前述のように、 10.0.0.0/18 ルートが prefix-length-range /22-/24 条件に一致しないため、この照合は失敗します。ただし、今回は「ウォークアップ」でプロセスを続行し、より限定的でないルート 10.0.0.0/8 フィルターを調べます。orlonger のルート条件はこのフィルターに一致するため、ルートはRouteFilter-1条件で受け入れられます。
これは、 show route protocol bgp 10.0.0.0/18 コマンドで(BGPルートについて)確認できます。今回は、ルートは非表示になりません。
ウォークアップ機能をグローバルに有効にした場合、 [edit policy-options policy-statements policy-statement-name defaults route-filter no-walkup] ステートメントを使用してポリシーごとにローカルで上書きできます。