概要
ソケットアップグレードの失敗は、初期導入からスケジュールされたメンテナンスウィンドウ、手動アップグレードまでのさまざまな段階で発生することがあります。 これらの問題を即座に理解し解決することは、ネットワークの整合性を維持するために重要です。 ここでは、ソケットアップグレード失敗のトラブルシューティングプロセスの概要を紹介します。
症状
- 初期アップグレード失敗: ソケット導入時に発生します。
- メンテナンスウィンドウの問題: スケジュールされたメンテナンス中に多くのソケットがアップグレードされませんでした。
- 失敗したアップグレード後の確立されたトンネル: ソケットのアップグレードは失敗しましたが、トンネルは接続されたままです。
- アップグレード後のアクセス不可: アップグレード後、ソケットがアクセス不可になります。
可能な原因
- 接続性の問題: 遅いインターネットまたは不適切なMTU設定によるタイムアウト。
- DNS解決の失敗: cc2.catonetworks.comを解決できない。
- ファイアウォールの制限: SSL検査を行うファイアウォール。
- ポートの制限: WAN1/Port1の制限。
自動アップグレードを再スケジュールする
アップグレードが欠落した理由がflappingなISPリンクによるもので、アカウント全体の自動アップグレードがスキップされた場合、影響を受けたソケットのために自動アップグレードを一時停止して次のメンテナンスウィンドウに再スケジュールできます。
一度問題が解決されたら、問題のあるソケットを手動でアップグレードすることができます。
ソケットアップグレード失敗のトラブルシューティング
注意
注意: トラブルシューティングを開始する前に、次の記事でCatoでのソケットアップグレード方法を理解していることを確認してください: Understanding Cato's Managed Socket Upgrade Service
ソケットのアップグレードはCMAで設定されたメンテナンスウィンドウ中または初期展開中に行われます。 このセクションでは、ソケットアップグレード失敗のトラブルシューティングに関与するステップについて詳しく掘り下げます。 アップグレード失敗には主に3つの可能性があります：
- 初期ソケットアップグレードは、ソケットの展開中に失敗します。
- アップグレードの失敗にもかかわらず、トンネルは確立され続けています。
- トンネルが確立されず、アップグレード失敗後にソケットがアクセス不可になる。
初期アップグレード失敗
新たに導入されたまたは工場出荷状態にリセットされたソケットが初めてインターネットに接続されると、WANポートを介して継続的にCatoに接続を試み、ファームウェアバージョンのアップグレードを試みます。
初期アップグレードの失敗をトラブルシュートするには、初期ファームウェアアップグレードの失敗のトラブルシューティングを参照してください
アップグレード失敗後にトンネルが確立される
メンテナンスウィンドウ中に、ソケットのアップグレードプロセスが成功しない可能性があり、そのためのアップグレードの失敗が、アカウント内の他のソケットがアップグレードされるのを妨げることがあります。 失敗したアップグレードを特定し、新しいメンテナンスウィンドウをスケジュールする前にそれらのアップグレードに集中することが重要です。
CMAイベントの分析
サブタイプをソケットアップグレード、アクションを失敗としてフィルターしてソケットアップグレード関連イベントを確認します。
スキップのアクションを持つイベントは、メンテナンスウィンドウ中にソケットがオフラインであったか、または別のソケットがアップグレードに失敗した（猶予期間後にオープントンネルなし）ために全ての残りのソケットがスキップされたことを示している可能性があります。 スキップされたアクションの理由はイベントメッセージで確認できます。 例：
- アップグレードがスキップされました。 メンテナンスウィンドウ中にプライマリソケットがオフラインでした。
- アップグレードがスキップされました。 このソケットの保留中のアップグレードをスキップしました。他のソケットがアップグレードを完了できなかったためです。
失敗のアクションを持つイベントは、ソケットのアップグレードが試行されたが、アップグレードプロセス自体が失敗したことを示しています。 失敗したアクションの理由はイベントメッセージで確認できます
この失敗の後、ソケットがアクセス不可能になった場合は、アップグレード後にトンネルを確立できないを参照してください。
アクションが失敗したソケットに焦点を当ててトラブルシューティングプロセスを続行します。
アップグレード時のトラブルシューティング
アップグレードプロセス中、ソケットはファームウェアイメージをダウンロードしようとします。 次の理由でタイムアウトが発生する可能性があります：
- cc2.catonetworks.comのDNSを正しく解決できない
- 遅いまたは信頼性の低いインターネット接続がファームウェアのダウンロードを妨げる。
- WANインターフェースでの不適切なMTU設定。
上記の理由を除外するために、次の事項を確認してください：
-
WebUIのPingツールを使用して、ソケットがトンネルを介してcc2.catonetworks.comを解決できることを確認してください。 FQDNが解決できない場合は、WANポートでDNS設定を確認してください。
-
ネットワークアナリティクスでメンテナンスウィンドウ中にトンネルがパケットロスを示したかどうかを確認してください。 その場合、最終区間のパケットロスがあるかどうかを確認し、この問題をISPに報告してください。
- Catoソケットは、トンネル上で許可されているMTUを決定するためにPoPと共にPMTUD（MTU検出）を実行します。 しかし、WANインターフェースでMTUを手動で設定すると、パケットの断片化やパフォーマンスの低下を招く可能性があります。 WebUIで設定済みのMTU値を確認してください。
アップグレード後の失敗のトラブルシューティング
一度ファームウェアがソケットにダウンロードされインストールされると、ソケットはグレース期間（10分）に入り、そこで新しくインストールされたバージョンが安定しているかを判断するためのいくつかのチェックが実行されます：
- ソケットプロセスが実行中です。
- Pingはインターネット経由でcc2.catonetworks.com, 8.8.8.8、Facebookに対して機能します
- PoPへの接続が少なくとも5分間確立されました。
- ソケットとPoPの間で少なくとも10回以上の同期が成功しました。
- cURL はトンネル経由でcc2.catnetworks.comにアクセスします。
グレース期間中にチェックが成功しない場合、ソケットは新しいバージョンが不安定であると仮定して元のバージョンにロールバックされます。 ソケットがアップグレード完了後に10分間インターネットアクセスを維持することを確認してください。
ソケットの再起動を実行
いくつかの致命的なアップグレード障害において、ソケットを再起動することはファームウェアのアップグレードを再試行する前に役立つかもしれません。 アップグレード障害後もトンネルがまだ有効であれば、「WebUI」の管理タブからリモートでソケットを再起動できます。
アップグレード障害後ソケットがアクセス不能である場合は、「アップグレード後にトンネルの確立に失敗」に移動してください。
手動ソケットのアップグレードと再スケジュール
メンテナンスウィンドウ中にスキップアクションがあるソケットは、ソケットがオンラインに戻ったらCMAから手動でアップグレードできます。 失敗したアクションがあるソケットは、手動でアップグレードを試みる前に上記のトラブルシューティング手順に従う必要があります。 CMAでの手動アップグレードに関する情報については、「CMAマニュアルアップグレード」を参照してください。
大規模アカウントのため、CMA手動アップグレードが完了するまでに時間がかかる場合があります。 各ソケットを手動でアップグレードする代わりに、最初のメンテナンスウィンドウで失敗したソケット（アクション失敗）のみをトラブルシューティングしてアップグレードし、次のメンテナンスウィンドウをスケジュールすることができます。 CMAでメンテナンスウィンドウを再スケジュールする情報については、アップグレードプロセスの再スケジュールをご覧ください。
アップグレードプロセスが同じまたは他のソケットで失敗し続ける場合は、上記のトラブルシューティング結果を添えて、サポートチケットを提出してください。
アップグレード後にトンネルの確立に失敗
CMAイベントの分析
ソケットアップグレードイベントで、アクション失敗およびイベントメッセージ猶予時間後に開かれたトンネルなしが示すのは、ソケットがソケットアップグレード期間終了後（17分）にオフラインとして報告されたことです。
現地のスタッフは現地にいて、アップグレード後のアクセス不可ソケットを解決するで説明されている手順に従う必要があります。
発見された問題の解決
CMA手動アップグレード
アップグレードの失敗は、一時的な接続性の問題によって引き起こされた可能性があり、2回目の試行で成功する可能性があります。 新しいソケットアップグレードを試みるには、サイト設定 > ソケット > アクション > アップグレードから手動でアップグレードを開始します。 ソケットを手動でアップグレードするを参照してください
アップグレード方式が「Cato Cloud Initiated」である最新のファームウェアバージョンを選択することをお勧めします。 手動ファームウェアアップグレードが開始されてから17分後に、CMAは「アップグレードが正常に完了しました。」という通知を表示し、ソケットが猶予期間後にアップグレードに成功したことを示します。
アップグレード後のアクセス不能なソケットの解決
現地のスタッフは、次のステップに従う必要があります：
注: 可能な限り、ソケットを再起動する前にコンソール経由でSocketログファイルを収集するためにCatoサポートに問い合わせる。 これらのログは根本原因の分析にとって重要です。
-
コンソールログを収集します。 コンソールケーブルをソケットに接続します。 デバイスマネージャー > ポートに移動し、コンソールケーブルのCOMポートに注意します。 PuTTYまたは同様のターミナルアプリケーションを開き、以下のパラメータを使用します。
将来の調査のためにコンソール出力をテキストファイルに保存します。
- 物理的なソケットでは、ソケットログは再起動後に失われるため、ソケットを再起動する前にこのステップを完了する必要があります。
- Azure vSocketsの場合、VM > ヘルプ > ブート診断 > シリアルログ > シリアルログをダウンロードからAzureでコンソールログを取得できます。 これらのログは最大6回のブーツまで収集されます。
- 再起動します。 トンネルの確立に失敗したり、アップグレード後にソケットがアクセス不能になった場合、次のステップは再起動です。
- ソケットをサイトに割り当て解除し、再割り当てします。 再起動がトンネル/ソケットの起動に役立たない場合は、CMAでソケットを割り当て解除します。 ソケットが検出されると、数分後にCMA通知に表示されます。 ソケットを元のサイトに再割り当てします。
- ソケットをフラッシュします。 CMA通知がない場合は、次のステップとしてソケットを工場出荷時のデフォルト状態にフラッシュします。 F/Dボタンを30-35秒間押し続けるか、USBリセットを実行してこれを行います。
- サポートへのお問い合わせ。 収集したコンソールログをサポートに投稿し、ソケットのRMAプロセスを開始するように依頼してください。 上記のすべての手順を実行して失敗した場合、このプロセスを開始することをお勧めします。
Catoサポートへのケースの提出
上述のトラブルシューティング手順の結果を添えてサポート チケットを提出してください。 チケットに次の情報を含めてください：
- 影響を受けたソケットおよび全体的な影響の詳細。
- ソケットアップグレード失敗を示す関連CMAイベントおよび通知。
- 手動アップグレードおよびメンテナンスウィンドウ再スケジュールの結果。
- ソケットがアクセス不可能になった場合に収集されたコンソールログ。
0件のコメント
サインインしてコメントを残してください。