做网工这些年我越来越觉得巡检才是检验基本功的试金石。别看思科网络设备巡检命令翻来覆去就是那几条 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 summaryEstablished 状态的邻居才健康如果 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-addressinterface 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 收尾。命令顺序就是设备启动到协议收敛的流程照着这个思路就算遇到没见过的设备型号也不会漏掉关键检查项。