MXシリーズルーターの接続喪失によるファブリック関連障害の検知と復旧

ルーターの接続損失は、そのルーターのインターフェイスがアクティブな状態を維持しているにもかかわらず、ルーターが他の隣接ルーターにデータパケットを送信できない場合に発生します。その結果、隣接する他のルーターは影響を受けたルーターにトラフィックを転送し続け、他のルーターに通知を送信せずに到着したパケットをドロップします。

ルーター内のパケット転送エンジンが、同じルーター内のデータプレーンを介して他のパケット転送エンジンにトラフィックを送信できない場合、インターフェイスはコントロールプレーン上でアクティブとしてアドバタイズされますが、ルーターは隣接ルーターにパケットを送信できません。ファブリックの障害は、接続が失われる原因の 1 つである可能性があります。

以下のファブリック障害シナリオが考えられます:

コントロールボードの取り外し
高速リンク 2(HSL2)トレーニングの失敗
ラインカードのシングルリンク障害
同じラインカードまたは同じファブリックプレーンで複数のリンク障害が発生した場合
ラインカードまたはファブリックプレーンでランダムに複数のリンク障害が発生する
断続的な巡回冗長性検査(CRC)エラー
1 つの宛先のみの接続が完全に失われ、他の宛先への接続は失われない

何らかの理由でラインカードがデバイス内の他のラインカードにトラフィックを転送しない場合、ルーティングエンジン上の制御プロトコルはこの状態を検出できません。トラフィック伝送は、機能しているアクティブなラインカードに迂回されず、代わりに、パケットは影響を受けたラインカードに引き続き送信され、その時点で破棄されます。ラインカードがトラフィックを転送できない理由としては、以下が考えられます。

システム内のすべての平面が Offline または Fault 状態です。
ラインカード上のすべてのパケット転送エンジンが、宛先エラーによりファブリックストリームを無効にしている可能性があります。

すべてのSCB(スイッチコントロールボード)がラインカードへの接続を失うと、すべてのインターフェイスがダウンします。ラインカードのパケット転送エンジンがファブリックとの間の完全な接続を失うと、そのラインカードは停止します。

システムハードウェアの障害には、次の種類があります。

1 回の発生、または短期間のまれな障害 (環境スパイクなど)。この障害は、ファブリックプレーンを再起動し、必要に応じてラインカードとファブリックプレーンを再起動することで、手動による介入なしで効果的に修復されます。
頻繁に発生する障害の繰り返し。
恒久的な障害。

複数のプレーンで複数のパケット転送エンジンの宛先タイムアウトが発生するなど、スループットが低下した場合からの回復は試みられません。接続の復元は、すべてのプレーンが Offline または Fault 状態にある場合、またはすべてのアクティブなプレーンで宛先に到達できない場合にのみ試行されます。

宛先タイムアウトの共通の送信元または共通の宛先である特定のラインカードが原因で接続が失われた場合、[edit chassis fabric degraded]階層レベルでaction-fpc-restart-disableステートメントを設定している場合は、リカバリーアクションは実行されません。show chassis fabric reachabilityコマンド出力を使用して、ファブリックとラインカードのステータスを確認できます。アラームがトリガーされ、特定のラインカードが接続の損失を引き起こしていることを示します。

MXシリーズルーターでのファブリック障害検出方法

シャーシデーモン(chassisd)プロセスが、コントロールボードの取り外しを検出します。コントロールボードを取り外すと、そのボード上にあるすべてのアクティブなプレーンが無効になり、スイッチオーバーが実行されます。アクティブなルーティングエンジンもコントロールボードと一緒に取り外された場合、ルーティングエンジンのスイッチオーバーが発生し、プライマリ、バックアップルーティングエンジンペアでの再接続が発生するまで、コントロールボードの取り外しの検出は遅れます。グレースフルシャットダウンを発生させるように request chassis cb slot slot-number offline または物理ボタンを押してコントロールボードをオフラインにした場合、コントロールボードをオフライン状態に移行しても、ファブリック障害は発生しません。

プライマリルーティングエンジンのコントロールボードを取り外し、アクティブなファブリックプレーンを削除する場合、ラインカードは取り外したプレーンをローカルで無効化します。スペアプレーンが利用可能な場合、ラインカードはスペアプレーンへのスイッチオーバーを開始します。バックアップルーティングエンジン上のアクティブなコントロールボードが取り外された場合、プライマリルーティングエンジンは取り外したプレーンを無効にし、利用可能な場合はスペアプレーンへの切り替えを実行します。ソフトウェアは、削除されたすべてのプレーンを無効にすることで、接続が失われる期間を最適化しようとします。スペアプレーンは 1 つずつオンライン状態に移行します。

ファブリックの self-ping は、ファブリックデータパスの問題を検出するメカニズムです。各パケット転送エンジンは、自身宛てのファブリックデータセルを、すべてのアクティブなファブリックプレーンに転送します。データセルを送信するために、パケット転送エンジンファブリックはアクティブプレーンを介してリクエストセルを送信し、許可パケットを待ちます。宛先パケット転送エンジンは、リクエストセルを受信したのと同じプレーンを介してグラントパケットを送信します。許可セルを受信すると、送信元パケット転送エンジンがデータセルを送信します。

パケット転送エンジンのファブリックには、認可の遅延を検出する機能が含まれています。一定時間内に許可が受け取られない場合、宛先タイムアウトが宣言されます。2 枚以上のラインカード上のパケット転送エンジンによる特定のプレーンでの宛先タイムアウトは、プレーン障害の兆候と見なされます。ラインカード上の 1 つのパケット転送エンジンがエラーを点滅させたとしても、そのラインカードはエラーがあると見なされます。要求は有効なデータセルに対してのみ送信されるため、パケット転送エンジンがトラフィックをアクティブに送信すると、宛先タイムアウトが通知されます。ソフトウェアは、宛先タイムアウトに基づいて適切なアクションを実行します。self-pingの場合、データセルの宛先は送信元パケット転送エンジンのみです。

ファブリックping失敗メッセージは、ルーティングエンジン上のファブリック・マネージャーに送信され、すべてのライン・カードから報告されたすべてのエラーを照合して、是正措置を取ります。たとえば、同じラインカードのすべてのリンクで ping が失敗した場合は、ラインカードに問題があることを示している可能性があります。同じファブリックプレーンの複数のラインカードでpingが失敗する場合は、ファブリックに問題があることを示している可能性があります。

ルーティングエンジンが、ラインカードまたはパケット転送エンジンから受信したエラー情報に基づいて、ファブリックプレーンが5秒間にダウンしていると判断した場合、ファブリックの障害を示します。5秒は、ルーティングエンジンがすべてのラインカードからのエラーを照合する期間です。

ファブリック self-ping パケットが定期的に送信され、ファブリックリンクの正常性がチェックされます。自己 ping は 500 ミリ秒間隔で送信されます。宛先タイムアウトも 500 ミリ秒間隔でチェックされます。2つのタイムアウトが連続して発生した場合、self pingの失敗が検出されます。宛先タイムアウトを受信すると、パケット転送エンジンファブリックはファブリックへのパケットの送信を停止します。リンク状態を再度調べるために、ソフトウェアはクレジットをリセットして、新しいリクエストが再送信されるようにします。self-ping の障害が発生すると、ラインカードは、影響を受けるプレーンがすべての宛先にデータを送信できないようにします。この方法により、欠陥のあるプレーンで self-ping が再度送信されないようにすることができます。

self-ping 機能には、次のガイドラインが適用されます。

デフォルトでは、スペアファブリックプレーンはトラフィックを伝送しないため、スペアファブリックプレーンでは self ping は送信されません。
self-ping パケットのサイズは、すべてのアクティブなファブリックプレーンにセルをロードするのに十分な大きさです(MX2020 は 24 のファブリックプレーンをサポートし、MX10008 は 12 のファブリックプレーンをサポートします)。
受信した self-ping パケットの検出は実行されません。
高プライオリティキューは、オーバーサブスクリプションのケースで self-ping を送信できるようにするために使用されます。