做网工这些年，我越来越觉得，巡检才是检验基本功的试金石。别看思科网络设备巡检命令翻来覆去就是那几条 show 命令，真到设备告警、业务中断的时候，能不能从输出里一眼看出隐患，靠的就是平时对每一个字段背后含义的理解。这篇文章把我常用的思科网络设备巡检命令整理成一套能直接照抄的清单，覆盖交换机、路由器、无线控制器，还会把我在现场踩过的坑、排查思路、怎么用模拟器练手都写出来。刚入行的网工、负责机房运维的兄弟，或者准备考 CCNA 的朋友，都可以照这份清单搭起自己的巡检流程，省去满论坛翻帖子的时间。
1. 巡检这件事为什么不能凭感觉
1.1 巡检不是看通没通，而是看还能撑多久
很多朋友觉得巡检就是看看网通不通、设备能不能登录，这是误区。网络中断是显性故障，但更多问题是一天天积累出来的：光模块接收功率缓慢下降、电源模块明明已经失效却因为冗余还在硬撑、日志里反复出现 CRC 错误导致转包丢包、CPU 使用率从 20% 慢慢爬到 80%。如果你只靠业务反馈来发现问题，那等到用户报障的时候，往往已经到了非换设备不可的地步。
所以巡检真正的价值，是用一堆 show 命令把设备的当前状态“拍一张高清照片”，跟历史基线对比，找出那些还在恶化但还没中断的隐患。思科设备在设计上其实很透明，它把硬件状态、协议邻居、接口计数、日志记录都开放给了工程师，问题在于你愿不愿意定期去看、看得懂看不懂。
1.2 用基线思维替代临时抱佛脚
我刚入行时巡检就是登录设备敲几条 show interface，看到 up/up 就放心走人，结果设备半夜重启，早上到现场才发现 uptime 归零，但没人知道重启前发生了什么，因为没留任何历史输出。
后来我养成一个习惯：每一台设备首次巡检时，把 show version、show inventory、show running-config、show interfaces counters 的完整输出归档，后面每次巡检都拿当前输出和归档文件做对比。这样你不需要记住每台设备的“正常值”，只需对比两次输出的差异。比如 show version 里 uptime 从 300 天变成 2 天，那基本可以断定设备在巡检周期内重启过；show environment 里温度从 45℃ 涨到 60℃，就算还没到告警阈值，你也应该提前去摸一下机柜的通风情况。
2. 巡检前的准备：登录方式、基线与工具
2.1 登录设备：SSH 优先，Console 兜底
巡检第一步是能稳定登录设备。我强烈建议优先用 SSH，别用 Telnet。Telnet 是明文传输，用户名和密码在网络里裸奔，核心设备上跑一条抓包就可能把你管理账号泄露出去。SSH 配置不复杂，关键是提前在设备上把用户、权限、VTY 限制做好：
hostname SW-ACC-01 ip domain-name example.local crypto key generate rsa modulus 2048 username admin privilege 15 secret StrongPass123 line vty 0 4 transport input ssh login local exec-timeout 10 0这里注意 privilege 15 表示直接进特权模式，省去 enable 密码这一步，但安全要求高的环境不建议这样，可以先 privilege 1，再通过 enable secret 进特权模式。exec-timeout 10 0 是 10 分钟无操作自动断开，防止人走了会话还挂着。
Console 口是最后救命通道，尤其是远程设备 SSH 配置出错、或者 VLAN 管理接口失联的时候。现场维护包里永远要有一根 Console 线，检查笔记本上有驱动。老实说，我见过太多人远程把管理 ACL 写错、把自己锁在设备外面，最后只能跑一趟机房，这种坑巡检前就该避开。
2.2 先跑一遍“摸底三连”，把基线留好
给每台思科设备做第一次巡检时，我建议先敲这三条命令，把输出完整保存下来：
show version show inventory show running-config这三条命令我习惯叫“摸底三连”。show version 告诉你设备型号、IOS 版本、运行时间、上次重启原因；show inventory 告诉你硬件 PID、VID、序列号，后续报修、查维保全指望它；show running-config 是设备当前所有配置，相当于这台设备的“基因图谱”。
保存文件命名就按“设备名_日期.txt”来，比如 SW-ACC-01_20250615.txt。每台设备建一个目录，别混在一起。等三个月后再巡检，直接 diff 两个文件，任何配置变化都跑不掉。有人会说我用 NPM 网管软件自动备份配置，但命令行保存一份永远不会亏，特别是设备数量不多的时候，这个土办法最可靠。
3. 设备级巡检命令：版本、硬件、资源
3.1 show version 里的隐含信息
show version 是巡检必敲的第一条命令，但多数人只瞄一眼 IOS 版本就过了，其实里面信息密度很高：
Switch> show version Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version 15.2(2)E8, RELEASE SOFTWARE System returned to ROM by reload at 2025-06-01 02:33:10 System image file is "flash:c2960-lanbasek9-mz.150-2.E8.bin" cisco WS-C2960X-48FPS-L (APM86XXX) processor with 524288K bytes of memory SW1 uptime is 2 weeks, 3 days, 4 hours, 12 minutes重点看这几个字段：
| 字段 | 含义 | 巡检关注点 |
|---|---|---|
| IOS Version | 系统版本 | 是否过老、是否有已知安全漏洞 |
| System returned to ROM | 上次重启原因和时间 | reload 多为人为，crash/power cycle 需要警惕 |
| System image file | 启动加载的镜像文件 | 是否从 flash 加载，是否还有冗余镜像 |
| uptime | 连续运行时间 | 和基线对比，判断是否发生过重启 |
| processor 后面的内存 | 设备内存总量 | 老设备内存偏少，容易内存耗尽 |
如果看到上次重启原因是“reload”，多半是有人手动重启；如果是“power cycle”，可能发生过断电，需要检查供电链路；如果是“system crash”，那就要收集 crashinfo 文件，找根因。很多软故障其实早就在 show version 里告诉你答案了，只是你没注意。
3.2 show environment 看电源、风扇、温度
再看硬件健康状态，模块化交换机和路由器上最常用：
Switch# show environment all Switch# show environment temperature Switch# show environment power温度、风扇、电源这三样是硬件寿命的核心指标。风扇一旦故障，设备散热效率骤降，温度会很快爬到阈值，触发保护性关机——注意是关机，不是降频，生产设备直接停机你哭都来不及。电源模块如果有两个，一个挂了另一个还能带载，但此时已经失去冗余能力，必须尽快安排更换。
有些 PoE 交换机还要看 switch show power inline，因为接入层如果接了大量 IP 电话和摄像头，PoE 功率余量不足会导致设备反复掉线。巡检时记录每个电源模块的功率余量，跟基线比，如果某个新增摄像头之后功率余量突然变小，说明你该做供电规划了。
3.3 show inventory 和 show module 核对硬件状态
设备巡检还有一个容易漏的动作：核对硬件清单和板卡状态。
Switch# show inventory Switch# show module Switch# show switchshow inventory 会列出所有硬件组件，包括机箱、电源、风扇、模块的 PID 和 SN。这些信息在设备故障报修时直接抄给厂家客服，能省去大量沟通成本。show module 看板卡状态，状态字段必须是 ok，如果出现 faulty 或者 missing，说明板卡可能松动或损坏。
三层交换机和路由器上还要看堆叠或板卡成员关系，show switch 可以看堆叠成员状态。堆叠里有一台设备离线，整个堆叠都会降级，转发性能打折。巡检时如果发现成员数量比基线少，哪怕业务没断，也说明堆叠链路或成员设备已经出问题了。
4. 接口与链路巡检：从物理层到数据链路层
4.1 show ip interface brief 快速圈定接口状态
接口巡检是日常巡检里最枯燥也最重要的一环，我一般先用一条全局命令把接口状态拉出来：
Switch# show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet0/1 unassigned YES unset up up GigabitEthernet0/2 192.168.10.1 YES manual up up GigabitEthernet0/3 unassigned YES unset down down GigabitEthernet0/4 unassigned YES unset administratively down downStatus 和 Protocol 这两个字段要合在一起看。up/up 是正常；down/down 常见于物理链路断开或对端设备没通电；up/down 很诡异，物理链路是通的，但二层协议起不来，往往是对端封装不匹配或者协商出问题；administratively down 是人为 shutdown 的接口，先查配置意图再判断是否异常。
如果接口数量多，这条命令输出会很长，我习惯加一条过滤，只看非 up/up 的接口：
show ip interface brief | exclude up up注意输出里表头“Interface”和字段名不会匹配“up up”，所以表头也会被排除，但问题接口一目了然。这个方法新手一定要练熟，现场排查时能救命。
4.2 深入 show interfaces counters 和光模块检查
接口状态 up/up 不代表链路质量好，真正的问题藏在计数器里：
Switch# show interfaces counters errors Switch# show interfaces counters Switch# show interfaces transceiver properties Switch# show interfaces transceiver detailCRC 错误累计增长、input errors 上涨、runts 或者 giants 频繁出现，通常指向双工不匹配、线缆质量差、光模块劣化或者端口协商异常。曾经遇到一个现场，业务时好时坏，接口一直是 up/up，用 show interfaces counters errors 一看，CRC 错误每五分钟涨几百，顺着查下去发现是跳线压接过紧导致光纤弯曲半径过小，重做跳线后计数器就停涨了。
光模块巡检不能只看“有没有光”，要看功率值。show interfaces transceiver properties 输出里包含 Temperature、Voltage、Current、Tx Power、Rx Power。重点看 Rx Power 是否在接收灵敏度范围内。不同模块型号的阈值不一样，但经验法则是：如果 Rx Power 比正常基线低 3dB 以上，这块光模块大概率在劣化，趁业务没中断赶紧安排备件。
4.3 二层链路巡检：VLAN、STP、EtherChannel
交换机的核心是二层转发，所以 VLAN、STP、链路聚合是巡检里绕不开的三件套。
Switch# show vlan brief Switch# show spanning-tree summary Switch# show spanning-tree Switch# show etherchannel summaryshow vlan brief 看 VLAN 是否齐全，端口划到哪个 VLAN 跟配置是否一致。曾遇到有人误把终端口划到管理 VLAN，结果 DHCP 地址乱发，业务 IP 冲突一堆。
show spanning-tree 重点看端口角色和状态，正常是指定端口或根端口处于 forwarding，非根桥的冗余链路应该处于 blocking。如果发现本应 blocking 的端口变成 forwarding，说明 STP 域里有环路风险，要立刻查配置。有些接入交换机开了 PortFast，连接终端的端口可以快速转发，但切记只能在接入侧开，上行口乱开 PortFast 可能直接造成广播风暴。
EtherChannel 用 show etherchannel summary 看聚合口状态和成员口状态。Port-channel 是 up，但成员口可能有部分 down，流量由剩下的接口承担。如果流量接近带宽上限，风险就来了。
5. 路由、日志与无线控制器专项巡检
5.1 路由表和协议邻居怎么查
到了三层设备，核心就是路由表和协议邻居关系。我常用的命令组合是：
show ip route summary show ip route show ip ospf neighbor show ip bgp summary show cdp neighborsshow ip route summary 会告诉你路由总数和各类协议路由数量。如果路由数量突然暴涨，八成是收到了不该收的路由，或者路由过滤失效；如果比基线少，可能邻居断了或者静态路由被误删。show ip route 里最该关心的是缺省路由，很多分支机构的流量全靠一条默认路由上网，它没了，所有终端看起来还是 up，但业务全断。
OSPF 邻居看 show ip ospf neighbor，正常状态是 FULL/BDR、FULL/DR，如果看到 INIT 或者 EXCHANGE 持续不收敛，说明邻居关系在震荡，通常涉及 MTU、区域配置或认证问题。BGP 用 show ip bgp summary，Established 状态的邻居才健康，如果 Active 或者 Idle，说明 TCP 会话有问题，多半是 ACL、回环接口或对端配置问题。CDP 是思科私有协议，show cdp neighbors 可以快速画出一台交换机上下连了哪些设备，适合核对物理拓扑和记录 LLDP/CDP 邻居关系。
5.2 控制平面资源与日志检查
路由抖动、异常流量、配置错误都会反映在 CPU 和内存上，所以资源巡检不能跳：
show processes cpu sorted show processes memory sorted show logging show clock show ntp statusshow processes cpu sorted 按 CPU 占用排序，能直接看到当前最耗 CPU 的进程。思科设备常见的 CPU 高进程包括“IP Input”和“CEF process”，前者通常是流量冲击控制平面，后者可能是路由震荡。比较隐蔽的是“Cat4k Mgmt High”“IOSD”这类平台相关进程，占 CPU 不高但很关键，需要结合日志判断。
日志里最该搜的关键词是 err-disable、duplex、flapping、crash、reload。比如接口反复 down 又 up，日志会刷“Interface GigabitEthernet0/1, changed state to down”，如果你巡检周期内日志里类似消息出现上百条，说明链路已经很不稳定，可能光模块、网线或对端端口有问题。show clock 和 show ntp status 一起看，NTP 不同步会让日志时间轴失效，排障时你根本分不清哪个事件在先哪个在后。
5.3 思科无线控制器 3504 日志导出实操
无线控制器不同于交换机和路由器，它本身有独立操作系统和 Web 管理界面，日志导出有自己的一套流程。以思科无线控制器 3504 为例，日常巡检至少要看 AP 在线状态、客户端关联日志、射频干扰告警，并定期导出日志留档。
CLI 方式最直接：
show ap summary show client summary show logging show timezone把 show logging 的完整输出复制保存，就是一份文本版日志。GUI 方式也常用：登录 3504 的 Web 管理页面，导航到 Administration > Logs，选择 Syslog 或 Trap logs，可以按时间范围筛选再导出 CSV 或文本。更规范的方案是配置远程 Syslog 服务器，把控制器日志实时推送到日志平台，避免设备崩溃后本地日志丢失：
configure terminal logging host 192.168.100.50 logging trap warnings logging facility local0 end3504 日志导出最常被忽视的是时间问题。现场发现控制器显示的日志时间比实际时间差 8 小时，就是因为没配时区和 NTP。后来我在所有无线控制器上统一配置 NTP 和时区，日志分析才靠谱。还有一点，无线控制器日志默认只保留一定数量，增量导出比等日志被循环覆盖后再补救要靠谱得多。
5.4 用模拟器把巡检命令练熟练透
新手不敢在现网设备上乱敲命令，这很正常。思科模拟器就是练巡检最好的沙盘，不管是 Packet Tracer 还是 GNS3，都支持大部分常用 show 命令和配置命令。Packet Tracer 适合刚入门，安装简单，界面友好，注册一个 Cisco NetAcad 账号就能用。GNS3 更适合跑 IOS 真实镜像，能模拟更复杂的路由协议和故障场景。
我建议练习时故意给自己挖坑：把接口 shutdown，模拟光模块故障；把两端双工模式改成不一致，看看 show interfaces counters errors 里会不会涨 CRC；配置 DHCP 中继故意指错地址，看客户端能不能拿到地址；在接入交换机上配置端口安全，故意换一个 MAC 地址，模拟 err-disabled。这些故障在模拟器里复现一遍，再看命令输出，印象比背命令深刻十倍。
6. 常见问题排查与避坑心得
6.1 接口反复 down 或 err-disabled 的快速排查
接口 err-disabled 是巡检中最常见的告警之一。先用 show interfaces status 看接口处于 err-disabled 状态，再用 show interfaces status err-disabled 查看具体原因，常见原因是 port-security violation、bpduguard、环路保护。
处理时不要一上来就 clear errdisable interface，这样只会让你的交换机在同一接口上反复“生病”。正确做法是：
show errdisable detect show errdisable recovery show port-security interface gigabitethernet0/1 show spanning-tree inconsistentports先读懂 err-disabled 的原因，再针对性解决。比如端口安全违规，就把接口上的静态 MAC 和当前终端 MAC 核对，改端口安全配置或更新绑定；是 BPDU Guard 触发的，就检查这个接口是不是误开了 PortFast，或者对端是不是接了不该接的交换机。清了错误原因之后，再 clear errdisable recovery 或者手工 clear 才有意义。
6.2 端口绑定 MAC 后设备频繁掉线怎么查
“思科交换机如何在端口上绑定 MAC”是巡检群里问得很多的问题，但问的人往往只想要配置命令，真正该问的是“绑完之后出了问题怎么办”。端口安全配置本身很简单：
interface GigabitEthernet0/1 switchport mode access switchport port-security switchport port-security maximum 2 switchport port-security mac-address 0050.7966.6688 switchport port-security violation restrict但巡检时你会发现，设备换了一台，MAC 地址变了，端口直接 err-disabled。很多办公场景终端会换，笔记本电脑网卡 MAC 也可能因为 WWAN 和有线网卡不同而变化。所以在生产环境用端口安全要谨慎，要么配合 802.1X 做动态认证，要么把 violation 模式设为 restrict 而不是 shutdown，同时把 maximum 设成合理值，并开启 sticky MAC 自动学习：
switchport port-security mac-address sticky巡检时重点看 show port-security，核对每个安全端口当前学习到的 MAC 数量。如果最大数刚好等于上限，而且日志里频繁出现违例记录，就该重新评估这个端口到底要不要这么严格的绑定策略。
6.3 三层交换机上 DHCP 客户端拿不到地址
DHCP 和 DHCP 中继是我经常在巡检中验证的一类功能。很多分支网络部署了三层交换机做网关，DHCP 服务器在核心机房的独立服务器上，客户端和服务器不在同一 VLAN，这时候必须在三层交换机接口下配置 IP helper-address：
interface Vlan10 ip address 192.168.10.1 255.255.255.0 ip helper-address 192.168.200.10如果配置了 helper-address 但客户端还是拿不到地址，先看 show ip dhcp binding 里有没有租约记录，再看 show ip dhcp server statistics。发现收到 DHCPDISCOVER 但没发出 DHCPOFFER，就要检查 DHCP 服务器地址是否可达、ACL 是否拦截了 UDP 67/68 端口、上游是否配置了 dhcp relay。另外要特别留个心眼：如果三层交换机上还配了 ip dhcp snooping，接入端口没有做 trust 标记，DHCP 响应会被直接丢弃，这是很多人排半天都排不出来的坑。
6.4 Web 管理端口无法打开，比如 8001 端口案例
有朋友问“思科无法打开 8001 端口是什么意思”，这个案例很适合放进巡检排查。很多思科设备支持 Web 管理，默认端口是 80，但有人会改成 8001 或者别的端口，浏览器访问却打不开。
排查思路分几步走：先在设备上确认 HTTP/HTTPS 服务是否开启，端口是否真的监听：
show running-config | include http show ip http server status show ip http server如果配置里显示 ip http port 8001，但浏览器还是打不开，接下来检查管理 VLAN 和 ACL。Web 管理端口通常只允许管理网段访问，你如果从办公网直接访问，ACL 没放行必然失败。再看看 VTY 或者线卡上有没有限制。还有一种情况是设备上配了 ip http access-class，访问控制列表把源地址拒绝了，show access-lists 能看到匹配计数。最后别忘了本机防火墙和浏览器代理，我遇到过无数次，设备一切正常，结果是自己电脑防火墙挡了 8001 端口。
如果用的是思科模拟器，8001 端口多半是模拟器映射到本机的管理端口，那就要检查映射配置和端口占用，比如在 GNS3 里绑定本地端口时，另一个进程已经占用了 8001，自然打不开。
6.5 烽火交换机能不能直接套用思科命令
很多人私信问“烽火交换机是用思科命令吗”。我只能说部分像，但不要默认完全一样。烽火等国产交换机的命令行风格确实参考了 Cisco 风格，很多查询命令比如 show interface、show vlan、show running-config 的样子很像，但细节上往往有差异，比如进入接口模式的方式、端口编号写法、VLAN 配置命令字段，甚至用户权限模型都不一样。
所以在巡检场景里，如果现场同时有思科设备和烽火设备，我建议每台设备建立独立的命令手册，批量脚本也要分开维护。最稳妥的做法是先在测试设备上验证命令，再上线批量操作。别把思科命令在烽火上跑完发现不识别，结果把接口配置刷乱了，这种低级错误真的会发生在很资深的工程师身上。
6.6 巡检避坑清单与我的个人习惯
最后分享几条我用无数现场教训换来的巡检习惯，也算给网工同行提个醒。
第一，远程巡检绝不执行 reload 或 write erase，哪怕你只是想“模拟一下”，也找测试设备去试。第二，不要在高峰期跑 debug 命令，CPU 本来忙得要死，再开 debug 可能直接把设备拖崩。第三，巡检前先备份 running-config，备份文件放到本地或版本管理工具里，配置变更后也要再备份一次。第四，批量巡检时先拿一台设备做验证，确认命令兼容、输出正常，再推广到全部设备。第五，巡检不仅是采集信息，还要形成报告，哪怕只是简单记录每台设备的状态、异常项、处置建议，三个月后你能靠这份记录还原当时的故障。
我个人实际使用中发现，最提效不是背更多命令，而是把常用巡检命令做成一个模板文件。每次登录设备后把模板里的命令一次性贴进去执行，输出全部回显到同一个日志文件，等巡检完再统一分析。再配合一个小脚本按设备名和时间整理归档，基本可以解放三分之一的工作量。
这个巡检模板我自己是这么组织的：先用 show version 和 show inventory 记录设备身份，再 show module/show environment 看硬件健康，然后 show ip interface brief 看接口状态，接着 show vlan/show spanning-tree/show etherchannel 看二层，show ip route/show ip ospf neighbor/show cdp neighbors 看三层，最后 show logging/show clock 收尾。命令顺序就是设备启动到协议收敛的流程，照着这个思路，就算遇到没见过的设备型号，也不会漏掉关键检查项。
