マルチシェルフの構成例と MS 設定の一般的な問題と解決

MS の設定手順、MS の設定での一般的な問題、および解決方法

概要：
このドキュメントでは、基本的なマルチシェルフ構成の例とトラブルシューティングすべき一般的な問題について説明します。
機能識別子：マルチシェルフ構成の例と一般的な問題のトラブルシューティングおよび解決方法。

前提条件

1)マルチシェルフの概念に関する基本的な知識

2) CTCおよびLCDパネルのプロビジョニングが可能。

3)Cisco 15454 M6およびM12シャーシに関する基礎知識

ドキュメントの概要：

このドキュメントでは、M12 シェルフと M6 シェルフのシスコ マルチシェルフ構成の概要について説明します。
新規調整および運用ノードでの ONS 15454 マルチサービス トランスポート プラットフォーム（MSTP）のマルチシェルフ構成と一般的な問題。すべての問題と回避策/解決策は、報告されるさまざまな現場での問題に基づいて更新されています。

マルチシェルフ構成でのシェルフの種類

•コントローラ シェルフ
•サブテンド シェルフ

ハードウェア要件：

コントローラ シェルフ
1 ～ 29 のサブテンド シェルフ（M6 シェルフをノード コントローラとして使用する場合）。
2 台の Catalyst スイッチまたは 2 つの MS-ISC カード（M12 シェルフをノード コントローラとして使用する場合は、MS-ISC カードのみ使用）

 マルチシェルフの接続図：

 


ノード コントローラとしてスイッチに接続する M12：

ONS 接続へのスイッチの詳細：
ONS 15454 ノード コントローラ シェルフ
•TCC 7 から Catalyst 1 ポート 1
•TCC 11 から Catalyst 2 ポート 1
ONS 15454 サブテンド シェルフ 1 ～ 7
•N シェルフ TCC 7 から Catalyst 1 ポート n
•N シェルフ TCC 11 から Catalyst 2 ポート n
Catalyst 接続
•各 Catalyst ポート 23 からネットワーク
・ Catalyst 1ポート22からCatalyst 2ポート22
 マルチシェルフは内部 IP アドレスを使用します。
・ 192.168.190.16x（x=シェルフ番号）:2、3、4、5、6、7、または 8）
コントローラ シェルフへの Telnet 接続
ログイン
シェルフ 2 が正しくプロビジョニングされている場合、「192.168.190.162」に対して ping を実行すると応答が得られます。

コントローラ シェルフのプロビジョニング：

• [Shelf] > [Provisioning] > [Multishelf] に移動します。
• [Enable as Node Controller] をクリックします。
• [Stand-alone] を選択します。
• Apply をクリックします。

選択して [Apply] をクリックすると、シェルフが再起動し、ノード コントローラ シェルフとして表示されます。

Catalyst スイッチの基本設定

トランク ポート
•ポート 1 と 22 がトランク ポートです。
アクセス ポート
・ポート2 ～ 8はVLAN 2のアクセスポートです
•ポート 23 と 24 は VLAN 1 のアクセス ポートです。
その他のポートは無効になっています。
ポート 1 およびポート 22 をトランク ポートとしてプロビジョニング：
Switch(config)#int fa0/1
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk encap dot1Q
Switch(config-if)#switchport trunk allowed vlan 1,2
Switch(config-if)#switchport nonegotiate
Switch(config-if)#switchport trunk pruning vlan none

ポート 2 およびポート 21 をアクセス ポートとしてプロビジョニング：
Switch(config)#int fa0/2
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 2

VLAN 1 のポート 23 のプロビジョニング（外部ネットワークへのスイッチから接続します）
Switch(config)#int fa0/23
Switch(config-if)#switchport mode access
Switch(config-if)#switchport access vlan 1

MS 接続のために MS-ISC を使用している場合は、MS-ISC には事前に設定されている ML カードがあり、次に説明するように接続する必要があります。
ONS 15454 コントローラ シェルフ
•TCC 7 から MS-ISC 左ポート 9
•TCC 11 から MS-ISC 右ポート 9
ONS 15454 サブテンド シェルフ 1 ～ 7
•N シェルフ TCC 7 から MS-ISC 左ポート n
•N シェルフ TCC 11 から MS-ISC 右ポート n
MS-ISC 接続
•各 MS-ISC ポート 0 からネットワーク
・ MS-ISC左ポート10からMS-ISC右ポート10

サブテンド シェルフのプロビジョニング

CTC でサブテンド シェルフに接続します。
・ [Shelf] > [Provisioning] > [Multishelf Config]を選択します。
・ [Enable as Subtending Shelf]を選択します。
•シェルフ ID を選択します。
または前面パネルから設定します。
•MS メニューまでスクロールします。
・ [MS=Y]を選択します。
・シェルフ番号= nを選択します。
・イーサネット= Yを選択します。





成果
•どちらの TCC もアクティブではない状態でシェルフが再起動します。
•LCD ウィンドウに「Waiting for CT」と表示されます。
コントローラ シェルフに移動します。
・ [Shelf] > [Provisioning] > [Multishelf]に移動します。
・最初のマルチシェルフを右クリックします。
・ [Add Shelf with number = n]を選択します。
・スタンドアロンをイーサネットに変更
・ [Apply]をクリックします。
成果
•マルチシェルフが再起動し、コントローラ シェルフからダウンロードします。
・ CTCウィンドウがマルチシェルフ構成に変更
CTC からのマルチシェルフ ビュー  


マルチシェルフのプロビジョニングに関するドキュメントの参照リンク：
http://www.cisco.com/c/en/us/td/docs/optical/hardware/15454install/guide/hig15454/hig_15454.html#wp546337

http://www.cisco.com/en/US/partner/docs/optical/hardware/15454install/guide/hig_15454.html#wp547312

マルチシェルフ プロビジョニングの一般的な問題と解決方法の詳細：

問題 1：
既存のマルチシェルフ構成への新しいシェルフの挿入。

解決策：

• 新しいマルチシェルフ（シェルフ4など）を既存の3シェルフのマルチシェルフ構成に挿入する予定でしたが、新しいシェルフを挿入しようとすると、シェルフIDを変更するオプションがLCDパネルに表示されませんでした。シェルフ4から両方のコントローラカードを取り外し、シェルフ4のスロット8にシェルフ3スロット3のスタンバイTNCカードを挿入しました。LANケーブルの再接続後、CTCにシェルフ4を追加できました。
• しかし、シェルフ 4 のスペア TNC-E カードをシェルフ 3 のスロット 8 に挿入しようとしたところ、これらのカードが起動しませんでした。
• シェルフ 4 に TNCE カードを挿入してもこれらのカードは起動しないため、新しい TNCE カードが不良であると考えました。
• ノードのソフトウェア リリースを確認したところ 9.21 であり、TNCE カードはこのリリースの TNC カードと互換性がありませんでしたが、リリース 9.30 より後では互換性があります。
• TNC カードを取り外し、シェルフ 3 のスロット 8 に挿入したところ、起動しました。

問題 2
シェルフ 2 でのシェルフ通信の失敗

解決策：

• サイトのフィールド技術担当員が、両方の LAN ポートがブロック/無効状態であることを検出しました。
• 取り外してから再び差し込んだところ、問題が解決しました。

問題 3

TCC3 カードが装着されている M12 NC に M6 をサブテンド シェルフとして追加しましたが、サブテンド シェルフの TNC カードでサブテンド カード ソフトウェアのダウンロードが失敗しました。

解決策：

• 分析の結果、ノード コントローラ TCC3 でライト ソフトウェア バージョンが保護パーティションにロードされていたことが判明しました。TNC/TSC ではライト バージョンはサポートされていないため、この問題が発生しました。ノード コントローラ シェルフにフル バージョンを保護としてロードする必要があります。
• フル バージョンを保護パーティションにロードした後（フル バージョンを再度ダウンロードした後）で、サブテンド シェルフは NC からソフトウェアを取得でき、マルチシェルフ構成が正常に完了しました。

問題 4

[Its Completely New Node*** Multi-shelf and VLAN provisioning] ボタンがグレー表示されていました。

解決策：
LCDボタンを使用してプロビジョニングを変更できません。CTCキャッシュを削除し、変更はありません。データベースを削除し、その後マルチシェルフに変更できました。

問題 5
MW で  M12 シェルフを M6 ノード コントローラにサブテンドする予定でした。

解決策：

• M12 シェルフは TCC3 カードを使用して準備されており、NC にサブテンドされましたが、起動しませんでした。シェルフのすべてのコントローラのリセット/再設置を試行しましたが、シェルフ 2 は起動しませんでした。
•  サイトで 2 つの TCC2P カードを準備しました。
• このうちの 1 つを M12 に追加し、NC でサブテンドするシェルフ 2 に設定しましたが、これも失敗しました。
• 次に、もう 1 つのスペア TCC2P カードを使用しました。正しい MSTP ソフトウェアをダウンロードし、ノード コントローラにこれをサブテンドしました。この方法が成功し、シェルフ 2 が追加されました。次に、TCC2P カード（以前は機能しなかったカード）をスタンバイに追加しました。
• MSPP SW リリースが含まれていることが検出され、失敗しました。他の 2 つの TCC3 カードでも同様の問題が発生しました。
• TCC3 カードはスタンバイとして起動すると、アクティブ コントローラから正しいソフトウェアをコピーしました。
• 次にサイド スイッチ オーバーが実行され、別の TCC3 も追加されました。TCC3 カードを使用してサブテンド シェルフが適切に起動しました。
• TCC3 カードには正しいソフトウェア コピーが含まれていませんでした。

問題 6
マルチシェルフでの 9.21 から 9.605 2d シェルフへのアップグレードが失敗しました。

9.221 から 9.605 へのノードのアップグレード後に、シェルフ 2 がアップグレードしませんでした。
デバッグでは、シェルフ 2 の TNC スロット 1 でソフトウェア 9.605 が示されず、スロット 8 のその他の TNC はスタンバイとして示され、両方のソフトウェアがあることが示されました。シェルフ通信障害アラームがシェルフ 2 で観測されました。

解決策：

• TNC カードをスロット 1 から取り外します。
• スロット 8 が引き継がない場合は 10 分間待機してから、スロット 8 の TNC カードを装着し直します。
• シェルフ 2 が起動した後で、スロット 1 をシェルフに挿入します。

推奨アクション プランの実行後に問題が解決しました。

問題 7
新しいサブテンド シェルフを追加したところ、新しいシェルフの TNC-E がロード中の状態のままになります。

解決策：

•  ノード コントローラのソフトウェアのバージョンが 9.203 です。
• サブテンド シェルフには TNC-E コントローラ カードが装着されています。
• TNC-Eカードは9.3より前のソフトウェアをサポートしていないため、問題が発生し、ロード状態に継続的に表示されます。9.605にアップグレードされ、サブテンドシェルフが正常にメインシェルフに追加されました。

問題 8

M6 サブテンド シェルフ 4 が、M12 ノード コントローラを備えたマルチシェルフに追加されません。

解決策：

•  シェルフ 4 のマルチシェルフ構成を LCD から正常に変更しました（例：MS=Y、ID=4、VLAN=Y など）。
• スイッチが接続されたシェルフ4がマルチシェルフとして追加されず、両方のTSCカードでLEDステータスが表示されません。
• スイッチ接続後にシェルフ 4 のカードが起動しませんでした。
• そこで LCD を取り外し、sl-1 を取り外し、sl-8 TSC カードだけをシェルフに残した状態で、ECU の MSM ポートに LAN ケーブルを接続したところ機能し、sl-8 カードが起動しアクティブになりました。
• 次に sl-1 と LCD を挿入したところ、シェルフが CTC シェルフ 4 で通常通りに起動しました。

問題 9
ローカル ログインから M6 ノードに接続できません。

解決策：

•  ノードに対して ping を実行できませんでした。LCD パネル LED は、SC がプロビジョニングとマルチシェルフを待機していることを示しました。  これは
  スタンドアロンノードであることが想定されています。マルチシェルフ構成を無効にするには、LCDボタンを使用します。  TNC リセット後に、ノードにローカル ログインできました。

問題 10

シェルフのすべてのカードが断続的に再起動します。

• ノード ソフトウェアのバージョン：9.211
  シェルフ 3 のスロット 7 がアクティブであり、スロット 11 がスタンバイです。
   1 ～ 2 分経過後に、スロット 7 のカードが定期的にロード中状態になり、スロット 1、3、12、13、14、17 のトランスポンダ カードがすべてロード中状態になります。
  スロット 7 がロード中状態であるときに、スロット 11 もロード中状態になり、アクティブになりません。
   Telnet セッションからこのカード（スロット 7）のリセットを試行しましたが、スロット 11 がアクティブになりませんでした。
   スロット 11 がアクティブになった後で、しばらくすると再びロード中状態になり、すべてのトランスポータ カードから装置障害が報告されました。

解決策：
サイトにフィールド技術担当員がいるときに実行したアクションは次のとおりです。

• スロット 7 を取り外し、スロット 11 がアクティブな状態で、他のカードの LED 表示を確認しました。他のすべてのカードがロード中状態であることを示しました。
• スロット 11 カードも取り外してから、新しいスペア カードをスロット 7 に挿入しました。
• カードは正常に起動しましたが、このカードがノード コントローラ カードとして示され、メイン コントローラ カードと通信できませんでした。
• ローカル ログインしてサブテンド シェルフへ変更しようとしましたが、Java の互換性がないことが原因で、ローカル ログインができませんでした。
• LCD パネルからマルチシェルフに設定しようとしましたが、現場技術担当員は LCD パネルで MS 構成のオプションにアクセスできませんでした。非常に不可思議です。
• LCD を装着し直しましたが、状況は変わりませんでした。
•  シェルフコントローラカードの両方を取り外し、コントローラカードをシェルフ2から取り外し、シェルフ3のスロット7に挿入するとカードが正常に起動し、MS設定を変更するオプションが表示されました（この時点で、シェルフ3からすべてのLAN接続を削除しました）
• これをシェルフ 3 に変更し、以前にマルチシェルフ構成で接続されていたとおりに接続したところ、シェルフ 3 が再び通信できるようになりました。
•  スロット 11 に新しい TCC2P カードを挿入したところ、正しくスタンバイとして起動しました。
• すべてのカードを 1 つずつ挿入したところ、すべてのカードが正しく起動しました。
•  このアクティビティが観測されなくなった後で、シェルフを再起動したところ、すべてのトラフィック カードの自動再起動が停止しました。
• 新しい TCC カードを用意してシェルフ 2 のスロット 11（シェルフ 3 の復元のために、以前にカードを取り外したスロット）に装着したところ、カードは正常にスタンバイとして起動しました。
• トラフィックが動作していることが確認されました。

問題 11

TCC3 で 9.6.05 が稼働する M12 シェルフ（M6 シェルフの追加を試行したシェルフ）で、TSC-E で同じバージョンが稼働していましたが、ソフトウェア ダウンロード プロセスが 18 時間にわたり停止しませんでした。

解決策：

• スイッチの設定を調べたところ、特に問題はありませんでした。
• マルチシェルフ構成の削除を試行しました。
• ノード コントローラから 3 番目のシェルフを削除しました。
• LAN 接続から接続解除しました。
• 個別に起動しました。
• ノード コントローラでアクティブ/スタンバイの変更を試行しました。
• ノード コントローラに新しいノードを再び追加しました。
• LAN に接続しました。
• 新しいシェルフ 3 のスロット 8 でソフトウェア ダウンロード プロセスを実行したところ、ループ状態のままになりました。
• それ以降起動しなくなりました。
• スロット 8 TSCE を削除しました。
• ソフトウェア ダウンロード プロセスが終了しましたが、ロード中状態から起動することはありませんでした。
• 解決の概要：
• シェルフ 3 を MS 構成から削除し、flmdelete db,usb を
• スタンドアロン モードのシェルフ 3 で実行し、シェルフに直接ログインし、CTC からこれをサブテンド シェルフ 3 にしました。
• メイン ノード コントローラで、動作するソフトウェア ロードがフル バージョンであり、保護ソフトウェア ロードがライト バージョンであることが観測されました。
• フル バージョンを保護フラッシュ パーティションにダウンロードし、シェルフ 3 を MS に接続したところ、シェルフ 3 が正常に起動しました。

問題 12

シェルフ 4 でシェルフ通信障害アラームが発生しました。
シェルフ 4 のスロット 7 の TCC2P カードで再起動が繰り返し実行され、スロット 11 でのみ
PWR-A と PWR-B が緑色になり、このカードのそれ以外のライトは点灯しませんでした。

解決策：

•  VxWorks（shelfConns）で確認したところ、使用停止シェルフ リストにシェルフ 4 がないことが判明しました。
• スロット 7 は再起動を繰り返す状態であり、TCC2P カードがノード コントローラと正しく通信しておらず、shelf-comm alarm を宣言したと見込まれます。
• スロット 11 にはアクティブとスタンバイのどちらのステータスも示されませんでした。
• この問題の原因は、NC と通信していないシェルフ 4 の TCC2P カードにあると考えられました。
• シェルフ 4 に接続しているスイッチ ポートを変更することが推奨されました。
• スイッチ ポートを変更すると問題が解決し、シェルフ 4 を確認できました。
• シェルフ 4 のスロット 7 の TCC カードがロード中状態のままになるため、このカードを装着し直しました。
• EQPT 障害が報告され、起動しませんでした。
• スロット 7 にスペア TCC を挿入したところ、起動が完了するまでに約 20 分かかりました。
• シェルフ 4 のスロット 7 はスタンバイとして起動し、スロット 11 がアクティブでした。

問題 13

TSC を備えた M6 シャーシを既存の M12 マルチシェルフに追加できません。

解決策：

• 問題の項で説明したように、TCC3 カードと R9.603 フルバージョンがノード コントローラ シェルフに含まれています（ノード コントローラは TCC3 カードを備えた M12 でした）。
• Webex と Telnet でノードに接続し、fimStat をダンプ出力したところ、保護パーティションにライト バージョン r9.603 がロードされていることが示されました。
• ノード コントローラにフルバージョンの R9.603 をダウンロードし、m6 シャーシの追加を再試行しました。この操作の後に TSC が正常に起動しました。

問題 14

既存のマルチシェルフ ノードに M12 ノードと M6 ノードの追加を試行します。

解決策：

• M12 シェルフはシェルフ 3 として正常に起動しました。ただし M6 シェルフは起動しません。TNC カードの LED は点灯せず、Link/Act だけが点灯します。ディスプレイに「SC waiting Prov」と表示されます。 M6 が 10 ～ 15 分間隔で再起動します。
•  この問題は、スイッチへの M6 ポートのパッチが適切でなかったことを示しています。MS スイッチを M6 TNC
• LAN ポートに装着しました。  MSM p1 にケーブルを移動しました。  ノードは正常に起動しました。

問題 15

シェルフ 2 でシェルフ通信障害が発生しました。

解決策：

• 両方のシェルフ コントローラ カードがアクティブまたはスタンバイのいずれも示していません。
• TCCカードをノードコントローラから取り外し、TCCを挿入しましたが、CTCおよびLCDを介してシェルフIDを変更できませんでした。TCCカードをノードコントローラに取り付けて完全に起動し、DB同期で正常ににに起動したしたスロットスロット111111111111111111111111111111111111111111111111111111100000000000シェルフの通信が復元されたことを確認しました。

問題 16
新しいシェルフの追加が行われません。

解決策：

• 新しい M6 シェルフには TSC カードが装着されています。
• ノード コントローラ シェルフのソフトウェア バージョンは 9.604、保護フラッシュでは 9.40（ライト バージョン）でした。M6 TSC カードでは 9.40 ライト バージョンがサポートされておらず、これが原因で SS M6 が起動できませんでした。
• フル ソフトウェア バージョン 9.604 をコントローラと M6 シャーシにダウンロードしたところ、接続完了後にすべて正常に起動しました。

問題 17

ソフトウェア アップグレード中にサブテンド シェルフが失われ、シェルフ通信障害が発生しました。
マルチシェルフ構成で外部スイッチが使用されていました。

解決策：

• ソフトウェアのアクティベーション中に、TCC カードが再起動し、これが原因で TCC イーサネット ポートとスイッチ イーサネット ポート間の接続がドロップしました。
•  TCC の起動完了後に、サブテンド シェルフとメイン シェルフ間の通信が復元されませんでした。
•  この 2 つのシェルフ間の通信はスイッチ経由でなされます。
•  TCC カードのイーサネット ポートは 10Mbps、半二重であることに注意してください。
  この例ではスイッチ インターフェイスが 100Mbps、全二重自動ネゴシエーションです。
•  したがって、TCC の再起動後にスイッチ インターフェイスは速度とデュプレックス設定をネゴシエートできませんでした。このため、スイッチ インターフェイスを半二重、10Mbps に変更しました。

問題 18

ノードのシェルフ 5 のすべてのカードがロード中状態になります。

解決策：

• シェルフ 5 ですべてのカードが連続的にロード中状態になり、スロット 8 がアクティブでした。
• スロット 8 がロード中状態の場合、スロット 1 をアクティブにすることはできません。
• シェルフ 5 に Telnet 接続しようとしましたが、内部に到達できませんでした。
• シェルフ 5 のスロット 8 からカードを取り外したところ、処理が安定しました。
• シェルフ 5 内部での Telnet 接続は可能であり、正しいステータスが示されました。
• スロット 8 に新しいカードを挿入したところ、スロット 8 のすべてのプロビジョニング情報がコピーされました。
• シェルフ 5 は正常に稼働しました。

MS のプロビジョニング前の重要なポイント：

• 使用しているノード コントローラ カードのタイプ（TCC3 を備えた M12 シェルフの場合）。M12 コントローラの下に M6 シェルフをサブテンドする場合は、TCC3 カードにライト バージョンではなくフル ソフトウェア バージョンがロードされていることを確認します。
• M6 シェルフをノード コントローラとして使用している場合、ECU の EMS ポートが外部スイッチに接続され、MSM ポートがマルチシェルフ ノード カスケードのために使用されます。
• スイッチからコントローラ カード/サブテンド シェルフ カードへの接続を最初に確認してから、それ以降の装置レベルでの回避策に進みます。
• ノードで実行されたプロビジョニングのタイプを示す LCD パネル プロビジョニング ステータスを確認します。
• ノードコントローラとシェルフコントローラのLED表示を確認します。他のメイトのコントローラカードがロード状態であるか、重大なアラームが発生している場合は、カードを取り付け直さず、TACに連絡してトラブルシューティングを進めてください。