思科网络设备巡检命令详解：从show到故障预警的完整指南

先说个前段时间遇到的场景。半夜接到电话，一台接入交换机出现间歇性断网，所有人第一反应都是：“是不是光模块坏了？是不是光纤被老鼠咬断了？”结果我一登录设备，show interfaces counters errors 往下一拉，发现某个接口的 input errors 已经涨到几十万，CRC 错误更是一路狂飙，再翻 show logging，光模块光功率早就跌破告警阈值了。如果之前巡检时多看一眼错误计数，根本不需要扛着设备半夜跑机房。

这就是我这篇文章的由来。思科网络设备巡检命令，听起来不过是一串 show，但我干了这么多年网络，最大的感受是：巡检不是把命令敲一遍就完事，而是通过这几个命令读懂设备当前在说什么、未来可能发生什么，在故障还没爆发之前就把它摁住。思科设备在数据中心、园区网、运营商网络里依然占着相当大的份额，无论你是刚入门的学生党，还是在机房摸爬滚打多年的老网工，这套命令体系都是绕不开的基本功。

这篇文章不打算讲高深的安全加固，也不聊复杂的自动化平台，只把日常巡检思科设备时实打实要用的命令整理出来，按“硬件环境、接口链路、CPU内存、路由冗余、日志配置”几个层面拆开讲，每个命令后面带上字段怎么读、数据在暗示什么问题。你可以拿着这份清单直接去敲设备，也可以在模拟器上练手熟悉，方法论是通用的。

提示：文中的命令以常见 IOS 和 IOS-XE 平台为例。不同型号、不同软件版本之间，命令名可能有细微差异，但核心字段的含义基本一致。

1. 巡检到底查什么？先给设备列一张“体检表”

任何靠谱的巡检，都不是登上去随便 show 两下就完事。你手里管着三五十台设备，如果每台都从头到尾全量查一遍，不但人累，还容易漏掉真正关键的东西。我自己的习惯是先把巡检这件事拆成三件事：定设备清单、定巡检周期、建基线表。这三件事先做了，命令才有意义。

1.1 先列设备清单，分清核心与边缘

巡检最大的误区就是“一台一台全查”。网络规模小还好说，中大型网络里你如果对所有设备一视同仁，等到真正出了问题，你会发现最重要的那台核心设备反而可能因为“今天没排到”而没查到。我的做法是把设备分成三类，然后再确定命令组合：

• 核心/汇聚层设备：承载跨区域流量的核心交换机、汇聚交换机、出口路由器。这类设备一旦故障影响面最大，要优先查、高频查，命令覆盖要全。
• 接入层设备：数据中心接入交换机、园区网的终端接入交换机。可以稍微降低频率，但硬件状态和接口错误计数不能放松，毕竟用户直接感受到的就是接入层。
• 边缘/专线设备：分支出口路由器、专线接入设备、跨地域互联设备。重点看链路状态、广域网接口错误、路由邻居关系。

这个分类直接决定你后面的巡检命令。比如核心设备要跑到接口、路由、堆叠全量信息，接入设备可以先只查环境、CPU、关键接口这三个维度。有了清单，巡检才不是漫无目的地“扫街”，而是有重点、分层次的“体检”。

1.2 巡检频率怎么定？日周月的分工

我给客户做巡检方案，一般会把巡检节奏分成三档，每档覆盖范围和耗时不一样：

有人觉得每日巡检太频繁，没必要。但实测下来，一台核心交换机哪怕每天只花五分钟扫一眼环境和 CPU，就能避免大量“莫名其妙的故障”。巡检的本质不是预测未来，而是尽早发现趋势——电源风扇转速变慢、设备温度缓慢爬升、CRC 错误缓步增长，这些都是靠高频对比才能看见的趋势性信号。

1.3 建一张基线表，让“异常”自己跳出来

很多人第一次巡检完，把输出看一眼就关掉了，下次巡检时完全想不起上次是什么数值。我的习惯是第一次巡检时，把所有关键指标记录成一张基线表：CPU 峰值、内存使用率、接口错误计数、温度、邻居数量。后面每一次巡检都拿当前值和上一次、和基线值做对比。

为什么要这样做？因为网络故障往往不是“瞬间发生”，而是“慢慢偏离基线，直到超过阈值”。比如某个接口的 CRC 错误从 0 涨到 1000，大多数人觉得没什么，但如果你记录了三周的数据，发现它每周都在翻倍，那基本可以判断光模块在劣化，提前换掉就行。光有命令不行，一定要有记录习惯。我自己用 Excel 表格，每次巡检后把关键摘要填进去，标注异常项，长期积累下来，这张表就是整个网络健康状况的“病历本”。

2. 硬件与环境状态：show environment 系列命令怎么用

很多网工巡检只看 CPU 和接口，电源、风扇、温度经常被当成“无关紧要的部分”。但我得说一句大实话：网络设备的硬件故障往往比软件故障更致命。软件问题还能重启恢复，电源烧了可能就直接宕机，而且宕机前往往没有任何明显征兆。硬件环境巡检，恰恰是最能“捡回一条命”的部分。

2.1 show version：先摸清设备底细

登录设备，我习惯第一句先敲 show version。它能告诉你很多基础但重要的信息：

• 设备型号和硬件版本，比如 Catalyst 9300、ISR 4331
• IOS 版本和特性集
• 设备连续运行时间（uptime）
• 序列号、MAC 地址信息

uptime 这个字段尤其值得注意。 一台设备如果 uptime 显示只有 10 天，说明它 10 天前刚重启过。是因为人为维护重启，还是设备自己崩溃一次？这是判断稳定性的重要线索。很多老设备 uptime 一年以上，说明运行非常稳定；如果一台设备频繁重启，就得警惕版本缺陷、硬件故障或者电源问题。

另外 show version 还能看到设备当前运行的软件版本。定期核对版本，确认它是不是你规划中的版本，也很重要。有一次我巡检发现一台接入交换机跑着一个老得掉牙的中间版本，后来查变更记录才知道是某个同事临时刷错镜像刷上去的，如果不巡检，这个隐患可能一直躺在那。

2.2 show environment：温度、电源、风扇一次看完

在常见思科设备上，环境状态命令有三兄弟：

• show environment all：一次性查看温度、电压、电源状态、风扇状态
• show power：只看电源模块供电情况
• show fan：只看风扇模块

以 show environment all 为例，你通常能看到类似这样的维度：

温度这一块最容易看出问题。如果一台设备温度长期在 55 度以上，而且没有改善趋势，多半是机房空调异常、通风道被堵，或者风扇开始老化。思科设备通常设置了几档温度阈值，一旦超过最高阈值会触发硬件保护，设备自动关机。我们不能等它强制关机才发现问题，巡检时要看的是温度曲线的走势，而不只是一个孤立的数字。

提示：不是所有型号都支持 show environment all。老一点的 2960 可能只支持 show env 或 show environment temperature status，新平台 Catalyst 9000 系列一般支持 show environment all。登录后可以先用 show environment ? 看看你的设备支持哪些参数。

2.3 电源和风扇的“冗余陷阱”

数据中心设备通常都配了双电源，很多人觉得“双电源就是绝对安全”，其实最大的坑是：一台电源已经故障了，设备在单电源状态下继续运行，你巡检时没注意，等另一台电源再出问题，设备就彻底没电了。所以巡检一定得看 show power，确认两个模块都在位、状态都是 ok。

风扇也是一样。模块化交换机可能有多个风扇托盘，show environment 里每个风扇状态都要是 ok。有些设备风扇转速有档位，比如 normal、high、low，异常时会出现 warning。如果风扇变慢导致温度上升，即使系统还没报警，也值得提前安排备件更换。在实际处理中，我见过不少“机柜风扇坏了但设备还能跑”的情况，这类隐患如果不查，迟早会变成事故。

2.4 发现硬件问题后的标准处置动作

如果 show environment 显示电源或风扇异常，我会继续用下面的命令缩小范围：

• show inventory：查看设备的部件编号、序列号和槽位信息，联系厂商或代理备件时直接能用
• show logging | include 模块编号：从日志里找到具体是哪个模块从什么时候开始异常

这一步属于“巡检发现问题后的标准动作”。很多年轻网工卡在这一步，拿了异常值之后不知道下一步该干嘛。记住：巡检发现问题不是终点，定位问题和跟踪进展才是重点。每次巡检发现硬件告警，我都建议在工单或表里留一下状态，下次巡检确认是变好了还是恶化了。

3. 接口与链路：show interface 才是“流量生死线”

接口状态直接决定业务通不通。我巡检思科设备时，接口部分花的时间最多，因为它信息量最大，也最容易被忽略。接口巡检的核心是看两层：端口状态和错误计数。光看“端口是不是 up”远远不够。

3.1 show interface status：先抓全局状态

show interface status 是最快的一眼全局视图。它不需要你逐个接口去翻，直接列出所有接口的状态概要，重点看三个字段：

• 端口名、VLAN、模式（access/trunk）
• 状态（connected / notconnect / disabled）
• 速率和双工模式（比如 a-1000 表示自动协商到 1000M）

connected 的接口不代表健康。 有时候接口显示 connected，但速率跌到了 10M，而你预期是 1000M，这说明线缆或模块可能有问题，或者两端协商失败。这种情况最容易被人忽略，因为终端还能上网，大家不会去专门看端口速率。但如果这个接口是一个关键的上行口，10M 和 1000M 的差距就是灾难。

3.2 show interfaces 详看错误计数

show interface status 只负责“快看有没有 down”，想看更详细的健康程度，就要用 show interfaces 或 show interfaces 具体接口名。下面的输出片段是关键字段的示意：

code复制GigabitEthernet1/0/1 is up, line protocol is up (connected)
  5 minute input rate 123000 bits/sec, 45 packets/sec
  5 minute output rate 89000 bits/sec, 30 packets/sec
  1234567 packets input, 987654321 bytes
  Received 123 broadcasts (0 multicasts)
  0 runts, 0 giants, 0 throttles
  123 input errors, 45 CRC, 12 frame, 0 overrun, 0 ignored
  987654 packets output, 123456789 bytes, 0 underruns
  0 output errors, 0 collisions, 0 interface resets
  0 babbles, 0 late collision, 0 deferred

你重点要盯的是 input errors、output errors、CRC、runts、giants、ignored、overruns 这几个值：

• input errors：接收方向出错的报文总数。任何硬件、线路、协商问题都可能推高它。
• CRC：数据帧在传输过程中未通过 CRC 校验。光纤/网线质量和长度、光模块衰减、双工不匹配都可能产生 CRC。
• runts 和 giants：小于最小帧长和大于最大帧长的帧，通常和硬件故障、冲突有关。
• overruns / ignored：接收队列溢出或被处理器忽略，往往和拥塞、硬件速率不匹配相关。
• output errors：发送方向问题，可能是冲突、队列满等。

光看有没有错误是不够的，关键是看是否持续增长。 一次链路重启可能产生一些复位错误，这属于正常现象。但如果两次巡检之间，同一接口的错误计数从几千变成几十万，这条链路一定有隐患。我在现场排查时，最喜欢用 show interfaces counters errors 这个命令，它能一次性列出一堆接口的收发错误汇总，不用挨个 show interfaces。

实际操作技巧：两次巡检之间，建议用 show interfaces counters errors 或 show interfaces counters 快速对比累计值。如果有网管平台，可以把这些计数器做成曲线；没有平台也不怕，手工记录两次输出，diff 一下，异常数据自己就浮出水面了。

3.3 接口链路抖动的三个“伪装者”

在实际巡检中，一些接口问题表现得很隐蔽，不深入看计数器根本发现不了：

1. 双工模式不匹配：接口看起来是 connected，但一端是 auto，另一端强制成 100M full，远端接口会出现大量 late collision。老设备之间这种问题比较多见，新设备少见，但历史遗留网络里依然有。
2. 光模块功率劣化：接口仍然是 up，但光接收功率已经接近灵敏度极限，CRC 错误缓慢增长。除非你看光模块诊断信息或系统日志，否则接口状态完全看不出任何异常。
3. 微突发拥塞：瞬时流量过大导致队列溢出，overruns 增加，但 CPU 可能并不高。有时候 on接口看 output drops 在增长，但实际上并不代表带宽不够，而是瞬时突发超过了转发能力。

接口巡检的最终目的，是找出那些“还没完全断，但已经快要断”的链路。看到错误计数有增长趋势，就尽早安排更换光模块、重做网线头或者调整协商参数，而不是等到业务中断了才去救火。

3.4 CDP/LLDP 邻居帮你校验物理连接

show cdp neighbors detail（思科私有协议）和 show lldp neighbors（标准协议）能看到对端设备信息，比如相邻设备型号、IP、对端接口。这个命令在巡检中的意义在于：校验物理连接是否符合预期。如果某个端口连接了预期之外的设备，或者对端型号、VLAN 配置明显不对，就要警惕有意外设备接入网络。这虽然不直接算“硬件检查”，但确实是网络巡检里不可少的一环，尤其对管理松散的办公网格外有用。

4. CPU、内存与丢包的关系：别被“空闲”骗了

很多人对 CPU 的认知就是“小于 50% 就没事”。但真的上了生产环境你就会发现，有些设备 CPU 显示只有 30%，业务却频繁卡顿，因为问题不在平均利用率，而在某个瞬间的峰值尖刺。这一章要说清楚 CPU、内存和丢包之间的关联关系。

4.1 show processes cpu 怎么看

show processes cpu 输出里有几个地方要重点看：总体 CPU 利用率（五秒、一分钟、五分钟三个时间窗口），以及占用 CPU 最高的进程列表。

常见的高 CPU 进程有哪些呢？

• OSPF、BGP 等路由协议进程：邻居抖动或路由大量更新时会暴涨
• IP Input / IP Background：大量流量需要 CPU 处理，通常和 ACL、NAT、组播、软转发有关
• SNMP / NETCONF 等管理协议：网管频繁轮询也可能把 CPU 拉高
• 各种加密进程：IPsec 流量加密会吃掉 CPU

具体判断时，我会把五分钟窗口当作稳定指标，五秒窗口当作毛刺指标。如果五分钟长期高于 50%，就要排查是持续攻击、路由抖动还是配置问题。如果只有五秒窗口偶尔跳到 70% 甚至 90%，但一分钟、五分钟都比较低，那大概率是瞬时突发，不用太紧张。

code复制CPU utilization for five seconds: 8%/3%; one minute: 7%; five minutes: 6%

注意这里第一个数代表总 CPU，第二个代表被中断占用的部分。如果中断占比过高，往往意味着设备在处理大量硬件中断，比如流量风暴、端口抖动，这种时候哪怕总 CPU 不高，也要引起警惕。

4.2 CPU 高和接口丢包要放在一起看

很多人查故障只看 CPU 或者只看丢包，结果两条线索都看到了，却想不到一起去。这里有个经常被忽略的点：接口出现 input drops / output drops 时，不一定就是带宽不够，也有可能是 CPU 来不及处理。

我在巡检时会把“CPU 高”和“接口队列丢包”放在一起分析：

• CPU 高 + 接口 output drops：通常是拥塞，流量超过接口带宽。
• CPU 高 + 接口 input drops：多数是 CPU 过载，无法及时处理接收到的报文，比如 ACL log、SSH 泛洪、路由协议更新风暴。
• CPU 不高 + 接口 drops：更可能是缓存不足、突发流量或硬件队列问题。

这种关联分析比单独看一个指标可靠得多。有一次客户的交换机出现周期性数据卡顿，单独看 CPU 只有 20%，单独看接口也不觉得有异常，但把时间点对齐后才发现，每到整点网管轮询时，CPU 瞬时冲到 80%，接口开始丢包。不把两个指标放在一个时间维度里看，这个故障能查一整天。

4.3 show memory：内存泄漏的早期信号

show memory 主要是看 free memory 和 allocated memory 的变化。思科设备的内存问题很少一夜爆发，更多是缓慢泄漏——某个进程长期占用内存，free memory 不断下降，最终导致设备无法创建新会话或者无法 reload。

巡检时记录当前 free memory 值，下次巡检再对比。如果 free memory 持续走低，就优先看是哪个进程占了内存。我遇到过 BGP 进程内存泄漏导致路由器几乎僵死的案例，早期就是靠巡检对比内存值发现的。很多人不重视内存字段，觉得“还没卡死就没事”，但实际上等它卡死再处理，业务早就受到影响了。

5. 路由与冗余协议：邻居关系好，业务路径才对

如果你负责的是核心交换机或者路由器，那路由协议和冗余协议的检查优先级要比接口还要高。为什么？接口 down 了你会立刻感觉到，但路由邻居出问题，流量往往不是断，而是绕路，或者间歇性中断，排查起来反而更难。业务流量能不能走对路径，全靠这些协议的健康程度。

5.1 OSPF 邻居：show ip ospf neighbor

这个命令能看到每个 OSPF 邻居的邻居 ID、优先级、状态（Full / 2Way / Init / Down）和 Dead timer。输出示意：

code复制Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2        1     FULL/DR         00:00:35    10.0.0.2        GigabitEthernet0/0
10.0.0.3        1     FULL/BDR        00:00:32    10.0.0.3        GigabitEthernet0/1

巡检核心看两条：

1. 邻居状态是不是 Full：Full 是正常状态，如果出现 Down、Init、Exch 等，基本就是建邻失败或正在重新建立。
2. 邻居数量是否和基线一致：我每次巡检都会数一下邻居数量。如果原本有 10 个 OSPF 邻居，这次只剩 8 个，那一定有链路或配置问题。邻居静默消失比接口 down 更隐蔽，因为接口可能还是 up，但二层/三层参数已经不对了。

如果发现邻居抖动，可以用 show ip ospf events 或者看日志来追踪原因，但日常巡检只需要确认“当前状态”和“邻居数量”，不建议在巡检时做太多深度排障，那是另一套工作流。

5.2 BGP 邻居与路由数量：show bgp summary

BGP 场景下，show ip bgp summary 是必查命令。先看 Peer 状态列，Established 说明邻居关系建立成功；如果反复在 Active/Connect 之间切换，基本就是网络抖动或配置冲突。再看每一个邻居的已接收路由前缀数（PfxRcd）。

code复制Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.2        4        65001  123456  123450    1000    0    0 2w3d          5000

这里要特别关注路由数量的变化趋势。路由数量突然暴涨，可能是收到了异常的路由通告，未必是好事；突然暴跌，可能是邻居断掉或策略生效。如果你发现关键邻居的 PfxRcd 比基线少了几百条，那基本可以断定有路由在某个环节被吞掉了。

提示：思科新平台的命令可能是 show bgp summary（不带 ip 前缀）或 show bgp vrf xxx summary。IOS-XE 已经逐渐统一。写脚本或记录模板前，先确认设备版本，避免命令不兼容。

5.3 HSRP、VRRP 和堆叠的冗余状态

园区网和接入层经常用 HSRP 或 VRRP 做网关冗余，用堆叠做交换机多机虚拟化。巡检冗余状态时，命令如下：

• show standby：看 HSRP group 状态是 Active 还是 Standby，以及虚拟 IP、优先级，输出示意：

code复制Interface   Grp  Pri P State   Active          Standby         Virtual IP
Vlan10      1    110 P Active  local           10.1.1.2        10.1.1.254

• show vrrp：VRRP 输出类似，看 State 是 Master 还是 Backup
• show switch / show switch stack-ports / show vstack：看堆叠成员和 stack port 状态

冗余协议最常见的坑是“双主”：HSRP 因为心跳断开出现两个 Active，VRRP 因为优先级设计不当出现抢占混乱，堆叠因为 stack link 异常导致设备分裂。这些问题等到故障出现再去查就晚了，巡检时看状态列反而是最容易发现的。如果一个 HSRP 组同时出现了两个 Active，这就是板上钉钉的异常，得马上处理。

5.4 路由表里的“意外路径”

show ip route 可以快速确认去关键网段的路由还是不是预期的那一条。如果应该走专线的路由变成了走 Internet，或者等价负载均衡的下一跳少了一条，说明上游邻居或链路发生了变化。

路由层面的巡检，本质上是在回答一个问题：当前流量走的路，还是当初设计的那条吗？ 有时候路由变化是正常的，比如割接后调整了路径；但如果你不知道这个变化，就很危险。所以巡检不只是看命令输出，还要和网络设计文档、变更记录对照着看。

6. 日志、时间与配置一致性：不查“历史”的巡检不完整

前面几个步骤都是看“现在”，但一台设备的“现在”往往是“过去”叠加的结果。日志、时钟、配置这三个点，能帮我们把设备的历史串联起来。很多人巡检只盯当前状态，忽略日志和配置，结果设备早就重复报错了，却一直被当成噪音忽略。

6.1 show logging 快速定位故障时间线

show logging 默认显示设备内存缓冲区里的日志。巡检时我不会把全部日志从头翻到尾，而是用过滤姿势：

• show logging | include UPDOWN：看端口 up/down 事件
• show logging | include OSPF|BGP|HSRP：看路由和冗余协议抖动
• show logging | include %SYS-5-CONFIG_I：看配置变更记录
• show logging | last 50：只看最近 50 条

端口 up/down、协议邻居波动、配置被修改，这些事件在日志里都有痕迹。如果设备最近出过一次问题，但当时没人知道原因，这些日志往往是最快的线索来源。比如你发现某个接口一天内 up/down 了十几次，而接口当前状态又恰好是 up，那这个问题光看接口状态是看不出来的，非日志不可。

一个容易被忽略的坑：如果设备日志缓冲区比较小，而日志量又大，早期故障信息可能已经被后来的日志覆盖。所以重要的核心设备，建议把 logging host 指向日志服务器，或者调大 log buffer 的容量。

6.2 show clock 与 NTP：时间不同步，日志等于白查

严格说，show clock 和 show ntp status 不算“传统巡检命令”，但我会把它排进每次月度巡检清单。为什么？因为你查日志时，如果设备时间不准，所有的时间线都是错的。跨设备排障时，每台设备时间都不一样，你根本无法把不同设备的日志按时间对齐。

巡检时顺手确认几点：

• show ntp status 显示 clock is synchronized
• 时间源地址和层级正常
• 设备时间与真实时间的误差尽量控制在几十毫秒级别

如果发现设备 NTP 不同步，要尽快处理。时间不同步表面看是小事，实际影响日志分析、证书校验、认证系统等很多层面。巡检时花十秒看一下，能为以后排障省下大量时间。

6.3 配置一致性检查：running-config 与 startup-config

配置漂移是很常见的问题：有人临时改了配置，但没保存；也有人改了配置后设备重启，运行状态和启动配置不一致。月度巡检一定要做：

• show running-config 和 show startup-config 对比，找出差异
• 如果设备配了 archive，用 show archive config differences 查看配置历史差异
• 把 running-config 备份到本地，保存成带日期的文件

配置一致性检查的意义在于：万一设备重启，你至少能确定它恢复出来的配置是不是你认可的配置。很多网络故障不是因为配置本身错，而是因为配置和预期不一致，自己还没察觉。巡检时多花几十秒做一次 diff，能少踩很多“神秘故障”的坑。

6.4 把输出沉淀成“网络历史档案”

我习惯把每一次巡检的关键输出保存到统一目录，文件名格式是“设备名_日期”。积累一年之后，这些输出本身就是珍贵的网络历史档案。比如你后来发现某个端口某个时段总在抖，翻回去查档，立刻能定位是从哪天开始的，再结合那天的日志和变更记录，基本就能拉出故障根因。

这件事听起来简单，但坚持下来的人很少。大部分人的巡检输出都是看一眼就丢，出了故障只能凭记忆。相信我，人的记忆在复杂网络故障面前非常不靠谱，一整套有规律的输出存档远比你的印象可靠。

7. 把命令变成模板：手工高效巡检与半自动化

这一部分讲讲我是怎么把零散命令整理成模板，并逐步提升效率的。不涉及复杂框架，但足够应对日常巡检工作。

7.1 我常用的手工巡检命令模板

下面这份清单是我按模块整理出来的，照着敲就不会漏项。它覆盖了从硬件到配置的主要维度，你也可以在此基础上增删：

1. 设备身份与运行时间：show version
2. 硬件环境：show environment all / show power / show fan
3. 全局接口状态：show interface status
4. 关键接口错误：show interfaces counters errors
5. CPU：show processes cpu
6. 内存：show memory
7. 路由协议邻居：show ip ospf neighbor / show ip eigrp neighbors / show bgp summary（按需）
8. 冗余状态：show standby / show vrrp / show switch（按需）
9. 路由表概要：show ip route summary
10. 日志：show logging | last 100
11. 时间：show clock detail / show ntp status
12. 配置差异：show archive config differences（如果配置了 archive）

这个模板比较全，适合周检和月检。日检可以只保留第 2、3、5、10 项，控制在五分钟之内。

7.2 不同平台命令差异：IOS、IOS-XE 与 Catalyst 9000

现在思科设备主要分两类：老款 IOS（比如 Catalyst 2960、ISR 2921）和新款 IOS-XE（比如 Catalyst 9000、ISR 4000）。大部分 show 命令是通用的，但有几点差异要注意：

• Catalyst 9000 上 show version 也能看 IOS-XE 版本，但有时要结合 show platform software 命令看更底层的状态
• 堆叠命令因平台而异，老平台是 show switch，部分新平台统一到新语法，具体以设备支持为准
• 一些模块化平台支持 show module，用于查看模块状态和状态灯

做巡检模板时，我建议按平台分别保存一份，别拿一份命令列表通吃所有设备。给客户做方案时，我也会给老平台和新平台各做一份 command list，避免现场抓瞎。

7.3 半自动化的思路：Python、Netmiko 与文件归档

手工敲命令效率始终有限。如果你管着几十台设备，我建议尝试半自动化。入门路径不难：用 Python 加 Netmiko 库，批量登录设备抓取输出，保存到文件。思路大概是：

1. 准备设备清单（IP、用户名、密码、enable 密码）
2. 定义要执行的命令列表
3. 批量登录并抓取输出，按设备和日期保存
4. 后处理时只提取关键字段，生成汇总表

这类脚本不复杂，但效果立竿见影。如果你不想上手 Python，也可以退而求其次，用 SSH 客户端登录后，把输出统一粘贴到文件，再做一份“半自动”的归档。真正重要的不是自动化程度多高，而是你能不能定期拿到完整、可对比的输出档案。

7.4 巡检的节奏：高频查“有没有坏”，低频查“有没有变坏的趋势”

最后把巡检节奏重新收敛一下。我自己的分配方式是：

• 日检：环境状态 + CPU + 全局接口状态 + 日志摘要，每台 5-10 分钟
• 周检：邻居状态 + 错误计数对比 + 冗余状态 + 路由摘要，每台 20 分钟
• 月检：配置归档 + 版本核对 + 完整错误统计 + 风险评估，批量完成

这套节奏不一定适合所有网络，但核心思想是相通的：高频查“有没有坏”，低频查“有没有变坏的趋势”。 小型网络可以合并日检和周检，大型网络可以再细分，但原则不变。

老网工有句话：网管这活儿，功夫在平时。巡检看起来枯燥，但一旦发生过一次重大故障，你就再也不敢“糙巡”了。从我自己的经验来看，故障原因里有很大一部分是可以在巡检中提前发现的——不是靠什么高级技术，而是老老实实把命令执行到位，把数据记录成习惯，把变化看进眼里。

最后分享一个小习惯：每次巡检完，我都会在终端里再敲一遍 show environment all 和 show logging | last 20，确认自己记录过了再离开。别小看这个动作，它可能帮你少熬几个通宵。