概览
Socket升级失败可能发生在各个阶段，从初始部署到计划维护窗口和手动升级。 及时理解并解决这些问题对于保持网络完整性至关重要。 以下是解决Socket升级失败问题的故障排除过程概览。
症状
- 初始升级失败：发生在Socket部署期间。
- 维护窗口问题：大量Socket未在计划维护期间升级。
- 升级失败后建立的隧道：Socket升级失败，但隧道仍保持开启。
- 升级后无法访问：Socket在升级后变得无法访问。
可能原因
- 连接性问题：由于互联网缓慢或MTU设置错误导致超时。
- DNS解析失败：无法解析cc2.catonetworks.com。
- 防火墙限制：具有SSL检查的防火墙。
- 端口限制：WAN1/Port1限制。
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已经手动或在支持的协助下升级，可以通过更改CMA中的Socket维护窗口日期/时间来安排新建维护时段以升级其余的Sockets。 请参见配置Socket升级维护窗口
此操作将触发CMA通知“可用的Sockets版本升级”，显示将在新建维护时段中升级的Sockets数量。 确保在您安排的新建维护时段至少48小时后计划。 如果距离站点维护窗口开始小于48小时，则站点将等待到下周再启动Socket升级。
解决升级后不可访问的Socket
现场人员需要遵循以下步骤：
注意： 在可能的情况下，联系Cato支持，通过控制台收集Socket日志文件然后重启Socket。 这些日志对于根本原因分析至关重要。
-
收集控制台日志。 将控制台电缆连接到Socket。 转到设备管理器>端口，并注意控制台电缆的COM端口。 打开Putty或类似终端应用程序并使用以下参数。
将控制台输出保存在一个文本文件中以供将来调查。
- 对于物理Sockets，此步骤必须在重启Socket之前完成，因为Socket日志在重启后会丢失。
- 对于Azure vSockets，控制台日志可以从Azure的VM>帮助>启动诊断>串行日志>下载串行日志中获得。 这些日志最多收集6次启动。
- 重启。 如果隧道无法建立或Socket在升级后变得不可访问，则下一步是重启。
- 取消分配并重新分配Socket到站点。 如果重启没有帮助建立隧道/Socket，则在CMA中取消分配Socket。 如果检测到Socket，几分钟后它将出现在CMA通知中。 将Socket重新分配给相同站点。
- 刷新Socket。 如果没有CMA通知，下一步是将Socket刷新到其出厂默认状态。 您可以按住F/D按钮30-35秒，也可以执行USB重置来实现。
- 联系支持。将收集的控制台日志提交给支持，并请求为Socket启动RMA流程。 如果执行了上述所有步骤并且失败，我们建议启动此流程。
将问题报告给Cato支持
提交一个支持工单，并附上上述故障排除步骤的结果。 请在工单中包含以下信息：
- 受影响的Sockets的详细信息和整体影响。
- 相关CMA事件和通知显示Socket升级失败。
- 手动升级的结果和维护时间窗口的重新安排。
- 收集的控制台日志，如果Socket变得不可访问。
0 条评论
请登录写评论。