概要
ソケットのアップグレード失敗は、初期の展開から予定されたメンテナンスウィンドウや手動のアップグレードまで様々な段階で発生することがあります。 これらの問題を素早く理解し解決することは、ネットワークの整合性を維持するために重要です。 このプレイブックは、アップグレード後にサイトがCatoクラウドへのトンネルを確立できなかったストーリーを説明するために設計されています。
ステップ1 - サイトが切断されていることを確認する
- ホーム > Stories Workbenchに移動し、ネットワーク操作プリセットを選択して閉じられていないまたはミュートされていないサイトダウンストーリーを見つけます。
- ホーム > イベントに移動し、メッセージ"猶予時間後にオープントンネルなし"でアクション失敗とラベル付けされたイベントを検索します。 これらのイベントは、ソケットアップグレード期間終了後にソケットがオフラインと報告されたことを示しています（17分）。
ステップ2 - ソケットのCatoクラウドへの接続を確認する
- ソケットの接続状況は、ソケットWebUIを通じて確認できます。 ローカルでソケットWebUIにアクセスするには、ソケットWebUIへのローカルログインを参照してください。
- ソケット監視タブで、Catoクラウドへの接続に使用されているWANポートを確認します。 リンク状況がダウン（赤）と表示されている場合、ソケットとISPデバイス間にアクティブな物理リンクがあるか確認してください。
- インターネット接続があるがCatoクラウドへの接続がない場合は、トラフィックキャプチャタブに移動し、関連するWANインターフェースを選択してキャプチャを開始します。 1分後にダウンロードして停止をクリックします。
- Catoサポートへのケース作成セクションに進み、収集したすべてのデータを提供します。
ステップ3 - アップグレード後にアクセスできないソケットを解決する
現地の技術者は次のステップを実行する必要があります。
注意: 可能な場合は、ソケットを再起動する前に、Catoサポートに連絡してコンソール経由でソケットログファイルを収集します。 これらのログは根本原因の分析に不可欠です。
-
コンソールログを収集します。 コンソールケーブルをソケットに接続します。 デバイスマネージャー > ポートに移動し、コンソールケーブルのCOMポートを確認します。 Puttyまたは類似の端末アプリケーションを開き、以下のパラメータを使用します。
将来の調査のためにコンソール出力をテキストファイルに保存します。- 物理ソケットの場合、ソケットログが再起動後に失われるため、再起動する前にこのステップを行う必要があります。
- Azure vSocketsでは、AzureのVM > ヘルプ > ブート診断 > シリアルログ > シリアルログをダウンロードからコンソールログを取得できます。 これらのログは最大6回の起動まで収集されます。
- 再起動。 トンネルが確立されない場合には、次のステップは再起動です。または、アップグレード後にソケットがアクセス不能になります。
- ソケットをサイドに割り当て解除して再割り当て。 再起動がトンネル/ソケットの動作を改善しない場合は、CMAでソケットを割り当て解除します。 ソケットが検出されると、数分後にCMA通知に表示されます。 同じサイトにソケットを再割り当てします。
- ソケットをフラッシュします。 CMA通知がない場合、次のステップはソケットを工場出荷時デフォルト状態にフラッシュします。 それを行うには、F/Dボタンを30〜35秒間押し続けるか、USBリセットを行います。
- サポートに連絡。 収集されたコンソールログをサポートに提出し、ソケットのRMAプロセスの開始を要求してください。 上記の手順がすべて実行され、失敗した場合には、このプロセスを開始することをお勧めします。
Catoサポートへのケース作成
上記のトラブルシューティング手順の結果を含むサポートチケットを提出します。 次の情報をチケットに含めてください:
- 影響を受けたソケットの詳細と全体の影響。
- ソケットのアップグレード失敗を示す関連CMAイベントと通知。
- 手動アップグレードとメンテナンスウィンドウ再スケジュールの結果。
- ソケットがアクセス不可になった場合に収集されたコンソールログ。
0件のコメント
サインインしてコメントを残してください。