Cisco Catalyst 9000系列交换机已经成为许多企业的交换机选择，包括我所工作的环境，其中运行直布罗陀-16.12.3代码的Cisco Catalyst 9300 24和48端口交换机已经成为接入层的标准，当需要超过12个端口时。
那是大约两年前的事了，大约一年后，我们开始收到来自某个现场位置的通知，说该站点出现了间歇性的网络中断和性能下降。这是我们如何找到解决问题的方法，直到思科提供了一个永久的解决方案。
我们开始排除问题，并发现了以下syslog消息，我们以前从未见过:
- %PLATFORM-3-ELEMENT_TMPFS_CRITICAL: Chassis 1 R0/0: smand: 1/RP/0: TMPFS值55% above critical level 50%。
- %PLATFORM-4-ELEMENT_WARNING: Switch 2 R0/0: smand: 1/RP/0:已用内存值95%超过警告级别90%
一旦我们发现了这些问题，我们向思科技术援助中心(TAC)打开了一个案例，并描述了一些症状:CPU进程高、性能慢，以及交换机崩溃和重启本身导致的网络中断。Cisco TAC告诉我们，直布罗陀-16.12.3代码中有一个漏洞——TMPFS中的内存泄漏，它将所有文件保存在虚拟内存中。他们还告诉我们，这个问题没有解决办法。
我们使用思科漏洞搜索工具找到了更多信息，并发现:“催化剂9300可能会重新加载，因为TMPFS (RAMDISK)的内存泄漏。在"的输出显示平台软件挂载交换机主R0/tmp使用的内存不断增加。泄漏正在影响所有堆栈成员。”
我们还发现这个问题始于直布罗陀16.11.1代码发行版，当我们意识到这个问题时，还没有确定的修复方案，但我们确实提出了两个解决方案，帮助减轻了这个问题的严重性。
夜间重新加载
我们注意到一些开关要坠毁并重新启动,这将恢复到正常的CPU利用率,所以管理员的想法利用嵌入的事件管理器(思科IOS的一部分)阶段的计划重新启动开关。管理员使用这个命令写了一个脚本:“事件定时器cron cron-entry”然后是重新加载开关的时间，然后发出“行动重新加载”命令。
经过一些测试，我们发现这允许我们在晚上重新加载交换机，从而清空内存，并防止CPU占用在第二天过载，防止交换机崩溃。根据您的环境、策略和过程，您可能无法在夜间重新启动交换机，因为这将导致在需要网络时它们不可用。在我们的例子中，某些大楼的工作人员是24x7，因此无法使用这个脚本重新加载交换机，而不会造成中断。
Splunk警报
对于那些不允许夜间重新加载的网站，我们找到了一种方法，在崩溃可能发生时发出警告，这样我们就可以进行干预。
其中一名技术人员在Splunk中创建了一个警报，查找TMPFS阈值syslog消息，并向团队发送电子邮件，通知我们CPU的峰值达到了75%。然后，只有在必要时，我们才可以重新启动开关，有时是远程重启，但有时是直接进入机器。(这花费了大量时间，给网络团队和终端用户带来了挫折，他们不得不等待交换机和他们的设备恢复在线。)
Splunk监控还允许我们记录哪些开关达到了75%的阈值，以及这种情况发生的频率。
决议
当直布罗陀16.12.4代码发布时，我们安装了它，但它没有解决问题。我们继续与思科TAC就该问题进行沟通，并继续每晚重新加载交换机，并接收关于TMPFS阈值的Splunk通知作为解决方案。在与TAC保持了几个月的联系后，我们被告知Gibraltar16.12.5代码即将发布，我们希望它能够解决TMPFS问题。我们将实验室的开关升级到新代码，并对它们进行密切监控，结果发现这是一个巨大的成功。将代码升级到16.12.5解决了内存泄漏问题。
到目前为止，我们已经将超过60%的交换机迁移到16.12.5，并且问题更少，性能更好。
(了解更多关于如何升级到直布罗陀16.12.5和16.12.5b在这里．)