Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

ルート フィルターのウォークアップの概要

複数のポリシー条件にルート フィルタが分割されているため、ポリシー パフォーマンスに懸念がある場合は、ウォークアップ機能を使用します。ウォークアップ機能により、1 つのポリシー条件でルート フィルタを統合できます。

デフォルトでは、Junos はポリシー ステートメント条件で複数のルート フィルタを評価し、最初に最長一致プレフィックスを見つけ、次にプレフィックス範囲などのルート フィルタにアタッチされた条件を評価します。ルート フィルタ条件が false の場合(たとえば、プレフィックスが指定された範囲に含まれていない場合)、ルート フィルタ プレフィックスが真に短くなる可能性がある場合でも、条件全体は false になります。この動作により、ルート フィルターが個別のポリシー ステートメント条件に分割されると、パフォーマンスの問題が発生する可能性があります。walkup 機能は、デフォルトのルート フィルタ動作を変更します。

一部の自動化ポリシー ツール(BGP(境界ゲートウェイ プロトコル)の自律システム 境界ルーターに使用されるツールなど)は、デフォルトのルート フィルタの動作により、ルート フィルタを複数の条件に分割します。ルート フィルターは、BGP 以外のルーティング プロトコルでも使用されます。ウォークアップ機能は BGP ルート フィルターに限定されません。

注:

技術的には、BGP は OSPF や IS-IS と同じ方法でルートを処理しません。BGP の「ルート」は、ネットワーク レイヤー到達可能性情報(NLRI)の更新と呼ばれます。ただし、「route」という用語はほとんどのドキュメントで使用され、ここで使用されます。

ルート フィルターは、次の 3 つの主要な部分で構成されています。

  1. プレフィックスとプレフィックスの長さ(たとえば) 10.0.0.0/8

  2. 照合条件 (たとえば、 exact)

  3. 前の部分(プレフィックスと照合条件)の両方が 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 アドレス スペースが使用されています。

ルート フィルターは、単一のポリシー ステートメント条件で組み合わせることができます。その場合、評価はより複雑になります。次のルーティング ポリシーを検討してください。

フィルターには、 10.0.0.0/8 orlonger そのスコープ内のフィルターが 10.0.0.0/16 prefix-length-range /22-/24 含まれています。つまり、 10.0.0.0 プレフィックスが 8 ビット以上のルートは、22 ビットから 24 ビットの範囲のプレフィックスを持つルートである可能性もあります。

デフォルトでは、複数のルート フィルターを使用するポリシー ステートメント条件の評価は、2 段階のプロセスです。

  1. ポリシー フレームワーク ソフトウェアは、プレフィックスとプレフィックスの長さの値に基づいて、リストで最長一致ルックアップを実行します。

  2. ソフトウェアはルート フィルタ条件(orlongerなど exact)を考慮します。ルートは、ルート フィルタ条件(成功)を満たすか、ルート フィルタ条件(障害)と一致しません。

これらの 2 つのステップの結果に基づいて、一致または失敗によって決定されたアクションがルートに適用されます。で Route-Filter-A、これは、「true」であるルートが受け入れられ、その用語の RouteFilter-1 「偽」であるルートが拒否されていることを意味します。このルートは非表示(フィルタリング)ルートになります。

たとえば、次のポリシー ステートメントRouteFilter-Aによってルート10.0.0.0/18が評価されたときに何が起こるかを考えてみましょう。

まず、 10.0.0.0/18 ルートは条件によって RouteFilter-1 評価されます。より長いため10.0.0.0/1610.0.0.0/810.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 以上のエントリーを持つバックボーン ルーティング テーブルでは、すべての可能なルートまたはネットワークに追加される可能性のあるすべての新しいルートに合わせて調整されたルート フィルタを設定することはできません。

ルーティング ポリシーの例から適切な動作を実現するための既定の回避策は、ルート フィルタごとに個別の条件を設定することです。これは、以下のように頻繁に行われます。

10.0.0.0/18この場合、ルートは引き続き一致条件にRouteFilter-1失敗しますが、新しいRouteFilter-2項(10.0.0.0/8最長一致であり、条件が真)に一致するため、このルートがorlonger受け入れられます。このアプローチの問題は、複数のルート フィルターがグループ化されている場合よりも、完全なルーティング ポリシーの評価に時間がかかることです。この方法では、メンテナンスも複雑になります。

ルートごとに 1 つの条件フィルターアプローチの問題は、walkup ステートメントと機能を使用して解決されます。Walkup は、ルート フィルタ評価のデフォルト動作をグローバルまたはポリシーごとに変更します。

walkup機能を使用すると、複数のルートフィルタを持つ条件を「ウォークアップ」して、評価プロセスに、より具体的でないルートと最長の一致を含めることができます。言い換えると、walkupノブはデフォルトの動作を「1つが失敗すると、条件が失敗する」から「1つが一致し、その後用語が一致する」に変更します。

ウォークアップ機能をポリシー ステートメントの例に適用することを検討します(設定されたすべてのポリシーにグローバルにウォークアップを適用することもできます)。

これは、ルート プレフィックス 10.0.0.0/18 がポリシー ステートメント RouteFilter-Aによって評価された場合に発生します。

既定の動作は、walkup ノブによって変更されます。以前と同様に、ルートは10.0.0.0/18長く、より具体的なルート プレフィックスと一致します。なぜなら、より長い10.0.0.0/8からです10.0.0.0/16。前述のように、ルートが条件と一致しないため、 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] ローカルに上書きできます。