Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
項目一覧
 

ルーティングエンジン冗長性の設定

以下の手順と例に従って、ルーティングエンジンの冗長性を設定します。

手記：

次のセクションのタスクを完了するには、 re0 および re1 設定グループを定義する必要があります。設定グループの詳細については、 Junos OS CLIユーザーガイドを参照してください。

デフォルト ルーティングエンジン プライマリ ロールの変更

ルーティング エンジンを 2 つ搭載したルーターでは、どちらのルーティングエンジンをプライマリで、どちらをバックアップのルーティング エンジンにするかを設定できます。デフォルトでは、スロット0のルーティングエンジンがプライマリ(re0)で、スロット1のがバックアップ(re1)です。

手記：

ルーティングエンジンを2台搭載したシステムでは、両方のルーティングエンジンを同時にプライマリに設定することはできません。この設定では、コミット・チェックが失敗します。

デフォルトの設定を変更するには、[edit chassis redundancy]階層レベルでrouting-engineステートメントを含めます。

slot-number は 0 または 1 です。ルーティングエンジンをプライマリとして設定するには、 master オプションを指定します。バックアップとして設定するには、 バックアップ オプションを指定します。ルーティングエンジンを無効にするには、 disabled オプションを指定します。

手記：

プライマリとバックアップのルーティングエンジンを切り替えるには、 ルーティングエンジンのプライマリロールの手動切り替えを参照してください。

バックアップ ルーティングエンジンへの自動フェイルオーバーの設定

以下のセクションでは、プライマリ ルーティングエンジンで特定の障害が発生した場合に、バックアップ ルーティングエンジンへの自動フェイルオーバーを設定する方法について説明します。

パケット転送を中断することなく

ルーティングエンジンを2つ搭載しているルーターでは、グレースフルルーティングエンジンスイッチオーバー(GRES)を設定できます。グレースフルスイッチオーバーが設定されている場合、ソケットの再接続はパケット転送を中断することなくシームレスに行われます。グレースフル ルーティングエンジン スイッチオーバーの設定方法については、「 グレースフル ルーティングエンジン スイッチオーバーの設定」を参照してください。

プライマリ ルーティングエンジンのハード ディスク エラー検出時

バックアップ ルーティングエンジンを構成した後に、プライマリ ルーティングエンジンからハード ディスク エラーが検出された場合、自動的にプライマリ ロールを担うように指示できます。この機能を有効にするには、[edit chassis redundancy failover]階層レベルでon-disk-failureステートメントを含めます。

手記：

[edit chassis redundancy]階層レベルのon-disk-failureステートメントは、Junos Evolvedを実行しているPTXプラットフォームではサポートされていません。これらのプラットフォームでは、ディスク障害が検出されると、デフォルトで切り替わります。

VMとRE間の壊れたLCMD接続の検出時

VM と RE 間の LCMD 接続が切断されたときに RE が自動的にスイッチオーバーされるように、次の構成を設定します。この機能を有効にするには、[edit chassis redundancy failover]階層レベルでon-loss-of-vm-host-connectionステートメントを含めます。

LCMD プロセスがプライマリでクラッシュしている場合、バックアップ RE LCMD 接続が安定していれば、システムは 1 分後にスイッチオーバーします。バックアップRE LCMD接続が不安定な場合、または現在のプライマリがプライマリロールを取得したばかりの場合、システムはスイッチオーバーしません。プライマリがプライマリロールを取得したばかりの場合、スイッチオーバーは 4 分後にのみ行われます。

プライマリ ルーティングエンジン からのキープアライブ信号損失の検出について

バックアップ ルーティングエンジン を設定した後、プライマリ ルーティングエンジンからのキープアライブ信号の損失を検出した場合、自動的にプライマリ ロールを担うように指示できます。

キープアライブ損失信号の受信時にフェイルオーバーを有効にするには、[edit chassis redundancy failover]階層レベルで on-loss-of-keepalives ステートメントを含めます。

手記：

[edit chassis redundancy]階層のon-loss-of-keepalivesステートメントは、Junos Evolvedを実行しているPTXプラットフォームではサポートされていません。これらのプラットフォームでは、キープアライブ メッセージが検出されない場合のスイッチオーバーがデフォルトになります。

グレースフル ルーティングエンジン スイッチオーバーが設定されていない場合、デフォルトでは、フェイルオーバーは 300 秒(5 分)後に発生します。時間間隔を短くしたり長くしたりできます。

手記：

プライマリ ルーティングエンジンが手動で再起動または停止された場合、キープアライブ時間は 360 秒にリセットされます。

キープアライブ期間を変更するには、[edit chassis redundancy]階層レベルでkeepalive-timeステートメントを含めます。

キープアライブ時間の範囲は2〜10,000秒です。

次の例は、プライマリ ルーティングエンジンでキープアライブ信号の損失を検出するようにバックアップ ルーティングエンジンを設定した場合のイベントのシーケンスを示しています。

  1. キー プアライブタイム を 25 秒に手動で設定します。

  2. プライマリルーティングエンジンへのパケット転送エンジン接続が失われ、キープアライブタイマーが終了すると、パケット転送は中断されます。

  3. キープアライブの損失が 25 秒間続くと、メッセージが記録され、バックアップ ルーティングエンジンが主要な役割を果たそうとします。バックアップ ルーティングエンジンがアクティブになるとアラームが発生し、表示がルーティングエンジンの現在のステータスに更新されます。

  4. バックアップ ルーティングエンジンがプライマリの役割を引き継いだ後も、引き続きプライマリとして機能します。

手記：

グレースフル ルーティングエンジン スイッチオーバーが設定されている場合、キープアライブ信号が自動的に有効になり、フェイルオーバー時間が 2 秒(M20 ルーターでは 4 秒)に設定されます。キープアライブ時間を手動でリセットすることはできません。
手記：

プライマリ ルーティングエンジンを停止または再起動すると、Junos OS はキープアライブ時間を 360 秒にリセットし、360 秒のキープアライブ時間が終了するまで、バックアップ ルーティングエンジンはプライマリの役割を引き継ぎません。

以前のプライマリルーティングエンジンは、バックアップルーティングエンジンへのフェイルオーバー後にサービスに戻ると、バックアップルーティングエンジンになります。プライマリ ステータスを以前のプライマリ ルーティングエンジンに戻すには、運用モード コマンドを request chassis routing-engine master switch 使用できます。

ルーティング エンジンの 1 つが存在しない場合は、冗長性がどのように設定されていても、残りのルーティングエンジンが自動的にプライマリになります。

プライマリルーティングエンジンのem0インタフェース障害検知時

バックアップルーティングエンジンを設定した後、プライマリルーティングエンジンでem0インタフェースに障害が発生した場合、自動的にプライマリロールを担うように指示します。この機能を有効にするには、[edit chassis redundancy failover]階層レベルでon-re-to-fpc-staleステートメントを含めます。

ソフトウェアのプロセスが失敗した場合

ソフトウェア プロセスが失敗した場合にバックアップ ルーティングエンジンへの自動スイッチオーバーを設定するには、[edit system processes process-name]階層レベルで failover other-routing-engine ステートメントを含めます。

process-name は、有効なプロセス名の 1 つです。このステートメントがプロセスに対して設定され、そのプロセスが30秒以内に4回失敗した場合、ルーターは他のルーティングエンジンから再起動します。 [edit system processes] 階層レベルで利用可能なもう一つのステートメントは、 フェイルオーバー代替メディアです。代替メディアオプションについては、 ルーティングデバイス用Junos OS運用管理ライブラリを参照してください。

ルーティングエンジンのプライマリ ロールの手動切り替え

ルーティングエンジンのプライマリ ロールを手動で切り替えるには、以下のコマンドのいずれかを使用します:

  • バックアップルーティングエンジンで、 request chassis routing-engine master acquire コマンドを発行して、バックアップルーティングエンジンがプライマリロールを担うように要求します。

  • プライマリルーティングエンジンで、 request chassis routing-engine master release コマンドを使用して、バックアップルーティングエンジンプライマリロールを引き受けるように要求します。

  • どちらのルーティングエンジンでも、 request chassis routing-engine master switch コマンドを発行してプライマリ ロールを切り替えます。

ルーティングエンジン冗長性ステータスの検証

冗長性ログ用に、 /var/log/mastership に別のログファイルが用意されています。ログを表示するには、 file show /var/log/mastership コマンドを使用します。 表 1 に、プライマリ ロールのログ イベントのコードと説明を示します。

表 1: ルーティングエンジンのプライマリ ロール ログ

イベントコード

形容

E_NULL = 0

イベントは null イベントです。

E_CFG_M

ルーティングエンジンはプライマリとして構成されます。

E_CFG_B

ルーティングエンジンはバックアップとして構成されます。

E_CFG_D

ルーティングエンジンは無効に構成されています。

E_MAXTRY

1 次ロールの獲得または解放の最大試行回数を超えました。

E_REQ_C

要求プライマリ ロール要求が送信されました。

E_ACK_C

要求のプライマリ ロールの確認応答を受信しました。

E_NAK_C

要求のプライマリ ロール要求が確認されませんでした。

E_REQ_Y

プライマリロールの確認が要求されます。

E_ACK_Y

プライマリロールが確認されています。

E_NAK_Y

プライマリロールは確認されません。

E_REQ_G

プライマリロールのリリースリクエストがルーティングエンジンから送信されました。

E_ACK_G

ルーティングエンジンは、プライマリ ロールのリリースを確認しました。

E_CMD_A

コマンド request chassis routing-engine master acquire がバックアップ ルーティングエンジンから発行されました。

E_CMD_F

コマンド request chassis routing-engine master acquire force がバックアップ ルーティングエンジンから発行されました。

E_CMD_R

コマンドrequest chassis routing-engine master release がプライマリルーティングエンジンから発行されました。

E_CMD_S

コマンド request chassis routing-engine master switch は、ルーティングエンジンから発行されました。

E_NO_ORE

他のルーティングエンジンは検知されません。

E_TMOUT

要求がタイムアウトしました。

E_NO_IPC

ルーティングエンジンの接続が失われました。

E_ORE_M

その他のルーティングエンジンの状態をプライマリに変更しました。

E_ORE_B

その他のルーティングエンジンの状態をバックアップに変更しました。

E_ORE_D

その他のルーティングエンジンの状態が無効に変更されました。

CPU とメモリの全体的な使用率を確認する

目的

ルーター上で実行され、制御端末を持つソフトウェア プロセスに関する網羅的なシステム プロセス情報を表示できます。このコマンドは、UNIXのtopコマンドと同じです。ただし、UNIXのtopコマンドは、メモリ値が絶えず変化するリアルタイムのメモリ使用量を示し、show system processes extensiveコマンドは、特定の瞬間のメモリ使用量のスナップショットを提供します。

アクション

CPU とメモリの全体的な使用状況を確認するには、以下の Junos OS CLI(コマンドライン インターフェイス)コマンドを入力します。

サンプル出力

user@R1> show system processes extensive

意味

サンプル出力は、ルーティングエンジンとソフトウェアプロセスによって使用される仮想メモリの量を示しています。たとえば、118 MB の物理メモリが空きで、512 MB のスワップ ファイルが空きの場合、ルーターのメモリが不足していないことを示します。processes フィールドは、58 個のプロセスのほとんどがスリープ状態であり、1 個が実行状態であることを示しています。実行中のプロセスまたはコマンドが最上位のコマンドです。

コマンド列には、現在実行中のプロセスが一覧表示されます。たとえば、シャーシ プロセス(chassisd)のプロセス識別子(PID)は 4480 で、現在の優先度(PRI)は 2 です。優先度の数値が低いほど、優先度が高いことを示します。

プロセスはアクティビティのレベルに従って一覧表示され、最もアクティブなプロセスが出力の一番上に表示されます。たとえば、chassisd(chassisd)プロセスは 2.34 % と、最も大量の CPU リソースを消費しています。

メモリ フィールド(Mem)は、ルーティングエンジンによって管理され、プロセスによって使用される仮想メモリを示します。メモリ フィールドの値は KB と MB で、次のように分類されます。

  • [アクティブ(Active)]:割り当てられ、プログラムによって実際に使用されているメモリ。

  • Inact:割り当てられているが最近使用されていないメモリ、またはプログラムによって解放されたメモリ。非アクティブなメモリは、1 つ以上のプロセスのアドレス空間にマップされているため、それらのプロセスの常駐セット サイズにカウントされます。

  • 有線—スワップの対象とならないメモリ。通常はルーティングエンジンのメモリ構造やプロセスによって物理的にロックされたメモリに使用されます。

  • キャッシュ:どのプログラムにも関連付けられておらず、再利用する前にスワップする必要のないメモリ。

  • Buf:最近ディスクから呼び出されたデータを保持するために使用されるメモリバッファのサイズ。

  • [Free]:どのプログラムにも関連付けられていないメモリ。プロセスによって解放されたメモリは、メモリを解放するためにプロセスが使用した方法に応じて、非アクティブ、キャッシュ、または解放になる場合があります。

システムがメモリ不足に陥っている場合、ページアウト処理は、空きページ、キャッシュページ、非アクティブページ、および必要に応じてアクティブページのメモリを再利用します。

「スワップ」フィールドには、使用可能なスワップ・スペースの合計と、未使用の量が表示されます。この例では、合計 512 MB のスワップ領域と 512 MB の空きスワップ領域が出力されています。

最後に、各プロセスのメモリ使用量が一覧表示されます。SIZE フィールドは仮想アドレス空間のサイズを示し、RES フィールドは物理メモリ内のプログラムの量 (RSS または常駐セット サイズとも呼ばれます) を示します。サンプル出力では、chassisd(chassisd)プロセスに 3728 KB の仮想アドレス空間と 1908 KB の物理メモリがあります。

ルーティングエンジンの初期設定の例

コンフィギュレーショングループを使用することで、各ルーティングエンジンに正しいIPアドレスが使用されるようにし、両方のルーティングエンジンで単一の構成ファイルを保持することができます。

次の例では、設定グループ re0 と re1 を別々の IP アドレスで定義しています。これらのよく知られたコンフィギュレーショングループ名は、適切なルーティングエンジンでのみ有効になります。

両方のルーティング エンジンで、管理イーサネット インターフェイス(この例では fxp0 )に追加の IP アドレスを割り当てることができます。割り当てられたアドレスは master-only キーワードを使用し、両方のルーティング エンジンで同一であるため、プライマリ ルーティングエンジンの IP アドレスにいつでもアクセスできます。このアドレスは、プライマリー ルーティングエンジンの管理イーサネット インターフェイスでのみ有効です。ルーティングエンジンのスイッチオーバー時に、アドレスは新しいプライマリ ルーティングエンジンに移動します。

例えば、 re0 では、設定は次のようになります。

re1 では、設定は次のとおりです。

デュアル ルーティング エンジンの初期設定の詳細については、 Junos OS ソフトウェア インストールおよびアップグレード ガイドを参照してください。両方のルーティング エンジンで master-only キーワードを使用して、管理イーサネット インターフェイスに追加の IP アドレスを割り当てる方法については、 Junos OS CLI ユーザー ガイドを参照してください。

参照

コンフィギュレーション・ファイルを 1 つのルーティングエンジンからもう 1 つのにコピーする

コンソール ポートまたは管理イーサネット ポートのいずれかを使用して、2 つのルーティング エンジン間の接続を確立できます。その後、コピーするか FTP を使用してプライマリからバックアップに設定を転送し、ファイルをロードして通常の方法でコミットできます。

管理イーサネットポートを使って他のルーティングエンジンに接続するには、以下のコマンドを発行してください:

TXマトリクス ルーターで、管理イーサネット ポートを使用して他のルーティングエンジンに接続するには、次のコマンドを発行します。

request routing-engine loginコマンドの詳細については、CLIエクスプローラーを参照してください。

構成ファイルを 1 つのルーティングエンジンから別のにコピーするには、 file copy コマンドを発行します。

この場合、 source は構成ファイルの名前です。これらのファイルは、 ディレクトリ /config に保存されます。アクティブな設定は /config/juniper.conf で、それより古い設定は /config/juniper.conf {1...9} にあります。 destination は、もう一方のルーティングエンジン上のファイルです。

次の例では、ルーティングエンジン0からルーティングエンジン1に構成ファイルをコピーします。

次の例では、構成ファイル を ルーティングエンジン 0 から TX マトリクス ルーター上のルーティングエンジン 1 にコピーします。

構成ファイルを読み込むには、[edit]階層レベルで load replace コマンドを入力します。

注意：

ルーティングエンジン0の管理イーサネットインターフェイス設定で指定されたIPアドレスを、ルーティングエンジン1に適したアドレスに変更してください。

参照

他のルーティングエンジンからソフトウェアパッケージを読み込む

既存の request system software add package-name コマンドを使用して、他のルーティングエンジンからローカルルーティングエンジンにパッケージをロードできます。

URLの re 部分で、他のルーティングエンジンの番号を指定します。URL の filename 部分で、パッケージへのパスを指定します。通常、パッケージは /var/sw/pkg ディレクトリにあります。

参照

関連資料