1. 巡检不是抄状态而是按诊断思路拆解设备1.1 四条主线决定你巡检时“该看什么”巡检设备最怕的不是设备当场出故障而是故障迹象早就写在巡检记录里却没人当回事。我见过不少网工把巡检理解成“把设备上所有状态命令敲一遍输出复制进表格就收工”。但同样的命令有人能提前几天判断出光模块快坏了有人等链路中断了才回头翻记录差别就在“看什么”和“怎么记”。一开始就要把设备分成四条检查主线整机资源、链路质量、转发表项、日志配置。整机资源回答“设备累不累”重点是CPU、内存、温度和电源链路质量回答“链路脏不脏”重点是端口协商、错包、光功率转发表项回答“转发对不对”重点是MAC、ARP、路由表和协议邻居日志配置回答“变更乱不乱”重点是告警日志、NTP和配置备份。所有锐捷巡检命令基本都落在四条主线里。一台设备上可能有几百个接口、几十个协议、上千条日志全部看一遍既不现实也没必要。按主线走每类只需两到三条命令交叉验证就能得出可靠结论。我遇到过新手在所有端口上逐个敲show interface花了一个上午却漏掉了OSPF邻居因Hello报文被过滤而间歇性down这就是没有主线、只有命令的典型后果。1.2 先show version确认你在和谁打交道锐捷设备型号跨度大不同系列、不同软件版本的命令风格并不是完全统一的。上设备第一件事不是敲show cpu而是先敲show version确认设备型号、软件版本、Boot版本、序列号和连续运行时间。为什么要先做这一步因为不同版本命令不完全一致比如有的平台查CPU用show cpu usage有的用show process cpu查温度有的用show environment有的用show device。确定版本后再决定后续命令能避免很多“命令不存在”的尴尬。这里有个容易忽略的细节show version里还会显示设备的连续运行时间如果一台设备运行时间长达几百天在后续巡检中又出现可疑的不稳定现象可以把“设备长时间未重启”作为一次维护窗口的备注反过来如果发现设备运行时间意外归零说明设备重启过要区分是计划内重启还是非计划重启后者往往涉及硬件隐患。把版本信息记录到巡检台账里还有一个作用当你需要联系技术支持或到社区搜索问题时别人第一句话就会问“软件版本是多少”这条信息永远是排障的起点。养成“先看版本再谈状态”的习惯比背任何命令都值钱。2. 整机资源与硬件状态先判断设备本身还能撑多久2.1 CPU与内存盯5分钟均值别被瞬时值带走锐捷设备通常用show cpu usage查看CPU占用率输出里一般能看到5秒、1分钟、5分钟三个时间窗的均值。很多刚接触设备的人一看到5秒均值冲到90%就慌了实际上真正需要警惕的是5分钟均值持续高于70%并且伴随CPU相关进程占用异常升高。瞬时值冲到很高但5分钟均值平稳多数是一瞬间的协议计算或登录操作引起比如有人正在SSH登录、网管系统刚好来采集数据记录一下就好不必立刻处理。内存用show memory查看。锐捷设备的内存使用量有一个关键判断维度剩余内存在长期趋势上是否持续缩小。内存不可能无限增长如果每次巡检剩余可用内存都在下降说明可能存在内存回收不及时或疑似泄漏的问题。这里要顺带提一下内存碎片正常情况下不用过度关注碎片率但当设备同时运行大量路由协议、ACL策略时内存碎片化严重可能会影响控制面的响应。我自己的判断习惯是把CPU和内存放在一起看两者同时异常才优先处理单一项偏高先记录并观察趋势。2.2 温度、风扇、电源机房空调故障的先兆show environment部分平台用show device能查看机箱温度、风扇转速、电源状态。作为网工这个命令比业务监控软件更容易帮你“提前发现问题”因为很多机房环境变化里设备温度是比业务告警更早出现的信号。我给自己定过一个判断原则绝对值不是最可怕的趋势才值得关注。一台设备常年温度在55到60度之间某天升到65度虽然没有触发高温告警但往往意味着空调系统出风异常或风扇效率下降。这时候趁业务低峰期检查一下机柜风道、清理一下防尘网比武警告警响了再去救火要主动得多。风扇状态要看有没有转速为0的项电源状态要看Active和Standby是否都在预期状态。电源和风扇故障通常不会立刻导致断网但会让设备进入降级运行失去冗余能力这个时候设备的可用性就悬了。2.3 重启记录与连续运行时间把show version里的运行时间字段单独拎出来讲是因为它太容易被忽略。设备正常运行时连续运行几百天甚至上千天都很正常。如果某次巡检发现运行时间突然清零首先确认是不是有人做了计划内重启排除计划内操作后重点排查电源模块历史、内存硬件这类存量问题。我有个切身教训以前一台核心设备频繁在凌晨三四点自动重启一开始怀疑是软件版本缺陷反复升级还是没有解决。后来才发现是电源模块老化导致电压纹波异常换掉电源后问题消失。非计划重启往往不是纯粹的软件问题硬件隐患占比很高。这类故障的特点是“日志里有重启记录但重启前没有任何明显报错”如果你只是翻日志会浪费大量时间在错误方向上。3. 接口与链路层八成隐性故障藏在这里3.1 端口状态down口不一定是故障意外翻转肯定是show interface status是最常用的端口状态命令能快速列出所有端口的连接状态、VLAN、速率、双工模式。看端口状态时不要只盯数量要区分“预期内的down”和“意外的down”。接入层交换机上大量未启用端口处于down状态完全正常真正要警惕的是业务链路对应的端口出现了up/down翻转。端口协商也值得多看一眼。如果出现速率、双工模式协商不一致连接虽然显示up但丢包和错包会持续增长。网络里“时通时断”的问题很大一部分最后都查到了网线质量不过关、水晶头氧化、跳线过长导致协商异常。这些物理层问题在命令输出里往往只能看到端口状态不稳定需要结合线缆现场排查。我的习惯是每次巡检把核心链路端口单独列出来只要出现一次非正常的 down就要在当次巡检记录里标注清楚连续两次则必须现场处理。3.2 CRC与错包判断链路“脏不脏”的核心指标show interfaces counters部分平台写作show interfaces counters errors可以查看接口收发报文统计重点关注错误包、CRC错误、runts、giants、discards等计数项。CRC错误持续增长意味着物理链路质量正在下降可能是弱光、电磁干扰、水晶头氧化、光纤弯曲半径过小等原因。如果CRC、runts、giants同步增长物理层的嫌疑就更大了。有一个关键经验看错包量要看“增长趋势”而不是单次数值。单次看到几十个CRC错包不代表链路坏了可能是对端设备重启瞬间产生的垃圾帧但如果每次巡检CRC都在增长且增速没有放缓这条链路大概率已经有物理层隐患需要尽早安排接线测试或更换线缆。把“CRC增量”和“巡检时间跨度”计算成速率比如每24小时增长多少比单纯看计数器归零与否有用得多。3.3 光模块光功率提前预判链路失效的利器show interface transceiver可以查到光模块类型、收发光功率、温度和电压。光功率是典型的“会渐变恶化”的指标正常光纤链路很少会今天好好的、明天完全断掉更多是光模块老化、尾纤污染、法兰盘松动导致接收光功率持续下滑直到跌过灵敏度阈值才彻底中断。所以巡检光模块的重点是建立基线和看趋势。以常见的10km单模模块为例接收光功率通常在-3dBm到-15dBm之间接收灵敏度一般在-20dBm左右。我的通用判断标准是接收光功率与模块接收灵敏度的差值最好大于3dBm如果已经非常接近灵敏度或者多次巡检有持续下滑趋势就要列入待处理清单。记录每个核心接口的光功率基线后我确实通过对比曲线发现过一条业务正常但光功率持续下滑的链路后来在低峰期更换尾纤后恢复正常没有升级为业务故障。这就是巡检里最划算的投入。4. 二三层转发表项网络“骨架”的体检4.1 MAC地址表和ARP表环路的照妖镜show mac-address-table看二层MAC地址表能发现环路和地址漂移的早期信号。正常网络里MAC表项数量与终端规模大致匹配每个MAC也基本稳定出现在固定端口。如果某个端口下的MAC数量在短期内异常膨胀或者同一个MAC频繁在不同端口之间跳变就要高度怀疑二层环路或存在异常的地址移动。ARP表用show arp查看正常环境的ARP表项不会剧烈抖动。ARP表异常增长背后可能是地址扫描、接口异常或三层网关配置错误。排障时有一个经验环路初期症状往往是网络间歇性卡顿、设备CPU升高、MAC表抖动直接看接口和路由不一定能发现异常但MAC表一定会先有动作。所以这条命令不是“例行公事”而是排除环路和欺骗的关键证据。4.2 路由表与协议邻居转发正确的前提show ip route看路由表重点确认有没有不该出现的缺省路由、有没有路由在持续振荡。动态路由协议环境里路由振荡往往先表现为协议邻居状态不稳。show ip ospf neighbor查看OSPF邻居状态时正常状态是Full如果长期停留在Down、Attempt、Init等状态说明Hello报文被过滤、认证配置不一致或链路本身有问题。跑BGP的核心设备用show ip bgp summary确认邻居数量是否稳定Established状态的邻居如果频繁翻动对转发的影响是非常直接的。我的巡检顺序习惯是先看邻居再看路由。邻居状态是路由表变化的上游原因邻居稳定但路由缺失问题多数出在路由聚合、过滤策略或接口状态邻居先抖动起来路由表变化只是结果。顺序对了定位会快很多。4.3 网关冗余协议状态别等切网才发现双主锐捷设备支持VRRP等网关冗余协议用show vrrp查看组内主备状态。这里只有一个核心判断标准同一个VRRP组里必须只有一台Master出现多个Master就是“双主”状态会造成网关MAC漂移、终端网关不稳定、丢包严重。VRRP双主多数是心跳报文被过滤、接口down或优先级配置错误导致巡检时记录Master设备的IP和状态与上一次结果对比能及时发现“主备切换后没有按预期回切”这类沉默故障。主备切换本身不是问题真正危险的是切换后业务状态不完整或者切换后没有回切导致冗余角色混乱。这类问题平时不出声一旦对端设备重启或维护立刻变成全网故障。巡检时顺手记一条VRRP状态成本极低收益却非常直接。5. 日志、时间与配置给排障留好后路5.1 NTP同步先校准时间再谈日志show ntp status查看NTP同步状态。设备系统时间如果不准所有日志时间戳都是错的。网工最怕的事情不是“日志有没有记录”而是“日志记录了但时间对不上”。一台设备说14点23分接口down另一台说14点25分接口up如果时间本身有差异整个故障时间线就是乱的还原现场会非常痛苦。锐捷设备的最佳实践是让所有核心设备通过NTP同步到统一时间源巡检时随手看一眼offset一旦发现偏差超过秒级就要处理。时间同步问题通常不会直接导致业务故障但会间接延长所有排障时间属于“迟发性问题”的高频根源。5.2 日志分级不要逐行读只看升级的和重复的show logging输出通常很长正确做法是先看error、critical级别报错再针对相同报错做频次统计。对每次巡检做一次日志快照重点识别两类问题一是出现了之前没出现过的报错二是同一条报错在短时间内反复出现。比如某个接口的up/down日志反复出现往往说明物理链路质量正在恶化或者对端设备存在隐性故障。锐捷设备日志里有大量正常的协议交互信息比如协议邻居周期性的信息级记录这些不属于故障。新手最容易踩的坑是把所有日志当告警处理把自己搞得很焦虑结果真正的隐患混在里面反而没被注意到。知道哪些日志可以忽略、哪些日志必须立即处理是网工经验的分水岭。我的底线是“新出现的报错必须搞清楚原因重复出现的报错必须判断趋势”。5.3 配置备份diff比记忆可靠得多show running-config看运行配置这里的核心价值不在于“看配置有没有错”而在于形成可回溯的基线。我习惯的巡检基本功是每次变更前执行一次show running-config保存到本地文件变更后保存第二次之后用文本对比工具比较两次输出。这样能精确看到改了什么、有没有改错比靠脑子回忆可靠得多。尤其是配置量大、多人维护的网络环境里两次配置的diff就是事故发生时最直接的证据。还有一个容易被忽略的细节改完配置后一定要执行write memory部分设备也支持copy running-config startup-config把配置保存到启动配置里。不保存意味着设备一旦重启就回到修改前状态。很多网工都经历过“确认过配置正常重启后发现配置消失”的尴尬巡检时把这个动作变成条件反射能帮你避免大量隐性风险。6. 把零散命令串成一套可落地的检查方案6.1 锐捷巡检命令速查表下面这张表是我日常维护锐捷设备时使用的命令组合覆盖前面说的四条主线。不同系列、版本命令可能存在差异建议以实际设备上帮助输出为准但检查思路完全通用。检查维度核心命令主要看什么处置思路设备身份与运行时间show version型号、软件版本、连续运行时间版本异常或重启记录需记录并跟踪CPU使用率show cpu usage5分钟均值、高占用进程持续高于70%且伴随异常再处理内存使用show memory剩余内存趋势、碎片状态剩余持续下降则重点观察温度与硬件状态show environment / show device温度、风扇转速、电源状态温度趋势异常优先处理风道端口状态show interface statusup/down状态、协商模式业务端口意外down需立即排查接口计数与错包show interfaces countersCRC错误、runts、giants、discards增量持续增长则检查物理链路光模块光功率show interface transceiver收发光功率、模块温度接近接收灵敏度则列入待处理MAC地址表show mac-address-table表项数量、MAC漂移异常膨胀优先排查环路ARP表show arp表项数量、异常条目持续增长需排查地址扫描路由表与邻居show ip route / show ip ospf neighbor / show ip bgp summary路由缺失、邻居状态邻居先抖动再查路由策略网关冗余show vrrpMaster数量和角色出现双主立即排查心跳链路时间同步show ntp statusoffset偏差、同步状态偏差超秒级需重新同步系统日志show loggingerror/critical级别、重复报错新报错必须定位原因运行配置show running-config与基线对比、变更内容变更后记得保存配置6.2 巡检时机与历史趋势记录巡检时间不要随意变化最好固定在业务低峰的同一时间段比如工作日上午。固定时间点的意义在于让每次输出的业务负载相对接近CPU、流量、接口错包这些指标才有横向对比的基础。如果今天上午巡检、明天下午巡检业务压力不同数值波动很容易误导判断。每次巡检的关键数值要按“设备名日期”建目录归档。有条件就放进运维系统没有条件就用表格记录重点字段包括CPU平均值、接口CRC增量、光功率、协议邻居状态、VRRP主备状态、日志新报错。这些指标单独看都不起眼拉出一个月的时间轴之后很多规律自己就浮现出来了。设备故障里有一大类是“渐变型”故障单次快照看不出任何问题只有历史趋势能暴露恶化轨迹。6.3 巡检中常见的误判与规避最后分享几个实操中容易误判的地方这些坑我自己都踩过或者见过别人踩。第一个是CPU瞬时100%就认定设备故障。很多情况下只是有人正在登录设备、网管系统正在采集数据先看5分钟均值再下结论不要让瞬时值吓到自己。第二个是接口CRC偶发几条就紧张。判断标准是“持续增长”而不是“出现过”一次性垃圾帧可以先记录不清零下次巡检再对比。第三个是光功率显示负得很大就认定模块坏了。不同模块的接收灵敏度差异很大要结合模块类型、光纤长度和灵敏度阈值综合判断。第四个是配置对比时只扫一眼就说“一样”。配置里隐藏的空格、行尾、大小写差异可能影响实际行为必须用diff工具逐字符对比。这些误判的共同根源是“只看单次数值不看上下文和趋势”。巡检动作本身不产生价值产生价值的是判断。把命令输出当成一组体检指标来读结合历史数据和业务上下文做决策才是网工巡检的正确打开方式。我现在的习惯是每次巡检固定走同一套命令但重点永远放在“和上次比变了什么”。巡检的意义不在于把每一行输出都看懂而在于在业务还没有感知到链路劣化之前提前把隐患修掉。锐捷设备型号版本差异很多命令细节可能不完全一致只要沿着整机资源、链路质量、转发表项、日志配置这四条主线走配合历史趋势去判断这套巡检思路放在任何品牌的网络设备上都一样成立。对网工来说能发现问题的巡检才叫巡检只会敲命令收集输出设备一多就会露馅。