トリガーは、IOS の同期光ファイバ ネットワーク(SONET)インターフェイスの因果関係における原因の役割を果たすイベントです。場合に応じて、pos delay triggers コマンドを使用できます。また別の場合には、特に、厳しいサービス レベル契約(SLA)を満たすことを試みる場合に、pos delay triggers コマンドを使用しないことを推奨します。 サービス プロバイダーは、特定の契約に基づいて差別化したレベルのサービスを提供しています。契約は、内部的にネットワークがどのようにカスタマー トラフィックのパスを指定するか、保護するか、または優先順位付けするかを扱います。これらのコマンドは、プロバイダーがサービス契約を満たすためにネットワークを調整する際に役立ちます。
このドキュメントはインターフェイス アップおよびダウン イベントに関連するトリガーについて説明します。また、Packet over SONET(POS)の導入方法やレイヤ 3 での SLA とコンバージェンス時間についても説明します。
このドキュメントに特有の要件はありません。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
このセクションでは POS インターフェイスをダウンさせるイベントについて説明し、関連するコマンドをリストアップします。
このセクションのトリガーのリストは、GR-253-CORE Synchronous Optical Network (SONET) Transport Systems:Common Generic Criteria 仕様を参考にしています。
Section Loss of Signal(SLOS):2.5us以上100us(6.2.1.1.1)以下を検出する必要があることを示します。
Section Loss of Frame(SLOF;セクション損失フレーム):この障害を少なくとも3ミリ秒(または24の連続エラーフレーミングパターン)(6.2.1.1.2)で検出する必要があることを示します。
Alarm Indication Signal - Line(AIS-L):AIS-Lは、必要に応じて、125usec以内に送信する必要があります。K2 のビット 6、7、8 が 111 に設定されている 5 つの連続フレームをデバイスが確認した場合、デバイスは AIS-L の受信を検出する必要があります(6.2.1.2.1)。
Signal Degrade Bit Error Rate(SD-BER):SD-BERは、自動保護スイッチング(APS)(B2 BERの計算に結び付けられる)を備えたインターフェイスでのみトリガーされます。
Signal Failure Bit Error Rate(SF-BER):SF-BERは、APSインターフェイスと非APSインターフェイスの両方(B2 BERの計算に結び付けられる)のトリガーです。
リモート不具合表示(RDI-L):RDI-LはPOSまたはAPSのトリガーではありません(ただし、RDI-LはMPLS FRRのトリガーです)(セクション5.3.3.1)。
このリストに記載されているセクションの詳細については、Telcordia Information SuperStore Webサイトを参照してください。
pos delay triggers line n コマンドは、このコマンドがラインのダウンをトリガーする前の n ミリ秒間、LOS/LOF/AIS をホールドオフします。
数値を指定せずにコマンドを設定すると、遅延時間はデフォルトで 100 ms となります。ライン トリガーはどの非 APS POS インターフェイス上でも使用できます。ライン トリガーは APS の動作に干渉するため、APS に参加しているインターフェイスでライン トリガーを使用することはできません。pos delay triggers line n コマンドは、内部の DWDM 保護の切り替えが発生したときに、内部で保護されている高密度波長分割多重(DWDM)ギアから発生した短い LOS でラインがダウンしないようにします。遅延期間中に故障が解消された場合、故障がまったく生じていないように見えます。
pos delay triggers line コマンドは、指定のホールドオフ期間が終了するまで、故障に基づいてあらゆる動作をホールドオフします(故障カウンタが増加する以外)。
このコマンドを有効にしないと、上記の SONET の故障による APS およびリンクのダウンがルート プロセッサ(RP)でただちにトリガーされます。
これらの特定のパス レベルの故障は、インターフェイスで pos delay triggers path を有効にしたときだけステータスの変更を開始します。
AIS-P:この不具合は、AIS-Pの原因となる不具合の検出から125usec以内に発生する必要があります。STSパスのH1バイトとH2バイトに3フレーム連続するすべての1が含まれる場合、Path Terminating Equipment(PTE)は、この不具合をを検出します。連結したパスでは、最初の H1 および H2 バイトのみを観察する必要があります。詳細は、R6-175 および R6-176 のセクション 6.2.1.2.2 を参照してください。
RDI-P:RDI-P が発生している場合、故障は 10 フレーム以内に検出する必要があります。R6-221 の 6.2.1.3.2 を参照してください。
B3用B3-TCA(しきい値超過アラーム):このアラームは、B3バイナリ同期通信(Bisync)IP(BIP)計算に結び付けられます。
LOP-P(パス損失ポインタ)(IOSバージョンにCSCdx58021が含まれる場合):GR-253のセクション6.2.1.1.3を参照してください。
このリストに記載されているセクションの詳細については、Telcordia Information SuperStore Webサイトを参照してください。
pos delay triggers path <msec>コマンドは、AIS-P、RDI-P、および過剰なB3エラーに対するリンクダウントリガーを有効にします。デフォルトでは、パス エラーでのリンク ダウンのトリガーは無効になっています。
このコマンドは、ホールドオフ時間を 0 ~ 511 ミリ秒の範囲で指定します(デフォルトは 100 ms)。 ホールドオフ期間の終了までにパス トリガー障害(AIS-P、RDI-P)が解消された場合、トリガーされません。POS インターフェイスでこのコマンドを明確に設定していないと、パス レベルの障害が処理されてもアクションが発生することはありません。ライン トリガーとは異なり、APS インターフェイスはパス トリガーを許可します。これは、パス トリガーが APS のライン レベルのアクティビティと干渉しないためです。Cisco IOS® ソフトウェア リリース 12.0(28)S より前のバージョンでは、パス トリガーを APS で設定することはできませんでした。パス トリガーは、SONET ネットワークへの接続時の POS インターフェイスのリンク アップ/ダウン動作を高速化するために追加されました。これにより、リモート エラーの発生時のレイヤ 3 のコンバージェンスをよりすばやく行えるようになりました。
次の表は、POS トリガーの条件および関連する結果を示しています。
条件 | 結果 |
---|---|
POS トリガーに明確に関連するものを何も設定していない場合。 | ライン レベルのトリガーはただちに処理されます。 |
pos delay triggers line コマンドを設定している場合。 | ライン レベルのトリガーは 100 ms の遅延後に処理されます。 |
pos delay triggers line x コマンドを設定している場合。 | ライン レベルのトリガーは x 秒後に処理されます(x は 0 ~ 511 の間)。 |
パス トリガーに明確に関連するものを何も設定していない場合。 | パス トリガーは処理されず、アクションは実行されません。 |
pos delay triggers path コマンドを設定している場合。 | パス レベルのトリガーは 100 ms の遅延後に処理されます。 |
pos delay triggers path x コマンドを設定している場合。 | パス レベルのトリガーは x ミリ秒後に処理されます(x は 0 ~ 511 の間)。 |
故障によって発生した SONET アラームは、故障が解消された後も 10 秒間(10.5 +-.5)保持されます。
IOS では、トリガーが異なるため、POS カードは故障処理のための 2 種類の一般的な手段を通じてライン状態を変更します。インターフェイス固有の設定(APS または非 APS)に依存しますが、一般的には 2 つのタイプの障害があります。
マネージド
アンマネージド
このドキュメントで使用するアラーム処理特有の用語を理解している必要があります。
故障:ハードウェアが認識する障害状態。
Failure:必要な約2.5秒間ずらした不具合で、SONET-4-ALARMメッセージを介して報告されます。トリガーとなる故障は継続しません。
アンマネージド障害:LOS、LOF などのイベント。これらは定義されたパラメータ セットによって SONET フレーマが検出する障害であり、計算は不要です。故障が存在してハードウェアによってアサートされているか、故障が存在しないかのどちらかです。このようなハード障害は一般に、割り込みによって処理されます。LOS、LOF、AIS-L、そして特殊な場合では AIS-P と RDI-P もすぐにアサートされます。これらは、こうした各故障を検出するために定義したルールやフレーマに依存します。これらの故障の影響はすぐに現れます。ただし、ルータに指示してこの故障を障害としてアサートするのを遅らせることができます。遅延値を決めるタイマーには、pos delay triggers [path | line]およびcarrier delay。これらについてはドキュメントの後半で説明します。
マネージド アラーム:TCA や SD/SF-BER 計算などのイベント。これらは、存在するか、増加または減少しているかどうかを判断するために計算が必要です。たとえば、ルータの観点から「LOS-ness」を増加させるLOSを持つことはできません。増加または減少中の BER を持つことはできますが、その対策は異なります。BER や TCA などのソフト障害では、ユーザが設定できるしきい値、ビット レート、BIP CV の最大数(B1、B2、B3 ごとに異なっているため)のような多数の要因が関わってくるため、多少の計算が必要です。 ハードウェアが BIP カウンタについてポーリングするため、これらの障害の検出には時間がかかります。また、この種類の故障は本質的に徐々に起こるものであり、時間をかけて蓄積されることも原因の 1 つです。さらに、一般にネットワークに他の種類のハード障害が発生していなければ、0 BIP から信号劣化(SD)や信号障害(SF)に直接進むことはないことも事実です。これらの故障は、ハード障害と比べてゆっくりと発生します。
次に、BER の計算方法を説明する、基本的な計算方法の一般的なアプローチを示します。
計算を再開するたびに、BER_Period が Required_BER_Period(統合ウィンドウが完全に展開されていない)に達するまで、このアルゴリズムは厳密に統合または平均化として機能します。
BER_Period = BER_Period + 1 秒。
Current_BIP = Current_BIP + BIP_new。
Current_BER = Current_BIP/BER_Period。
BER_Period が Required_BER_Period(統合ウィンドウが完全に展開され、スライドを開始)に達すると、アルゴリズムはリーキー バケットとして機能します。
BER_Period = Required_BER_Period。
Current_BIP = Current_BIP + BIP_new - Current_BER * 1 秒。
Current_BER = Current_BIP/BER_Period。
Required_BER_Period は、ライン レートと設定された BER しきい値のみに基づいて、規格に従って決定されます(GR-253 の図 5-5、スイッチの開始時間基準を参照)。 ただし、これは当社のサンプリング レートの下限である 1 秒間に制限されます。
したがって、BER_Period(統合ウィンドウ)はポーリングごとに移動し、ポーリングごとに新しい BER が計算されます。Current_BER が所定の上限を超えた場合、その同じポーリング間隔または計算間隔の間に迅速に該当する故障を提起し、応答を最小限に保ちます。シスコはこれらの計算を毎秒繰り返し、次の 3 つのイベントのいずれかが発生していないか確認します。
BER は引き続きその同じ範囲内にある。新しいアクションはありません。
BER が再び上昇し、SD または SF のしきい値を超えた(B2 について)。 新しいアラームを発生させます。
BER が BER のしきい値未満に低下した。アラームをクリアします。
TCA や SD/SF のアサーションには、それぞれのポーリング間隔で制限を超えるまで待つ必要があります。計算時に Current_BER がしきい値を超えたかどうか確認し、もし超えている場合は、先に進んでソフトウェアからすぐにアラームをアサートすることができます。
これが有効な理由は、アラームを最初にトリガーするのに十分なほど Current_BER が大きい場合、BER_Period が終了しても条件が有効であるためです。これは、計算ウィンドウに関連してどのように値が定義され、比較されるかに基づいています。
アラームをクリアしたら、BER_Period 計算ウィンドウが終了するまで待つ必要があります。これは、ウィンドウの最後の部分でしきい値を超えるような 新しい BIP が集まらないようにするためです。
注:GR-253によると、SD-BERとSF-BERは両方ともB2 BIPカウントに厳密に結び付けられています。現在のデフォルトのしきい値は次のとおりです。
BERしきい値:SF = 10e-3 SD = 10e-6
TCAしきい値:B1 = 10e-6 B2 = 10e-6 B3 = 10e-6
注:エンジン2 OC-48カードには次のデフォルトしきい値があります。
BERしきい値:SF = 10e-4 SD = 10e-6
TCAしきい値:B1 = 10e-6 B2 = 10e-6 B3 = 10e-6
B3 TCA PathトリガーをSFと同様に動作させるには、B3しきい値を同じしきい値(10e-3)に設定する必要があります。router(config-if)#プロンプトでpos threshold b3-tca 3コマンドを使用して実行できます。
注:ポーリング間隔は1秒なので、TCAまたはSD/SFの不具合を通知および発生する最小時間です。また、TCA/SD/SF の累積的な性質上、この種の障害には、一般的な障害時にすぐに発生するその他の障害が伴います。これにより、ルータのプロセッサの使用率とパフォーマンスのバランスが維持されます。ポーリング間隔は設定できません。
このセクションでは、IOS のさまざまなユーザ調整可能なノブのインタラクションを確認するための背景情報を説明します。
pos delay triggers [line | path]コマンドを使用すると、不具合のレポートとアクションを短時間で遅延させることができます。
POS 遅延トリガー ラインはライン アラームに対応する前の保留時間です。デフォルトでは即時に対応するので、pos delay trigger line 0 となります。値を指定せずに直接 pos delay triggers line を設定すると、100 ms のデフォルト値が考慮されます。これにより、必要な結果に基づいて即時または遅延応答を有効にします。これらのいずれかを設定すると、ホールドオフ時間が過ぎるまで故障がアクティブ アラームとして表示されなくなります。
スケジュール:
|----------|----------|----------|----------|----------| T0 T1 T2 T3 T4 T5
次のことを示しています。
t0:不具合が発生する時刻。
t1:ハードウェアが不具合を検出した時刻。
t2:障害として不具合が報告される時間。
t2-t3:設定されたトリガーに対してホールドオフされる時間。
t3-t4:キャリア遅延のために待機する時間。
t4:インターフェイスが実際にIOSでダウンした時間。
t5:ルーティングプロトコルの隣接関係がダウンする時間。
スケジュールを確認し、さまざまな結果を得るために異なるノブの調整方法を観察してみましょう。
post delay triggers コマンドは t2 と t3 の間の期間に影響し、ホールドオフ期間が終了するまで、故障を実質的に IOS から隠します。当然ながら、t3 に到達する前に故障が解消されると何の応答も行われないため、まるで何も起こらなかったかのように見えます。ライントリガーとパストリガーのデフォルト値は100ミリ秒で、範囲は0 ~ 511ミリ秒です。pos delay triggers pathが最初に設定されていない限り、パストリガーは有効になりません(つまり、アクションは実行されません)。pos delay trigger path はパス アラームに達する前の保留時間です。デフォルトでは応答なしです。値を指定せずに直接 pos delay triggers line を設定すると、100 ms のデフォルト値が自動的に割り当てられます。これには AIS-P、RDI-P および B3-TCA が含まれます。この機能は、CSCds82814 によって追加されました(12.0(15.5)S/ST 前後)。
キャリア遅延は、POS 遅延保留時間が終了し、IOS インターフェイスがダウンするまでの保留時間です。デフォルトは 2000 ミリ秒です。キャリア遅延は、t3(IOS が障害を認識したとき)と t4(インターフェイスがダウンしたとき)の間の時間です。 これはデフォルトでは 2 秒に設定され、ミリ秒の値にも設定できます。スケジュールが示すように、これは SONET レベルのホールドオフ タイマーに加えられた追加機能です。これは POS トリガーと同じように動作します。つまり、アラームがホールドオフ期間中に削除されるとインターフェイスはダウンしません。しかし、ここで難しい問題があります。SONET のデバウンス タイマーは、キャリア遅延が長い(10 秒を優に超える)場合を除いて、キャリア遅延が有効になる前に故障をクリアすることはありません。 この結果、キャリア遅延がほぼ常に有効になり、そのため POS インターフェイスとともに導入した場合、かなり小さくすることを考慮すべき状況が生じます。キャリア遅延は、アラームがクリアされた後でも、インターフェイスも同じく回復したと宣言する前に追加されます。したがって、インターフェイスが回復する前に、キャリア遅延の値が 2 回発生する可能性があります。
インターフェイスや物理メディアによっては、これが便利な場合もあります。しかし、POS インターフェイスでは使用できる多数のトリガーとタイマーがあり、それらを組み合わせることで望ましい効果を生むことができ、キャリア遅延がこのような重要な役割を果たすことはありません。0 ~ 8 ミリ秒というキャリア遅延の値は、これらのノブを自分でテストする際の開始地点として適しています。一般に、pos delay triggers コマンドを使用して問題を緩和し、望ましいホールドオフ効果をもたらすことが正しい考え方です。キャリア遅延は、この影響を最小限に抑えるため小さくすることができます。
前述の SONET デバウンス タイマーは 10 秒 (+/- 0.5 秒)に設定され、10 秒未満のフラップ期間が発生しないようにすることが GR-253 によって要求されています。タイマーは故障がクリアされてから開始します。タイマー ウィンドウの期限が切れる前に別の故障イベントが発生すると、タイマーはリセットされます。
スケジュール:
|----------|----------|----------|----------|----------|---------| T0 T1 T2 T3 T4 T5 T6
次のことを示しています。
t0:不具合がクリアされます。
t0:デバウンスタイマーが開始します。
t4:t0 + 10sec(したがって、t0とt4の間に新しい不具合が発生しない場合は、障害をクリアする必要があります)。
イベントが t4 の前、たとえば t2 で発生した場合(これは別の故障でも、同じ種類の故障の再発でも構いません)、この新しい故障がクリアされるまでタイマーは停止します。t3 では、アクティブな故障がなく、約 10 秒間カウントするとタイマーが再開します。新しいイベントが発生しなかった場合、t5 でアラームをクリアし、キャリア遅延タイマーを開始します。キャリア遅延が t6 でクリアされたら、インターフェイスを再度有効にします。
この情報から、POS インターフェイスがさまざまな SONET/SDH 状態にどのように対処するかをより明確に理解できるはずです。これにより、顧客の意図した動作に従って、より正確に装置を設定できるようになります。
このセクションでは、pos delay triggers [line | path]コマンドを発行し、使用できない場合に使用します。
pos delay triggers を使用すべきでないシナリオを次に示します。複数のシナリオがあります。
ライン トリガーは APS が設定されたインターフェイスと一緒に使用できません。Cisco IOS ソフトウェア リリース 12.0(28)S より前のバージョンは、パス トリガーの使用も許可していませんでした。
パス レベルの故障時にインターフェイスをダウンさせることを明確に望まない場合、これらのトリガーは使用できません。
ライン レベルのトリガーが遅延なしでインターフェイスをダウンさせることを望む場合、このコマンドは使用できません。
pos delay triggers コマンドを使用できるシナリオを次に示します。
ライン レベルの故障の影響を一時的に保留させたい場合。
パス レベルの故障時にインターフェイスがただちにダウンするようにする機能を有効にする場合。
パス レベルの故障時にインターフェイスをダウンさせるが、一定のホールドオフ期間を持たせる場合。
次のスケジュールを確認してください。
|----------|--------------------| T0 T1 T2
Time t=0(t0):不具合が検出された場合。
時間t2:必要なSLA復元時間。
時間t1:pos delay triggersコマンドからのホールドオフが設定されている(LINEのデフォルトは0、PATHのデフォルトは有効になっていない)。
X はホールドオフ期間の値です(つまり X = t1 の値)。
Y はレイヤ 3 のサービスの復元にかかる時間です。
pos delay triggers コマンドを使用できる場合もあれば、使用できない場合もあります(厳しいサービス レベル契約(SLA)を満たすことを試みる場合には特に)。
t1 が任意の値で Y > (t2-t1) の場合、ホールドオフを設定すると SLA を満たすことができないため、ホールドオフはよい方法ではありません。
Y <= (t2-t1) の場合は、ホールドオフの実装を検討できます。障害の長さが (t1-t0) 未満の場合、ルータのリソースを使用する必要がなく、望ましい SLA を満たすことができるため、ホールドオフを設定できます。故障が時間 t1 を過ぎても継続する場合、IP レベルで復元を始める前に多少時間が失われますが、まだ SLA を満たすことができます。
次の式で使用できる値を確認するには、基本的なトランスポート ネットワークと、レイヤ 3 ネットワークのコンバージェンス時間に関する知識が必要です。また、いくつかのテストを実行する必要があります。
トリガーがどのように機能するかを次に示します。
pos delay triggers line n コマンドは、このコマンドがライン ダウンをトリガーする前の n ミリ秒間、LOS/LOF/AIS をホールドオフします。デフォルト値は 100 ミリ秒です。このコマンドはどの 非 APS POS インターフェイスでも使用できます。pos delay triggers line n コマンドは、内部の DWDM 保護の切り替えが発生したときに、内部で保護されている DWDM ギアから発生した短い LOS でラインがダウンしないようにします。遅延期間中に故障が解消された場合、故障がまったく生じていないように見えます。
pos delay triggers line コマンドは、指定のホールドオフ期間が終了するまで、故障に基づいてあらゆる動作をホールドオフします(故障カウンタが増加する以外)。
このコマンドを有効にしないと、APS およびリンクのダウンが RP でただちにトリガーされます。
このセクションでは、SONET トリガーの導入について説明します。
SONET ネットワークには内部保護があります。これは、SONET ネットワーク内に障害が発生すると保護スイッチをトリガーし、サービスを非常に早く復元できることを意味します。したがって、インターフェイスをダウンさせてレイヤ 3 に通知するかどうかを検討する必要があります。ほとんどの場合、保護スイッチが SONET ネットワーク内で発生すると、ネットワークが復元のための行動を起こす間に、ルータに短時間のラインまたは パス AIS が表示されます。ただし、これは障害がどちらのルータからも離れている場合のみ起こります。SONET ネットワークの直径は数 NE である可能性があり、どちらのルータもライン障害をパス障害のみとして考えます。この場合、ホールドオフを希望するならばパス レベルおよびライン レベルのトリガーを考慮してください。
この判断を行うには、両方のアプローチの関連コストを理解する必要があります。ネットワーク オペレータとして、以下の点を考慮してください。
ネットワークのコンバージェンスは十分迅速ですか。そうでない場合、このアプローチは適していません。
ルーティングはそのような障害にどのような影響を与えますか。パフォーマンスが許容できないレベルまで低下するほど大きな影響がルータにおよびますか。
最終的には、約 60 ミリ秒のヒットを無視できるかどうか、またはそのようなイベントをルーティングすることを希望するかどうかを判断しなければなりません。このヒットを無視できる場合、この故障を数ミリ秒でもホールドオフして是正措置を遅らせることを望まないのですから、どの程度の「誤差」を追加するかを特定する必要があります。
このシナリオでは、pos delay triggers line と path で十分でしょう。また、ホールドオフが保証されている場合は、少なくとも 60 ミリ秒の値を考慮します。ネットワークが十分に大きく、ラインおよびパス レベルの故障の発生時にただちに対処する場合、ライン レベルのトリガーを設定する必要はありません。ただし、パス レベルの故障の迅速な処理を有効にするには、pos delay triggers path を値 0 に設定する必要があります。
保護されていない SONET ネットワークでは、最初のシナリオと同じリスクに加えて、さらにいくつかのリスクが生じます。ネットワークが十分に大きい場合、故障はすべてフィルタリングされるため、障害イベント時にルータがライン レベルの故障を認識できない可能性があります。ルータはアップ ストリームとダウン ストリームのパス レベルの故障を確認できます。したがって、障害がネットワーク内で発生した場合、ルータがパス レベルのイベントのみを把握するためルータ間のエンドツーエンドの継続性がない場合もあります。さらに悪いことに、この状況に対処するための SONET レベルでの復元も発生しません。
このシナリオでは、ルータがホールドオフ効果を望まない場合であっても、ルータにパスの故障が発生した場合にルータがシンプルにどちらかの端で対処できるようにするように、パス トリガーを設定する必要があります。パス トリガーを設定している場合、ネットワーク オペレータとして、レイヤ 3 の復元をホールドオフするのとトリガーするのとどちらが適しているかを確認する必要があります。
Cisco IOS ソフトウェア リリース 12.0(28)S では、APS 回線でパス トリガーを有効にできます。ローカルまたはリモート ルータに APS を導入すると、APS スイッチによりリモート動作ルータや保護ルータが短いパス レベルの故障を確認するようになります。この状況では小さいトリガー値でもインターフェイスがダウンしますので、望ましくありません。インターフェイスがダウンすると、進行中のサービスの復旧が遅延します。クラウド内で生じている一時的な障害も、サービスの復旧を遅らせます。しかし、永続的なパス レベルのエラーの発生は、回線保護(ネットワーク内または遠端での)が接続を復元できないことを示しています。この場合、APS ルータが対策を取り、ルーティングの再コンバージェンスを開始する必要があります。100 ミリ秒以上のパス トリガーの遅延値を設定できます。この設定では、永続的なエラーが SONET ネットワーク内またはリモート エンドで発生した場合、ルータは両方の APS インターフェイスをリンク ダウン状態に入れます。こうしてルータはサービスのより高速な再ルーティングと復元を開始します。
このシナリオでは、DWDM ネットワークが SONET プロトコル レベルで参加していないため、パス トリガーを使用する必要はありません。ルータはセクションまたはライン レベルで障害を検出します。
ここでも、DWDM ネットワークは内部で保護されているため、ネットワーク内部の障害の復旧は迅速に行われます。ルータは通常、短い LOS、LOF または BIP エラーのバーストを確認します。
このため、このネットワークでホールドオフが望ましいかどうかだけ決定する必要があります。
遅延を選択した場合、この状況では pos delay triggers line コマンドで十分です。
トランスポート内の DWDM ネットワークが保護されていない場合、ルータ内の障害に対処する必要があります。この状況では、DWDM が SONET プロトコルに参加しないので、デフォルト設定はいずれのルータで発生した障害にも即時に対応できるようになります。この効果を希望する場合は、POS トリガーを設定しないデフォルト設定が適しています。
ホールドオフが必要な場合、この機能を提供するには pos delay triggers line コマンドで十分です。
2 つの POS インターフェイス間でバックツーバッグ接続された 2 つのルータは、直近のシナリオと同じように動作します。SONET オーバーヘッド上で動作する中間機器、または SONET レベルの信号の一部を終了する中間機器がないため、いずれのルータでも障害を迅速に確認することができます。
興味深い状況として、R1 が S-LOS を確認し、R2 が L-RDI と P-RDI の両方を確認する場合があります。R1 は回線終端装置(LTE)およびパス終端装置(PTE)の両方です。 L-RDI は受信時に結果として行われる対策を明示的に拒否するため、R2 は結果としてインターフェイスをドロップします。この問題は、R1 のインターフェイスがダウンしているが、R2 のインターフェイスはアップ状態でトラフィックを転送しているという状況を引き起こす潜在的な可能性があります。もちろん、レイヤ 2 キープアライブ(High-Level Data Link Control(HDLC;ハイ レベル データ リンク制御)が提供するような)はタイムアウトし、設定されたタイマーに基づいて一般的に 30 秒でリンク ダウンを宣言します。ただし、一部の事業者はこれらのレイヤ 2 キープアライブを無効にしているため、この状況を防ぐことはできません。この問題を解決するには次に説明するように複数のアプローチがあり、それぞれのアプローチが異なる視点からこの問題に対処します。
パス トリガーをオンにする:パス トリガーを有効にすると P-RDI がインターフェイスをダウンさせます。迅速な対応とインターフェイスのドロップを引き起こすにはこの方法を使用します。注目すべき点は、L-RDIがGR-253に従って通常の動作時にP-RDIをマスクアウトすることです。POSトリガーが不具合レベルで処理されるため、トリガーはアラームマスキングの前に処理され、インターフェイスは設定遅延時間にドロップします。
レイヤ2キープアライブを有効にする:このオプションを使用すると、3つのキープアライブが失われた後、R2のインターフェイスがタイムアウトします。通常、これは合計 30 秒(3x10)であり、シスコは一般に、クイック リンク コンバージェンスを調整するためのツールとしてこのオプションを使用することは推奨していません。
リンクステートルーティングプロトコルの有効化:R1のインターフェイスがS-LOSのためにダウンすると、リンクステートメッセージがすぐに送信されます。R2 のインターフェイスが引き続きアップ状態であっても、リンクステート メッセージがエリア全体で受信されると、SPF が実行され、リンクの双方向接続チェックが失敗するため、リンクはトポロジから削除されます。これにより、ネットワークがそのシンプレックス シナリオを通じてルーティングされることを防ぎます。
2 つのルータをバックツーバック接続または SONET ネットワーク上で接続すると、提供された運用アーキテクチャが障害シナリオの大部分の検出を行います。
通常、ローカル通知とリモート通知があります。ただし BIP エラーの数が増え、しきい値を超えると(SD または SF、B3-TCA)、この状況が発生したことを示すためのリモート通知は送信されなくなります。したがって、マルチ プロトコル ラベル スイッチング(MPLS)の Fast Reroute 保護を採用すると、トリガーによって即時の保護スイッチが有効になることはありません。リンク上のレイヤ 2 キープアライブまたは内部ゲートウェイ プロトコル(IGP)ピア間の隣接関係の障害を引き起こすのに十分なトラフィックが失われるまで、トラフィックはブラックホール化されたままとなります。場合によってはこれがまったく起こらず、トラフィックのブラックホール化が継続します。
このような状況に対応するため、CSCec85117 は POS および SONET コマンド構造に pos action b3-ber prdi コマンドを採用しました。
このコマンドを使用すると、B3 しきい値を超えたときに P-RDI を送信するようにオペレータがインターフェイスを設定することができます。このオプションでは、トポロジに関係なく、リンクをエンドツーエンドで最適にモニタできます。ルータで pos delay triggers path が有効になっていると、pos action b3-ber prdi コマンドがダウンしたリンク(および対応する Fast Reroute(FRR)またはルーティング アップデート)をアクティブ化します。 これが劣化リンクでのブラックホール効果を回避します。
この操作の感度を変更するには、次のように b3-tca を制御します。
router(config-if)# pos threshold b3-tca ?
提示される値は BER の計算の指数成分です(たとえば、pos threshold b3-tca 3 は 1x10^-3 のレートに相当する B3-TCA を設定する)。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
21-Jul-2005 |
初版 |