ルーティング エンジンの冗長性について
概要 ルーティング エンジンの冗長性により、ネットワークの継続的な機能が確保されます。プライマリ ルーティング エンジンが(フェイルオーバーまたはスイッチオーバーのいずれかによって)オフラインになった場合、スタンバイのルーティング エンジンはすべてのルーティング機能を引き継ぎます。
ルーティング エンジン冗長性の概要
冗長ルーティング エンジンは、同じルーティング プラットフォームにインストールされた 2 つのルーティング エンジンです。一方はプライマリとして機能し、もう1つはプライマリルーティングエンジンに障害が発生した場合にバックアップとして機能します。デュアル ルーティング エンジンを搭載したルーティング プラットフォームでは、単一のルーティング エンジンを使用するルーティング プラットフォームよりも、ネットワークの再コンバージェンスが速くなります。
ルーティングエンジンがプライマリとして設定されている場合、全機能を備えています。ルーティング情報を受信して送信し、ルーティングテーブルを構築および維持し、インターフェイスおよびパケット転送エンジンコンポーネントと通信し、シャーシを完全に制御します。ルーティング エンジンがバックアップとして設定されている場合、ルーティング エンジンはパケット転送エンジンまたはシャーシ コンポーネントと通信しません。
Junos OSリリース8.4以降を実行しているデバイスでは、両方のルーティングエンジンを同時にプライマリに設定することはできません。この設定により、コミットチェックが失敗します。
プライマリールーティングエンジンからバックアップのルーティングエンジンへのフェイルオーバーは、プライマリルーティングエンジンにハードウェア障害が発生した場合、または特定の条件に基づいてプライマリロールの変更をサポートするようにソフトウェアを設定した場合に、自動的に発生します。また、いずれかのコマンドを発行することで、ルーティングエンジンのプライマリロールを手動で request chassis routing-engine 切り替えることもできます。このトピックでは、「 フェイルオーバー 」という用語は自動イベントを指し、 スイッチオーバー は自動イベントまたは手動イベントのいずれかを指します。
フェイルオーバーまたはスイッチオーバーが発生すると、バックアップルーティングエンジンは、新しいプライマリルーティングエンジンとしてシステムを制御します。
-
グレースフル ルーティング エンジン スイッチオーバーが設定されていない場合、バックアップ ルーティング エンジンがプライマリになると、スイッチ プレーンがリセットされ、マイクロケルネルの独自バージョンがパケット転送エンジン コンポーネントにダウンロードされます。パケット転送エンジンが再初期化されている間、トラフィックは中断されます。カーネルと転送プロセスはすべて再起動されます。
-
グレースフル ルーティング エンジン スイッチオーバーが設定されている場合、インターフェイスとカーネル情報が保持されます。パケット転送エンジンが再起動されないため、スイッチオーバーの速度が速くなります。新しいプライマリ ルーティング エンジンは、ルーティング プロトコル プロセス(rpd)を再起動します。すべてのハードウェアとインターフェイスは、ウォーム リスタートと同様のプロセスによって取得されます。
-
グレースフルルーティングエンジンのスイッチオーバーと ノンストップアクティブルーティング (NSR)が設定されている場合、スイッチオーバー中にトラフィックは中断されません。インターフェイス、カーネル、ルーティング プロトコルの情報が保持されます。
-
グレースフル ルーティング エンジン スイッチオーバーとグレースフル リスタートが設定されている場合、トラフィックはスイッチオーバー中に中断されません。インターフェイスとカーネル情報が保持されます。グレースフル リスタート プロトコル拡張機能は、隣接するルーターからルーティング情報を迅速に収集して復元します。
ルーティング エンジンのフェイルオーバーをトリガーする条件
以下のイベントにより、設定に応じてルーティング エンジンのプライマリ ロールが自動的に変更される場合があります。
-
ルーティング プラットフォームにハードウェア障害が発生します。ルーティング エンジンまたは関連するホスト モジュールまたはサブシステムのいずれかが突然電源をオフにした場合、ルーティング エンジンのプライマリ ロールの変更が発生します。また、プライマリ ルーティング エンジンでハード ディスク エラーが検出された場合に、バックアップ のルーティング エンジンがプライマリロールを受け取るように設定することもできます。この機能を有効にするには、 階層レベルで
failover on-disk-failureステートメントを[edit chassis redundancy]含めます。 -
ルーティング プラットフォームでは、カーネル のクラッシュや CPU ロックなどのソフトウェア障害が発生します。キープアライブ信号の損失を検出する際に、バックアップのルーティングエンジンが主な役割を果たすよう設定する必要があります。このフェイルオーバー方法を有効にするには、 階層レベルで
failover on-loss-of-keepalivesステートメントを[edit chassis redundancy]含めます。 -
ルーティング プラットフォームでは、プライマリ ルーティング エンジンで em0 インターフェイス障害が発生します。バックアップのルーティング エンジンが em0 インターフェイスの障害を検出した場合に、プライマリロールを受け取るように設定する必要があります。このフェイルオーバー方法を有効にするには、 階層レベルで
on-re-to-fpc-staleステートメントを[edit chassis redundancy failover]含めます。 -
特定のソフトウェア プロセスが失敗します。1 つ以上の指定されたプロセスが 30 秒以内に少なくとも 4 回失敗した場合に、プライマリロールを受け取るようにバックアップルーティングエンジンを設定できます。階層レベルに
failover other-routing-engineステートメントを[edit system processes process-name]含めます。
これらの条件のいずれかが満たされた場合、メッセージがログに記録され、バックアップルーティングエンジンがプライマリロールを受け取ろうとします。デフォルトでは、バックアップのルーティングエンジンがアクティブになるとアラームが生成されます。バックアップ ルーティング エンジンがプライマリロールを受け取った後、元に設定されたプライマリ ルーティング エンジンが正常に動作を再開した後でも、プライマリとして機能し続けます。手動で以前のバックアップステータスに復元する必要があります。(ただし、いつでも 1 つのルーティング エンジンが存在しない場合、冗長性の設定方法に関係なく、もう一方のルーティング エンジンは自動的にプライマリになります)。
デフォルトのルーティング エンジン冗長性の動作
デフォルトでは、Junos OSはプライマリルーティングエンジンとして re0 を使用し、バックアップルーティングエンジンとして re1 を使用します。設定で特に指定されていない限り、 re0 は、動作するプライマリルーティングエンジンが再起動されたときに常にプライマリになります。
シャーシ内の 1 つのルーティング エンジンは、以前はバックアップ ルーティング エンジンであったとしても、常にプライマリ ルーティング エンジンになります。
以下の手順を実行して、デフォルトのルーティング エンジン冗長性設定の仕組みを確認します。
-
re0 がプライマリ ルーティング エンジンであることを確認します。
-
プライマリー ルーティング エンジンから コマンドを発行して、ルーティング エンジン プライマリ ロールの
request chassis routing-engine master switch状態を手動で切り替えます。 re0 はバックアップ ルーティング エンジンになり、 re1 はプライマリ ルーティング エンジンです。メモ:プライマリールーティングエンジンの次回の再起動時に、Junos OSは再起動後にこの状態を維持するようにルーティングエンジンを設定していないため、ルーターをデフォルトの状態に戻します。
-
プライマリ ルーティング エンジン re1 を再起動します。
ルーティング エンジンが起動し、設定を読み取ります。ルーティング エンジンがプライマリである設定で指定されていないため、 re1 はデフォルト設定をバックアップとして使用します。 re0 と re1 の両方がバックアップ状態になりましたJunos OSはこの競合を検出し、プライマリ状態を防ぐために、 re0 をプライマリにすることを指示するデフォルト設定に戻します。
TX マトリクス ルーターでのルーティング エンジン冗長化
ルーティング マトリクスでは、TX Matrixルーターと接続されたT640ルーターのすべてのプライマリルーティングエンジンが、同じJunos OSリリースを実行する必要があります。同様に、ルーティング マトリクス内のすべてのバックアップ ルーティング エンジンは、同じ Junos OS リリースを実行する必要があります。ルーティング マトリクス内のすべてのプライマリおよびバックアップルーティングエンジンで同じJunos OSリリースを実行すると、ルーティングマトリクス内のバックアップルーティングエンジンにプライマリロールが変更されても、ルーティングマトリクス内の他のシャーシのプライマリロールに変更はありません。
(TX マトリクスまたは TX マトリクス プラス ルーターのみに基づくルーティング マトリクス)ルーティング マトリクス内では、すべてのルーティング エンジンが同じ Junos OS リリースを実行することを推奨します。ルーティング エンジンで異なるリリースを実行し、TX Matrix ルーターまたは TX Matrix Plus ルーターに基づくルーティング マトリクス内のバックアップ ルーティング エンジンでプライマリ ロールの変更が発生した場合、1 つまたはすべてのルーターが TX Matrix ルーターまたは TX Matrix Plus ルーターから論理的に切断され、データ 損失が発生する可能性があります。
ルーティング マトリクス内のすべてのプライマリおよびバックアップルーティングエンジンで同じJunos OSリリースが実行されていない場合、 階層レベルに含まれる[edit chassis redundancy]ステートメントisが発生するとfailover on-loss-of-keepalives、以下の結果が発生します。
-
ステートメントが
failover on-loss-of-keepalives階層レベルに[edit chassis redundancy]含まれ、あなたまたはホストサブシステムがTX Matrixルーターのバックアップルーティングエンジンへのプライマリロールの変更を開始すると、T640ルーターのプライマリルーティングエンジンは、ソフトウェアリリースとTX Matrixルーターの新しいプライマリルーティングエンジンの不一致を検出し、バックアップルーティングエンジンへのプライマリロールをスイッチします。 -
コマンドを使用して
request chassis routing-engine masterT640ルーターのバックアップルーティングエンジンにプライマリロールを手動で変更すると、T640ルーターの新しいプライマリルーティングエンジンが、TX Matrixルーターのプライマリルーティングエンジンと一致しないソフトウェアリリースを検出し、元のプライマリルーティングエンジンにプライマリロールを放棄します。(この場合、TX マトリクス ルーターのルーティング エンジン プライマリ ロールは切り替えません)。 -
ホスト サブシステムが、プライマリ ルーティング エンジンに障害が発生したために、T640 ルーターのバックアップ ルーティング エンジンにプライマリ ロールの変更を開始すると、T640 ルーターは TX Matrix ルーターから論理的に切断されます。T640ルーターに再接続するには、TX Matrixルーターのバックアップルーティングエンジンにプライマリロールの変更を開始するか、T640ルーターの障害ルーティングエンジンを交換し、プライマリロールをスイッチに置き換えます。置換ルーティング エンジンは、TX Matrix ルーターのプライマリ ルーティング エンジンと同じソフトウェア リリースを実行している必要があります。
ルーティング マトリクス内のすべてのプライマリおよびバックアップルーティングエンジンで同じJunos OSリリースが実行されていない場合、 階層レベルに含まれる[edit chassis redundancy]ステートメントis notが発生するとfailover on-loss-of-keepalives、以下の結果が発生します。
-
TX Matrix ルーターのバックアップ ルーティング エンジンにプライマリ ロールの変更を開始すると、すべての T640 ルーターが TX Matrix ルーターから論理的に切断されます。T640ルーターを再接続するには、T640ルーター内のすべてのプライマリルーティングエンジンのプライマリロールをバックアップルーティングエンジンに切り替えます。
-
T640ルーターでプライマリロールのバックアップルーティングエンジンに変更を開始すると、T640ルーターはTXマトリクスルーターから論理的に切断されます。T640ルーターに再接続するには、T640ルーターの新しいプライマリルーティングエンジンのプライマリロールを元のプライマリルーティングエンジンに戻します。
TX マトリクス プラス ルーターでのルーティング エンジン冗長化
ルーティング マトリクスでは、TX Matrix Plusルーターと接続されたLCC内のすべてのプライマリルーティングエンジンが、同じJunos OSリリースを実行する必要があります。同様に、ルーティング マトリクス内のすべてのバックアップ ルーティング エンジンは、同じ Junos OS リリースを実行する必要があります。ルーティング マトリクス内のすべてのプライマリおよびバックアップルーティングエンジンで同じJunos OSリリースを実行すると、ルーティングマトリクス内のバックアップルーティングエンジンにプライマリロールが変更されても、ルーティングマトリクス内の他のシャーシのプライマリロールに変更はありません。
(TX マトリクスまたは TX マトリクス プラス ルーターのみに基づくルーティング マトリクス)ルーティング マトリクス内では、すべてのルーティング エンジンが同じ Junos OS リリースを実行することを推奨します。ルーティング エンジンで異なるリリースを実行し、TX Matrix ルーターまたは TX Matrix Plus ルーターに基づくルーティング マトリクス内のバックアップ ルーティング エンジンでプライマリ ロールの変更が発生した場合、1 つまたはすべてのルーターが TX Matrix ルーターまたは TX Matrix Plus ルーターから論理的に切断され、データ 損失が発生する可能性があります。
ルーティング マトリクス内のすべてのプライマリおよびバックアップルーティングエンジンで同じJunos OSリリースが実行されていない場合、 階層レベルに含まれるステートメントisが発生するとfailover on-loss-of-keepalives、以下のシナリオが[edit chassis redundancy]発生します。
-
ステートメントが
failover on-loss-of-keepalives階層レベルに[edit chassis redundancy]含まれ、あなたまたはホストサブシステムがTX Matrix Plusルーターのバックアップルーティングエンジンへのプライマリロールの変更を開始すると、接続されたLCCのプライマリルーティングエンジンは、ソフトウェアリリースとTX Matrix Plusルーターの新しいプライマリルーティングエンジンの不一致を検出し、バックアップルーティングエンジンにプライマリロールを切り替えます。 -
コマンドを使用して
request chassis routing-engine master、接続されたLCC内のバックアップルーティングエンジンにプライマリロールを手動で変更すると、接続されたLCCの新しいプライマリルーティングエンジンが、TX Matrix Plusルーターのプライマリルーティングエンジンと一致しないソフトウェアリリースを検出し、元のプライマリルーティングエンジンにプライマリロールを放棄します。(この場合、TXマトリクス プラス ルーターのルーティング エンジン プライマリ ロールはスイッチしません)。 -
ホスト サブシステムが、プライマリ ルーティング エンジンに障害が発生したために、接続された LCC のバックアップ ルーティング エンジンにプライマリ ロールの変更を開始すると、接続された LCC は TX Matrix Plus ルーターから論理的に切断されます。接続されたLCCに再接続するには、TX Matrix Plusルーターのバックアップルーティングエンジンにプライマリロールの変更を開始するか、接続されたLCCおよびスイッチのプライマリロールの障害が発生したルーティングエンジンを置き換えます。交換ルーティング エンジンは、TX Matrix Plus ルーターのプライマリ ルーティング エンジンと同じソフトウェア リリースを実行している必要があります。
ルーティング マトリクス内のすべてのプライマリおよびバックアップルーティングエンジンで同じJunos OSリリースが実行されていない場合、 階層レベルに含まれるステートメントis notが発生するとfailover on-loss-of-keepalives、以下のシナリオが[edit chassis redundancy]発生します。
-
TX Matrix Plusルーターでバックアップのルーティングエンジンにプライマリロールの変更を開始すると、接続されたすべてのLCCが論理的にTX Matrix Plusルーターから切断されます。接続されたLCCに再接続するには、接続されたLCC内のすべてのプライマリルーティングエンジンのプライマリロールをバックアップルーティングエンジンに切り替えます。
-
接続されたLCCのバックアップルーティングエンジンにプライマリロールの変更を開始すると、接続されたLCCは論理的にTXマトリクスプラスルーターから切断されます。接続されたLCCに再接続するには、接続されたLCCの新しいプライマリルーティングエンジンのプライマリロールを元のプライマリルーティングエンジンに戻します。
ルーティング エンジンの停止が必要な状況
2 つのルーティング エンジンを搭載したルーティング プラットフォームに電源を切る前に、またはプライマリ ルーティング エンジンを削除する前に、まずバックアップ ルーティング エンジンを停止してから、プライマリ ルーティング エンジンを停止する必要があります。それ以外の場合は、Junos OS を再インストールする必要がある場合があります。プライマリ ルーティング エンジンで コマンドを request system halt both-routing-engines 使用できます。このコマンドは、最初にプライマリ ルーティング エンジンをシャットダウンしてから、バックアップ ルーティング エンジンをシャットダウンします。バックアップルーティングエンジンのみをシャットダウンするには、バックアップルーティングエンジンで コマンドを発行 request system halt します。
プライマリ ルーティング エンジンを停止して、プライマリ ルーティング エンジンの電源をオフにしたり、取り外したりしない場合、プライマリ ルーティング エンジンからのキープアライブ信号の損失を検出する際にプライマリとして設定していない限り、バックアップ ルーティング エンジンは非アクティブのままになります。
ルーターを再起動するには、ルーティング エンジンの(イーサネット管理ポートではなく)コンソール ポートにログインする必要があります。プライマリ ルーティング エンジンのコンソール ポートにログインすると、システムが自動的に再起動します。バックアップのルーティング エンジンのコンソール ポートにログインした後、Enter キーを押して再起動します。
バックアップルーティングエンジンをアップグレードした場合、最初に再起動してから、プライマリルーティングエンジンを再起動します。