简介针对H3C GB0-372网络技术认证考试整理的注释版PDF复习资料覆盖STP生成树、VRRP虚拟路由冗余、PIM组播及IGMP Snooping等核心考点适合备考H3C网络技术认证或希望巩固交换与组播技术的网络技术人员。资料以题目解析形式呈现包括STP中配置BPDU与TCN BPDU的发送接收规则、VRRP备份组Master/Backup选举与状态迁移、PIM-DM中SPT树的扩散剪枝过程以及核心层/汇聚层/接入层功能划分等常见考点。资源包内文件总数为1个类型为PDF大小约9.1MB便于下载后离线阅读和按题号检索。目前已有97人学习对认证冲刺和实际网络排错均有参考价值仔细研读后可系统梳理STP拓扑收敛、VRRP故障切换、组播转发控制等关键配置思路并借助注释理解选项背后的原理避免死记硬背。1. GB0-372 备考到底考什么从 H3C 认证体系里抓住这门“路由交换硬骨头”的定位接触过 H3C 网络工程师认证的人应该都听过 GB0-372 这门课——它是 H3CSE Routing Switching 认证的核心笔试科目考的是路由交换的高级部分也就是从 HCIA 这种入门级往 HCIP 走的那道必经关卡。说白了GB0-372 不是背几个命令就能过的那种科目它对 OSPF、BGP、组播、QoS 的理解深度要求相当高尤其是协议原理和排错思路这两块几乎占了一半以上的分值。这份注释版的 PDF 我在实际使用中感觉最值钱的地方就是它在关键难点上添加了大量中文批注把命令输出的含义、Debug 信息的解读逻辑都讲透了——这对于中文考生来说能省掉大量自己翻文档、查英文手册的时间。适合谁用正在准备 H3CSE 笔试的人或者已经在做网络运维、想补一遍 H3C 协议实现细节的工程师。如果你只是刚入门我建议先把基础命令刷熟再碰这份资料否则很多高级特性的注释你会看得比较吃力。2. 先啃路由协议OSPF 邻居状态机与 LSA 类型的注释解析2.1 OSPF 状态机的实际排错思路GB0-372 在 OSPF 这块考得极深不只是让你背状态机的名字而是给你一段 display ospf peer 输出要你判断问题出在哪一步。注释版 PDF 里在这个部分做了大量状态迁移的批注特别是从 Init 到 2-Way 再到 Full 的每个阶段对应什么网络条件。备战时一定要把每个状态的关键事件记牢。Down 表示没有收到 HelloInit 表示收到了对方 Hello 但对方没收到我的2-Way 是双向通信建立但还没开始同步数据库。常见考场陷阱是把 Attempt 和 Init 搞混注意 Attempt 只在 NBMA 网络里出现是主动发送 Hello 但没收到回复的状态。ExStart 和 Exchange 阶段考的是 DR/BDR 选举完之后的数据库描述报文交互这里有个容易丢分的点DD 报文里的序列号和 I/M/MS 位的作用注释里专门有一张表列了主从关系协商过程。# 常用的 OSPF 排错命令组合 display ospf peer # 查看邻居状态确认卡在哪个状态机阶段 display ospf lsdb # 检查链路状态数据库是否完整 display ospf error # 查看 OSPF 报文错误统计定位协议层面的问题 debugging ospf event # 打开事件调试观察 Hello 报文收发和状态迁移三条 display 命令配合一条 debugging 命令是实际工程里排查 OSPF 邻居问题的标准操作。display ospf peer 能快速判断问题层级——如果状态一直停在 Init大概率是 Hello 参数不匹配或区域 ID 不一致如果停在 ExStart问题多出在 MTU 不匹配上。error 命令能看到校验和错误、区域不匹配错误的具体计数这个输出里的值不是每次都为 0若有非零值就要对应报文类型去分析。debugging ospf event 这种调试命令在现网慎用有 CPU 过载的风险建议在测试环境或低峰期开。实战里我遇到过最坑的情况是 MTU 不一致导致状态卡在 ExStart 循环两台设备 MTU 相差超过 20 字节就会出现频繁重传这种问题光看配置很难定位必须抓包才能看出来。2.2 LSA 类型与区域设计的对应关系GB0-372 对 LSA 类型的考查不亚于状态机尤其是 Type-3 和 Type-4 的区别很多考生在这个点上栽过跟头。Type-3 是区域间路由的汇总 LSA由 ABR 生成描述的是某个区域内的网段在另一个区域里的表现形式Type-4 是 ASBR 汇总 LSA它的职责是告诉其他区域“ASBR 在哪个位置”。注释版用了一张对比表把这七种常用的 LSA 和对应的生成设备、传播范围理得很清楚。OSPF 特殊区域也是高频考点Stub 区域里不允许 Type-5 进入Totally Stub 连 Type-3 也不让进但两者都允许 Type-3 默认路由NSSA 区域引入了 Type-7 LSA由 ASBR 在区域内生成到了普通区域再转成 Type-5。注释里反复强调了一个容易错的点Type-7 转换成 Type-5 是 ABR 做的不是 ASBR 自己做的这个转换动作发生在 ABR 上。# 配置 OSPF 特殊区域的基本步骤 interface GigabitEthernet0/1 ip address 192.168.1.1 255.255.255.0 # ospf 1 router-id 192.168.1.1 area 0.0.0.1 network 192.168.1.0 0.0.0.255 stub # 把 area 1 配置为 Stub 区域 default-route-advertise always # 向 Stub 区域下发默认路由配置 Stub 区域时要注意一个关键前提区域内所有路由器都必须启用 stub 命令如果有一台没配邻居关系会建立不起来因为 Hello 报文里的 E 位不一致会导致协商失败。default-route-advertise always 是 ABR 向 Stub 区域通告默认路由的关键参数加与不加的差别在考场里经常拿来出题。最后的 always 关键字表示无论本地区域有没有路由可达外部都强行下发默认路由实际工程里这个参数用来兜底防止 Stub 区域内设备访问外部网络时因缺少默认路由而丢包。3. BGP 机制与属性操控把选路原则变成排查工具3.1 从邻居状态到路由通告的条件BGP 在 GB0-372 里占的比重很大考的不只是概念而是让你根据 show bgp neighbor 判断连接问题。BGP 邻居状态有六种Idle、Connect、Active、OpenSent、OpenConfirm、Established考试里最常见的是给你看状态卡在 Active要你说出原因。Active 状态表示 TCP 连接没有建立成功常见原因包括对端地址写错、对端没有开 BGP、TCP 端口 179 被 ACL 拦住。注释版在这个地方专门谈到了一个工程里很容易翻车的细节——BGP 的 Router ID 冲突。如果两台设备的 Router ID 配成一样的邻居状态会在 OpenConfirm 附近反复震荡因为 Open 报文里携带的 Router ID 被对端发现重复后会直接断开。用 display bgp peer 看的话状态会在 Established 和 Connect 之间来回跳不抓包很难定位。路由通告的条件也容易被忽略只有通过 network 命令精确匹配或 import 引入的路由并且下一跳可达才会被通告给邻居。而 iBGP 的水平分割规则——从 iBGP 邻居学到的路由不会通告给其他 iBGP 邻居——是考试里的经典考点破解方法就是配路由反射器或全互联。# BGP 基本配置与路由发布 bgp 65001 router-id 1.1.1.1 peer 2.2.2.2 as-number 65002 # ipv4-family unicast peer 2.2.2.2 enable network 10.10.0.0 255.255.255.0 # 精确发布路由 import-route static # 引入静态路由这段配置里有两个容易操作失误的地方。network 命令在 BGP 里的语义跟 OSPF 不一样它不是“宣告接口网段”而是“在本地路由表里精确匹配这条路由并发布”配套的掩码必须跟路由表里的完全一致写错了不会有报错只是这条路由不会被通告。另一个是 import-route static 会把所有静态路由都引进来如果只想引某几条建议配合 route-policy 做过滤。工程里有种常见做法是用 ip-prefix 加 route-policy 精确控制引入的范围避免把一些内网管理网段意外广播到 BGP 对端。3.2 选路原则的优先级与属性修改BGP 选路原则在 GB0-372 里属于必考内容完整背下来有十几条但实际高频考到的是前五条Preferred-Value、Local-Preference、AS-Path、Origin、MED。注释版专门提醒了一个容易弄混的点Preferred-Value 是本设备本地生效的不会传给对端而 Local-Preference 会在 IBGP 邻居之间传播。考试经常会出这种题——两台路由器分别从两个 AS 收到同一条路由让你根据修改的属性判断最终走哪条。解题关键就是按选路顺序逐条比较前一条分不出来再看下一条。实际工程里最常用的是 Local-Preference 和 MED前者用于控制离开本 AS 的流量即“出口选路”值越大越优先后者用于控制进入本 AS 的流量即“入口选路”值越小越优先。# 用 route-policy 修改 BGP 属性并应用到对等体 route-policy LP_PERMIT permit node 10 if-match ip-prefix PREFIX_10 apply local-preference 200 # bgp 65001 peer 2.2.2.2 route-policy LP_PERMIT importroute-policy 里 apply local-preference 200 表示把从对端收到的路由的本地优先级改成 200默认值是 100改高之后本 AS 内的路由器会优先选择这条路径。import 方向控制入方向的路由属性export 方向控制出方向的路由属性这个方向性很多新手会搞反。工程里最常见的场景是运营商给客户两条链路客户想引导去往特定目的地的流量走主链路就会在主链路的入方向把 Local-Preference 调高。需要注意 route-policy 里的 if-match 没有命中时流量会走 permit node 后面的隐性 deny所以策略写完后用 display route-policy 确认一下匹配结果再用 display bgp routing-table 看属性是否生效。3.3 路由反射器与联盟的取舍iBGP 全互联在路由器数量多的时候扩展性很差每加一台设备就要跟所有现有 iBGP 对等体建立连接连接数是 N×(N-1)/2。GB0-372 在这块考的是路由反射器和联盟的选型。路由反射器是在一个 AS 内指定一台设备作为反射器其他设备只跟它建立 iBGP 连接反射器再把学到的路由反射给其他客户端。里面的核心规则是三条从非客户端学到的路由反射给所有客户端从客户端学到的路由反射给所有非客户端和客户端从非客户端学到的路由不会反射给其他非客户端。这三条规则注释版里用图配文字解释了考试时经常让你判断某条路由能否被反射。联盟的机制是把一个 AS 划分成若干子 AS子 AS 内部跑 iBGP子 AS 之间跑联盟 EBGP对外整体表现为一个 AS。注释里给的建议很实用反射器配置简单适合大多数场景联盟适合需要精细控制路由策略的场合因为联盟边界可以应用路由策略而反射器本身不做策略控制。工程上反正我见过的 H3C 网络基本都是反射器方案联盟比较少用。4. 组播协议栈IGMP 与 PIM-SM 的机制串联4.1 IGMP 工作机制与版本差异组播在 GB0-372 里也是必考模块但考核重点集中在 IGMP v1/v2/v3 的差异和 PIM-SM 的机制上。IGMPv1 只有查询和报告两种报文没有离开报文主机离开组播组时需要等待超时效率很低IGMPv2 增加了离开报文和特定组查询极大地缩短了离开延迟IGMPv3 引入了源过滤主机可以指定只接收来自某个源的流量这是 SSM 模型的基础。注释版对这三者的表格对比做得很好考试里常考的点是 IGMPv2 的查询器选举机制——网段里有多台路由器时IGMP 查询器的选举看 IP 地址地址最小的获胜。如果启用了 PIM-SM则 PIM 的 DR 会成为 IGMP 查询器这个联动关系很多人会忽略。# IGMP 配置示例 interface GigabitEthernet0/1 igmp enable # 接口下使能 IGMP igmp version 3 # 指定 IGMP 版本 igmp static-group 239.1.1.1 # 配置静态组播组igmp static-group 常用于测试环境或特定业务场景它让设备主动加入该组不必等待主机的 IGMP 报告报文。这个命令在现网里要慎用因为静态加入会让交换机始终向该组转发流量不管实际有没有接收者容易造成组播流量泛洪。版本设置上IGMPv3 向下兼容 v2 和 v1但默认版本改高了之后老版本主机用的设备可能无法正常上报实际部署时往往需要根据主机端支持的版本统一规划。注释版特别强调了 IGMP 报文是发送给组播组地址本身的目的 IP 就是组地址目的 MAC 是组播 MAC 地址 01-00-5E-xx-xx-xx抓包时用这个特征确认报文是否正常到达二层网络。4.2 PIM-SM 的 RP 机制与注册过程PIM-SM 的核心思想是“按需建树”没有接收者的时候不转发组播流量。这里面的角色有三个DR、RP、BSR考试经常把这三者的职责混在一起出题。组播源侧的 DR 负责把源发出的组播数据封装成注册报文发送给 RP接收者侧的 DR 负责代表接收者向 RP 发送加入报文。RP 是核心所有的组播流量在初期都要经过 RP 转发。BSR 负责在全网范围内选举 RP通过 BSR 报文通告 RP 信息。注册过程是高频考点源 DR 收到组播数据后将其封装在 Register 报文里单播发送给 RPRP 解封装后沿共享树向接收者转发同时向源 DR 发送 Register-Stop 消息源 DR 停止注册报文的发送。注释版用大段的文字解释了为什么 RP 会发送 Register-Stop——因为后续数据已经通过 SPF 计算出的最短路径树直接到达 RP不需要再走注册报文封装了。切换最短路径树的时机也是考点默认配置下接收者侧 DR 在收到第一个组播数据包后就会发起 SPT 切换。# PIM-SM 与静态 RP 配置 multicast routing-enable # 开启组播路由功能 # interface GigabitEthernet0/1 pim sm # 接口上使能 PIM-SM # pim static-rp 3.3.3.3 # 配置静态 RP第 1 行的 multicast routing-enable 是全局开关不打开的话后面所有组播配置都不生效这是一个典型的低级错误考试却经常拿它出题。pim sm 要在所有参与组播转发的三层接口上都配漏掉一个接口就可能导致组播流中断。static-rp 是所有路由器上都要配置的RP 设备本身也要配默认情况下如果某台路由器上没有配置 static-rp 且没有收到 BSR 通告它就不会知道 RP 是谁组播源 DR 发出的注册报文就会因为没有 RP 而无法处理。工程上选择静态 RP 还是 BSR取决于网络规模。小网络用静态 RP 简单可预期大网络用 BSR 自动选举可以减少人工配置但要保证 BSR 消息能穿透所有区域。5. QoS 与流量调度实践从分类标记到拥塞管理5.1 流量分类与标记的标准做法QoS 在 GB0-372 里属于理论偏多但实操容易失分的部分主要原因是它涉及很多细节参数。流量分类是整个 QoS 的入口分类的依据可以是报文的 DSCP、IP 优先级、VLAN 优先级或者五元组。在 H3C 设备上分类通常用 classifer 定义匹配规则再用 behavior 定义动作最后用 policy 把两者关联起来并应用到接口。匹配的顺序很关键H3C 的 QoS 策略默认按配置顺序逐条匹配匹配了就执行对应动作不再继续向下看后面的规则。所以实际配置时要把精确匹配的规则放在前面宽泛匹配的规则放后面避免流量被错误分类。# QoS 分类标记配置示例 traffic classifier C2 operator and if-match dscp af21 # traffic behavior B2 remark dscp ef # traffic policy P1 classifier C2 behavior B2 # interface GigabitEthernet0/1 traffic-policy P1 inboundif-match dscp af21 匹配 DSCP 值为 AF21 即中优先级流量remark dscp ef 将匹配到的流量标记为 EF。这里注意一个很容易犯的错——af21 和 ef 这些缩写背后都有具体数值如果在不同厂商设备之间对接务必确认是写别名还是写数值H3C 是支持别名的但用数值可读性更差但兼容性更好。traffic-policy 应用在 inbound 方向时报文进入设备后立即匹配分类规则文档里最常见的做法就是在入口处统一做标记中间设备只认标记后的值这样整个 DiffServ 域内语义一致。实际运维中我通常把这段配置写成模板通过批量下发工具推送到全网接入交换机省得一台台敲。5.2 队列调度与拥塞管理的参数选择H3C 的拥塞管理支持多种队列机制SP、WRR、WFQ以及混合模式 SPWRR。SP 严格优先级调度的特点是高优先级队列里的报文不处理完低优先级队列就没有机会优点是低延迟业务有保障缺点是可能“饿死”低优先级。WRR 按权重循环调度每个队列都有机会被服务但无法控制延迟因为高优先级队列在 WRR 下并不能抢占服务。WFQ 是加权公平队列能根据报文长度和权重计算调度次序。注释版强调了一个在实际配置中容易误解的点WRR 和 WFQ 都不是真正的带宽保证它们只是在拥塞时的调度优先权真正要保证带宽需要配置 GTS 或 LR。# 接口下的队列调度配置 interface GigabitEthernet0/1 qos wrr 1 group 1 queue-id 1 weight 10 qos wrr 1 group 1 queue-id 2 weight 20 qos wrr 1 group 2 queue-id 4 weight 30 qos wrr 1 group 1 priority 1这段配置把队列 1 和队列 2 划分到一个调度组权重分别是 10 和 20队列 4 单独分到另一个组权重为 30。groups 之间的调度关系默认是 SP 严格优先先服务 group 1 再服务 group 2。这种分组设计很常见——低延迟业务放一个组普通业务放另一个组既不饿死低优先级队列又保证高优先级组的延迟可控。队列数和权重的换算关系取决于接口带宽实际配置时建议先算清楚每条队列能分到的带宽比例否则可能出现带宽分配不符合预期的现象。反正我配置队列权重时一定会先画一张带宽分配表写明每个队列的业务类型、权重值、预期带宽配完之后再用速率测试工具验证。5.3 流量整形与监管的边界流量监管和整形是 QoS 里容易搞混的一对概念。监管用令牌桶机制超出的流量直接丢弃适用于入方向控制或对用户限速整形同样用令牌桶但超出的流量会缓存到队列里在下一拍再发出去适用于出方向平滑突发流量。GB0-372 对两者的考查集中在命令参数和效果差异上。H3C 设备上监管通常用 car 命令整形用 qos gts 命令两者都能设置承诺速率 CIR 和突发尺寸 CBS。实际工程里最典型的场景是运营商侧对接——用户侧路由器往运营商设备发数据运营商会做流量监管因此用户侧设备要做整形也就是在物理接口上限制发送速率略低于运营商承诺值减少因突发导致的丢包。# 接口上的流量监管配置 interface GigabitEthernet0/1 qos car inbound car-name CAR_IN dscp ef cir 10240 cbs 20480 ebs 10240 green pass yellow pass red discardcar 命令里 cir 10240 的单位是 kbps这里配置的是 10Mbps 的承诺速率cbs 20480 是承诺突发尺寸单位是字节表示允许在瞬间突发到 20KB。red discard 表示超过突发尺寸的报文直接丢弃yellow pass 表示黄色报文放行但不做标记这个动作组合要按业务需求来定。实际生产里非常不建议先确定参数就上线通常的做法是先配一个较大 burst观察一段时间内的丢包与延迟数据根据实际流量模型逐步调整到最优值。我在一次项目里遇到监管导致视频会议花屏的问题就是 cbs 配置过小——视频流的瞬时突发远超令牌桶容量大量报文被丢弃把 cbs 调大 4 倍后问题消失。6. 避坑指南与常见问题排查六个典型故障场景的记录6.1 OSPF 邻居一直卡在 ExStart现象是 display ospf peer 显示邻居状态为 ExStart长时间不进入 Exchange。原因是两台设备互联接口的 MTU 大小不一致。OSPF 在 ExStart 阶段会协商 DD 报文的大小如果接口 MTU 不一致双方无法就 DD 报文大小达成协议状态就一直卡住。解决方法是把两端接口的 MTU 配置成一致或者在接口下配置 ospf mtu-enable 关闭 MTU 协商检查。我踩过这个坑时是在一个跨越二层隧道的场景里隧道 MTU 比物理接口小 20 字节排查了很久才发现是 MTU 的问题。从那以后我每次配置 OSPF 互联口都会顺手查一下两端 MTU就再没在这个问题上翻过车。6.2 BGP 邻居反复振荡现象是 display bgp peer 显示邻居状态在 Established 和 Connect 之间反复跳并伴随 TCP 连接重置日志。原因是 Router ID 冲突本端和对端的 Router ID 重复时双方建立 TCP 连接后交换 Open 消息发现 Router ID 相同会互相断开然后再重试。另一种原因是 Update 报文里有错误路由导致 NLRI 被拒触发 Notification 消息断开邻居。解决方法是检查两边 Router ID还要检查 update-delay 和 route-policy 是否导致某些路由被反复撤销和通告。工程上我建议给每台设备规划独立的 LoopBack 接口地址作为 Router ID用脚本检查全网唯一性。6.3 组播业务不通但单播正常现象是视频点播服务无法播放但在设备上用 ping 测试组播源和接收者之间的单播是通的。原因是中间链路上没有使能组播路由或者接收者网段的 IGMP 没有打开。排错顺序要先确认接收者是否发出了 IGMP 报告再逐跳查看组播路由表里有没有对应条目最后检查路由器接口是否使能了 pim sm。值得注意的一个细节是很多交换机默认关闭未知组播泛洪如果 IGMP Snooping 开启了但路由器没有发出通用查询交换机老化掉原有的组播表项后不会主动学习新表项导致组播断流。解决方法是检查 IGMP Snooping 的查询器配置确保网络中能正常进行查询。6.4 QoS 队列配置不生效现象是接口上配置了 qos wrr 和 weights但流量行为没有变化高优先级流量依然和低优先级一起被处理。原因往往是 QoS 策略应用的接口方向写反了或者接口本身没有拥塞发生所以队列调度没有机会生效。还有一个常见原因是队列编号超出该接口支持的队列数范围H3C 有些接口只支持 4 个队列配置第 8 个队列时设备不会报错但日志里会有错误记录实际调度时不生效。解决方法是先确认接口能力和当前接口速率再用 display qos queue-statistics 看队列计数确认流量有没有进入预期队列。6.5 策略路由与 QoS 分类冲突现象是 QoS 策略匹配的流量没有按预期走有些流量被错误地执行了动作。原因是策略中的 if-match 规则与其他模块的 ACL 或策略路由规则冲突流量先被策略路由重定向走了根本没到 QoS 模块或到了但匹配到了不同的分类规则。处理方法是把策略路由和 QoS 策略的匹配规则做成同一个 ACL 或者同一套前缀列表保证语义一致。如果确实需要两套独立规则至少在规则里加注释并记录在变更单里避免后续排错时互相误导。我在现网做过一次变更就是因为策略路由里的 permit 条目顺序比 QoS 里的分类定义更宽松导致流量走了重定向路径。6.6 链路聚合下的负载不均现象是做了二层链路聚合后所有流量都打在同一条物理链路上其他成员链路利用率很低。原因是聚合负载分担的算法基于报文的源/目的 MAC 或 IP在流量特征单一的情况下哈希结果高度集中。解决方法是检查聚合口下的负载分担模式比如从 src-dst-ip 改成 src-dst-mac或者用 14 元组增强模式。H3C 在高端设备上支持更细粒度哈希实际效果取决于报文的五元组多样性。工程上不要只看聚合口的总带宽要逐条查看成员口流量用 display link-aggregation verbose 观察每口的速率。7. 验证与实战训练用模拟器搭一套完整的考试实验环境备考 GB0-372 只看注释版 PDF 是不够的必须把知识落到命令上搭一个能跑的实验环境是效率最高的路径。我一般用 HCL 模拟器建三台路由器两台交换机的拓扑把 OSPF 多区域、BGP 联盟、组播、QoS 全在上面复现一遍。拓扑设计上三台路由器组成一个三角形两两互联各自带一个模拟终端的交换机网段这样既能做 OSPF 区域间路由又能模拟 BGP 邻居关系。核心训练动作是把注释版里的每个 debug 命令都跑一遍对照注释里说的输出格式观察状态迁移和报文交互过程这是最快建立排错手感的方式。# 检查模拟器环境中的 OSPF 收敛状态 display ospf peer brief display ospf lsdb summary debugging ospf packet模拟器和真实设备最大的差距在性能和数据面转发但控制面的协议行为是完全一致的所以考试涉及的路由协议排错完全可以在模拟器里练。我备考时分阶段推进第一轮按章节过知识点在模拟器上照着配置命令敲一遍并截图记录状态输出第二轮开始做“破坏性实验”比如手动改错参数、误删路由观察故障现象再自己排查这样做的效果比光看注释要好得多。特别是在 BGP 属性操控方面模拟器上可以随意对路由做各种 apply 操作再用 display bgp routing-table 看实际选路结果比死记硬背选路原则效果强得多。有一个值得注意的细节是 HCL 模拟器的报文转发性能和真实设备差距明显并发大流量场景就不要指望模拟结果完全可信但 GB0-372 考的核心是控制面行为所以模拟器完全够用。最后分享一个自己的习惯每次做实验都会开启日志同步功能把操作命令连同输出一起存档这样白天刷题遇到不确定的知识点晚间用最小复现的方式验证一遍并把这轮验证的命令和输出参考放进自己的笔记文档里。这套方法帮我在两次考前都快速回看过关键实验结果。从 H3CSE 的角度看GB0-372 的含金量很大知识密度也很高对着注释版逐行刷题再配合模拟器的反复验证通过的把握会大很多。希望这份笔记对你备考有用。本文还有配套的精品资源点击获取