简介：这份H3CTE Lab考试拓扑图及参考配置文档由阿寇鲜生整理，面向备考华为H3CTE认证的网络工程师。文档涵盖考试常用拓扑图，并结合OSPF、IS-IS、BGP等动态路由协议，VRRP、HSRP冗余协议，以及MPLS、GRE隧道等配置示例，帮助读者理解设备连接关系、接口模式和配置原理，为实验练习和故障排查提供参考。资源为单个docx文件，压缩包大小约4.35MB，包含拓扑说明与配置命令，适合集中阅读。作者同时提醒，所附配置并非最终考试答案，实际考试需要结合现场环境进行优化，宜作为备考起点而非标准模板。目前已有236人学习下载，适合需要系统梳理H3CTE Lab配置重点、并借助拓扑图开展模拟练习的中高级网络工程师。
1. H3CTE Lab考试：为什么参考配置能成为考场的定位器
H3CTE（H3C Certified Troubleshooting Expert）的LAB考试和笔试不是一种玩法。笔试考记忆，LAB考的是你拿到一张拓扑图、看到设备报错、敲下命令之后，能不能按步骤把故障定位并恢复。很多人挂在考场的不是知识点，而是面对一组没有规律的故障现象不知道从哪下手。这份《H3CTE Lab考试拓扑图及参考配置【阿寇鲜生.撰写】.docx》解决的就是这件事：它把考试拓扑中每台设备应有的配置基线摊开，让你考前就建立「正常状态长什么样」的参照系。适合两类人：刚过H3CSE准备冲TE的考生，以及考过一次没通过、想针对故障区域做复盘的人。带着配置进考场，你不是去猜故障，而是去对照故障。
2. Lab拓扑图是排错地图：先读懂三块区域再动手
考试拓扑图是考场里唯一不会主动变化的东西。故障藏在配置里，但拓扑图告诉你的设备角色、接口编号和链路类型不会变。所以第一件事是把拓扑图当作全卷的目录来读，先看懂再动手，这条原则我每次带学生复训时都会重复一遍。
2.1 设备类型决定故障层：路由器、交换机、防火墙的判断
常见考试拓扑一般是两台路由器加一台交换机，或者三台路由器串一条链，偶尔在出口挂防火墙做安全域隔离。别看这个判断简单，设备类型直接决定了故障最可能出现在哪一层，这也是为什么拿到考卷要先花两分钟做设备角色清单。
先说路由器为主的拓扑。这类网络里故障点大概率在路由协议、静态路由和接口地址。OSPF 邻居起不来、静态路由下一跳写错、接口被 shutdown，都是考卷上的老面孔。路由器为主的网络，排错线索多集中在三层，你看到的现象通常是「某段路由缺失」或「某条链路不通」，解决手段也直接，改地址、改宣告、改启停状态。
再说交换机参与的拓扑。这类网络里你需要多关注 VLAN、Trunk 口、STP 状态和端口 PVID。二层故障在三层配置里看不出任何异常，ping 不通时你会盯着路由表发呆，实际原因是一个 access 口放错了 VLAN。我见过很多考生在交换机类故障上浪费大量时间，就是因为没有先从拓扑图上意识到「这里有三层设备，也有二层设备，故障可能在二层」。
最后是防火墙或安全网关的拓扑。域间策略和包过滤是重灾区，路由修好之后策略没放通，业务照样中断，而且这种故障最容易让你误判为「路由问题还在」。防火墙设备上还有一个额外考点：默认区域通常是 untrust，内网接口要确认是否在 trust 区域，接口区域配错导致的安全策略不生效，这类问题在参考配置里不会明说，但你对比配置时一眼就能看到差异。
我在读图时会在草稿纸上画一个简化版，只保留五项：设备名、接口号、互联地址段、业务网段、出口方向。考试时间有限，只靠脑子记住真实拓扑很容易丢信息，草稿纸比显示器可靠性高很多，而且画图这个动作本身就是在帮你建立拓扑的空间感。
2.2 链路与互联地址是故障高发区：怎么快速筛出问题口
几乎每版考试都在接口和互联地址上动过手脚，这是最好做也最容易翻车的故障类型。接口 IP 改一位，表面配置看不出毛病，路由协议却可能因此起不来。这类故障的特点是定位简单、修复更简单，但非常考验你的细心程度。
读拓扑图时，把每一对互联地址逐一抄到草稿上，然后逐台核对配置。常见动作就这么几类：互联地址网段被改大或改小，比如 /30 改成 /29，邻居学不到正确路由；接口被 shutdown 但配置还在，display 时接口配置完好、物理状态却是 administratively down；接口速率或双工模式不匹配，表现为时通时不通，看着像链路质量问题。还有一种值得单独提一下，就是对端设备接口被划到了错误的 VLAN，三层的互联地址还在，但二层转发走不通，这类故障纯靠本端单看是看不出来的。
动手前先做一件事：把全拓扑的接口状态刷一遍。
# 查看所有接口的状态和配置概要 display interface brief这条命令会输出每个接口的物理层、链路层状态和 IP。看到物理状态不是 up 的口，直接进接口查 VLAN 和 shutdown，这种故障定位最快。注意接口 brief 里显示 up 的，还要看有没有错误计数，错误计数多说明物理层有问题，而不是配置有问题。如果某个接口状态显示 up，但物理层报错数量和 CRC 错误持续增长，那基本可以断定是双工或速率协商异常，进接口固定 speed 和 duplex 就能解决。
2.3 参考配置的阅读顺序：先剥离默认参数再锁定差异
拿到参考配置文档，别从头到尾顺着读，长配置会被默认参数淹没。一份设备配置里可能有几十行默认值，真正需要你关心的业务配置往往只占三分之一。我的习惯是分成四层来读，这个顺序也适用于考场上对比参考配置与现场配置。
第一层是接口部分。把每个接口的 IP、VLAN、端口类型记下来与拓扑图对照，确认物理连接和图纸一致。接口部分是最容易出现隐蔽故障的地方，比如某个接口的 description 描述字段可能暗示了业务用途，考卷里故障注入时可能会把描述信息删除，这虽然不影响业务运行，但会干扰你对接口用途的判断。第二层是路由部分，把所有静态路由、动态路由的宣告网段、引入点圈出来，回答一个问题：全网段怎么走通。第三层是策略部分，包括 ACL、防火墙域间策略、QoS 或路由策略，这个区域在与参考配置做 diff 时最容易被漏掉，因为很多人只看路由和接口。第四层是管理杂项，管理地址、SNMP、登录密码这些，不影响业务但影响你能否登进设备。
参考配置的价值是给你一条「全对」的线。考试时每台设备的当前配置就是这条线被弄歪之后的形态，你对着一台设备对照参考配置，改动几处，大致就能判断故障范围。这不是玄学，是基础排错法。具体怎么比对，下一章我会把操作手法展开。
提示：读参考配置时多带一支不同颜色的笔，把每个接口的 IP、每个路由协议的进程号、每个 ACL 的编号用荧光笔标出，这会让你之后做 diff 时效率高很多。
3. 把参考配置当基线：三步做完配置差异定位
参考配置不能只是考前读一遍，你得把它变成排错时的基线。基线的意义是，考场里你不是凭空判断哪儿坏了，而是拿当前设备状态跟基线做差，差异就是故障源头。这一章的操作方法我称之为「三步定位法」，第一步做现场快照，第二步做配置 diff，第三步看路由表健康度。
3.1 上手先保存三张快照：配置、接口、路由表
考试开始后第一件事不是改配置，而是保存现场。我把这个动作叫照快照，三张快照分别是当前配置、接口状态、路由表。这个习惯的重要性在于：你后面改了什么东西，都需要回到最初的状态去验证，没有快照等于没有参照。
第一张快照是当前配置：
# 导出当前配置，作为与参考配置对比的依据 display current-configuration第二张快照是接口状态：
# 记录接口物理层和链路层状态，排除物理层故障 display interface brief第三张快照是路由表：
# 记录全网路由基线，作为判断可达性问题的依据 display ip routing-table第一条命令和参考配置逐段比，能找出被刻意修改的配置差异；第二条接口表直接暴露 shutdown、down、双工异常这类二三层问题；第三条路由表给出全网可达性的全局视图。三个快照集齐后，你对考试的把握度至少提升五成，因为接下来的每一步操作都有据可依。
如果考场允许复制文本，把输出直接存到本地记事本；不允许就抄关键部分到草稿纸。重点抄两块：所有接口的状态，以及路由表里业务网段的总条目数。总条目数很关键，因为路由表里条目数量和参考配置不一致时，你马上知道有路由没学到。我见过有人把三张快照全抄下来耗时二十分钟的，这没必要，快照的目的不是备份全部内容，而是抓取可用于对比的关键信息。
3.2 配置 diff 的操作手法：该比什么、不该比什么
把当前配置与参考配置做 diff，不用比默认参数，只比有业务含义的配置。实际操作时，我看三个子项：接口下的 IP 与端口模式、路由协议宣告与引入、策略和 ACL 的顺序。这三个子项覆盖了考试里九成以上的故障注入点。
# 查看单个接口下的完整配置 display current-configuration interface GigabitEthernet 0/0/1# 查看路由协议相关配置（以 OSPF 为例） display current-configuration configuration ospf对照时注意三点：地址段是否一致、宣告网段是否缺失、策略规则是否多了一条 deny。有一个常见误判我得提出来：不同型号设备接口编号可能不一样，比如同一个互联口在一台设备上是 GE0/0/1，另一台设备上是 GE0/0/4，你要按拓扑图的端口标注来对齐，不要因为接口编号不同就认为配置错了，这不是故障，别浪费时间去改。
做 diff 时还要特别注意配置块之间的顺序。比如两个 ACL 规则，参考配置是先 permit 再 deny，现场配置改成了先 deny 再 permit，这会导致后续规则永远不生效，业务就被挡掉了。这种顺序问题比内容问题更难发现，因为它不涉及具体参数差异，只涉及规则排列。我的做法是把 ACL 部分单独打印出来逐行对照，不跳着看。
3.3 路由表作为健康指标：条目多了和少了分别代表什么
路由表是最直观的风向标。与参考配置推导出的全网路由期望值相比，少了网段，方向就锁定在宣告、接口状态、策略更新过滤这三个里面。多了不该有的路由，十有八九是被注入了非法静态路由，这类故障经常考，要求你判断这个条目合不合理然后删掉。
还有一个容易被忽略的是路由优先级问题。参考配置里可能出现两条目的地址相同的路由，一条静态一条动态，预期是动态优先、静态兜底。如果现场配置把优先级调乱，转发路径就会选错，业务异常得很诡异。业务流量绕远路甚至走向黑洞，但路由表看起来并没有缺条目。
# 单独查看某个路由协议的完整表项，确认优先级和来源 display ip routing-table protocol ospf看到两条相同前缀的条目时，重点看 Preference，数值小的优先。如果和你预期不符，到对应协议视图下改回来。这一步能解决大部分「路由看起来全对但业务就是不通」的疑难杂症。如果多条路由来自同一个协议，还要检查 metric 值，H3C 设备选路时协议内会优先比较 metric，metric 一致再比较下一跳地址大小，这几个细节在参考配置里都有对应值，比对时留意一下。
4. H3CTE Lab常见问题与避坑指南：五个翻车现场记录
备考路上踩坑是难免的，关键是把坑的位置告诉后面的人。以下五条是我在教学和复盘里见过最多次的翻车现场，每一条都按现象、原因、解决来展开，想看哪条直接跳。
4.1 现象：配置与参考一致，业务仍然不通
排错经验少的人最容易卡在这个现象上：配置从参考文档比对下来一字不差，业务还是不通。这时候千万别怀疑题目本身有问题，去查链路层。
原因：出题人在拓扑里模拟的是物理层或二层故障，比如接口被 shutdown、接口速率双工不匹配、VLAN 划分错位。参考配置只描述设备端应有的参数，链路层状态它表达不了。你只对配置，不看状态，自然查不出问题。
解决：用 display interface brief 看物理层状态，是 down 就进接口取消 shutdown；是 up 但有大量错误计数就查 duplex 和 speed。对于 VLAN 错位，登录对端设备看端口所属 VLAN 和 PVID。排查的顺序一定要从物理层往上层推，不要一上来就钻进路由协议里。
4.2 现象：路由学到了，但流量走了黑洞路由
考试里有一种很隐蔽的故障：路由表里有目标网段条目，但下一跳是个不存在的地址，业务全部被丢进黑洞。表面看你的路由表是完整的，实际转发已经断了。
原因：出题人注入了一条 preference 更小（优先级更高）的静态路由，指向一个不存在的下一跳，让设备优先选择这条废路由。设备本身的选路逻辑没有错，错的只是这条注入的静态路由欺骗了选路。
解决：先找下一跳不可达的条目。
# 查看所有静态路由，定位指向虚地址的条目 display ip routing-table protocol static确认是指向不存在地址的静态路由后，删掉它，或者把下一跳改成正确的互联地址。这条命令我建议每台设备都跑一遍，因为它看得最直观。删完再用 display ip routing-table 复查一下，确认设备重新选择了正确的路径。
4.3 现象：故障修好了，重评后故障又回来了
这是新手最常见的翻车：排错半小时把配置改对了，业务通了，但评分系统一刷新，故障重新出现。考生当场心态就崩了，因为明明刚才还测过是通的。
原因：修改只写在运行配置里，没有保存到存储介质。考试系统的评分机制是按启动配置来判定的，你改动没有持久化，等于没改。这个道理很多人知道，但实际操作中一紧张就会漏掉保存这一步。
解决：改完所有配置后，逐台执行保存命令。
# H3C 设备保存当前配置到主配置文件 save force确认保存成功的方法是 display saved-configuration，看看文件里的内容和 current 是否一致。执行保存的时机也很讲究：不要拖到最后才保存，每修完一个故障点就 save 一次，这样即使后面操作失误，也能回到一次已知的正确状态。
4.4 现象：排错途中把自己锁在设备外面
考试排错过程中，有可能出现登录不上的情况，这是最紧张的故障，因为处理不好整个考试就报废了。尤其在模拟考试环境里，控制台和远程登录的通道一旦断掉，恢复起来很费时间。
原因：很多考生在验证管理通路时，随手把某个 ACL 加到 vty 接口上，或者改动了管理口 IP，把自己挡在门外。参考配置里对管理口和 ACL 的关联关系，你动手前没有备份，出了状况就找不到原始配置。
解决：考前先查看 vty 配置和 ACL 编号，把管理口的原 IP 记在草稿纸上。如果锁死了，看考场环境是否提供 console 入口恢复。最重要的是，考试的前三分钟不要急着排错，先把管理通道记牢，因为排错过程里动管理口是大概率事件。vty 接口里如果绑定了 ACL，也要确认 ACL 里 permit 的是你的管理网段。
4.5 现象：故障全部修复，复查时反而弄出新问题
考场的最后阶段有一种心态陷阱：修完所有故障后不放心，一遍又一遍验证，结果在验证过程中把正常配置改崩了。这种翻车最可惜，因为故障本来已经全部处理完了。
原因：验证动作带着副作用。比如为了测试某条链路，临时改了一条路由的下一跳，测完没有还原，等于把一个新的故障注入了进去。再比如为了验证策略，手滑在 ACL 里加了一条拒绝规则，忘了删。
解决：修完所有故障之后，把验证动作统一改成只读操作。只用 display 命令检查，不带任何配置命令。需要快速验证连通性时，用 ping 和 tracert，只要结果符合预期就收手，不要为了「再确认一下」去做配置改动。这条纪律我从第一年带考就反复强调，但每年都有人因为这个丢分。
5. 用参考配置做考前自测：自己给自己出题的演练方法
考前只看不练是记不住的。这份参考配置最有价值的地方在于，你可以拿它来给自己出模拟题。自己给自己出题这件事听起来简单，实际操作里需要一点设计感，不然就变成照着答案抄一遍配置，没有任何训练价值。
5.1 自测的具体操作：把参考配置挖掉一角再考自己
我建议的用法是这样：先把参考配置完整读一遍，然后打开一份备份，把其中一台设备的关键配置改出错，比如把互联地址 /30 换成 /24，或者把 OSPF 的宣告网段改成别的区域号。改完不要看答案，凭拓扑图和业务要求去判断故障点在哪里，然后把配置修好。
这一步和考试节奏几乎一致。考试时你面对的也是「一张正常拓扑 + 一台被人改过的设备」，你要做的就是找出改动点并恢复。自己改自己修，比干读配置更能建立排错手感和配置直觉。我在训练里会让学员至少这样练三轮，每一轮换不同的故障点和不同设备，三轮下来基本能把参考配置里的网络结构烂熟于心。
如果你用的是模拟器，比如 H3C HCL，自测效果更好。把参考配置导入模拟器，启动后故意改坏一台设备，再用排错流程重新排查一遍。模拟器里可以反复重置，适合反复练习直到形成肌肉记忆。自测时不要急着看配置，先根据现象推断故障范围，再去对比配置，这样能训练你的判断力而不是背答案能力。
5.2 自测检查清单：把每条验证点列为评分项
自测时不能只修完一个点就结束，你要像考试评分一样把所有检查点过一遍。下面这张表是我个人的排错检查清单，每次自测都强制走一遍。
| 检查项 | 验证命令 | 合格标准 |
|---|---|---|
| 接口状态 | display interface brief | 所有互联口物理层和链路层都 up |
| 互联可达性 | ping 对端互联地址 | 全部能通，延迟正常 |
| 业务网段路由 | display ip routing-table | 业务网段路由条目齐全 |
| 出口方向 | 查看默认路由和 NAT 策略 | 外网可达，策略放行 |
| 管理通道 | SSH 登录测试 | 能正常登录且权限正确 |
这张表覆盖了考试里绝大多数故障类型。接口状态检查排除物理层，互联可达性检查排除二层和三层的链路问题，业务网段路由检查排除路由协议问题，出口方向检查排除策略问题，管理通道检查保障你的最后一条退路。每一行都是独立的评分点，在自测里照着走一遍，就能模拟真实考试的评分逻辑。把这表格打出来放在桌面上，比任何参考配置都实用。
自测时还要注意一点：修复故障的顺序是有讲究的。先修接口，再修路由，最后修策略。这个顺序决定了你的排错效率，因为路由协议依赖接口状态，策略依赖路由结果。顺序反了会出现一种尴尬情况：你先修好策略，但路由还没通，测试不通，你以为策略没修好，反复检查浪费时间，等路由通了才发现策略其实没问题。
5.3 时间分配节奏：前 15 分钟、中 40 分钟、后 20 分钟、最后 5 分钟
考试时间是有限的，我会把时间切成四段。这个时间分配方式适用于大多数版本的 H3CTE Lab 考试，如果你的考场时长不同，按比例缩放即可。
第一段（前 15 分钟）：做三张快照，记管理口，画简化拓扑。这一段不做任何配置修改，只做信息收集。第二段（中 40 分钟）：逐台设备做配置 diff，定位并修复故障点。修完一个点保存一次。第三段（后 20 分钟）：做全拓扑连通性验证，用 ping 和 display 检查所有网段可达。这一段时间内只做只读操作。第四段（最后 5 分钟）：检查保存状态，确认每台设备都执行过 save，再检查一遍启动配置。
第一段看起来最不重要，但它决定了你后面三段的效率。快照做得到位，你后面不用反复刷 display 命令；管理口记牢了，你不用担心中途被锁在外面。如果你觉得自己排错速度慢，问题多半出在第一段没有把基线建立好，导致后面反复做无用功。这套节奏我反复用在自己的每一次考试练习里，坚持下来最大的改变是心里不慌。
6. 交卷前的验证习惯：保存重启后的最后检查
最后这一环节很容易被忽略，但它的价值不亚于整个排错过程。我在教学生时反复强调一个观念：评分系统看的是你启动配置之后设备的状态，不是你看在显示器上的当前状态。所以交卷之前，必须确认设备重启后配置还在、故障已恢复。这一步做不好，之前几个小时的排错可能全部白费。
6.1 保存后的配置文件确认
执行保存命令之后，不要想当然地认为保存成功了。至少要用两条命令做确认。
先看设备启动时实际加载的文件是哪个，确认你没有保存到错误的文件路径：
# 查看设备启动时加载的配置文件 display startup再看保存到存储介质的配置是否和当前运行配置一致：
# 确认保存结果 display saved-configuration如果display startup显示的配置文件名和你执行save时的目标文件名不一致，说明保存到了其他位置，重启后加载的还是旧配置。这种情况下要手动指定配置文件名称重新保存。别小看这一步，设备在考试环境里可能被设置成非默认路径，很多人就是在这里吃了暗亏。
6.2 重启后的最终自检
如果考场允许，最稳妥的办法是重启一次设备，然后用几条基础命令确认基础状态恢复。这一步能暴露所有保存相关的问题。
# 重启后确认接口状态恢复 display interface brief # 重启后确认路由表恢复 display ip routing-table为什么我如此强调重启验证？我曾经在练习里犯过一个低级错误：save 的时候没注意当前目录不是默认存储路径，配置根本没写进去，重启后故障原样回来。幸好那只是练习，没有造成实际损失。从那以后，我每次考试练习都强制走一遍「保存—重启—再登录—再验证」的流程，用这个方式来杜绝最后一步翻车。
希望在考场上，你不用经历一次「重启后故障重现」的惊魂时刻再想起来检查。考前把这份参考配置和上面这套流程结合，多自测两轮，比盲目刷题管用得多。希望帮到你。
本文还有配套的精品资源，点击获取
