简介面向中大型网络组网仿真场景的H3C路由交换综合实验包适合网络工程专业毕业设计、H3C认证备考及模拟企业级网络架构的进阶学习者。实验以8台路由器、13台交换机、2台防火墙、无线控制器及AP/PC/Phone等设备构建核心-汇聚-接入三层组网核心层采用M-LAG分布式聚合与VRRP冗余机制汇聚层通过聚合上行、VRRP下行实现高可用接入AC直连汇聚并纳管AP整体覆盖路由协议、链路聚合、冗余备份及无线漫游等关键知识点。资料共44个文件以32个设备cfg配置文件为主另含拓扑png、README说明、项目配置及备份文件压缩包约35.99MB便于按设备模块对照学习配置量大时也可分批次启动部分设备进行验证。已有565人浏览下载适合作为毕业设计参考、实验复盘或综合组网能力提升的完整案例。1. 综合网络实验怎么开题从“能通”到“能讲”的落差才是毕设的真正分水岭做H3C路由交换综合实验最容易踩的坑不是配不通而是配通了却讲不清。很多人把实验停留在OSPF邻居UP、全网Ping通就交差答辩时被问一句“你这个网络如果骨干链路断了会怎样”就卡住。真正能拿高分的综合网络实验是模拟一个带骨干、汇聚、接入三层结构的大型网络在里面跑通MPLS、SRSegment Routing再用TE Policy流量工程策略控制业务路径。这套方案的思路是以HCL模拟器为底座用SR-MPLS TE Policy作为设计主线把路由协议、MPLS转发、流量调度串成一个完整故事。适合正在选毕设题的学生也适合想从“配通”进阶到“设计”的从业者。它的价值在于一次实验同时覆盖了IGP、BGP、MPLS、SR和TE五个层次每一层都能单独展开讲答辩时永远有东西可讲。2. 综合网络实验的需求分析与总体设计网络规模、拓扑结构与地址规划怎么定2.1 需求边界毕设规模怎么定才不自找麻烦综合网络实验最容易翻车的地方是规模失控。见过有同学一开始就规划二十台设备每台设备四个接口结果HCL模拟器跑起来CPU直接拉满一个命令敲下去要等十秒实验做到一半就放弃了。毕设不是越复杂越好而是“结构完整、层次清晰、能自圆其说”。通常的做法是控制在一个核心层、一个汇聚层、一个接入层加上出口路由器总共控制在8到12台设备之间其中至少有两台设备启用SR功能形成一条可对比的主备路径。另一个容易忽略的需求点是文档和配置的一致性。综合网络实验的交付物不只是拓扑能通还包括一份完整的配置手册、IP规划表和验证记录。很多人在做实验的时候随手配地址最后写论文时发现地址段到处都是答辩被问到“这个网段为什么这样划分”时完全答不上来。所以一开始就要把地址规划当成需求来分析而不是等配完了再补。还有一点是所有H3C实验都躲不开的HCL模拟器对某些高级特性的支持是阉割过的。比如部分MPLS TE的扩展属性在HCL里无法完整模拟这时候设计方案里就必须写明“哪些特性在模拟器里验证哪些特性在真机上才能完全生效”。把这个边界写清楚反而能让答辩老师觉得你思考过真机和模拟器的差异。2.2 拓扑规划核心-汇聚-接入三层结构与路由协议选型综合网络实验的拓扑结构我一般推荐采用双核心加双汇聚的架构。核心层两台设备做双机热备汇聚层两台设备分别连接不同的接入交换机形成一个无环的层次化结构。接入层根据需求挂三到四台设备模拟不同部门或不同业务区域。出口路由器连接核心层模拟与外部网络的互联。这个拓扑有一个明显的好处天然支持主备路径的流量工程验证。比如从接入层A到接入层B正常情况下走核心1当核心1到汇聚1的链路中断时流量自动切到核心2路径。但如果你只用OSPF的等价路由切换是自动发生的看不见任何“设计感”。所以要在汇聚层引入MPLS核心层启用SR让流量路径变得可控可预期。路由协议方面核心与汇聚之间运行IS-IS或OSPF均可但如果你后面要做SR-MPLS TE PolicyIS-IS会更顺手。因为SR的Prefix Segment和Adjacency Segment可以通过IS-IS的扩展TLV自动分发OSPF虽然也支持但在HCL模拟器里IS-IS配合SR的配置更稳定。业务路由用BGP承载核心层两台设备作为BGP反射器汇聚层和接入层作为BGP对等体。2.3 地址与路由规划IP编址、AS划分和路由引入策略地址规划的原则是“一眼能看出业务归属”。通常的做法是把整个实验网络的地址段划分为几个连续的/24网段用第二个八位组区分区域第三个八位组区分设备类型。比如核心层互联地址用10.0.1.0/24汇聚层互联地址用10.0.2.0/24业务网段用10.1.x.0/24来区分不同部门。LoopBack地址单独划分一个段比如10.255.x.x/32用于BGP和MPLS的Router ID。AS划分建议保持简单整个实验网络使用一个私有AS号比如AS 65001。BGP只在核心层和汇聚层之间建立接入层不跑BGP只跑OSPF或静态路由。这样设计的好处是路由层次清晰IGP负责底层互联互通BGP负责业务路由的承载和通告MPLS负责转发层面的标签交换。路由引入是一个容易被忽视的坑。OSPF引入BGP路由时需要特别注意Tag标记否则路由回灌会导致环路。具体做法是在核心层设备上将从BGP学到的路由引入OSPF时打上特定的Route Tag在汇聚层做路由过滤时按Tag过滤。同时BGP的同步和Next-Hop属性也要处理干净否则会出现路由学到了但下一跳不可达的情况。2.4 HCL模拟器的硬限制与实验方案的调优HCLH3C Cloud Lab模拟器是H3C官方的图形化网络模拟工具对H3C设备的命令行支持比较完整但有几个硬限制必须在方案设计阶段就考虑。第一是设备型号固定HCL里只有固定的几款路由器型号不支持自定义硬件参数所以设计时不要写“核心层采用高性能设备”这类话直接写模拟器里的具体型号即可。第二是部分MPLS TE的CSPF算法参数无法调整这意味着你在做带宽约束计算时只能依赖默认策略。第三是HCL的进程资源占用比较高设备越多越卡顿。通常的做法是每台设备分配512MB内存CPU核心数给到2如果机器配置不够就适当减少接入层设备数量。还有一点经验是HCL对Windows防火墙依赖较强第一次启动时如果设备无法连接先检查防火墙有没有放行HCL的相关进程这能省掉很多排查时间。另外HCL里保存配置的机制也要熟悉。实验做完以后需要手动执行save操作并且把设备的配置文件导出到本地目录。如果你用的是HCL的“一键部署”功能要注意它默认会把所有设备配置清空所以不要在部署前忘了备份。3. 核心协议部署从IGP到SR-MPLS TE Policy的完整配置链路3.1 底层IGP的选择与配置IS-IS还是OSPF底层IGP是整个实验的地基。IS-IS和OSPF都能完成这个任务但在SR场景下IS-IS的配置更简洁清晰。原因在于SR的Prefix Segment在IS-IS里通过Router Capability TLV自动通告不需要额外配置扩展属性OSPF虽然也支持SR但在HCL模拟器里需要额外配置Segment Routing MPLS的能力步骤更多。IS-IS的配置核心是两部分一是网络实体名称NET的规划二是Level的划分。综合网络实验建议所有设备运行IS-IS Level-2简化设计避免Level-1和Level-2之间的路由泄漏问题。NET地址用49.0001.0000.0000.0001.00这种格式其中中间的12位十六进制数要和LoopBack地址对应方便排错时快速识别设备。IS-IS的认证也要在实验里体现。核心层和汇聚层之间的IS-IS邻居建议配置MD5认证这是答辩时能讲的亮点。配置方法是接口下执行isis authentication-mode md5在进程视图下执行area-authentication-mode md5。注意两边设备配置的密钥必须一致否则邻居关系起不来这也是最常见的配置错误之一。3.2 SR-MPLS的启用Prefix Segment与Adjacency Segment的分配与验证启用SR-MPLS之前必须确认设备支持MPLS转发。H3C设备上需要先开启MPLS能力然后再开启Segment Routing。顺序不能反否则SR的配置命令无法识别。具体步骤是在系统视图下执行mpls lsr-id指定本端LSP的LoopBack地址然后执行segment-routing mpls进入SR配置视图。Prefix Segment的分配是SR的关键。在IS-IS进程视图下执行segment-routing mpls prefix-sid为每个设备的LoopBack地址分配一个全局唯一的SID。SID的取值范围建议从16000开始比如核心1的LoopBack地址对应SID 16001核心2对应16002按设备编号顺序递增。这样做的好处是排错时看到SID就能知道是哪台设备答辩时也能清楚解释SID的规划逻辑。Adjacency Segment则不需要手动分配IS-IS协议会自动为每一条邻接关系分配一个本地SID。你要做的是在接口下启用SR的邻接标签能力执行命令是isis adjacency-sid。这里有一个常见的坑如果接口下的IS-IS邻居关系不稳定频繁Up/Down会导致Adjacency SID频繁变化影响SR Policy的稳定性所以接口参数的协商比如MTU、DCN要在启用SR之前就固定好。验证SR是否生效用display segment-routing mpls prefix-sid和display isis route命令查看。重点看两条一是每台设备的LoopBack路由是否都带上了SID信息二是SR的转发表项是否完整。如果发现有设备的路由没带SID大概率是这台设备的SR功能没有启用或者IS-IS进程没有正确识别到SR扩展TLV。3.3 SR-MPLS TE Policy的配置从路径计算到显式路径绑定SR-MPLS TE Policy的价值在于它能把流量引导到一条人为指定的路径上而不是交给IGP去自由选路。传统MPLS TE依赖RSVP-TE做信令交互而SR直接通过Segment列表SID列表来定义路径。H3C设备上SR Policy的配置核心是policy的创建、候选路径Candidate Path的绑定和流的引流。配置一个SR Policy通常分三步。第一步创建Policy指定Policy的名称和Endpoint地址即流量的目的地。第二步配置候选路径如果是动态路径就指定路径约束条件比如带宽、时延、亲和属性如果是显式路径就手动指定SID列表。第三步把Policy应用到业务流上H3C里常见的是通过引流策略Traffic Policy把匹配特定ACL的流量导向Policy。一个可复现的显式路径配置示例如下# 创建SR PolicyEndpoint是汇聚2的LoopBack地址 segment-routing mpls traffic-engineering policy srte-policy-1 endpoint 10.255.4.2 color 100 candidate-path preference 10 explicit-path name path-core1 index 10 sid 16001 index 20 sid 16003 index 30 sid 16004这段配置的含义是定义了一条名为srte-policy-1的策略目的地是10.255.4.2颜色值为100优先级的候选路径通过显式路径path-core1指定依次经过SID 16001核心1、16003汇聚1、16004接入2。这样就形成了一条完全可控的转发路径。配置完以后必须检查SR Policy的状态。用display segment-routing mpls traffic-engineering policy命令查看Policy是否处于Up状态。如果状态是Down最常见的原因是Endpoint地址不可达或者显式路径里的某一个SID不存在。还有一种情况是Policy没有绑定Color导致引流策略匹配不到流量不会进入Policy。3.4 BGP业务路由与SR Policy的联动让流量按策略走SR Policy配好了但如果你直接把业务流量丢给路由表它大概率不会走Policy因为传统IP转发只查路由表不看TE Policy。要把流量引到Policy上需要有明确的引流机制。H3C的实现是通过流量分类和引流策略来完成的。简单可靠的做法是使用Policy-Based RoutingPBR与应用了SR Policy的接口配合。具体是在核心层的入口接口上配置QoS策略匹配特定源地址或目的地址的流量重定向到SR Policy对应的隧道接口。如果实验时间紧张也可以在设备上定义一个ACL匹配特定的目的网段然后在接口下使用traffic-redirect ipv4 policy命令把流量引导到Policy关联的转发路径。这里有一个必须强调的坑SR Policy的Endpoint地址和引流目标地址不是一回事。Endpoint是SR Policy的目的节点引流目标地址是实际业务的访问目标。比如业务是访问10.1.20.0/24这个网段SR Policy的Endpoint是10.255.4.2汇聚2的LoopBack引流时匹配的是10.1.20.0/24不是10.255.4.2。很多同学在这里配错导致Policy一直是空的流量根本没走进去。验证流量是否真正走入了SR Policy建议在核心设备上用display segment-routing mpls traffic-engineering policy statistics查看包计数。如果计数在增长说明引流成功。如果不增长在接口下抓包或者debugging te policy查看报文有没有被正确处理。3.5 数据面验证从Ping通到路径可证明到这一步实验的核心链路就已经通了。但要让实验成果能答辩必须让“流量走了指定路径”这件事可视化。通常的做法是在核心1上开启MPLS的TTL复制然后在路径上的每一跳设备上查看标签转发表。具体验证方法在源设备的接口下执行ping mpls ipv4 10.255.4.2 16001带SID去ping如果通说明SID路径可用。再用tracert mpls ipv4 10.255.4.2 16001能看到每一跳的标签信息这是答辩时最能说明问题的输出。另外在旁路设备上可以配置端口镜像或者流统计把经过的MPLS报文统计出来和SR Policy的统计信息互相印证。多一重证据答辩时就多一分说服力。4. 常见翻车点排查H3C综合实验里最容易栽的五个坑4.1 现象IS-IS邻居起不来接口物理UP但协议DOWN原因通常是NET地址或Level不匹配。IS-IS的NET地址最后一位必须是00Area ID必须一致Level必须一致全用Level-2最省事。还有一个隐蔽原因是接口下没有执行isis enable命令导致IS-IS协议没有在这个接口上运行。解决方法是先display isis interface确认接口是否已启用IS-IS再用display isis peer查看邻居状态。如果接口没有启用在接口视图下执行isis enable 1编号要和进程号对应。如果Area ID不一致需要统一NET地址前10位49.0001部分必须相同。4.2 现象SR Policy创建后状态一直Down原因分为两类。一是Endpoint地址在IGP路由表中不存在导致系统无法计算路径二是显式路径里指定的SID不存在或顺序错误。SID错误一般是规划时没对齐LoopBack地址和SID的对应关系。解决方法是先ping Endpoint地址确认可达性再display segment-routing mpls prefix-sid核对SID是否和设备对应。如果显式路径里用了邻接SID还要确认邻接SID在指定接口上是稳定的不能和别的链路共用同一个SID值。4.3 现象主备切换后流量黑洞Ping不通了这个坑出现在核心层和汇聚层之间。当你断开核心1的链路模拟故障时流量应该切到核心2的SR Policy但实际上切不过去。原因通常是两部分一是BGP在一台核心设备Down了以后没有及时撤销对应的路由导致流量还在往旧路径上送二是SR Policy没有配置备份候选路径主路径断了整个Policy就失效了。解决方法是在BGP视图下调整定时器加快收敛同时在SR Policy里配置多条candidate-path并给不同路径分配不同优先级。主路径优先级高备份路径优先级低主路径失效时自动切换。配置完以后disconnect链路再观察Policy的状态变化确认备份路径被激活后再做Ping测试。4.4 现象HCL模拟器重启后配置全部丢失原因是HCL默认不会自动保存配置而且设备重启后如果没有执行save所有配置都会被清空。还有一种是save了但导出的文件没有被保存到项目目录下次打开项目时加载的是空白配置。解决方法是每完成一个阶段的配置就执行一次save并把配置文件用display current-configuration重定向到本地文本文件。不要依赖HCL的自动保存功能手动备份是唯一的可靠方案。建议在实验方案里把备份点也列出来哪些配置完成后必须备份形成习惯。4.5 现象MPLS转发不生效标签头不出现核心层配置了MPLS和SR但抓包看流量还是普通IP报文没有加标签。原因通常是接口下没有开启MPLS能力。MPLS是逐接口生效的只在系统视图下配置mpls lsr-id是不够的必须在每个参与MPLS转发的接口下执行mpls enable命令。解决方法是检查所有涉及的物理接口和子接口逐一开启MPLS。还有一种情况是设备之间MPLS MTU不一致导致带有标签的大报文被丢弃。建议把接口MTU统一调整为1500以上或者在接口下配置mpls mtu 1600避免分片导致的丢包。5. 验收与答辩让综合网络实验从“能通”到“能讲”综合网络实验的验收标准不能只看Ping通与否。我一般建议把验收拆成三层基础连通性验收、协议状态验收、业务路径验收。基础连通性包括全网设备LoopBack互通、业务网段互通协议状态验收包括IS-IS邻居状态、BGP邻居状态、MPLS转发表项、SR Policy状态业务路径验收是最关键的要能证明特定流量走了指定路径并且在故障注入后完成了主备切换。答辩时的演示顺序按照“拓扑介绍 → 路由协议状态展示 → SR Policy路径展示 → 故障切换演示 → 抓包证据”这个顺序来。每一步的展示时间控制在两分钟左右全程五分钟到八分钟结束。故障切换演示是最出彩的部分先ping通一段业务流量然后在核心1的接口上执行shutdown观察SR Policy的状态变化和Ping的恢复时间把恢复时间记录下来作为性能数据。这样整个答辩就有了一个“问题-设计-验证-数据”的完整闭环。答辩时容易被问到的几个问题提前准备好一是“为什么选SR-MPLS TE Policy而不是传统RSVP-TE”回答要点是SR不需要信令协议、SID即可表达路径、控制面更简单在H3C模拟器里配置也更直观。二是“如果网元不支持SR怎么办”回答要点是可以在边界设备上做SR与普通MPLS的互通或者退化为隧道嵌套。三是“Color值有什么用”回答要点是Color用来区分不同SLA要求的业务类型配合引流策略实现差异化转发。当年我做这个实验时第一次配置完SR Policy怎么都调不起来后来发现是Endpoint地址写错了整整排查了一个下午。从那以后我每次配置完Policy都会强制走一遍SID核对流程从display segment-routing mpls prefix-sid的输出逐行比对确认每个SID都落在预期设备上。这个习惯帮我后来在多个项目里少踩了很多坑。希望这篇方案能帮你在做综合网络实验时把时间花在真正有价值的设计和验证上。本文还有配套的精品资源点击获取
