尧图网站建设 
简介面向网络运维人员与H3C设备管理者这份专业巡检模板适用于路由器、交换机、防火墙等各类H3C网络设备用于将日常分散的检查命令整合为标准化巡检流程。模板覆盖从设备基本信息、软件版本与运行时间、CPU/内存利用率、模块与电源风扇状态、端口配置、链路带宽、VLAN与以太通道、路由交换协议、STP、NAT连接数到防火墙策略及机房环境等十余个巡检维度每条检查项均附有具体查询命令、期待结果、备注说明和结果判定栏做到直观可执行。包内共1个doc文档文档约38KB排版紧凑既可直接打印作为纸质巡检单也可编辑后留存电子记录。该资源已有108人学习使用适合网络运维新手快速建立巡检思路也可作为团队统一巡检模板的参考基线帮助提前发现潜在风险并支撑网络优化与长期规划。1. H3C网络设备巡检报告模板16项检查与命令清单一次讲清深夜两点值班同事打来电话核心交换机温度65度要不要去机房如果手边有一份H3C网络设备巡检报告模板这个问题几秒钟就有答案——模板里的C-A-06项写得很清楚设备内部各部分工作温度小于最高限制80摄氏度。这份模板最大的价值就是把散落在各设备手册里的巡检命令、判断阈值、记录方式收敛成一份可以照着执行、照着填写的检查单。H3C网络设备巡检报告模板包含16个编号检查项每项都给出了检查命令、期待结果、备注和检查范例后面还附了网络拓扑、链路、设备信息的巡检单适合刚接手网络运维、需要建立巡检基线的新人也适合老工程师查漏补缺完善自己的巡检清单。2. 模板框架拆解检查指导的分组逻辑与巡检单信息设计2.1 模板的三段式结构先知道查什么再知道怎么查最后记录这套巡检模板打开看其实分三块。第一块是网络巡检项目总清单把网络拓扑、链路类型、设备信息、软件版本、连通性、协议状态、防火墙、机房环境等大类列出来相当于告诉巡检的人这次要看哪些面第二块是检查指导对每一个检查项做了编号并给出命令、期待结果、备注与检查范例相当于一份标准的操作手册第三块是多张巡检报告单包括网络拓扑巡检报告单、网络链路状况巡检单、网络设备巡检单防火墙、路由器用来落地记录。这三块分别对应完整闭环先知道查什么再知道怎么查最后把结果写下来。我实际排障时也按这个节奏走——接到故障先翻对应检查项目C-A系列的输出能快速定位硬件类问题C-B系列则用来判断协议和业务链路的状态。模板里每个检查项都留有检查范例这个设计值得单独说一句新手照着范例比对当前输出能快速看出差异不用对着满屏数字发呆。2.2 C-A与C-B为什么硬件健康和应用状态要分开编号模板的检查指导部分按C-A和C-B两组编号。C-A共7项C-A-01到C-A-07对应设备软件版本、持续运行时间、CPU利用率、内存利用率、模块运行状态、运行温度、系统日志全部是设备自身的健康指标C-B共9项从C-B-01到C-B-09覆盖VRRP、VLAN、链路聚合、trunk、路由、STP、接口状态、NAT、防火墙全部是网络协议与业务运行的状态。这个分组不是随便排的。设备反复重启、风扇异响、温度异常优先跑C-A业务不通、路由振荡、VLAN错乱优先跑C-B。两组检查的侧重点不同故障定位的思路也不同。实际巡检中C-A组有任何一个不达标C-B组的协议状态也基本无法稳定所以顺序上我一般先过C-A再过C-B。分组编号范围检查内容C-A 硬件健康C-A-01 ~ C-A-07软件版本、运行时间、CPU、内存、模块状态、温度、日志C-B 协议与应用C-B-01 ~ C-B-09VRRP、VLAN、链路聚合、trunk、路由、STP、接口、NAT、防火墙2.3 巡检单里的设备台账字段CPU以外的东西有时更救命巡检单里除了CPU利用率、内存利用率、日志信息这些运行指标还有一列设备基本信息品牌、序列号、设备型号、管理地址、软件版本、放置位置、机架设备、端口数量、端口类别。这些字段看起来是台账信息但排障时真的救命。设备报修要序列号走商务流程要问保修状态现场割接前得知道设备在哪个机柜、有没有备件。模板里放置位置和设备作用描述是分栏填写的这两栏把一台设备在网络里的身位交代清楚了。端口类别明确区分了□光□电这个细节也有实际意义——光口要备SFP模块电口要备电口模块备件类型完全不同。还有一处容易被忽略的字段标签完善程度。标签不全的跳线在割接时就是翻车现场一张巡检单把标签情况也纳入记录等于逼着巡检人把物理链路状态也过一遍。模板末尾的网络链路状况巡检单里专线类型、带宽、链路联通性状态都有对应格子这种记录习惯对后续链路扩容、故障通报都很实用。提示模板里一直写IOS版本信息IOS备份情况但H3C设备实际运行的是VRPVersatile Routing Platform系统命令是display version。理解这一点就不会拿着思科IOS的概念往H3C设备上套。模板沿用IOS是早期从思科习惯带过来的写法命令体系仍是H3C/华为VRP这套。3. 硬件健康巡检命令落地版本、CPU、内存、温度、日志怎么查3.1 版本与运行时间C-A-01、C-A-02display version要看的四块信息[H3C] display version输出里需要抓住四块信息。第一是VRP软件版本号C-A-01的判定标准是同合同也就是版本与采购合同约定的版本一致避免出现合同里谈的是新版本、现场跑的是老版本的情况第二是uptime即设备持续运行时间正常应该是从设备上线到当前日期第三是Last reboot后面的重启原因和时间第四是内存大小、闪存大小、VRP映像文件名和启动位置。模板给的范例里Quidway AR46-20 uptime is 44 weeks, 5 days这台设备连续跑了44周多属于健康的运行状态。反过来如果uptime只有几天就要立刻去看Last reboot后面的原因再结合日志定位是什么把设备搞重启了。3.2 CPU利用率C-A-03look at VIDL再看历史趋势[H3C] display cpu [H3C] display cpu historydisplay cpu默认查近60秒周期内的CPU占用率输出会列出TaskName和CPU两列模板范例里VIDL 98%表示空闲进程占了98%设备很闲。display cpu history看过去60分钟内的平均CPU占用趋势判断是否有持续的峰值。判定标准模板写得很明确CPU利用率平均值小于50%最大值小于70%。注意不要被CPU Usage那个百分比迷惑要结合进程表里VIDL的值来看100%减去VIDL才是当前实际占用率。平均值长期贴着60%、70%跑的设备需要重点排查是否跑着异常进程或者业务量本身就快接近设备上限了。3.3 内存利用率C-A-04涨上去未必会自动降回来[H3C] display memory输出就三行System Available Memory系统可用内存、System Used Memory系统已用内存、Used Rate使用率。模板判定标准是使用百分比小于80%。范例里Used Rate: 22%说明内存很富余。内存和CPU不一样CPU是瞬时指标内存是累计指标。如果Used Rate持续走高要留个心眼——是不是ARP表项、路由表项、NAT会话在膨胀这类表项型内存占用涨上去之后未必会自动降回来往往要等表项老化或者重启设备才能释放。3.4 模块状态与温度C-A-05、C-A-06电源和风扇是不是Normal[H3C] display device [H3C] display environmentdisplay device输出各槽位模块的在线状态和Status模板范例里Slot 0的RPU是NormalSlot 6/7的PWR电源也是NormalSlot 8的FAN风扇Normal。所有模块都应显示Normal电源冗余双PWR和风扇状态是重点这两处出问题往往不会立刻断网但会埋下隐患。display environment输出各温度采集点的当前温度、低限和高限。模板里HighLimit是80摄氏度实际巡检中温度逼近上限前就要排查机房空调是不是失效了、设备进风口是不是被遮挡、风扇转速是不是下降了。温度问题拖到告警再处理往往已经对设备硬件造成了不可逆损伤。3.5 日志检查C-A-07先对时间再看logbuffer[H3C] display clock [H3C] display logbufferdisplay clock先看设备时间和实际时间差。模板备注说偏差超过10分钟就要校准时间不对的日志在排障时就是干扰项。display logbuffer输出日志缓冲区的配置和内容重点看Dropped messages、Overwritten messages和反复出现的告警。偶尔出现一条告警可以忽略连续刷同一条告警就要查了。4. 协议与业务状态巡检VRRP、VLAN、路由、STP、NAT的检查要点4.1 VRRP热备C-B-01Master/Backup状态和优先级都要核对[H3C] display vrrp [H3C] display vrrp statisticsdisplay vrrp输出里关键字段是Virtual Router的state当前是Master还是Backup、Config Priority配置优先级、Run Priority运行优先级、Preempt抢占是否开启、Auth Type认证类型。判定标准是主备状态与设计相符。模板范例里state是MasterConfig Priority 120这种配置一般对应主设备备设备的优先级应该更低且Preempt开启时主备切换才能自动回切。display vrrp statistics看切换次数切换次数异常增加说明主备在频繁抖动常见原因是对端VRRP配置不一致或者上行链路不稳。注意Auth Type如果配置了认证两端必须一致否则VRRP报文会被丢弃主备状态直接混乱。4.2 VLAN与trunkC-B-02、C-B-04先看VLAN数量再查trunk允许列表[H3C] display vlan all [H3C] display port trunkdisplay vlan all最前面一行会列出当前存在的VLAN ID比如模板范例里1(default), 100, 107-112, 114, 116, 118, 4000, 4094先和设计文档比对数量和ID是否一致再看每个VLAN里包含的端口是否与预期相符。常见问题是VLAN数量比设计多——多半是有人临时建了VLAN没删或者配置了VLAN但没加端口残留配置会干扰后面排障。display port trunk看各接口的PVID和VLAN passing。模板备注里有一句很值得记VLAN passing应该按照实际需求尽可能减少通过的VLAN。默认放通全部VLAN是很多现场的习惯但VLAN越多广播域越大环路风险也越高trunk上只放业务需要的VLAN才对。4.3 链路聚合C-B-03Select Ports和Unselect Ports的比值是关键[H3C] display link-aggregation summary输出里几个字段值得对照AL ID聚合组ID、TypeM表示手工聚合、Select Ports被选中的成员端口数、Unselect Ports未被选中的成员端口数、Share TypeShar表示负荷分担、Master Port主端口。模板范例里Select Ports为1、Unselect Ports为0说明这个聚合组唯一成员端口工作正常。如果Unselect Ports大于0说明有成员端口聚合失败常见原因有两端聚合模式不匹配一侧手工一侧静态、成员端口物理状态down、端口速率不一致。还有个容易被忽略的场景聚合口上方接了流量很大的业务成员端口满载后出现丢包这时要确认聚合组内所有成员都被Select避免聚合口满了但部分链路空转。4.4 路由与STPC-B-05、C-B-06默认路由、直连路由、根桥优先级一起看[H3C] display ip route [H3C] display stp briefdisplay ip route检查路由表重点看默认路由、直连路由、动态路由三条线。模板备注说得很实在对于企业一般都是交换网一条默认路由指出只是注意VLAN信息与直连路由是否相符。如果出现路由表里有的网段实际VLAN不存在或者VLAN存在但路由缺失基本就是配置不同步的结果。display stp和display stp brief检查生成树状态。模板备注里有一句建议不要全部采用默认优先级尤其是根网桥的优先级一定要低。全网优先级都是默认32768时根桥由MAC地址最小者决定一旦新设备接入或旧设备下线根桥可能漂移STP会重新计算收敛网络在收敛窗口内会出现广播风暴和短暂中断。核心设备stp priority建议调到4096或更低接入层保持默认即可。4.5 接口状态与NATC-B-07、C-B-08错误包占比要小于万分之一[H3C] display interface [H3C] display nat statistics [H3C] display nat alldisplay interface可加具体端口查看单接口状态重点关注Input errors、collisions、crc、late collisions这几类计数。模板备注给出了量化标准端口冲突、错误等信息小于1/10000。错误包占比超标的常见原因是双工模式不匹配、线缆老化、光模块衰减查的时候先看端口双工和速率协商结果再换线缆或光模块验证。display nat statistics看当前NAT连接数和转换情况display nat all查看NAT地址池、老化时间和Server配置。模板范例里TCP老化时间是86400秒这个数值在生产环境偏大P2P、视频类业务并发连接多时老化时间太长会导致NAT表项快速占满。模板给的建议很直接在没有流量控制设备的情况下在NAT设备上做连接数限制每个用户限制100个连接防止连接数过多超出设备承载能力。4.6 防火墙检查C-B-09ACL里出现permit ip any any要警惕防火墙一般通过WEB界面登录查看重点检查四块策略应用是否符合设计、failover状态如果是双机、xlate状态、DMZ区是否正常。模板备注里对ACL的建议值得单独记一笔禁止使用permit ip any any这类允许所有流量的语句尤其是互联网边界。H3C/华为防火墙基于安全域做策略默认拒绝跨域流量配置策略时应该是显式放行业务流量而不是图省事全放通。5. 巡检避坑uptime误导、CPU误解、日志漂移等5个翻车点5.1 uptime短不等于设备质量差要看Last reboot做了什么现象display version显示uptime只有几天但设备采购运行时间已经一年多了。原因设备曾经重启过可能是机房断电、温度过高保护触发、内存泄漏导致进程重启也可能是人为误操作。解决重点看Last reboot行模板范例里System returned to ROM By Power-on表示上电重启属于断电后恢复的常见情况如果显示其它原因要结合display logbuffer找重启前后的日志。模板C-A-02的备注写得很明确设备uptime时间比较短一定要利用这个命令查看最近一次重启时间。5.2 CPU利用率看错对象CPU Usage那行数字不是全部现象display cpu输出CPU Usage: 2%看起来很低但设备处理明显变慢网页打不开、ping延迟大。原因全局利用率低只代表平均负载低可能存在单进程异常比如SNMP频繁轮询、FTP传输、攻击流量把某个进程占满。解决看TaskName列VIDL是空闲进程100%减去VIDL的占比才是实际CPU占用率再用display cpu history看60分钟趋势如果平均值超过50%就要定位是哪个进程在消耗。5.3 日志时间漂移导致排障时间线对不上现象日志里告警时间与业务故障的实际时间对不上排查时无法对应事件先后顺序。原因设备没有配置NTP或者NTP服务器不可达设备重启后时间回退到出厂值。解决先display clock看当前时间偏差超过10分钟就校准配置NTP同步H3C设备启用ntp-service功能后指向内网NTP服务器。纯内网没有NTP服务器时至少每周手动校时一次否则日志分析的参考价值会大打折扣。5.4 STP根桥优先级全默认拓扑一变更就收敛现象网络里新接入一台交换机后业务出现短暂中断持续几十秒又恢复。原因所有交换机优先级都是默认32768新设备的MAC地址更小根桥漂移到了新设备上STP重新计算收敛期间端口经历了Listening和Learning状态。解决核心交换机把stp priority调到4096或更低明确根桥位置接入层保持默认优先级。改完后用display stp确认根桥MAC是否与预期设备一致。5.5 NAT连接数飙升终端不多但表项爆了现象display nat statistics显示连接数持续逼近设备上限新业务无法建立连接。原因P2P下载、视频会议、网络直播这类应用会产生大量并发连接NAT表项被占满后新的连接无法转换。解决在NAT设备上做连接数限制模板建议每个用户限制100个连接同时结合业务情况调整老化时间TCP老化时间86400秒对多数场景都偏长。改完后观察连接数曲线确认限制策略对正常业务没有误伤。6. 把巡检模板变成自动化脚本Netmiko采集与阈值判定6.1 用Netmiko批量采集H3C巡检命令模板里的16个检查项逐条手动敲一遍一台设备至少要十几分钟设备一多就很浪费时间。常见做法是用Netmiko把命令批量发到设备上H3C的Comware系统对应device_type是hp_comware。登录方式、enable密码、超时时间都写在连接字典里改成自己设备的IP和账号就能跑。from netmiko import ConnectHandler h3c_device { device_type: hp_comware, # H3C Comware 系列设备 host: 192.168.1.254, username: admin, password: Pssw0rd, timeout: 30, } commands [ display version, display cpu, display memory, display environment, ] with ConnectHandler(**h3c_device) as conn: for cmd in commands: output conn.send_command(cmd) print(f {cmd} ) print(output)这段代码的逻辑是先用ConnectHandler建立SSH连接循环发送命令列表里的巡检命令并打印输出。device_type参数决定Netmiko用哪种CLI交互方式hp_comware适用于H3C的Comware V5/V7系列timeout参数设置连接超时时间设备响应慢时防止脚本卡死。采集到的原始输出可以继续喂给解析函数。6.2 解析关键指标生成Excel报告采集只是第一步真正有复用价值的是把输出里的CPU、内存、温度解析出来和模板里的阈值比对自动标记异常项。用正则从输出文本里提取关键数据再按模板的判定标准CPU平均小于50%、内存小于80%、温度小于80℃逐项检查最后用pandas导出Excel这个思路也能扩展到Oracle巡检脚本等其他运维场景。import re def parse_metrics(raw: str, device: str): cpu re.search(rCPU Usage\s*:\s*(\d)%, raw) mem re.search(rUsed Rate\s*:\s*(\d)%, raw) temp re.findall(r(\d)\s(\d)\s(\d), raw) return { device: device, cpu: int(cpu.group(1)) if cpu else None, memory: int(mem.group(1)) if mem else None, temperature: int(temp[0][0]) if temp else None, } def judge(metrics): problems [] if metrics[cpu] and metrics[cpu] 50: problems.append(CPU超过50%) if metrics[memory] and metrics[memory] 80: problems.append(内存超过80%) if metrics[temperature] and metrics[temperature] 80: problems.append(温度超过80℃) return problemsparse_metrics里的正则分别匹配display cpu输出的CPU Usage : 2%、display memory输出的Used Rate: 22%、display environment输出的温度三列当前值/低限/高限。judge函数按模板阈值判定并返回问题列表没有返回说明该项正常。解析结果可以拼成DataFrame后用to_excel导出这样一台设备的巡检结论直接落到Excel和模板里的巡检单对应起来。我现在的习惯是每接手一批新设备先跑一遍采集脚本把基线存下来后面每次巡检都拿新输出和基线做对比有差异先查原因再动配置。这套模板配上脚本基本能在半小时内把一台设备的健康状态摸清楚比逐条敲命令再手填巡检单高效得多。希望帮到你。本文还有配套的精品资源点击获取 H3C网络设备巡检模板：16项检查命令与自动化脚本指南
简介面向网络运维人员与H3C设备管理者这份专业巡检模板适用于路由器、交换机、防火墙等各类H3C网络设备用于将日常分散的检查命令整合为标准化巡检流程。模板覆盖从设备基本信息、软件版本与运行时间、CPU/内存利用率、模块与电源风扇状态、端口配置、链路带宽、VLAN与以太通道、路由交换协议、STP、NAT连接数到防火墙策略及机房环境等十余个巡检维度每条检查项均附有具体查询命令、期待结果、备注说明和结果判定栏做到直观可执行。包内共1个doc文档文档约38KB排版紧凑既可直接打印作为纸质巡检单也可编辑后留存电子记录。该资源已有108人学习使用适合网络运维新手快速建立巡检思路也可作为团队统一巡检模板的参考基线帮助提前发现潜在风险并支撑网络优化与长期规划。1. H3C网络设备巡检报告模板16项检查与命令清单一次讲清深夜两点值班同事打来电话核心交换机温度65度要不要去机房如果手边有一份H3C网络设备巡检报告模板这个问题几秒钟就有答案——模板里的C-A-06项写得很清楚设备内部各部分工作温度小于最高限制80摄氏度。这份模板最大的价值就是把散落在各设备手册里的巡检命令、判断阈值、记录方式收敛成一份可以照着执行、照着填写的检查单。H3C网络设备巡检报告模板包含16个编号检查项每项都给出了检查命令、期待结果、备注和检查范例后面还附了网络拓扑、链路、设备信息的巡检单适合刚接手网络运维、需要建立巡检基线的新人也适合老工程师查漏补缺完善自己的巡检清单。2. 模板框架拆解检查指导的分组逻辑与巡检单信息设计2.1 模板的三段式结构先知道查什么再知道怎么查最后记录这套巡检模板打开看其实分三块。第一块是网络巡检项目总清单把网络拓扑、链路类型、设备信息、软件版本、连通性、协议状态、防火墙、机房环境等大类列出来相当于告诉巡检的人这次要看哪些面第二块是检查指导对每一个检查项做了编号并给出命令、期待结果、备注与检查范例相当于一份标准的操作手册第三块是多张巡检报告单包括网络拓扑巡检报告单、网络链路状况巡检单、网络设备巡检单防火墙、路由器用来落地记录。这三块分别对应完整闭环先知道查什么再知道怎么查最后把结果写下来。我实际排障时也按这个节奏走——接到故障先翻对应检查项目C-A系列的输出能快速定位硬件类问题C-B系列则用来判断协议和业务链路的状态。模板里每个检查项都留有检查范例这个设计值得单独说一句新手照着范例比对当前输出能快速看出差异不用对着满屏数字发呆。2.2 C-A与C-B为什么硬件健康和应用状态要分开编号模板的检查指导部分按C-A和C-B两组编号。C-A共7项C-A-01到C-A-07对应设备软件版本、持续运行时间、CPU利用率、内存利用率、模块运行状态、运行温度、系统日志全部是设备自身的健康指标C-B共9项从C-B-01到C-B-09覆盖VRRP、VLAN、链路聚合、trunk、路由、STP、接口状态、NAT、防火墙全部是网络协议与业务运行的状态。这个分组不是随便排的。设备反复重启、风扇异响、温度异常优先跑C-A业务不通、路由振荡、VLAN错乱优先跑C-B。两组检查的侧重点不同故障定位的思路也不同。实际巡检中C-A组有任何一个不达标C-B组的协议状态也基本无法稳定所以顺序上我一般先过C-A再过C-B。分组编号范围检查内容C-A 硬件健康C-A-01 ~ C-A-07软件版本、运行时间、CPU、内存、模块状态、温度、日志C-B 协议与应用C-B-01 ~ C-B-09VRRP、VLAN、链路聚合、trunk、路由、STP、接口、NAT、防火墙2.3 巡检单里的设备台账字段CPU以外的东西有时更救命巡检单里除了CPU利用率、内存利用率、日志信息这些运行指标还有一列设备基本信息品牌、序列号、设备型号、管理地址、软件版本、放置位置、机架设备、端口数量、端口类别。这些字段看起来是台账信息但排障时真的救命。设备报修要序列号走商务流程要问保修状态现场割接前得知道设备在哪个机柜、有没有备件。模板里放置位置和设备作用描述是分栏填写的这两栏把一台设备在网络里的身位交代清楚了。端口类别明确区分了□光□电这个细节也有实际意义——光口要备SFP模块电口要备电口模块备件类型完全不同。还有一处容易被忽略的字段标签完善程度。标签不全的跳线在割接时就是翻车现场一张巡检单把标签情况也纳入记录等于逼着巡检人把物理链路状态也过一遍。模板末尾的网络链路状况巡检单里专线类型、带宽、链路联通性状态都有对应格子这种记录习惯对后续链路扩容、故障通报都很实用。提示模板里一直写IOS版本信息IOS备份情况但H3C设备实际运行的是VRPVersatile Routing Platform系统命令是display version。理解这一点就不会拿着思科IOS的概念往H3C设备上套。模板沿用IOS是早期从思科习惯带过来的写法命令体系仍是H3C/华为VRP这套。3. 硬件健康巡检命令落地版本、CPU、内存、温度、日志怎么查3.1 版本与运行时间C-A-01、C-A-02display version要看的四块信息[H3C] display version输出里需要抓住四块信息。第一是VRP软件版本号C-A-01的判定标准是同合同也就是版本与采购合同约定的版本一致避免出现合同里谈的是新版本、现场跑的是老版本的情况第二是uptime即设备持续运行时间正常应该是从设备上线到当前日期第三是Last reboot后面的重启原因和时间第四是内存大小、闪存大小、VRP映像文件名和启动位置。模板给的范例里Quidway AR46-20 uptime is 44 weeks, 5 days这台设备连续跑了44周多属于健康的运行状态。反过来如果uptime只有几天就要立刻去看Last reboot后面的原因再结合日志定位是什么把设备搞重启了。3.2 CPU利用率C-A-03look at VIDL再看历史趋势[H3C] display cpu [H3C] display cpu historydisplay cpu默认查近60秒周期内的CPU占用率输出会列出TaskName和CPU两列模板范例里VIDL 98%表示空闲进程占了98%设备很闲。display cpu history看过去60分钟内的平均CPU占用趋势判断是否有持续的峰值。判定标准模板写得很明确CPU利用率平均值小于50%最大值小于70%。注意不要被CPU Usage那个百分比迷惑要结合进程表里VIDL的值来看100%减去VIDL才是当前实际占用率。平均值长期贴着60%、70%跑的设备需要重点排查是否跑着异常进程或者业务量本身就快接近设备上限了。3.3 内存利用率C-A-04涨上去未必会自动降回来[H3C] display memory输出就三行System Available Memory系统可用内存、System Used Memory系统已用内存、Used Rate使用率。模板判定标准是使用百分比小于80%。范例里Used Rate: 22%说明内存很富余。内存和CPU不一样CPU是瞬时指标内存是累计指标。如果Used Rate持续走高要留个心眼——是不是ARP表项、路由表项、NAT会话在膨胀这类表项型内存占用涨上去之后未必会自动降回来往往要等表项老化或者重启设备才能释放。3.4 模块状态与温度C-A-05、C-A-06电源和风扇是不是Normal[H3C] display device [H3C] display environmentdisplay device输出各槽位模块的在线状态和Status模板范例里Slot 0的RPU是NormalSlot 6/7的PWR电源也是NormalSlot 8的FAN风扇Normal。所有模块都应显示Normal电源冗余双PWR和风扇状态是重点这两处出问题往往不会立刻断网但会埋下隐患。display environment输出各温度采集点的当前温度、低限和高限。模板里HighLimit是80摄氏度实际巡检中温度逼近上限前就要排查机房空调是不是失效了、设备进风口是不是被遮挡、风扇转速是不是下降了。温度问题拖到告警再处理往往已经对设备硬件造成了不可逆损伤。3.5 日志检查C-A-07先对时间再看logbuffer[H3C] display clock [H3C] display logbufferdisplay clock先看设备时间和实际时间差。模板备注说偏差超过10分钟就要校准时间不对的日志在排障时就是干扰项。display logbuffer输出日志缓冲区的配置和内容重点看Dropped messages、Overwritten messages和反复出现的告警。偶尔出现一条告警可以忽略连续刷同一条告警就要查了。4. 协议与业务状态巡检VRRP、VLAN、路由、STP、NAT的检查要点4.1 VRRP热备C-B-01Master/Backup状态和优先级都要核对[H3C] display vrrp [H3C] display vrrp statisticsdisplay vrrp输出里关键字段是Virtual Router的state当前是Master还是Backup、Config Priority配置优先级、Run Priority运行优先级、Preempt抢占是否开启、Auth Type认证类型。判定标准是主备状态与设计相符。模板范例里state是MasterConfig Priority 120这种配置一般对应主设备备设备的优先级应该更低且Preempt开启时主备切换才能自动回切。display vrrp statistics看切换次数切换次数异常增加说明主备在频繁抖动常见原因是对端VRRP配置不一致或者上行链路不稳。注意Auth Type如果配置了认证两端必须一致否则VRRP报文会被丢弃主备状态直接混乱。4.2 VLAN与trunkC-B-02、C-B-04先看VLAN数量再查trunk允许列表[H3C] display vlan all [H3C] display port trunkdisplay vlan all最前面一行会列出当前存在的VLAN ID比如模板范例里1(default), 100, 107-112, 114, 116, 118, 4000, 4094先和设计文档比对数量和ID是否一致再看每个VLAN里包含的端口是否与预期相符。常见问题是VLAN数量比设计多——多半是有人临时建了VLAN没删或者配置了VLAN但没加端口残留配置会干扰后面排障。display port trunk看各接口的PVID和VLAN passing。模板备注里有一句很值得记VLAN passing应该按照实际需求尽可能减少通过的VLAN。默认放通全部VLAN是很多现场的习惯但VLAN越多广播域越大环路风险也越高trunk上只放业务需要的VLAN才对。4.3 链路聚合C-B-03Select Ports和Unselect Ports的比值是关键[H3C] display link-aggregation summary输出里几个字段值得对照AL ID聚合组ID、TypeM表示手工聚合、Select Ports被选中的成员端口数、Unselect Ports未被选中的成员端口数、Share TypeShar表示负荷分担、Master Port主端口。模板范例里Select Ports为1、Unselect Ports为0说明这个聚合组唯一成员端口工作正常。如果Unselect Ports大于0说明有成员端口聚合失败常见原因有两端聚合模式不匹配一侧手工一侧静态、成员端口物理状态down、端口速率不一致。还有个容易被忽略的场景聚合口上方接了流量很大的业务成员端口满载后出现丢包这时要确认聚合组内所有成员都被Select避免聚合口满了但部分链路空转。4.4 路由与STPC-B-05、C-B-06默认路由、直连路由、根桥优先级一起看[H3C] display ip route [H3C] display stp briefdisplay ip route检查路由表重点看默认路由、直连路由、动态路由三条线。模板备注说得很实在对于企业一般都是交换网一条默认路由指出只是注意VLAN信息与直连路由是否相符。如果出现路由表里有的网段实际VLAN不存在或者VLAN存在但路由缺失基本就是配置不同步的结果。display stp和display stp brief检查生成树状态。模板备注里有一句建议不要全部采用默认优先级尤其是根网桥的优先级一定要低。全网优先级都是默认32768时根桥由MAC地址最小者决定一旦新设备接入或旧设备下线根桥可能漂移STP会重新计算收敛网络在收敛窗口内会出现广播风暴和短暂中断。核心设备stp priority建议调到4096或更低接入层保持默认即可。4.5 接口状态与NATC-B-07、C-B-08错误包占比要小于万分之一[H3C] display interface [H3C] display nat statistics [H3C] display nat alldisplay interface可加具体端口查看单接口状态重点关注Input errors、collisions、crc、late collisions这几类计数。模板备注给出了量化标准端口冲突、错误等信息小于1/10000。错误包占比超标的常见原因是双工模式不匹配、线缆老化、光模块衰减查的时候先看端口双工和速率协商结果再换线缆或光模块验证。display nat statistics看当前NAT连接数和转换情况display nat all查看NAT地址池、老化时间和Server配置。模板范例里TCP老化时间是86400秒这个数值在生产环境偏大P2P、视频类业务并发连接多时老化时间太长会导致NAT表项快速占满。模板给的建议很直接在没有流量控制设备的情况下在NAT设备上做连接数限制每个用户限制100个连接防止连接数过多超出设备承载能力。4.6 防火墙检查C-B-09ACL里出现permit ip any any要警惕防火墙一般通过WEB界面登录查看重点检查四块策略应用是否符合设计、failover状态如果是双机、xlate状态、DMZ区是否正常。模板备注里对ACL的建议值得单独记一笔禁止使用permit ip any any这类允许所有流量的语句尤其是互联网边界。H3C/华为防火墙基于安全域做策略默认拒绝跨域流量配置策略时应该是显式放行业务流量而不是图省事全放通。5. 巡检避坑uptime误导、CPU误解、日志漂移等5个翻车点5.1 uptime短不等于设备质量差要看Last reboot做了什么现象display version显示uptime只有几天但设备采购运行时间已经一年多了。原因设备曾经重启过可能是机房断电、温度过高保护触发、内存泄漏导致进程重启也可能是人为误操作。解决重点看Last reboot行模板范例里System returned to ROM By Power-on表示上电重启属于断电后恢复的常见情况如果显示其它原因要结合display logbuffer找重启前后的日志。模板C-A-02的备注写得很明确设备uptime时间比较短一定要利用这个命令查看最近一次重启时间。5.2 CPU利用率看错对象CPU Usage那行数字不是全部现象display cpu输出CPU Usage: 2%看起来很低但设备处理明显变慢网页打不开、ping延迟大。原因全局利用率低只代表平均负载低可能存在单进程异常比如SNMP频繁轮询、FTP传输、攻击流量把某个进程占满。解决看TaskName列VIDL是空闲进程100%减去VIDL的占比才是实际CPU占用率再用display cpu history看60分钟趋势如果平均值超过50%就要定位是哪个进程在消耗。5.3 日志时间漂移导致排障时间线对不上现象日志里告警时间与业务故障的实际时间对不上排查时无法对应事件先后顺序。原因设备没有配置NTP或者NTP服务器不可达设备重启后时间回退到出厂值。解决先display clock看当前时间偏差超过10分钟就校准配置NTP同步H3C设备启用ntp-service功能后指向内网NTP服务器。纯内网没有NTP服务器时至少每周手动校时一次否则日志分析的参考价值会大打折扣。5.4 STP根桥优先级全默认拓扑一变更就收敛现象网络里新接入一台交换机后业务出现短暂中断持续几十秒又恢复。原因所有交换机优先级都是默认32768新设备的MAC地址更小根桥漂移到了新设备上STP重新计算收敛期间端口经历了Listening和Learning状态。解决核心交换机把stp priority调到4096或更低明确根桥位置接入层保持默认优先级。改完后用display stp确认根桥MAC是否与预期设备一致。5.5 NAT连接数飙升终端不多但表项爆了现象display nat statistics显示连接数持续逼近设备上限新业务无法建立连接。原因P2P下载、视频会议、网络直播这类应用会产生大量并发连接NAT表项被占满后新的连接无法转换。解决在NAT设备上做连接数限制模板建议每个用户限制100个连接同时结合业务情况调整老化时间TCP老化时间86400秒对多数场景都偏长。改完后观察连接数曲线确认限制策略对正常业务没有误伤。6. 把巡检模板变成自动化脚本Netmiko采集与阈值判定6.1 用Netmiko批量采集H3C巡检命令模板里的16个检查项逐条手动敲一遍一台设备至少要十几分钟设备一多就很浪费时间。常见做法是用Netmiko把命令批量发到设备上H3C的Comware系统对应device_type是hp_comware。登录方式、enable密码、超时时间都写在连接字典里改成自己设备的IP和账号就能跑。from netmiko import ConnectHandler h3c_device { device_type: hp_comware, # H3C Comware 系列设备 host: 192.168.1.254, username: admin, password: Pssw0rd, timeout: 30, } commands [ display version, display cpu, display memory, display environment, ] with ConnectHandler(**h3c_device) as conn: for cmd in commands: output conn.send_command(cmd) print(f {cmd} ) print(output)这段代码的逻辑是先用ConnectHandler建立SSH连接循环发送命令列表里的巡检命令并打印输出。device_type参数决定Netmiko用哪种CLI交互方式hp_comware适用于H3C的Comware V5/V7系列timeout参数设置连接超时时间设备响应慢时防止脚本卡死。采集到的原始输出可以继续喂给解析函数。6.2 解析关键指标生成Excel报告采集只是第一步真正有复用价值的是把输出里的CPU、内存、温度解析出来和模板里的阈值比对自动标记异常项。用正则从输出文本里提取关键数据再按模板的判定标准CPU平均小于50%、内存小于80%、温度小于80℃逐项检查最后用pandas导出Excel这个思路也能扩展到Oracle巡检脚本等其他运维场景。import re def parse_metrics(raw: str, device: str): cpu re.search(rCPU Usage\s*:\s*(\d)%, raw) mem re.search(rUsed Rate\s*:\s*(\d)%, raw) temp re.findall(r(\d)\s(\d)\s(\d), raw) return { device: device, cpu: int(cpu.group(1)) if cpu else None, memory: int(mem.group(1)) if mem else None, temperature: int(temp[0][0]) if temp else None, } def judge(metrics): problems [] if metrics[cpu] and metrics[cpu] 50: problems.append(CPU超过50%) if metrics[memory] and metrics[memory] 80: problems.append(内存超过80%) if metrics[temperature] and metrics[temperature] 80: problems.append(温度超过80℃) return problemsparse_metrics里的正则分别匹配display cpu输出的CPU Usage : 2%、display memory输出的Used Rate: 22%、display environment输出的温度三列当前值/低限/高限。judge函数按模板阈值判定并返回问题列表没有返回说明该项正常。解析结果可以拼成DataFrame后用to_excel导出这样一台设备的巡检结论直接落到Excel和模板里的巡检单对应起来。我现在的习惯是每接手一批新设备先跑一遍采集脚本把基线存下来后面每次巡检都拿新输出和基线做对比有差异先查原因再动配置。这套模板配上脚本基本能在半小时内把一台设备的健康状态摸清楚比逐条敲命令再手填巡检单高效得多。希望帮到你。本文还有配套的精品资源点击获取