ルーティング ポリシー一致条件で使用するルート フィルターについて
ルート フィルターは、一致するプレフィックスの集合です。一致プレフィックスを指定する場合、特定のルートとの完全一致、またはより精度の低い一致を指定できます。リスト全体に適用される共通のアクションと、各プレフィックスに関連するアクションのいずれかを構成できます。
ルート フィルターの構成には、プレフィックスとプレフィックス長の設定が含まれるため、構成を進める前に、スーパーネッティングを含む IP アドレッシングと、ルート フィルターの評価方法について十分に理解しておいてください(ここでは、「 ルーティング ポリシーの一致条件」でルート フィルターがどのように評価されるかを参照)。
このセクションでは、以下のトピックについて説明します。
基数木
ルート フィルターの動作を理解するには、2 進数のマッチングに使われる基数木と呼ばれる(パトリシア トライまたは基数トライと呼ばれることもある)デバイスについて知っておく必要があります。基数木は、バイナリ ルックアップを使用して IP アドレス(ルート)を特定します。IP アドレスは、人間が理解しやすいようにドット付き 10 進数で表現された 32 ビットの数値であることに注意してください。これらの 8 ビットグループは、それぞれ 0 から 255 までの値を持つことができます。基数木は、これらの 2 進数を図式化したものにすることができます。
図1では、基数木は設定されていない値で始まり(0から始まる)、バイナリIPアドレスの左端の位置にあります。これは 0/0 と表示され、しばしばデフォルト ルートと呼ばれます。
これは 2 進法であるため、各ビットは 2 つの値(0 または 1)のうちの 1 つしか持つことができません。左側の枝を下に移動すると値 0 を表し、右に移動すると値 1 を表します。最初のステップを 図2に示します。最初の位置では、IP アドレスの最初のオクテットは、それぞれ 00000000 または 10000000(つまり 0 または 128)の値を持っています。これを 図2 では、0/1と128/1の値で表されています。
第 2 ステップを 図 3 に示します。この第 2 レベルの木には、最初のオクテットで 00000000、01000000、10000000、11000000 の 4 つの 2 進数値があります。これらの 10進数の 0、64、128、192 は、基軸木上の 0/2、64/2、128/2、192/2 の IP アドレスで表されます。
このステップごとのプロセスを合計 33 レベルにわたって継続し、指定可能なすべての IP アドレスを表します。
基数木構造は、最上位ビットがすべて同じであるルート グループを見つけるのに役立ちます。 図4 は、192.168.0.0/16ネットワークを表す基数木内のポイントを示しています。192.168.0.0/16 より具体的なルートはすべて、ハイライト表示されています。
ルート フィルターの設定
「ルート フィルターの設定」のトピックでは、Junos OS のデフォルトの動作について説明します。このトピックでは取り上げませんが、ウォークアップ機能は、ルーターが同じ条件内で構成されたより短い一致条件を考慮できるようにすることで、このトピックで説明した評価結果を変化させます。詳細については、「 ルート フィルターのウォークアップ の概要」を参照してください。
ルート フィルターを構成するには、1 つ以上の route-filter または source-address-filter ステートメントを含めます。
[edit policy-options policy-statement policy-name term term-name from]
route-filter destination-prefix match-type {
actions;
}
通常、 route-filter オプションは、受信したルートアドレスを、ユニキャスト送信元アドレスを除くあらゆるタイプの宛先一致プレフィックスにマッチングするために使用されます。
destination-prefixアドレスは、prefix/prefix-lengthとして指定されたIPバージョン4(IPv4)またはIPバージョン6(IPv6)アドレスのプレフィックスです。IPv4 プレフィックスの prefix-length を省略した場合、デフォルトは /32 になります。IPv6 のプレフィックスで prefix-length を省略した場合、デフォルトは /128 になります。from ステートメントで指定されたプレフィックスは、すべての IPv4 アドレスまたはすべての IPv6 アドレスのいずれかである必要があります。
通常、 source-address-filter オプションは、マルチプロトコルBGP(MBGP)およびマルチキャストソース検出プロトコル(MSDP)環境において、受信ルートアドレスをユニキャスト送信元アドレスとマッチングするために使用されます。
source-address-filter source-prefix match-type {
actions;
}
source-prefix address は、 prefix/prefix-length として指定された IPv4 または IPv6 アドレスのプレフィックスです。IPv4 プレフィックスで prefix-length を省略した場合、デフォルトは /32prefix-length になります。IPv6 のプレフィックスで prefix-length を省略した場合、デフォルトは /128 になります。 from ステートメントで指定されたプレフィックスは、すべてのIPv4アドレスまたはすべてのIPv6アドレスのいずれかである必要があります。
match-type は、送信元または宛先のプレフィックスに適用する一致のタイプです。 これは、表1に示す一致タイプのいずれかにすることができます。さまざまなルートを提示した場合の一致タイプと結果の例については、 表 2 を参照してください。
actions は、ルートアドレスが宛先一致プレフィックス( route-filter オプションの一部として指定)または送信元一致プレフィックス( destination-address-filter オプションの一部として指定)で指定された基準に一致した場合に取るべきアクションです。アクションは、 ルーティングポリシー用語のアクションに記載されている1つ以上のアクションで構成できます。
ルート フィルターでは、2 つの方法でアクションを指定できます。
-
route-filterまたはsource-address-filterオプション内—これらのアクションは、一致が発生した直後に実行され、thenステートメントは評価されません。 -
thenステートメント内 - これらのアクションは一致の発生後に実行されますが、route-filterまたはsource-address-filterオプションにはアクションは指定されません。
uptoとprefix-length-rangeの一致タイプは、最上位ビットを指定し、一致可能なプレフィックス長の範囲を提供するという点で類似しています。違いは、uptoではプレフィックス長の範囲に上限のみを指定できるのに対し、prefix-length-rangeでは下限と上限の両方を指定できる点です。
これらのルート フィルター一致タイプのその他の例については、「 ルート フィルターの例」を参照してください。
| 一致タイプ |
一致条件 |
|---|---|
|
|
以下はすべて真です。
注:
最長一致ルックアップがルート フィルター上で実行されると、ルックアップは このルート フィルター一致タイプの詳細については、「 アドレス マスク一致タイプの評価方法」を参照してください。
|
|
|
以下はすべて真です。
|
|
|
以下はすべて真です。
|
|
|
以下はすべて真です。
|
|
|
以下はすべて真です。
|
|
|
以下はすべて真です。
ほとんどのルーティングポリシー設定では、 |
|
|
以下はすべて真です。
|
図 5 は、ルート 192.168.0.0/16 の詳細な基数木を示しています。
図6 と 表2 は、さまざまなルートフィルター一致タイプの動作を示しています。
| プレフィックス |
192.168/16 正確な |
192.168/16 長い |
192.168/16 以上 |
192.168/16 最大/24 |
192.168/16 prefix-length-range/18 – /20 |
192.168/16〜192.168.16/20 |
192.168/19アドレスマスク255.255.0.0 |
|---|---|---|---|---|---|---|---|
| 10.0.0.0/8 |
– |
– |
– |
– |
– |
– |
– |
| 192.168.0.0/16 |
マッチ |
– |
マッチ |
マッチ |
– |
マッチ |
– |
| 192.168.0.0/17 |
– |
マッチ |
マッチ |
マッチ |
– |
マッチ |
– |
| 192.168.0.0/18 |
– |
マッチ |
マッチ |
マッチ |
マッチ |
マッチ |
– |
| 192.168.0.0/19 |
– |
マッチ |
マッチ |
マッチ |
マッチ |
マッチ |
マッチ |
| 192.168.4.0/24 |
– |
マッチ |
マッチ |
マッチ |
– |
– |
– |
| 192.168.5.4/30 |
– |
マッチ |
マッチ |
– |
– |
– |
– |
| 192.168.12.4/30 |
– |
マッチ |
マッチ |
– |
– |
– |
– |
| 192.168.12.128/32 |
– |
マッチ |
マッチ |
– |
– |
– |
– |
| 192.168.16.0/20 |
– |
マッチ |
マッチ |
マッチ |
マッチ |
マッチ |
– |
| 192.168.192.0/18 |
– |
マッチ |
マッチ |
マッチ |
マッチ |
– |
– |
| 192.168.224.0/19 |
– |
マッチ |
マッチ |
マッチ |
マッチ |
– |
マッチ |
| 10.169.1.0/24 |
– |
– |
– |
– |
– |
– |
– |
| 10.170.0.0/16 |
– |
– |
– |
– |
– |
– |
– |
ルーティング ポリシー一致条件でルート フィルターが評価される方法
ルート フィルターの評価時に、ポリシー フレームワーク ソフトウェアは各ルートの送信元アドレスとルート フィルターの宛先プレフィックスを比較します。評価は 2 つのステップで行われます。
-
ポリシー フレームワーク ソフトウェアは、最長一致ル ックアップを実行します。つまり、ソフトウェアはリストの中で最長のプレフィックスを検索します。
最長一致ルックアップでは、構成済みの一致プレフィックスの
prefixコンポーネントとprefix-lengthコンポーネントのみが考慮され、match-typeコンポーネントは考慮されません。以下のルート フィルター例は、この点を示しています。from { route-filter 192.168.0.0/14 upto /24 reject; route-filter 192.168.0.0/15 exact; } then accept;候補ルート 192.168.1.0/24 の最長一致は、プレフィックスとプレフィックス長のみに基づく 2 番目のルートフィルター 192.168.0.0/15 です。
-
受信したルートがプレフィックスに一致する場合(長いものから順に)、以下のアクションが発生します。
-
ルート フィルターは、一致タイプが失敗しても、他のプレフィックスの評価を停止します。
-
ソフトウェアは、そのプレフィックスに関連する一致タイプとアクションを調べます。
-
ルート送信元アドレスが address-mask 一致タイプを使用する一致条件に対して評価される場合、評価の両方のステップに構成済みのネットマスク値が含まれます。詳細については、「 アドレス マスク一致タイプの評価方法」を参照してください。
ステップ 1 で、ルート 192.168.1.0/24 が評価された場合、マッチングは失敗します。最長プレフィックスである 192.168.0.0/15 には一致しますが、 exactには一致しません。プレフィックスに一致したためルート フィルターは終了しますが、一致タイプに失敗したため、結果は一致失敗となります。
一致が発生した場合、プレフィックスで指定されたアクションが実行されます。プレフィックスでアクションが指定されていない場合は、 then ステートメントのアクションが実行されます。どちらの動作も指定されていない場合、次の項またはルーティングポリシーがあればそれを評価するか、デフォルト・ポリシーで指定された accept または reject のアクションを実行します。デフォルトのルーティングポリシーの詳細については、 デフォルトのルーティングポリシーを参照してください。
ルート フィルターに複数のプレフィックスを指定した場合、1 つのプレフィックスにのみ一致すれば、一致が発生します。ルート フィルターのマッチングは、事実上、論理 OR 演算です。
一致が発生しない場合、ソフトウェアは次の項またはルーティングポリシーを評価する(存在する場合)か、デフォルト ポリシーで指定された accept または reject アクションを実行します。
例えば、プレフィックス 192.168.254.0/24 を以下のルート フィルターと比較してみましょう。
route-filter 192.168.0.0/16 orlonger; route-filter 192.168.254.0/23 exact;
プレフィックス 192.168.254.0/23 が最長プレフィックスと判断されます。ソフトウェアが 192.168.254.0/24 を最長プレフィックスに対して評価すると、一致が発生します(192.168.254.0/24 は 192.168.254.0/23 のサブセットです)。192.168.254.0/24 と最長プレフィックスが一致するため、評価は続行されます。ただし、ソフトウェアが一致タイプを評価すると、192.168.254.0/24 と 192.168.254.0/23 exact の間に一致が発生しません。ソフトウェアは、条件が一致しないと結論付け、次の条件またはルーティングポリシーがある場合はそれに進むか、デフォルト ポリシーで指定された accept または reject アクションを実行します。
ウォークアップ機能により、複数のルート フィルターを持つ条件では、最長一致のルートだけでなく、あまり限定的でないルートも含めて評価プロセスを「ウォークアップ」できます。つまり、ウォークアップを有効にすると、デフォルトの動作が「失敗する場合は条件が失敗する」から「一致する場合は条件が一致する」に変更されます。 ウォークアップ 機能の詳細については、「 ルート フィルターのウォークアップの概要」を参照してください。
プレフィックス順序によるルート フィルター評価への影響
ポリシー フレームワーク ソフトウェアは評価中に最長プレフィックスを探してルート フィルターをスキャンするため、通常は、プレフィックスを指定する順序(上から下へ)は重要ではありません。ただし、リスト内で同じ宛先プレフィックスを複数回使用する場合は例外です。この場合、同一プレフィックスのリストが上から下にスキャンされ、ルートに一致する最初の一致タイプが適用されるため、プレフィックスの順序が重要です。
ウォークアップ機能により、複数のルート フィルターを持つ条件では、最長一致のルートだけでなく、あまり限定的でないルートも含めて評価プロセスを「ウォークアップ」できます。つまり、ウォークアップを有効にすると、デフォルトの動作が「失敗する場合は条件が失敗する」から「一致する場合は条件が一致する」に変更されます。 ウォークアップ 機能の詳細については、「 ルート フィルターのウォークアップの概要」を参照してください。
次の例では、同じプレフィックスに対して異なるマッチタイプが指定されています。ルート 0.0.0.0/0 は拒否され、ルート 0.0.0.0/8 は next-hop self でマークされ、ルート 0.0.0.0/25 は拒否されます。
route-filter 0.0.0.0/0 upto /7 reject; route-filter 0.0.0.0/0 upto /24 next-hop self; route-filter 0.0.0.0/0 orlonger reject;
アドレス マスク一致タイプの評価方法
address-maskルーティングポリシー一致タイプでは、構成済みの宛先一致プレフィックスの長さに加え、構成済みのネットマスク値で受信する IPv4 または IPv6 ルート アドレスをマッチングできます。ルート フィルターの評価時に、address-mask 一致タイプは、構成済みのネットマスク値を考慮し、他の ルーティングポリシー 一致タイプとは異なる方法で処理されます。
-
最長一致ルックアップが
address-maskルーティングポリシー一致タイプを評価するとき、構成された一致プレフィックスのprefix-length成分は 考慮されません。代わりに、ルックアップでは、構成済みのネットマスク値に設定されている連続した上位ビットの数が考慮されます。 -
受信する IPv4 または IPv6 ルート アドレスを、
address-maskルーティングポリシー一致タイプを使用するルート フィルター一致条件に対して評価するとき、以下の値が同一であればマッチングに成功します。-
構成済みネットマスク値と受信する IPv4 または IPv6 ルート アドレスのビット単位論理 AND
-
構成済みネットマスク値と構成済み宛先一致プレフィックスのビット単位論理 AND
-
2 つの address-mask 一致タイプを含むルート フィルターの設定例については、 最長一致ルックアップを使用したアドレス マスク一致タイプの評価を参照してください。
最長一致ルックアップでよくある設定上の問題
ルート フィルターを定義する際によくある問題は、マッチングさせたい短いプレフィックスと、より長い類似のプレフィックスを同じリストに含めることです。例えば、プレフィックス 192.168.254.0/24 を以下のルート フィルターと比較するとします。
route-filter 192.168.0.0/16 orlonger; route-filter 192.168.254.0/23 exact;
ポリシー フレームワーク ソフトウェアは最長一致ルックアップを実行するため、プレフィックス 192.168.254.0/23 が最長プレフィックスと判断されます。192.168.254.0/24 と 192.168.254.0/23 の完全一致は発生しません。ソフトウェアは、条件が一致しないと判断し、次の条件またはルーティングポリシーがある場合はそれに進むか、デフォルト ポリシーで指定された accept または reject アクションを実行します。(デフォルトのルーティングポリシーの詳細については、 デフォルトのルーティングポリシーを参照してください)。マッチングさせたいと思っていた短いプレフィックス 192.168.0.0/16 orlonger は、誤って無視されます。
この問題の解決策の 1 つは、この条件内のルート フィルターからプレフィックス 192.168.0.0/16 orlonger を削除し、リスト内で唯一のプレフィックスまたは最長のプレフィックスである別の条件に移動させることです。
別の解決策は、 ウォークアップ 機能を有効にすることです。詳細については、「 ルート フィルターのウォークアップ の概要」を参照してください。
ルート フィルターの例
このセクションの例では、ルーティング ポリシーの断片のみを示します。通常、これらの断片は、他の条件やルーティング ポリシーと組み合わせて使用します。
すべての例において、以下のアクションは非一致ルートに適用されることに留意してください。
-
次の条件を評価します(存在する場合)。
-
次のポリシーを評価します(存在する場合)。
-
デフォルトポリシーで指定された
acceptまたはrejectアクションを実行します。デフォルトのルーティングポリシーの詳細については、 デフォルトのルーティングポリシーを参照してください。
以下の例は、さまざまな目的でルート フィルターを構成する方法を示しています。
- 特定の宛先プレフィックスとマスク長を持つルートを拒否する
- マスク長が 8 より大きいルートを拒否する
- マスク長が 26〜29 のルートを拒否する
- 特定のホストからのルートを拒否する
- 定義済みのプレフィックス セットを持つルートを受け入れる
- 定義済みのプレフィックス セットを持つルートを拒否する
- 24 ビットより長いプレフィックスを持つルートを拒否する
- PIM マルチキャスト トラフィックの参加を拒否する
- PIM トラフィックを拒否する
- ルート アドレスと宛先一致プレフィックスにアドレス マスクを適用して、受信する IPv4 ルートを受け入れる
- 類似のパターンでプレフィックス長の異なる受信 IPv4 ルートを受け入れる
- 最長一致ルックアップを使用したアドレス マスク一致タイプの評価
特定の宛先プレフィックスとマスク長を持つルートを拒否する
宛先プレフィックスが 0.0.0.0 で、マスク長が 0 〜8 の ルートを拒否し、それ以外のルートをすべて受け入れます。
[edit]
policy-options {
policy-statement policy-statement from-hall2 {
term 1 {
from {
route-filter 0.0.0.0/0 upto /8 reject;
}
}
then accept;
}
}
マスク長が 8 より大きいルートを拒否する
マスクが /8 以上(つまり /8、/9、/10 など)のルートで、最初の 8 ビットが 0 に設定され ているものは拒否し、8 ビット未満のルートは受け入れます。
[edit]
policy-options {
policy-statement from-hall3 {
term term1 {
from {
route-filter 0/0 upto /7 accept;
route-filter 0/8 orlonger;
}
then reject;
}
}
}
マスク長が 26〜29 のルートを拒否する
宛先プレフィックスが 192.168.10/24 で、マスクが /26〜/29 のルートを拒否し、それ以外のルートを受け入れます。
[edit]
policy-options {
policy-statement from-customer-a {
term term1 {
from {
route-filter 192.168.10/24 prefix-length-range /26–/29 reject;
}
then accept;
}
}
}
特定のホストからのルートを拒否する
特定のホストからのルート範囲を拒否し、それ以外のルートを受け入れます。
[edit]
policy-options {
policy-statement hosts-only {
from {
route-filter 10.125.0.0/16 upto /31 reject;
route-filter 0/0;
}
then accept;
}
}
ほとんどのルーティングポリシー設定では、 through 一致タイプは使用しません。 through は、完全一致の連続したセットをグループ化するためのツールと考えるべきです。例えば、4 つの完全一致を指定する代わりに、次のようにします。
from route-filter 0.0.0.0/1 exact from route-filter 0.0.0.0/2 exact from route-filter 0.0.0.0/3 exact from route-filter 0.0.0.0/4 exact
以下の単一の一致で表現できます。
from route-filter 0.0.0.0/1 through 0.0.0.0/4
定義済みのプレフィックス セットを持つルートを受け入れる
限定されたプレフィックス セットを明示的に受け入れ(第 1 条件内で)、それ以外をすべて拒否します(第 2 条件内で)。
policy-options {
policy-statement internet-in {
term 1 {
from {
route-filter 192.168.231.0/24 exact accept;
route-filter 192.168.244.0/24 exact accept;
route-filter 192.168.198.0/24 exact accept;
route-filter 192.168.160.0/24 exact accept;
route-filter 192.168.59.0/24 exact accept;
}
}
term 2 {
then {
reject;
}
}
}
定義済みのプレフィックス セットを持つルートを拒否する
いくつかのプレフィックス グループを拒否し、残りのプレフィックスを受け入れます。
[edit policy-options]
policy-statement drop-routes {
term 1{
from { # first, reject a number of prefixes:
route-filter default exact reject; # reject 0.0.0.0/0 exact
route-filter 0.0.0.0/8 orlonger reject; # reject prefix 0, mask /8 or longer
route-filter 10.0.0.0/8 orlonger reject; # reject loopback addresses
}
route-filter 10.105.0.0/16 exact { # accept 10.105.0.0/16
as-path-prepend “1 2 3”;
accept;
}
route-filter 192.0.2.0/24 orlonger reject; # reject test network packets
route-filter 172.16.233.0/3 orlonger reject; # reject multicast and higher
route-filter 0.0.0.0/0 upto /24 accept; # accept everything up to /24
route-filter 0.0.0.0/0 orlonger accept; # accept everything else
}
}
}
}
24 ビットより長いプレフィックスを持つルートを拒否する
24 ビットより長いプレフィックスをすべて拒否します。このルーティングポリシーは、 export ステートメント内の一連のルーティングポリシーにインストールします。このフィルターの最初の条件は、プレフィックス長が 24 ビットまでのルートをすべて通過させます。2 番目の、名前のない用語は、それ以外をすべて否定します。
[edit policy-options]
policy-statement 24bit-filter {
term acl20 {
from {
route-filter 0.0.0.0/0 upto /24;
}
then next policy;
}
then reject;
}
この例で route-filter 0.0.0.0/0 upto /24 acceptを指定すると、一致するプレフィックスは直ちに受け入れられ、 export ステートメントの次のルーティングポリシーは決して評価されません。
用語 acl20 に then reject ステートメントを含めると、ポリシー フレームワーク ソフトウェアが用語の評価時に、then reject ステートメントに達する前に次のステートメントの評価に移るため、24 ビットを超えるプレフィックスは拒否されません。
PIM マルチキャスト トラフィックの参加を拒否する
ネイバーからの送信元宛先プレフィックスのプロトコル独立マルチキャスト(PIM)マルチキャスト トラフィックの参加を拒否するためのルーティングポリシーを設定します。
[edit]
policy-options {
policy-statement join-filter {
from {
neighbor 10.14.12.20;
source-address-filter 10.83.0.0/16 orlonger;
}
then reject;
}
}
PIM トラフィックを拒否する
インターフェイスからの送信元宛先プレフィックスの PIM トラフィックを拒否するためのルーティングポリシーを設定します。
[edit]
policy-options {
policy-statement join-filter {
from {
interface so-1/0/0.0;
source-address-filter 10.83.0.0/16 orlonger;
}
then reject;
}
}
以下のルーティングポリシー修飾子がPIMに適用されます。
-
interface—参加を受信するインターフェイス -
neighbor- 結合の発信元である -
route-filter- グループアドレス -
source-address-filter—参加を拒否する送信元アドレス
PIM プロトコル定義への PIM 参加フィルターのインポートの詳細については、 Junos OS マルチキャスト プロトコル ユーザー ガイドを参照してください。
ルート アドレスと宛先一致プレフィックスにアドレス マスクを適用して、受信する IPv4 ルートを受け入れる
宛先プレフィックスが 10.1.0/24 で、3 バイト目が 0 〜 14 の偶数である受信 IPv4 ルートを受け入れます。
[edit]
policy-options {
policy-statement from_customer_a {
term term_1 {
from {
route-filter 10.1.0.0/24 address-mask 255.255.241.0;
}
then {
...
reject;
}
}
}
}
ルーティングポリシー条件 term_1 のルート フィルターは、以下の受信 IPv4 ルート アドレスに一致します。
-
10.1.0.0/24
-
10.1.2.0/24
-
10.1.4.0/24
-
10.1.6.0/24
-
10.1.8.0/24
-
10.1.10.0/24
-
10.1.12.0/24
-
10.1.14.0/24
ネットマスク値と候補ルート アドレスのビット単位論理 AND は、ネットマスク値と一致プレフィックス アドレスのビット単位論理 AND と一致する必要があります。つまり、ネットマスク ビット パターン 255.255.241.0 にセット ビットが含まれる場合、評価される受信 IPv4 ルート アドレスは、宛先プレフィックス アドレス 10.1.0.0/24 の対応するビットの値と一致する必要があります。
-
ネットマスク値の最初の 2 バイトは 2 進数 1111 1111 1111 1111 です。これは、最初の 2 バイトが 10.1 でない場合、候補ルート アドレスがマッチングに失敗することを意味します。
-
ネットマスク値の 3 バイト目は 2 進数 1111 0001 であり、3 バイト目が 15(10 進数)より大きいか奇数、またはその両方の場合、候補ルート アドレスはマッチングに失敗することを意味します。
-
一致プレフィックス アドレスのプレフィックス長は 24(10 進数)であり、プレフィックス長 が厳密に 24 でない場合、候補ルート アドレスはマッチングに失敗することを意味します。
例として、ポリシーでテストする候補ルート アドレスが 10.1.8.0/24(2 進数 0000 1010 0000 0001 0000 1000)である場合を考えましょう。
-
この候補ルート アドレスにネットマスク値を適用すると、2 進数 0000 1010 0000 0001 0000 0000 になります。
-
構成済みの宛先プレフィックス アドレスにネットマスク値を適用すると、2 進数 0000 1010 0000 0001 0000 0000 になります。
-
両方の AND 演算の結果が同じであるため、2 番目の一致条件まで一致が続きます。
-
候補アドレスと設定された宛先プレフィックス アドレスのプレフィックス長が同じ(24 ビット)なので、マッチングに成功します。
別の例として、ポリシーでテストする候補ルート アドレスが 10.1.3.0/24(2 進数 0000 1010 0000 0001 0000 0011)である場合を考えましょう。
-
この候補ルート アドレスにネットマスク値を適用すると、2 進数 0000 1010 0000 0001 0000 0001 になります。
-
ただし、構成済みの宛先プレフィックス アドレスにネットマスク値を適用すると、2 進数 0000 1010 0000 0001 0000 0000 になります。
-
2 つの AND 演算の結果が異なるため(3 バイト目)、マッチングは失敗します。
類似のパターンでプレフィックス長の異なる受信 IPv4 ルートを受け入れる
10.*.1/24 または 10.*.1.*/32 形式の受信 IPv4 ルート アドレスを受け入れます。
[edit]
policy-options {
policy-statement from_customer_b {
term term_2 {
from {
route-filter 10.0.1.0/24 address-mask 255.0.255.0;
route-filter 10.0.1.0/32 address-mask 255.0.255.0;
}
then {
...
reject;
}
}
}
}
ルート フィルター一致条件 10.0.1.0/24 address-mask 255.0.255.0 、10.*.1/24 形式の受信 IPv4 ルート アドレスに一致します。ルートのプレフィックス長は、正確に 24 ビットでなければならず、2 バイト目は任意の値で構いません。
ルート フィルター一致条件 10.0.1.0/32 address-mask 255.0.255.0 、10.*.1.*/32 形式の受信 IPv4 ルート アドレスに一致します。ルートのプレフィックス長は正確に 32 ビットでなければならず、2 バイト目と 4 バイト目は任意の値で構いません。
最長一致ルックアップを使用したアドレス マスク一致タイプの評価
この例では、2 つの address-mask 一致タイプを含むルート フィルターを最長一致ルックアップで評価する方法を示しています。以下のルーティングポリシー項で設定されたルート フィルター term_3 考えてみましょう。
[edit]
policy-options {
policy-statement from_customer_c {
term term_3 {
from {
route-filter 10.0.1.0/24 address-mask 255.0.255.0;
route-filter 10.0.2.0/24 address-mask 255.240.255.0;
}
then {
...
}
}
}
}
受信する IPv4 ルート送信元アドレス 10.1.1.0/24 が、ポリシー条件 term_3 で構成されているルート フィルターに対してテストされるとします。
-
term_3ルーティングポリシー期間の最長一致ルックアップツリーには、10.0.1.0/24 address-mask 255.0.255.0用プレフィックスと10.0.2.0/24 address-mask 255.240.255.0用プレフィックスの2つの一致プレフィックスが含まれています。候補の最長プレフィックス一致をツリーで検索する場合、最長一致ルックアップでは、構成済みのdestination-prefixの長さではなく、構成済みのnetmask-value内の連続した上位ビットの数が考慮されます。-
最初のルート フィルター一致条件では、ネットマスク値に 8 個の連続した上位ビットが含まれているため、最長一致ルックアップ エントリーは 10.0.0.0/8 になります。
-
2 番目のルート フィルター一致条件では、ネットマスク値に 12 個の連続した上位ビットが含まれているため、最長一致ルックアップ エントリーは 10.0.0.0/12 になります。
候補ルート アドレス 10.1.1.0/24 では、最長一致ルックアップにより、ルート フィルター一致条件
10.0.2.0/24 address-mask 255.240.255.0に対応するツリー エントリー 10.0.0.0/12 が返されます。 -
-
候補ルート アドレスに対して
term_3最長一致プレフィックスが識別されたため、候補ルート アドレスがルート フィルター一致条件10.0.2.0/24 address-mask 255.240.255.0に対して評価されます。-
受信する IPv4 ルート アドレス 10.1.1.0/24 をテストするために、ネットマスク値 255.240.255.0 が 10.1.1.0/24 に適用されます。結果は 10.0.1.0 になります。
-
構成済みの宛先プレフィックス アドレス 10.0.2.0/24 をテストするために、ネットマスク値 255.240.255.0 を 10.0.2.0/24 に適用します。結果は 10.0.2.0 になります。
-
結果が異なるため、ルート フィルターのマッチングは失敗します。一致条件または
thenステートメントのどちらで指定されても、アクションは実行されません。受信する IPv4 ルート アドレスは、他の一致条件に対しては評価されません。
-