ルーティングポリシーの設定

ビルディングブロック: 基本的なフィルタリングルール

次に、他のポリシーによって参照されるポリシーについて説明します。お客様/ピア/伝送ごとに固有のものではなく、1回だけ定義する必要があります。

このセクションでは、実際のポリシーは示されていません。該当するプレフィックスリストとパスグループをカットアンドペーストして、この章の後のポリシーで使用することもできます。

Bogon 自律システム番号の拒否

BGP ルートアナウンスメントには、パスと呼ばれるフィールドが含まれています。これは、送信元の自律システム番号である宛先に到達するために、ルートアドバタイズを伝達するすべてのネットワークから構成される自律システム番号から成ります。

ルーティングテーブルに表示される AS パスは、各ネットワークがルートアドバタイズを伝達するたびに自動的に作成します。このパスには、独自の自律システム番号を付加します。最後に、ルーティングの決定に影響を与えるために、自律システム番号を手動で先頭に付加することができます。

RIRs によって割り当てられたパブリック自律システム番号に加えて、異なる目的に使用されるプライベート自律システム番号があります (プライベートピアリングは、RIR に割り当てられた自律システム番号を必要としないネットワークとの場合など)。

16ビット数に使用されるすべての自律システム番号 (0 から最大65535まで)。しかし、これらの日数は、32ビット自律システム番号が広くサポートされています。さまざまなタイプの自律システム num-bers は、以下のとおりです。

• 0: た

• 1 ~ 64495: パブリック自律システム番号

• 64496 ~ 64511: ドキュメントで使用するために予約済み

• 64512 ~ 65534: プライベート自律システム番号

• 65,535: た

• 42億 ~ 4294967294: 32ビットプライベート自律システム番号

プライベート自律システム番号のよく使用されるのは、上位ネットワークとの BGP セッションを確立するために、RIR によって割り当てられた自律システム番号を持たないネットワークの場合、このような数字がプライベートの自律システム番号リストからのものであるためです。この場合、誤りを簡単にすることができます。プライベートな自律システム番号は、「path」として公開されるようになっています。また、ネットワーク事業者が、希望する自律システム番号を誤って間違えて、受け取ったパスを汚染することもあります。そのため、プライベートまたは予約された自律システム番号を含むルートアドバタイズを拒否する必要があります。

Bogon 自律システム番号は、Rfc で定義されています。以下のリストは、どの RFC が bogon 自律システム番号を記述しているかを正確に示しています。そのため、特定の autono mous システム番号がセキュアルーティングテーブルに含まれていてはいけない理由については、該当する RFC を参照してください。

を定義 as-pathbogon 自律システム番号をリストするグループ:

そのためには、以下のコマンドを入力します。

これはまだ実際のポリシーではないことに注意してください。これらのプレフィックスリストを呼び出すポリシーを取得しています。そのため、いくつかの段落をお読みください。

このポリシーを使用すると、ルーターは外部から受信したルートにフィルターを適用します。これには、プライベート自律システム番号が含まれる場合があります。ネットワークからのプライベートな自律システム番号の通知 (送信) を回避するために、dfz オペレーションでは remove-privateEBGP セッションのオプションです。

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

すべての EBGP セッションでこのオプションが設定されていることを確認してください。

Bogon 接頭辞の拒否

Bogon プレフィックスは、内部使用 (RFC 1918)、テストネットワーク (RFC 4737)、マルチキャスト、その他の内部目的において、グローバルルーティングテーブルに表示されてはなりません。したがって、これらのプリフィックスは決して受け入れたり、DFZ に提供するべきではありません。

プレフィックスリストを作成するには、以下の手順に従います。

そのためには、以下のコマンドを入力します。

IPv6 コマンドの場合も同様です。

これらのプレフィックスリストを呼び出すポリシーを取得していますが、その他にもいくつかのパラグラフがあります。

長いプレフィックスを拒否

DFZ のグローバルルーティングテーブルは毎日拡張され、より多くのネットワークのプリフィックスの通知を開始しています。原則として、どのような長さ–のルートであっても、(1 つの IPv4 アドレスの場合は)/32 のルートを使用することで、問題が発生することはありません。しかし、ルーティングテーブルの制御されない成長は持続的ではありません (すべての IPv4 スペースが/32 としてアナウンスされた場合には、DFZ がどれだけ大きくなるかを計算するだけです)。多くのネットワークは、プレフィックス長でフィルタリングを開始しています。

通常、このお知らせは、/25 以上の接頭辞 (128 IPv4 アドレスのサブネット) を発表すると、削除されることを期待できます。次のポリシーでは、ネットワークが同じように設定されるので、このような pesky のリトル’/28 および32ルートは、すべてをリブにすることはできません。同様に、境界を/48 サブネットに配置した IPv6 にも適用されます。

このような長いプレフィックスのルートを選別するためのポリシーは、この章の後半で説明します。次の2つのステップで構成されています。呼び出される汎用ポリシーは、十分な長さのプレフィックスのみを返し、このリストを取得して、その一覧から関連ルートのみをフィルタリングするポリシーになります。

長さをパスとして拒否

ルート’上の各ネットワークでは、as path が“自動的”に作成され、独自の自律システム番号が、アドバタイズされたルートの正面に追加されるようになりました。デフォルトでは、BGP 最短パスを検索するため、ネットワークで使用しているアクティブなルートのほとんどは、1-6 自律システム番号としてのみのパスを持つことになります。場合によっては、パスが長くなることがあります。その後、手動でパスを先頭に (トラフィックエンジニアリングの基準として)、テーブルに長いパスが表示されるようになります。しかし、一般的に言えば、1 ~ 12 個の自律システム番号より長い AS path は、役に立たないと考えられます。このような「long AS」というパスが表示された場合は、ネットワーク管理者がこのガイドのコピーを必要としている可能性があります。

パスとして非常に長いのが最も一般的な理由は、その前に付加されます。必要に応じて、先頭に 2 ~ 3 回の固有の自律システム番号を使用して、ルートに影響を与える良い方法であると考えられます。しかし、それ以上には意味’がありません。この本の執筆時点では、DFZ には、AS パスの長さが約40の自律システム番号であるプレフィックスがいくつかあります。これは非常に良くわからないということです。’Deserving は安全なマージンを確保し、50以上のパスを持つすべてのものを考慮して、安全なルーティングテーブルでは役に立たず、を除外することを検討しています。

いつものように、まずフィルターを適用する対象を定義します。

その後、この定義を呼び出すポリシーについてご確認ください。あと1つの構成要素になります。

既知の転送または非常に大規模なネットワーク自律システム番号を含むルートを拒否します。

世界最大規模のネットワークは (主に階層“1”と呼ばれています)、お互いに、また“は小規模な”(tier 2) ネットワークから伝送を購入することはありません。たとえば、顧客や相手が AS path で AS2914 (NTT) または AS1299 (Telia) を使用してルートを送信し始めた場合、非常に奇妙になるかもしれません。NT t や Telia がお客様から転送を購入したということはほとんどありません。したがって、インポートポリシーには、その中の“大きな名前”の AS 番号を持つルートを拒否するパスフィルターも含まれています。お客様や同僚から合法的なものを受信する場合は、このガイドの対象読者ではないと考えられます。

Facebook、Google、Microsoft、Cloudflare など、その他の大規模ネットワークでも同じことが言えます。彼らは、おそらく同業者から輸送を購入していないので、ピアからルートを受け取った場合、 fishyが発生していることが必要になります。それでは、このような’ルートを使用していないことがわかったのはなぜでしょうか。

まず、AS’path group を定義してみましょう。

このポリシーをパスグループとして使用’することで、お客様や同僚が誤って漏洩しているルートを受け入れるのを防ぐことができます。これが大きな図にどのように対応するかについては後ほど紹介します。

このポリシーは、お客様とピア BGP セッションにのみ追加してください (転送する必要はありません)。また、最終的には、非常に小規模なルーティングテーブルを使用することになります。

剰余を拒否

デフォルトでは、BGP の Junos OS 実装の最後のアクションは、ポリシーの後に残されたものすべてを許可することです。Https://tools.ietf.org/html/rfc8212 で定義されているように、将来においてデフォルトの動作を設定して、準拠した BGP 状態を維持することができるようになります。しかし、本書を執筆する時点では、RFC8212’は実装されていませんでした。その後、その他のポリシーを却下するために、適切な方針を持っていることをご確認ください。

次のようなポリシーを定義して、表示されたすべてのルートを単純に拒否します。

または、切り取りと貼り付けのコマンドでは以下のようになります。

このポリシーは、ポリシーチェーンの最後に行われるプロトコル (BGP) に依存しないように、明示的な拒否を作成するために後で使用されます。設定を明確かつ明確にすることをお勧めします (最も人気のあるネットワーク管理者が午前4時にネットワーク停止のトラブルシューティングを行う必要があると考えてください)。

顧客ルートのフィルタリング

最後に、’実際のルーティングポリシーを設定しましょう。まず、顧客’から受信するルートをフィルタリングする方法と、デフォルトルートと完全なテーブルシナリオの両方で顧客へのルートを知らせるポリシーを設定する方法について見てみましょう。

顧客からのルートの受け入れ

お客様から許可されたルートを確認することは、ネットワークにおいて最も重要な構成です。最終的には、顧客’のルートを他の人に伝える必要があります。このよう–’なお知らせは、すっきりとして、正しいルーティング情報だけが含まれている必要があります。’この場合、ルートのみをクリアすることから開始します。その後、インターネットを停止させなければならないことを心配する必要があります。

顧客から受信したルートをフィルタリングするために使用するルーティングポリシーには、お客様が提供を許可されている接頭番号のリストが含まれています。この例では、プレフィックスリストを手動で設定しています’が、付録では、プレフィックスリストを自動更新する方法をご紹介します。このガイドを完了した後、顧客’のルートをフィルタリングするためにこの構成を使用’しても、ルーティングテーブルが安全になるように、自動プレフィックスリスト更新を実装することを忘れないでください。

以下の設定では、お’客様の192.0.2.0 が番号であることを前提としています。また、そのような場合は、123/24 と 2001: db8::/32 を発表します。また、所有者の番号は456であると仮定しています。

これらを設定するには、次のように入力します。

さらに、ポリシー’によって使用される2つの BGP コミュニティーと、後で必要となる1つのコミュニティを作成してみましょう。

破棄‘されたアンカールート’を作成してプリフィックスを発行する場合、このコミュニティを関連づけることができます。

これで、顧客’のルートを実際に受け入れるポリシーになります。そのためには、完全なプレフィックスを承諾することから開始されます。 prefix-list:

これを構成するには、以下のように入力します。

このポリシーは、すべてのお客様に固有の BGP ています。すべての接頭番号は、各 BGP のお客様にとって独自のものとして挙げられます。このインポートポリシーを BGP セッションに適用するには、インポートポリシーチェーンで顧客との連携を行います。

BGP コミュニティーを追加しました。 MYCUSTOMER顧客から受け入れられるルートへこれにより、後でこれらのルートを簡単にエクスポートできるようになります。

次に、顧客はより具体的な接頭語を伝えることができます。たとえば、接頭辞リストエントリーには/22 が定義されている場合がありますが、お客様に対しては、最大でも24を発表することを希望しています。簡単に使用 prefix-list-filter AS123 orlonger’お客様が最大で32を発表できるようになるため、機能しません。まず、最大/24 までのルートを許可するポリシーを作成し、それをポリシーと組み合わせることで、顧客のプレフィックスリスト内にある場合、これらのルートを許可します。

ことに注意してください policy-statement MORE-SPECIFIC-UPTO-24汎用–とは、ルーター上で1回だけ構成され、すべてのお客様に使用されることを示しています。こちらの policy-statement IMPORT-123は、各顧客に固有のものであり、顧客ごとに1回設定する必要があります。

これらのポリシーを設定するには、以下のように入力します。

ポリシーの MORE-SPECIFIC-UPTO-241回だけ定義する必要があります。顧客’の AS または接頭辞は、このポリシーで参照されるわけではありません。ポリシーの IMPORT-123顧客ごとに1回定義する必要があります。ただし、

IPv6 ポリシーには、まったく同じロジックが適用されます。これには、最大/48 のルートを受け付けることができます。

これを構成するには、以下のように入力します。

IPv4 ポリシーと同様に、ポリシー MORE-SPECIFIC-UPTO-48-INET61回だけ定義する必要があります。顧客’の AS または接頭辞は、このポリシーで参照されるわけではありません。ポリシーの IMPORT-123-INET6顧客ごとに1回定義する必要があります。ただし、

最後に、お客様がさらに具体的なルート–を、a/24 よりも詳細に通知するように選択することもできます。これらのルートを使用してトラフィックエンジニアリングを行うことができます。ネットワークで実行することもできますが、他のお客様やピア、またはその他の顧客に対して発表することはできません。このような理由で、これらを受け入れても、よく知られているものを追加します。“NO-EXPORT”BGP コミュニティー:

これを構成するには、以下のように入力します。

IPv6 の場合:

これを構成するには、以下のように入力します。

顧客’のルート’に対してインポートポリシーを定義したので、最終的な rejectお客様が発表できないルートを拒否するポリシーがあります。’ここでは、お客様からのルートのインポートに使用するポリシー全体を修正してい–ます。

BGP 構成

顧客ルートのインポートの最後の構成では、ポリシーを顧客との BGP セッションのインポートポリシーとして設定します。第1のポリシーは TRANSIT-CUSTOMER-GENERICはジェネリックであり、一度だけ定義する必要があります。2つ目のポリシーは、固有のものです。顧客ごとに3つのポリシーが連結されています。

1. 不要なルートを拒否する汎用ポリシー。

2. 顧客’のルートを受け入れる顧客固有のポリシー。

3. それ以外のすべてを拒否する最終的な拒否ポリシー。

例えば：

もう1つの顧客は以下のようになります。

お客様へのルートの発表

顧客はネットワーク’のルートを受信します。これにより、ネットワークを使用してトラフィックを送信できます。これは、完全なテーブルまたはデフォルトルートのどちらでもかまいません。顧客にデフォルトルートを送付する場合は、廃棄デフォルトルートを作成して、生成する必要があります。

テーブル全体とデフォルトルートのエクスポートの例をお読みになり、完全なテーブルとデフォルトルートを受信したいという顧客に対して、ポリシー catering を簡単に作成できるようになるはずです。

お客様への完全なテーブルの発表

テーブル全体を送信するためのポリシーは、見かけよりも複雑です。ルートをドロップする必要があります。 NO-EXPORTたとえば、コミュニティーです。’さらに、自社のネットワーク–が非常によく発生する間違いが発生したルートを受け入れるという用語を追加することは、実際の路線を含めず、ebgp (デフォルト BGP の動作) で学習したルートのみを送信することを忘れてはなりません。

または、カットアンドペースト形式では以下のようになります。

デフォルトのお客様への発表

デフォルトルートをお客様に送信するためのポリシーは簡単です。

または、切り取りと貼り付けのコマンドでは以下のようになります。

これは、ネットワークにすでにデフォルトルートがある場合に有効です。上記の警告をお持ちでない’場合は、そのことを忘れないでください。

BGP 構成

ルートを顧客にエクスポートするための最後の構成は、ポリシーを顧客との BGP セッションでのエクスポートポリシーとして設定することです。すべてのエクスポートポリシーは汎用であり、一度だけ定義する必要があります。お客様ごとに、次の2つのポリシーが連結されています。

1. デフォルトまたは完全なテーブルルートのどちらかを受け付ける汎用ポリシー。

2. それ以外のすべてを拒否する最終的な拒否ポリシー。

例えば：

もう1つの顧客は以下のようになります。

ピアリングルートのフィルタリング

ピアのポリシーは、顧客にとってはほとんど変わりませんが、それほどではありません。ピアについては、顧客と同じルートを拒否し、(自動的なプレフィックスフィルタリングが実装されている場合は) そのルートをセット内で受け入れます。もちろん、デフォルトルート、RPKI invalids、パス、および bogons は拒否されます。主な変更には、異なるローカル設定 (顧客ルートよりも低い) を使用し、ピアルートをエクスポートするための BGP コミュニティーを追加せず、/24 より長いプレフィックスを許可しないものがあります。

ピアからのルートの受け付け

これは、ピアからルートをインポートするポリシーステートメント全体を示しています。

または、カットアンドペースト形式では以下のようになります。

BGP 構成

ピアルートをインポートするための最後の構成では、ポリシーをピアとの BGP セッションのインポートポリシーとして設定します。第1のポリシーは PEER-GENERICはジェネリックであり、一度だけ定義する必要があります。2つ目のポリシーは、固有のものです。各ピアには3つのポリシーが連結されています。

1. 不要なルートを拒否する汎用ポリシー。

2. ピア’s ルートを受け入れるピア固有のポリシー。

3. それ以外のすべてを拒否する最終的な拒否ポリシー。

例えば：

ピアへのルートのアナウンス

お客様は、自社のルートと顧客のルートを受け取る必要があります。幸いなことに、BGP コミュニティを使用してこれらのルートをタグ付けしています。そのため、関連するポリシーステートメントを作成することが非常に簡単です。

または、カットアンドペースト形式では以下のようになります。

BGP 構成

ルートをピアにエクスポートするための最後の構成は、ポリシーをピアとの BGP セッションのエクスポートポリシーとして構成することです。すべてのエクスポートポリシーは汎用であり、一度だけ定義する必要があります。各ピアには、次の2つのポリシーが連結されています。

1. ルートと顧客ルートを受け入れる汎用ポリシー。

2. それ以外のすべてを拒否する最終的な拒否ポリシー。

例えば：

通過ルートのフィルタリング

中継プロバイダのポリシーは、ピアの場合とは少し異なりますが、それでもやはりそれほどではありません。トランザクションを転送するために、ピアと同じルートを拒否します。デフォルトルート、RPKI invalids、長距離 AS paths、および bogons。重要な変更は、 “ビッグネットワーク”からのルートを拒否するのではなく、異なるローカル設定 (ピアルートよりも低い) を使用し、通過ルートをエクスポートするための BGP コミュニティーを追加して、残りのルートすべてを拒否せずに受け入れるということではありません。

トランザクションの転送によるルートの受け入れ

これは、次のようなトランザクションからルートをインポートするポリシーステートメント全体です。

または、カットアンドペースト形式では以下のようになります。

BGP 構成

伝送ルートのインポートの最終部分は、伝送プロバイダとの BGP セッションのインポートポリシーとしてポリシーを設定することです。最初のポリシーである伝送汎用はジェネリックであり、1回だけ定義する必要があることに注意してください。2つ目のポリシーは、固有のものです。各伝送には、次の3つのポリシーが含まれています。

1. 不要なルートを拒否する汎用ポリシー。

2. 輸送’のルートを受け入れる伝送固有のポリシー。

3. それ以外のすべてを拒否する最終的な拒否ポリシー。

例えば：

トランザクションへの対応ルートを発表します。

さらに、自分のルートと顧客のルートを受信する必要があります。ここでは、ピアへのルートのエクスポートと同様に、BGP コミュニティを使用してこれらのルートにタグを付けているため、関連するポリシーステートメントを作成することが非常に簡単です。

また、カットアンドペースト形式でも次のようになります。

BGP 構成

ルートをトランジットエクスポートするための構成の最後の部分は、通過時に BGP セッションの輸出ポリシーとしてポリシーを設定することです。すべてのエクスポートポリシーは汎用であり、一度だけ定義する必要があります。各伝送には、次の2つのポリシーが連結されます。

1. ルートと顧客ルートを受け入れる汎用ポリシー。

2. それ以外のすべてを拒否する最終的な拒否ポリシー。

例えば：

まとめ

ポリシーの観点から見ると、ルーターはルートをフィルター処理し、セキュアなルーティングテーブルを作成し、顧客、ピア、中継事業者に BGP を伝えることができるようになりました。ネットワークが大きな形状になっている必要があります。よくやりましたね！

顧客、ピア、および中継セッションから発信されたルートをフィルタリングするポリシーを設定しなかったことに気付いたかもしれません。これは、目的に応じて、BGP によって、独自の通知を番号としてフィルター処理してループを回避するために使用されます。自分の接頭辞を含むルートアドバタイズメントを受信しても、別の番号から発信された場合、RPKI は ROAs を作成した場合にそれをフィルター処理します。しかし、すべての eBGP セッションで自分自身のルートを明示的に除外しても、それは問題ではありません。

次に、何かがうまくいっているかどうかを確認する方法と、’それができない場合の対処方法を示します。