企业官网建设流程全解析

做了这么多年网络运维，巡检这件事我基本每周都要干，不管是给客户做季度巡检，还是自己负责的网络日常例行检查，锐捷设备一直都是出现频率很高的设备。很多人觉得巡检就是登录设备敲几条命令、截图留档，但实际干过就会知道，巡检命令选得对不对、输出怎么解读、异常怎么定位，这中间的差距很大。这篇就围绕锐捷网络设备巡检命令，把我日常在用的命令、参数含义和踩过的坑整理一遍，给同行一个可以直接照着用的参考。

先说清楚这篇文章适合谁。如果你刚接触锐捷设备，还不知道该敲什么命令来检查设备状态，这篇文章能帮你建立一套完整的巡检命令框架。如果你已经有几年经验，文章里关于输出解读和故障排查的部分，大概率也能补上一些平时容易忽略的细节。无论你面对的是锐捷的园区交换机、核心交换机还是出口路由器，命令体系基本都能对得上。

1. 巡检这件事，为什么值得认真做

巡检的目的很多人理解成“看看设备有没有坏”，这个理解太浅了。真正的巡检是给网络做一次全面体检，目的有三个：一是确认设备当前运行状态健康，没有隐患；二是发现那些还没爆发但正在恶化的指标，比如光模块误码率持续上升、接口CRC错误开始增长；三是为后续故障排查留下基线数据，没有历史数据做对比，等出了故障再排查就会特别被动。

1.1 巡检到底在“巡”什么

我习惯把一次完整巡检拆成四个维度：硬件健康、系统资源、链路质量、协议状态。硬件健康看电源、风扇、温度，这个决定设备会不会突然宕机。系统资源看CPU、内存、缓冲区，这个决定设备在流量高峰时会不会丢包。链路质量看接口状态、光模块光功率、错误计数，这个决定用户上网体验好不好。协议状态看路由邻居、冗余网关、STP，这个决定网络在故障时能不能自动切换。

这四个维度不是并列关系，而是有逻辑顺序的。我巡检查硬件、查系统资源，如果这两层有问题，链路和协议查得再精细也没意义，因为设备本身已经处于亚健康状态了。反过来，如果硬件和系统资源都没问题，链路和协议的异常就能比较精准地定位到具体的线缆、光模块、配置上。这个顺序决定了巡检命令的敲击顺序，后面我会按这个思路来组织命令清单。

1.2 巡检前要准备什么

别上来就敲命令，先把准备工作做完。我每次巡检前都会确认三件事：设备管理IP通不通、SSH/Telnet登录方式可用、账号权限够不够。锐捷设备默认支持SSH和Telnet，现在能开SSH就尽量别用Telnet，明文传输容易被抓包，而且很多配置已经不让用弱协议了。

登录之后先别急着逐条敲命令，我习惯先把设备信息收集一遍：设备型号、序列号、软件版本。这些信息要记录到巡检表里，后续如果发现软件版本有已知问题或安全通告，能快速定位哪些设备受影响。版本号这块要特别注意，锐捷的设备软件版本号看起来差不多，但特性差异可能很大，比如某些版本对MSTP的处理就有细节差异，巡检时对比多个设备会发现同版本的行为不一致。

另外，如果管理的是多台设备，建议先把设备清单按网络层次整理好：核心层、汇聚层、接入层，每层巡检的重点不完全一样。核心层更关注CPU、内存、链路冗余和协议收敛，接入层更关注接口状态、终端接入、STP边缘端口配置。下面的命令我会按通用性来讲，具体使用时要结合设备在网络中的角色做取舍。

2. 开机必查：设备硬件与系统状态

硬件和系统状态是巡检的第一站，也是最容易被忽略的一站。很多网工上来就查接口流量，结果查了半天发现整台设备CPU已经跑到90%多，接口数据早就失真了。硬件和系统状态相当于一个人体检时的血压和心率，基础指标不正常，后面所有指标都要打问号。

2.1 版本信息与运行时长

第一组命令先看设备基本信息：

show version

这条命令在锐捷交换机、路由器上都通用，输出包含硬件型号、软件版本、系统运行时长、设备序列号等信息。运行时长是个容易被忽略但有价值的指标，如果设备刚重启不久，说明设备可能因为断电、崩溃、升级发生过重启，需要追问原因。时间字符串一般包含“System uptime is xxx”或类似字段，不同产品的显示格式略有差异，但思路是一样的。

接着可以看设备详细硬件信息：

show device show inventory

这两条在不同型号上可用性不完全一样，有些设备支持，有些设备不支持。它们用来查看单板、模块、电源、风扇的在线状态。如果是箱式核心交换机，这类命令尤其重要，单板掉线、电源不在位都能直接看出来。我记得有一次巡检一台汇聚设备，发现其中一个电源模块状态异常，但设备还在正常运行，要不是巡检时多看了这个字段，等那个电源彻底坏掉就麻烦了。

2.2 CPU与内存，先看最直观的健康指标

CPU和内存是最直接的健康指标，命令如下：

show cpu utilization show memory

CPU利用率的输出会按整体利用率和各任务占用率分别展示。正常情况，空闲设备的CPU利用率应该很低，有流量时会有波动，但如果持续高于60%甚至80%，就要注意了。我遇到过很多次CPU异常高的设备，打开输出一看全是某个协议进程在狂转，比如STP频繁计算、ARP泛洪，这种时候光看总利用率是不够的，必须看具体是哪个进程消耗的CPU。

内存这条命令输出的是内存总量、已用量、剩余量和缓冲区占用。锐捷设备内存耗尽的情况虽然比CPU异常少，但一旦发生基本就是设备重启级别的故障。巡检时要特别关注空闲内存是不是持续在减少，我见过某些软件版本存在内存泄漏问题，设备运行几个月后空闲内存越来越小，最终导致进程崩溃。这种趋势性的东西，一次两次巡检看不出来，但只要保留每次巡检的数据，横向对比就会发现异常。

提示：show cpu utilization和show memory建议每次巡检都记录具体数字，而不是只记“正常”“异常”。没有数字，下次巡检就没法对比趋势。

2.3 温度、风扇与电源

硬件环境状态直接关系设备寿命，命令如下：

show environment show fan show power

温度输出会列出设备内部各传感器的温度值，同时给出告警阈值。正常设备温度应该远低于阈值，如果接近阈值，说明机房空调有问题、设备通风不畅或者风扇转速下降。我记得有一次机房空调故障，核心交换机温度一路飙到接近告警线，巡检时如果不看温度，光看业务觉得一切正常，等设备过热关机就晚了。

风扇和电源的状态检查相对简单，看在线状态、转速是否正常、有没有告警。这里要提醒一个经验：电源和风扇的故障，很多是瞬间发生的，巡检能发现的是那些已经处于降级状态的情况。比如双电源设备一个电源失效，设备还能继续运行，但冗余能力已经没了，这时候必须尽快安排更换，不要抱侥幸心理。

3. 接口与链路，网络质量的根本

硬件和系统状态没问题后，第二个重点就是接口与链路。用户能感受到的网络问题，慢、卡、丢包，几乎都跟链路质量有关。接口这块巡检做得好不好，直接决定了你能不能在用户抱怨之前发现问题。

3.1 接口状态和流量怎么看

锐捷设备上，我习惯先看接口概况：

show interface status

这条命令会把所有接口的管理状态、操作状态、速率、双工模式列出来。我主要看几点：有没有接口处于“errdisable”或“down”状态但实际应该接线的、有没有接口速率协商异常（比如千兆口协商成千兆但实际流量很小，或者协商成了百兆）、有没有接口双工模式不对。

接口概况看完，再针对关键接口看详细统计：

show interface GigabitEthernet 0/1

详细输出里最重要的几个字段包括：接口当前状态、速率、双工、输入输出流量、输入输出错误计数、CRC校验错误、冲突计数。我查接口问题时，优先看CRC错误和输入错误计数。CRC错误持续增长，基本可以断定物理层有问题，可能是光模块老化、网线质量差、水晶头接触不良或者电磁干扰。

流量这块还要提一下，很多人用web界面或流量监控系统看带宽，但设备命令行里看的是瞬时流量，两者用途不同。巡检时我用命令行看的是接口是否出现突发拥塞、错包率是否在可接受范围，而不是看长期流量趋势。长期趋势要交给监控系统去统计。

3.2 光模块与误码，光路问题的早期信号

光纤链路在园区网和数据中心用得非常多，光模块的巡检单独拿出来讲：

show interface transceiver show interface transceiver diagnostics

第一条命令看光模块的基础信息：模块类型、生产厂家、序列号、光功率。第二条命令看光模块的详细诊断参数：发送光功率、接收光功率、温度、电压、偏置电流。光模块巡检的核心就是对比发送光功率和接收光功率是否在正常范围。

这里有个经验：光模块接收光功率不是看绝对值正不正常，更要看衰减和趋势。同一根光纤，上次巡检接收光功率是-8dBm，这次是-12dBm，虽然还没到告警阈值，但说明光路在劣化，可能是光纤弯曲过大、法兰头脏污、光模块老化。这时候应该安排清洁光纤接头或准备替换光模块。如果接收光功率掉到-20dBm以下，已经接近很多光模块的灵敏度极限，业务随时可能闪断。

误码率是另一个关键指标。很多光模块支持查看误码计数，误码持续增长说明物理层在丢bit，上层表现为偶发丢包、时延抖动。我曾经排查过一个“为什么视频会议画面偶尔卡顿”的问题，最后就是通过光模块误码计数定位到一根跳线有问题，换掉之后问题彻底消失。

注意：光模块诊断数据不是所有锐捷设备都支持，具体命令和输出字段在不同型号上会有差异。要求严格的环境，建议在巡检时记录基线数据，方便后续做趋势对比。

3.3 聚合链路与STP状态

核心层和汇聚层之间经常用链路聚合，巡检时要看聚合组的状态：

show lacp summary show etherchannel summary

锐捷设备上链路聚合命令在不同产品线上不完全一样，有的用LACP，有的叫法不同。核心要看的是聚合组里成员接口的状态是不是都在线、是不是都处于选中（Selected）状态。我最怕看到的情况是，聚合组里4个成员口只有2个在用，另外2个处于备用或失效状态，带宽直接少了一半。这种问题如果不看聚合状态，光看单个接口状态是发现不了的，因为每个口单独看都是正常up的。

STP状态也要顺带检查：

show spanning-tree summary show spanning-tree

主要确认几点：根桥是不是预期的设备、所有关键接口的角色是否正常（root/designated端口该是什么就是什么）、有没有端口被封堵（blocking）。遇到过接入层交换机由于BPDU Guard配置，把下联终端接口给errdisable的情况，这种问题就是巡检STP状态发现的，不然后面终端上不了网还不知道原因。

4. 路由与协议，连通性的核心

链路都是通的、硬件也没问题，但用户就是访问不了某个网段，这种时候基本就是路由和协议层的故障。协议层的巡检是三层设备巡检的重头戏，尤其是有冗余设计的网络。

4.1 路由表与邻居状态

先看整体路由：

show ip route show ip route summary

巡检时不要求把整张路由表背下来，但心里要有预期：这台设备是默认路由还是跑动态协议、哪些网段该出现在路由表里、通过什么下一跳出去。如果发现某些预期内的路由不见了，往往意味着链路或邻居关系出了问题。路由表摘要信息能快速确认路由总数，数量级如果突然异常增大，可能是路由环路或路由泛洪。

动态协议邻居状态必须逐条确认：

show ip ospf neighbor show bgp summary

OSPF邻居状态正常应该显示Full状态，如果有邻居卡在Init、Exstart、Exchange状态，基本就是MTU问题、区域配置不一致或者网络类型不匹配。BGP邻居状态正常应该是Established，如果一直处于Connect或Active状态，一般是TCP连接建立不起来，常见原因是过滤策略把端口给挡了或地址族配置出问题。

我处理过最典型的一次路由故障，就是两台设备之间OSPF邻居忽闪忽现，业务断断续续。巡检时看邻居状态发现一直在重启，排查到最后是对端设备的接口下配置了错误的网络类型，导致hello报文交互异常。如果当时巡检只看路由表，是根本发现不了这个问题的，因为路由表里OSPF路由还在，但实际已经在老化边缘了。

4.2 冗余网关与快速收敛

园区网和接入网经常用VRRP做网关冗余，巡检命令如下：

show vrrp show vrrp brief

重点是看虚拟IP地址是否正确、各设备的VRRP优先级配置是否符合预期、谁是Master谁是Backup。正常情况下，Master应该只有一台，Backup稳定待命。如果出现两台设备同时是Master的情况（俗称双主），就是VRRP配置冲突，会导致网关MAC地址飘忽不定，全网断断续续。这个故障我曾经在真实网络里见过一次，原因是两台设备的VRRP版本配置不一致，巡检时花了不少功夫才定位到。

如果是出口路由器，还要看NAT、策略路由等状态的实时情况。出口设备巡检常用的命令：

show ip nat translations show ip policy

NAT转换表如果异常增大，可能是内网有主机在大量发起外部连接，或者有异常流量在打满NAT表项。虽然这些不是标准的“连通性”巡检项，但出口设备的稳定性很大程度上取决于这些状态是否健康，我习惯在巡检时一起看一下。

5. 日志、配置与备份，事故后的救命稻草

设备日志和配置文件平时不起眼，但出了故障之后，它们就是第一手资料。更关键的是，如果不做配置备份，哪天设备坏了要更换，或者配置被误改要回退，你会非常被动。

5.1 日志里找线索

查看设备日志：

show logging show log buffer

锐捷设备的日志里最有价值的几类信息包括：接口状态反复变化、认证失败记录、STP拓扑变更、电源风扇告警、配置变更记录。我巡检时不会把所有日志从头看一遍，那是几千行起步的，我只关心最近一段时间内有没有异常级别的日志，以及日志是否在刷屏。

日志刷屏是个容易被忽视的问题。设备可能会因为某个接口反复up/down，或者某种协议报文被持续丢弃，每秒产生大量日志。日志刷屏的危害不仅是日志文件很快被写满，更严重的是会导致CPU占用升高，进而影响转发性能。我遇到过一次二层设备疯狂打印ARP日志的案例，设备CPU飙升，排查发现是下联交换机下挂了很多终端，不停的广播ARP请求，把设备的CPU吃掉了。

这里要说一个实用技巧：巡检时不要只盯当前日志，要看日志的时间分布。如果某个异常事件发生在凌晨3点，操作日志又是空白的，大概率是物理链路问题或者外部干扰。如果异常事件和配置变更时间重合，就要优先怀疑近期改动。日志和配置结合分析，往往能快速找到故障根因。

5.2 配置备份与基线对比

配置巡检的第一步其实就是保存和备份：

show running-config write memory

锐捷设备上保存配置的命令可能是write memory，也可能是copy running-config startup-config，不同设备型号有差异。我见过太多人改完配置忘了保存，设备一重启配置全丢。所以每次巡检，我会在确认配置没问题后，主动执行一次保存操作，确保运行配置和启动配置一致。

配置备份不只是保存当前配置，更要把配置导出留存。每天或每次重大变更后，把show running-config的输出保存成文件，按设备名和日期命名归档。别嫌麻烦，等配置被误改、需要回退的时候，你就知道这些历史配置文件有多值钱了。

导出配置后，下一步是做基线对比。拿当前配置和上次备份做diff，重点对比新增和删除的配置行。有些网络故障就是某次变更引入的，如果能在巡检阶段通过对比发现计划外的配置改动，就能在故障发生前解除隐患。我常用的做法是，把配置导出后用文本对比工具和基线比对，一眼就能看出差异点。

提示：配置对比不只要看内容差异，更要分析差异的影响范围。比如一条ACL的新增，要评估它是否会影响现有业务流量；一个端口模式的改动，要看是否会导致下联设备协商出问题。

6. 巡检中的典型故障与排查速查

巡检过程中大概率会遇到一些异常指标，与其说等故障爆发再排查，不如在巡检时就把常见异常的处理思路理清楚。这个部分是我的个人经验汇总，给做巡检的同行提供一些排查方向。

6.1 CPU高、丢包、闪断怎么定位

CPU持续偏高，先把show cpu utilization打开，看具体是哪个进程在占用。常见情况有三类：STP频繁计算、ARP泛洪、路由协议进程异常。STP频繁计算通常伴随拓扑变更日志，ARP泛洪通常出现在终端数量大或者有异常主机的网络里，路由进程异常则要结合路由邻居状态和路由表动态来看。

接口出现丢包，优先看错误计数是发生在物理层还是队列层。物理层错误表现为CRC、Input Errors增长，基本指向线缆、光模块、接地问题。队列层错误表现为Output Drops、Buffer Errors增长，指向带宽拥塞或缓冲区不足。两者处理方向完全不一样，一个是换线换模块，一个是扩容或做QoS。

接口闪断（物理层频繁up/down）是最难缠的问题之一。如果日志里有大量接口状态翻转记录，排查顺序建议是：先看光模块光功率是否在临界值、再看光纤跳线是否松动或弯折过大、然后看对端设备接口统计、最后检查电压和环境干扰。光模块光功率在临界值附近波动时，最容易出现频繁闪断。

VRRP双主怎么快速确认？两台设备都执行show vrrp，如果两台设备显示的Master优先级相同或都能收到对端VRRP报文，基本就是优先级、定时器或版本配置冲突。检查配置里VRRP的优先级、抢占模式、Advertisement定时器是否一致即可。

6.2 让巡检更省力的脚本化实践

如果你管理的是几台几十台设备，一条条命令敲过去还能接受。设备数量上百台之后，手工巡检就不现实了，我强烈建议做脚本化。思路很简单：用脚本SSH登录设备，批量执行巡检命令，把输出保存到文件，再做关键字分析和汇总。

一个基础的巡检脚本大致结构是这样：定义一个设备列表，循环登录设备，执行预定的命令清单，把输出按设备名和命令名写入文件。后面接一个关键字分析环节，扫描输出文件，匹配“error”“down”“critical”“fail”等标志性关键词，把命中的设备的告警信息汇总成一个表格。

脚本本身不复杂，但要注意几个细节。第一是命令清单要按设备角色区分，核心设备跑全套命令，接入设备只跑接口和STP相关命令。第二是登录和交互过程要处理好，尤其是密码输入和分页输出，锐捷设备默认有分页，脚本里最好先关闭分页，不然输出会被截断。第三是保存输出的文件名命名规范要统一，方便后续对比历史数据。

如果你的环境里有监控系统，也可以把巡检命令的返回结果通过SNMP或API方式接入监控平台，实现自动化告警。不过这个步子迈得比较大，要结合现有监控系统能力来设计。我个人建议先把脚本化的巡检跑起来，形成习惯，再逐步演进到更完整的自动化方案。

最后分享一个我个人的小习惯。每次巡检结束，我会把发现的问题按严重程度分类：紧急问题当天处理，重要问题列入计划，轻微问题记录到跟踪表。巡检不只是敲命令收集数据，更重要的是把数据变成行动项。很多网络故障之所以爆发，不是巡检没发现苗头，而是发现问题之后没有跟进处理。这个习惯坚持下来，你的网络会越来越稳，你也会更清楚自己管理的每一台设备在什么状态下运行。