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