Note: This is an Early Availability (EA) feature that is only available for limited release. For more information, contact your Cato Networks representative or send an email to ea@catonetworks.com.
概観
Catoは、BGPの設定変更によってソケットサイトへの影響を削減し、BGPセッションをリセットすることなく、BGPルーティング情報を更新します。 Catoは、サポートされているルートポリシーと広告変更を適用するために、可能な場合にはBGPソフトリセットメカニズムを使用し、BGPセッションを切断せずに行います。 これは、サポートされているBGP設定を編集する際にトラフィックの継続性を維持するのに役立ちます。ピアセッションが確立されたままで、ソケットはルートを更新またはリフレッシュできます。 ソフトリセットでは適用できない変更や、ピアが必要なBGP機能をサポートしていない場合、CatoはBGPセッションを切断して再確立するハードリセットを実行します。
この記事は、サポートされているサイトのソケットに対するBGPの設定変更をCatoがどのように処理し、どの変更がソフトリセットメカニズムを使用するか、どの変更がハードリセットを必要とするかを説明します。
サポートされているサイト
BGPのソフトリセットの動作は、ソケットサイトでサポートされています。
BGPリセットの動作の理解
ソケットサイトのためにBGP設定変更を保存するとき、Socketは変更のタイプを評価し、関連するBGPピアに対して最も影響の少ないサポートされたメカニズムを使用します。
SocketはBGPの変更に以下の方法で対処できます：
メカニズム | "説明" | 通常の影響 |
|---|---|---|
ルートリフレッシュ | ソケットはBGPピアにすべてのルートを再送するよう依頼し、それをソケットに宣伝することでソケットは更新されたインバウンドポリシーを適用します。 | BGPセッションは確立されたままです。 |
拡張ルートリフレッシュ | ソケットは、拡張ルートリフレッシュメカニズムを使用して、更新されたアウトバウンドルーティングテーブルをピアに送信します。 このメカニズムは、ルートリフレッシュの開始と終了をマークし、ピアが古くなったルートを識別し、広告されなくなったルートを削除できるようにします。 | BGPセッションは確立されたままです。 |
特定の更新メッセージ | 一部のアウトバウンド変更では、ソケットはアウトバウンド全体のルートテーブルをリフレッシュする必要はありません。 代わりに、影響を受けたルートのみを広告または撤回する目的で、ターゲットを絞ったBGP更新メッセージを送信します。 | BGPセッションは確立されたままです。 |
ハードリセット | ソケットはBGPセッションを切断して再接続します。 | BGPセッションが揺らぎます。 |
ルートリフレッシュ
ルートリフレッシュは、ソケットがピアから受け入れるルートに影響を与えるBGP設定変更に使用されます。 たとえば、BGPフィルタリングや受け入れられるルートの動作を変更した場合、ソケットはピアに関連するルートを再送信するよう依頼できます。
その後、ソケットは更新された設定に従って受信したルートを再評価します。 ピアがルートリフレッシュをサポートしている場合、BGPセッションは確立されたままです。
拡張ルートリフレッシュ
拡張ルートリフレッシュは、より複雑なアウトバウンドルート広告の変更に使用されます。 これらの変更は、ソケットがピアに広告するルーティング情報に影響を与えます。
拡張ルートリフレッシュでは、ソケットがリフレッシュされたルートテーブルの開始と終了を示す印を送信します。 ピアは以前に受け取ったルートを古いとマークし、リフレッシュされたルートテーブルを処理し、もはや広告されていないルートを削除できます。
ピアが拡張ルートリフレッシュをサポートしている場合、BGPセッションは確立されたままです。
特定の更新メッセージ
一部のアウトバウンド変更では、ソケットはアウトバウンドのルートテーブル全体をリフレッシュする必要はありません。 代わりに、影響を受けたルートに対する特定のBGP更新または撤回メッセージを送信します。
このメカニズムは、デフォルトルート広告やメトリックのように、ターゲットを絞ったルート更新として表現できる変更に使用されます。
ハードリセット
一部のBGP構成変更は、依然としてハードリセットを必要とします。 ソフトリセットメカニズムの1つでサポートされていない変更や、ピアが要求されるBGP機能をサポートしていない場合に、ハードリセットが発生します。
複数のBGP変更を一度に保存し、それらの1つがハードリセットを必要とする場合、Catoはハードリセットを実行し、ソフトリセットアクションも実行しません。
BGPの構成変更によるリセット動作
以下の表は、ソケットサイトのために保存された変更に対してCatoが使用するメカニズムにBGPの構成変更をマッピングします。
構成変更 | メカニズム |
|---|---|
ピアからのデフォルトルートを承認する | ルートリフレッシュ |
ピアからの動的ルートを承認する | ルートリフレッシュ |
許可されたサブネットのためのBGPフィルタリングルール | ルートリフレッシュ |
要約ルートを有効または無効にする | 拡張ルートリフレッシュ |
要約ルートの構成を変更する | 拡張ルートリフレッシュ |
BGPで広告されたトラフィックに対してNATを実行する | 拡張ルートリフレッシュ |
すべてのルートを広告する | 拡張ルートリフレッシュ |
デフォルトルートの広告 | 特定の更新メッセージ |
カスタムBGP範囲の有効化または無効化 | 特定の更新メッセージ |
カスタムBGP範囲構成の変更 | 特定の更新メッセージ |
BGPメトリックの変更 | 特定の更新メッセージ |
その他のBGP構成変更 | ハードリセット |
サポートされていないピア機能のフォールバック動作
ソフトリセットの動作は、セッション確立中にBGPピアによって交渉された能力に依存します。
ピアが構成変更に必要な機能をサポートしていない場合、Catoはハードリセットにフォールバックします：
必須機能 | 使用目的 | フォールバック動作 |
|---|---|---|
ルートリフレッシュ | 許可されたルートに影響を与える変更 | ピアがルートリフレッシュをサポートしていない場合のハードリセット |
拡張ルートリフレッシュ | 複雑なアウトバウンド広告の変更 | ピアが拡張ルートリフレッシュをサポートしていない場合のハードリセット |
特定の更新メッセージは、ソケットが影響を受けたルートのためのターゲットを絞ったBGP更新を送信するため、拡張ルートリフレッシュ能力を必要としません。
複数の変更を一度に保存
同時に複数のBGP構成変更を保存する際、Catoは優先順位のロジックを適用して、どのメカニズムを使用するかを決定します。
変更の組み合わせ | 結果 |
|---|---|
拡張ルートリフレッシュの変更と特定の更新の変更 | 拡張ルートリフレッシュのみが実行されます |
ソフトリセットの変更とハードリセットの変更 | ハードリセットが実行されます |
同じメカニズムを使用する複数のソフトリセットの変更 | 関連するソフトリセットメカニズムが実行されます |
複数のBGPピア
複数のBGPピアを持つサイトの場合、Catoは関連するピアセッションのために変更を評価します。 1つのピアに影響を与える変更は、関係のないピアセッションをリセットまたはリフレッシュする必要はありません。
保存された構成が複数のピアに異なる影響を与える場合、Catoは各ピアに関連するメカニズムを適用します。 例えば、1つのピアはハードリセットを必要とし、別のピアはソフトリセットメカニズムを使用します。