Understanding Graceful Routing Engine Switchoverがわからんので、 https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/topic-map/gres-understanding.html を見ていた。日本語にしていたら実質翻訳みたいになったので、供養する。
※ この文章は2024/05時点のものであり、翻訳の正しさについては責任を取れません。商用環境に設定をいれる場合はちゃんとオリジナルの方を見てご対応をお願いしまします。
GRESの説明と要件についての説明
- Graceful Routing Engine Switchover Concepts
Graceful Routing Engine Switchover (GRES) はJunos とJunos Evoで利用可能で、たとえprimary REが落ちても冗長系のREがパケットのフォワーディングを継続して実施する。 GRESはインターフェースとカーネルの情報を保存し、通信に影響がないようにする。しかし、GRESはc-planeの情報を保存しない。
- Junos Evo: - Junos Evoが乗っているPTX10k (PTX10004, PTX10004, PTX10016)はGRESがデフォルトでenableになっていてdisableにすることができない
- Note: - Tシリーズのルータはnonstop active routing (NSR) とGRESを組み合わせた場合にc-placeを保持する。またGRESが有効である状態だとPacket Forwarding Engineごとにline rateの75%のトラフィックを落とさずに通信する。
隣接するデバイスは、デバイスが再起動したことを検出し、個々のルーティングプロトコルの仕様で指定された方法でそのイベントに反応する。
switchover中もルーティングを提供するために、GRESは下記を組み合わせないといけない。
- Graceful restart protocol extensions
- Nonstop active routing (NSR)
primary REが切り替わるような事象が起きた際にbackup REにできるだけ早く切り替えを実施するためにいくつかのアップデートがある。
- Note: 2つのREがsyncするための要件やlogicのために、NSR/GRESのパフォーマンスはシステムの中のREの最も重いものために制限がある。
Primary Roleがbackup REにswtichするための条件は下記:
- primary REのカーネルの動作が止まった
- primery REのハードウェア故障
- 管理者が手動でswitchoverした
Note: switchoverの間にルーティングプロトコルのstateの情報を保持素早く修復するために、GRESはgraceful restartかNSRのどちらかか両方を組み合わせるべき(must)。 graceful restartの追加情報は https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/concept/graceful-restart-concepts.html を、NSRは https://www.juniper.net/documentation/us/en/software/junos/high-availability/topics/concept/nsr-overview.html を見てね。
もしbackup REがprimary REからkeepaliveを2秒( M20では4秒 )受け取ることができなかった場合は、primary REが故障したと決定すし、primary roleを引き受ける。 Packet Forwarding Engineは
- シームレスに古いREを切り離す
- 新しいREにつなぎ直す
- 再起動しない
- トラフィックに影響を与えない
もし新しいREとPacket Routing Engineはその後同期する。新しいprimary REがPacket Routing Engineが最新でないことを検知した場合、state update messageを再送信します。
下記のGRESの挙動の推奨と要件について注意すること
Junos 12.2から、もし隣接機器のhelpeのpeerrがタイムアウトしたり、デバイスが再起動したら、graceful restart protocolの拡張が再起動を起こしそうなことについてhelperデバイスのpeerが知らせることができない。Gracefull restartは停止し、トラフィックを落とす可能性がある。隣接関係を維持するために、IS-ISではhold-timeをデフォルトの27秒から40秒よりも大きくする。
連続したSwitchoverは両方のREが起動してから最低でも240秒ごとに実施する必要がある。240秒以内にswitchoverを試みると下記のようなメッセージが表示される。
Standby Routing Engine is not ready for graceful switchover. Packet Forwarding Engines that are not ready for graceful switchover might be reset
もしswitchoverが手動で実施された場合、デバイスはgraceful switchoverのための準備ができてないPacket Forwarding Engineのみリセットする。FPCは自動的に再起動してないようにする。warningが表示されなくなるまで待ってからswitchoverを実施することを推奨する。
Junos 14.2からMXシリーズでGRESをする場合は、clear synchronous-ethernet wait-to-restore コマンドを新しいPrimary REでwait-to-restore timerをクリアするために実施しなければならない。このコマンドはlocal REのタイマーのみをresetするため実施が必要である。
TX Matric Plusで3D SIBを使っている場合は、連続したREのswitchoverは両方のREが起動してから900秒以上経過しなければならない。同期に関する問題を避けてGRESするために一つだけで実施する必要がある。
Juniper社は下記を推奨しない。
- GRESが有効になっているデバイスでのbackup REへのcommit オペレーション
- backup REでGRESが有効になっている任意のシナリオ
あなたがNonstop routingをGRESと共にQFX10000で有効にしているとき、Juniper社は [edit routing-options] の階層に nsr-phantom-holdtime を設定することを強く推奨します。switchoverのときにトラフィックをロスすることを助けるために。もしこの設定を入れていたら、特定のhold-timerが切れるまで、phantom IPアドレスはswitchoverの間もカーネルに残る。タイマーが切れたあと、デバイスは適切なルーティングテーブルに対応する経路を追加する。Ethernet VPN (EVPN) - VXLAN環境では、Juniper社はhold-timeを300秒にすることを推奨します。このオプションは冗長REがなく、GRESをサポートしていないQFX10002では受け入れられません。
図1はGraceful Routing Engine switchoverのシステムアーキテクチャと、switchoverのためのREの準備に関するプロセスを表したものだ。
図は本家サイト見てね。
Note: 下記の両方を実行してGRESの準備ができていることを確認してください。 - Primary REで request chassis routing-engine master switch check を実行する。 - Backup REで show system switchover を実行する。
GRESのためのswitchoverの準備工程を下記の1から8で説明する。
- primary REのスタート
- routing platformプロセス (chassisプロセス[chassisd]のような)のスタート
- Packet Forwarding engineがスタートし、primary REと接続
- システムのすべての情報がアップデートされる
- backup REスタート
- システムはGRESを有効にできるか決定する
- kernel synchronization プロセス (ksyncd)はbackup REをprimary REと同期する。
- ksyncdが同期を完了させたあと、すべての状態の情報とforwardingテーブルをアップデートする
図2はルーティング(やスイッチング)プラットフォーム上でのswitchoverの効果を示している。switchoverは下記の1から5のステップで構成されている。
- primary REからkeepaliveがロストしたとき、システムはbackup REへの優雅な切り替えを実施する。
- Packet Forwarding Engineは新しくprimaryになった旧backup REに接続する。
- Routing platoformはGRESに含まれていない(rpdのようなroutingプロセス)の再起動を実施する。
- スイッチオーバーの時点から学習した状態情報はシステム内で更新される
- グレースフルリスタートプロトコルの拡張が設定されている場合、隣接するピアヘルパーデバイスからルーティング情報を収集し、復元する
Note: MXシリーズルーターで拡張サブスクライバー管理を使用している場合、新しいバックアップルーティングエンジン（以前のプライマリルーティングエンジン）は、優雅なルーティングエンジンの切り替えが実行されたときに再起動する。この再起動により、バックアップルーティングエンジンの状態が新しいプライマリルーティングエンジンの状態と同期され、切り替え中に発生した状態の不一致を防ぐ。
Note: GRESを使用するTシリーズおよびM320ルーターでは、GRES中にスイッチインターフェースボード（SIB）がオフラインになり、1つずつ再起動する。これは、SIBを管理するスイッチプロセッサメザニンボード（SPMB）が関連するSIBの状態情報を適切に取得するための時間を確保するためである。ただし、すべてのFPCがフルラインレートでトラフィックを送信している完全にポピュレートされたシャーシでは、切り替え中に一時的なパケットロスが発生する可能性がある。
注意：GRESが構成されていて、TX Matrix Plusルーターに3D SIBが搭載されている場合、restart chassis-controlコマンドを実行してもどのルーティングエンジンがプライマリになるかは判別できない。これは、chassisdプロセスがrestart chassis-controlコマンドの実行時に再起動するためである。chassisdプロセスはプライマリの役割を維持および保持する責任があり、再起動されると新しいchassisdはデバイスの負荷に基づいて処理される。その結果、どちらかのルーティングエンジンがプライマリになる。
Effects of a Routing Engine Switchover
表1は異なる機能をenableにしたときのREのswitchoverの効果について説明する。
- high availabilityの機能を使わない
- Graceful Routing Engine switchover
- Greceful restart
- Nonstop active routing
RE冗長あり(機能は有効になってない場合)
利点:
- 新しいプライマリルーティングエンジンへの切り替えが完了すると、ルーティング収束が行われ、トラフィックが再開されます
考慮点:
- すべての物理インターフェースがオフラインになる
- Packet Forwarding Engineの再起動
- backup REはルーティングプロトコルのプロセス(rpd)を再起動する
- すべてのハードウェアとインターフェースは新しいprimary REを発見する
- switchoverにいくつかの時間がかかる
- デバイスのすべての隣接関係は、物理的な変更（インターフェースのアラーム）およびルーティングの変更（トポロジー）に気付く
GRESが有効
利点:
- スイッチオーバー中、インターフェースとカーネル情報は保持される
- パケット転送エンジンは再起動されないため、スイッチオーバーは高速である
考慮点:
- 新しいプライマリ ルーティング エンジンはルーティング プロトコル プロセス (rpd) を再起動します。
- すべてのハードウェアとインターフェースは、ウォームリスタートに似たプロセスで取得されます。
- すべての隣接関係は、デバイスの状態変化を認識しています。
GRESとNSRが有効
利点:
- スイッチオーバー中、トラフィックは中断されません。
- インターフェースとカーネル情報は保持されます。
考慮点:
- サポートされていないプロトコルは、各プロトコル固有の通常の回復メカニズムを使用して更新する必要があります。
GRESとgraceful restartが有効
利点
- スイッチオーバー中、トラフィックは中断されません。
- インターフェースとカーネル情報は保持されます。
- 優雅な再起動プロトコルの拡張は、隣接デバイスから迅速にルーティング情報を収集し、復元します。
欠点
- 隣接デバイスは優雅な再起動をサポートする必要があり、待機間隔が必要です。
- ルーティングプロトコルプロセス (rpd) が再起動します。
- 特定のプロトコルでは、ネットワークの重大な変更が優雅な再起動を停止させる可能性があります。
- Junos OS リリース 12.2 以降では、再起動デバイスと隣接するピア「ヘルパー」デバイス間の隣接がタイムアウトした場合、優雅な再起動が停止し、トラフィックの中断を引き起こすことがあります。
