概概览
Socket升级失败可能发生在各个阶段，从初始部署到计划维护窗口和手动升级。 及时理解和解决这些问题对于维护网络完整性至关重要。 以下是解决Socket升级失败问题的故障排除过程概览。
症状
初始升级失败：发生在Socket部署期间。
维护窗口问题：大量Socket未在计划维护期间升级。
升级失败后建立的隧道：Socket升级失败，但隧道仍保持开启。
升级后无法访问：Socket在升级后变得无法访问。
可能的原因
连接性问题：由于互联网缓慢或MTU设置错误导致超时。
DNS解析失败：无法解析cc2.catonetworks.com。
防火墙限制：具有SSL检查的防火墙。
端口限制：WAN1/Port1限制。
重新安排自动升级
如果由于 ISP 链接不稳定导致升级被跳过，从而导致整个账户的自动升级被跳过，我们可以暂停自动升级为受影响的 Socket，并为下一个维护时间窗口重新安排自动升级。
问题解决后，我们可以手动升级有问题的Socket。
Socket升级失败故障排除
注意：
在开始故障排除之前，请务必了解Socket 升级在Cato中是如何工作的，您可以在以下文章中了解详情：了解Cato的托管Socket升级服务
Socket升级将在CMA中配置的维护时间窗口或初始部署期间进行。 本节将深入探讨解决Socket升级失败问题所涉及的步骤。 升级失败主要有三个可能的结果：
初始Socket升级在Socket部署期间失败。
尽管升级失败，隧道仍然保持开启并已建立。
隧道无法建立，并且Socket在升级失败后变得无法访问。
初始升级失败
当新部署或工厂重置的Socket首次连接到互联网时，它将持续尝试通过其WAN端口连接到Cato，并试图升级其固件版本。
要排除初始升级失败，请查看初始固件升级故障排除
升级失败后已建立隧道
在维护窗口期间，Socket升级过程可能未成功，导致升级失败，阻止整个账户的其他Socket进行升级。 重要的是要识别失败的升级，并在安排新的维护窗口之前专注于升级这些Socket。
分析CMA事件
通过将子类型过滤为Socket升级并将操作过滤为未成功来查看与Socket升级相关的事件。
带有操作已跳过的事件可能表明在维护时间窗口期间Socket处于离线状态，或者不同的Socket未能升级（宽限期后没有打开隧道），导致所有剩余的Socket被跳过。 跳过操作的原因可以在事件消息中看到。 例如：
已跳过升级。 在维护窗口期间主要Socket处于离线状态。
已跳过升级。 已跳过此Socket的待处理升级，因为不同的Socket无法完成升级。
带有操作失败的事件表示尝试进行了Socket升级，但升级过程本身失败了。 失败操作的原因可以在事件消息中看到。
如果Socket在此失败后变得无法访问，请前往隧道在升级后无法建立。
通过关注带有操作失败的Socket继续故障排除过程。
升级过程中故障排除
在升级过程中，Socket将尝试下载固件镜像。 以下原因可能导致超时：
无法正确解析cc2.catonetworks.com的DNS
缓慢或不可靠的互联网连接阻止固件下载。
WAN接口上不正确的MTU设置。
为排除上述原因，请检查以下内容：
使用WebUI中的Ping工具确认Socket可以通过隧道解析cc2.catonetworks.com。 如果FQDN无法解析，请检查WAN端口上的DNS设置。
在网络分析中检查隧道在维护时间窗口期间是否出现数据包丢失。 如果是，请检查是否有最后一英里的数据包丢失，并将此问题报告给ISP。
Cato Sockets通过与PoP进行PMTUD（MTU发现）来确定隧道上允许的MTU。 然而，在WAN接口上手动设置MTU可能导致数据包分段和性能下降。 在WebUI中检查配置的MTU值。
升级后的故障排除
一旦固件已下载并安装到Socket上，Socket将进入宽限期（10分钟），期间将运行多个检查以确定新安装的版本是否稳定：
Socket进程正在运行。
Ping通过互联网工作到cc2.catonetworks.com、8.8.8.8和Facebook
与PoP的连接已建立至少5分钟。
Socket和PoP之间至少有十次成功同步。
cURL通过隧道工作到cc2.catonetworks.com。
如果在宽限期间检查未成功，Socket将回滚到以前的版本，假设新版本不稳定。 确保Socket在升级完成后保持互联网访问10分钟。
执行Socket重启
在某些严重升级失败的情况下，重新启动Socket可能有助于在重新尝试固件升级之前恢复。 如果在升级失败后隧道仍然在线，可以通过WebUI下的管理选项卡进行远程Socket重启。
如果在升级失败后Socket无法访问，请访问升级后隧道无法建立。
手动Socket升级和重新安排
在维护窗口期间操作为已跳过的Sockets可以在Socket上线后从CMA手动升级。 操作为失败的sockets在尝试手动升级之前必须遵循上述故障排除步骤。 有关在CMA中手动升级的信息，请参见CMA手动升级。
对于大型账户，CMA手动升级可能需要很长时间才能完成。 在第一个维护窗口期间故障排除并升级第一个失败（操作为失败）的Socket，然后安排一个新的维护窗口，而不是手动升级每个Socket。 有关在CMA中重新安排维护时间窗口的信息，请参见重新安排升级进程。
如果升级过程在相同或其他Sockets上继续失败，请提交一个支持工单，并附上上述故障排除的结果。
升级后隧道无法建立
分析CMA事件
Socket升级事件操作为失败，事件消息为超出宽限时间后无打开的隧道，表示Socket升级期结束（17分钟）后，Socket被报告为离线。
现场人员需要在现场，并按照解决升级后不可访问的Socket中解释的步骤进行操作。
解决已发现的问题
CMA手动升级
升级失败可能是由于瞬时连接性问题引起的，第二次尝试可能会成功。 要尝试新的Socket升级，手动从站点配置>Socket>操作>升级来启动升级。 请参见手动升级Socket
建议选择最新可用的固件版本，升级机制为“Cato Cloud 启动”。 手动固件升级启动17分钟后，CMA将显示“升级成功”通知，指示Socket在宽限期后报告成功升级。
解决升级后不可访问的Socket
现场人员需要遵循以下步骤：
注意：
在可能的情况下，联系Cato支持，通过控制台在重启Socket之前收集Socket日志文件。 这些日志对于根本原因分析至关重要。
收集控制台日志。 将控制台电缆连接到 Socket。 进入设备管理器 > 端口，并记录控制台电缆的 COM 端口。 打开 Putty 或类似的终端应用程序并使用以下参数。将控制台输出保存为文本文件以供将来调查。
对于物理 Socket，此步骤必须在重启 Socket 之前完成，因为重启后 Socket 日志会丢失。
对于 Azure vSockets，控制台日志可以从 Azure 的 VM > 帮助 > 引导诊断 > 串行日志 > 下载串行日志中获取。 这些日志最多收集 6 次引导。
重启。 如果隧道无法建立或在升级后 Socket 无法访问，下一步是重启。
解除分配并重新分配 Socket 到站点。 如果重启没有帮助开启隧道/Socket，请在 CMA 中解除分配 Socket。 如果检测到 Socket，几分钟后它将出现在 CMA 通知中。 将 Socket 分配回同一站点。
重置 Socket。 如果没有 CMA 通知，下一步是将 Socket 恢复到出厂默认状态。 您可以按住 F/D 按钮 30-35 秒或执行 USB 重置来做到这一点。
联系支持。 提交收集到的控制台日志到支持部门，并请求启动RMA流程以更换Socket。 如果以上所有步骤都已执行且未成功，我们建议启动此流程。
向 Cato 支持提交问题
提交支持工单，附上上述故障排除步骤的结果。 请在工单中包含以下信息：
受影响的 Socket 的详细信息和整体影响。
相关的 CMA 事件和通知显示 Socket 升级失败。
手动升级和维护窗口重新安排的结果。
如果 Socket 无法访问，所收集的控制台日志。