企业官网建设流程全解析

1. 为什么要在一张拓扑里塞进这么多协议：综合实验的真正价值

先说个直觉：BGP、OSPF、RIP、VRRP、MSTP、DHCP中继、EasyIp、NAT-Server这些技术单独拎出来，每一样都有大量配置模板，学完照着抄也能通。但把它们放进同一张网络里，事情就没那么简单了——协议之间会互相影响，冗余方案会打架，路由重分发会成环，NAT和DHCP的配合会出回流问题。这个实验之所以叫“综合”，考的就是你能不能在这些技术咬合的时候，理清哪一层该由谁负责、哪个参数改了会影响哪条路径。

实验做完以后，我最大的感受是：网络排错不是看单点配置对不对，而是看整条链路的状态是否自洽。这篇文章我就按自己的实验复盘顺序，把这套拓扑里每个关键点的设计思路、配置细节、踩坑过程都梳理一遍，给后面做类似园区网综合实验的人一点参考。

适合看这篇文章的人有两类：一类是正在备考网络认证、需要把路由交换知识点串起来的学员；另一类是实际要搭分支机构互联或园区冗余网络，想少走弯路的工程师。我不打算把每个协议的完整配置贴一遍，而是重点讲“为什么这样配”“配完以后有什么坑”——这些才是实验报告里写不出来、但真正值钱的部分。

2. 实验场景设定和技术分工：每一层放什么协议，先想清楚再动手

2.1 拓扑需求：冗余、负载分担和跨域互访缺一不可

我搭的实验场景是一个模拟的多部门园区网，分成接入层、汇聚层、核心层，再往上通过边界路由器连接一个模拟的外部AS。设计需求有三条：

• 链路冗余：接入到汇聚至少两条物理链路，链路断了不能影响业务。
• 网关冗余和负载分担：两个汇聚设备都要干活，不能让一台闲着。
• 跨域路由：园区内部跑IGP，外部AS跑BGP，内部外部要能互通，还要能控制选路。

这三个需求正好对应标题里那堆技术。链路冗余用链路聚合解决，网关冗余用VRRP，二层防环用MSTP做多实例负载分担，内部路由用OSPF和RIP，跨域用BGP，出口地址转换用EasyIp和NAT-Server，地址下发用DHCP中继。

2.2 各协议的分工边界

我习惯先把一张表画出来，再动手配置。这样每个技术点在拓扑里负责什么，清清楚楚：

这一张表基本就是整份实验的“灵魂”。配置顺序也按照这个分工来：先做二层（链路聚合、MSTP、VRRP），再做三层（DHCP、OSPF、RIP），最后做边界（BGP、NAT）。顺序不能乱，因为后面协议要依赖前面的接口和VLAN状态。

3. 链路聚合、MSTP和VRRP：二层高可用三件套的配合实录

3.1 Eth-Trunk的配置：先建聚合口，再绑物理口

很多人做链路聚合习惯直接在物理口上配trunk，然后发现VLAN配置不同步、接口起不来。正确的顺序是先创建逻辑聚合口，把物理口加进去，再在逻辑口上做trunk配置。

我实验里的配置片段大概是这样的（以VRP系命令为例）：

interface Eth-Trunk 1 port link-type trunk port trunk allow-pass vlan 10 20 30 40

然后把两个物理口加进聚合组：

interface GigabitEthernet0/0/1 eth-trunk 1 interface GigabitEthernet0/0/2 eth-trunk 1

这里有个关键点：负载分担的哈希是逐流转发的，不是逐包轮询。我第一次验证的时候用一条iperf流打流量，发现聚合后带宽并没有翻倍，还以为链路聚合没生效。后来用多条流同时打，带宽才上去。这是因为聚合口默认按源目MAC或IP做哈希，同一条流的五元组不变，只会走一条物理链路。做验证的时候切记要起多条流，否则很容易误判配置失败。

3.2 MSTP多实例划分：让两台汇聚设备都能干活

二层环路从设计上就要避免，所以我全局启用MSTP，然后按VLAN划分实例。实验里把VLAN 10和20放进实例1，VLAN 30和40放进实例2，让两台汇聚设备分别做两个实例的根桥。

配置的关键是区域配置必须一致，包括区域名和实例映射。我碰到过一个很隐蔽的问题：两台设备上区域名不同，MSTP直接退回为STP兼容模式，整个二层的收敛速度和负载分担全部失效。检查MSTP配置一致性是必须做的一步。

根桥设置直接指定：

stp region-configuration region-name TEST instance 1 vlan 10 20 instance 2 vlan 30 40 active region-configuration

stp instance 1 root primary

stp instance 2 root primary

这样VLAN 10和20的主根在A设备，VLAN 30和40的主根在B设备。流量天然分开，两台设备都有活干。

3.3 VRRP和MSTP必须“对齐”，否则流量会绕远路

VRRP负责网关冗余，MSTP负责二层路径选择。这两者如果主备角色不一致，会出现一个经典的次优路径问题：VLAN 10的网关master在A设备，但MSTP实例1的根桥在B设备。PC发出去的流量要先从接入层绕到B，再绕回A的网关，白白浪费带宽还增加时延。

所以我的做法是把VRRP的主备角色和MSTP根桥对应起来——VLAN 10的VRRP master放在A，MSTP实例1根桥也放在A；VLAN 30的VRRP master放在B，MSTP实例2根桥也放在B。验证方式很简单：在接入设备上查看各实例的根桥MAC，再查看VRRP的master IP，两者指向同一台设备就对了。

VRRP配置里必须做上行链路跟踪。否则汇聚设备的上行口断了，网关还是它，流量到了设备却送不出去。

interface Vlanif 10 vrrp vrid 10 virtual-ip 10.1.10.254 vrrp vrid 10 priority 120 vrrp vrid 10 track interface GigabitEthernet0/0/1 reduced 30

上行口断掉后优先级降低30，master角色让给B设备，流量切换走另一条路径。实测下来VRRP切换在秒级，配合MSTP重收敛，整网恢复时间会比单跑VRRP慢一点，因为二层拓扑也要重新计算。想缩短收敛时间，可以调整MSTP的forward delay和max age，但不能调得太激进，否则容易造成临时环路。

4. DHCP中继与EasyIp、NAT-Server：从地址下发到出口翻译的一条线

4.1 为什么这里要中继，而不是每个网段单独建DHCP

实验里VLAN多、网段多，如果每台汇聚设备的每个VLAN接口都配一个DHCP地址池，配置量会爆炸，而且地址池分散以后很难管理。用DHCP中继把所有请求集中送到一台服务器上，是更符合工程习惯的做法。

PC发出的DHCP请求是广播报文，三层路由不能转发广播。中继设备收到广播后，把它封装成单播报文转发给指定的DHCP服务器，服务器再通过中继设备把配置回给PC。这里需要注意，汇聚设备VLAN接口上的地址池里的网关列表，要和VRRP的虚拟IP保持一致，否则PC拿到错误网关，整个网络都会出问题。

4.2 中继配置的三个细节

中继侧的配置比较简单：

interface Vlanif 10 ip address 10.1.10.252 255.255.255.0 dhcp select relay dhcp relay server ip 10.1.1.10

但有几个地方特别容易踩：

• DHCP服务器侧的地址池里要排除所有网关、服务器等静态地址。我一开始只在地址池里写了一个排除范围，结果某个VLAN里有一台静态IP的设备反复和DHCP分配的地址冲突，排查了半天才发现排除范围没覆盖全。
• 中继路径上如果有ACL，必须放行UDP 67和68端口。我模拟器环境里没开ACL，倒是没遇到；但实际现网中继报文大概率要穿越安全区域，这两端口不放行，PC会一直拿不到地址。
• 地址池里的网关列表要写VRRP虚拟地址。如果写成某台物理设备地址，主备切换后PC拿到的默认网关会指向一个不存在的IP，连外网直接断。

4.3 EasyIp和NAT-Server：两个NAT功能在同一个出口的协作

边界路由器出口上，内网访问互联网用EasyIp，原理就是PAT——内网所有源地址复用出接口的公网IP，用不同端口区分不同会话。配置如下：

acl 2000 rule 5 permit source 10.1.0.0 0.0.255.255 interface GigabitEthernet0/0/2 nat outbound 2000

而外网用户访问内部服务器用的是NAT-Server，做目的地址转换：

nat server protocol tcp global 202.100.1.1 80 inside 10.1.10.100 80

这两个功能如果只是为了“能通”，按上面配就行。但实测时我遇到一个经典问题：内网用户通过公网IP访问自己的服务器不通，外网用户反而正常。原因很简单——内部PC访问公网IP时，流量经过NAT出口又被转换回了内网服务器地址，服务器响应时一看源地址是内网网关，直接走内网回包，不回NAT设备，会话就断了。

这个问题的通用解法是开启**NAT回流（NAT Hairpin）**能力，让内网访问公网IP的流量也经过NAT设备的会话表处理，回包再反解一次。不同版本设备默认行为不完全一样，我在实验环境里是手动开启后才通的。这个坑如果不亲自做一遍，光看配置文档是发现不了的。

5. RIP和OSPF共存：路由重分发里那些“隐藏的环”

5.1 两种IGP为什么要共存，重分发位置又该怎么选

实验里有一片模拟老旧分支，跑RIP；园区核心跑OSPF，多区域互联。两边必须互通，所以要在交界设备上做路由重分发。

重分发的位置选择很关键。我最初图省事，只在其中一台设备上做了单向重分发：RIP引入OSPF、OSPF引入RIP都放一台设备上。这样配置简单，但存在单点故障——那台设备挂了，整个分支网络和园区之间就断了。实验为了模拟更真实的冗余场景，我把重分发做成了双点双向：两台设备都同时把RIP引入OSPF、把OSPF引入RIP。结果问题来了。

5.2 双点双向重分发的环路问题：我实际踩到的现象

配完双点双向后，我用display ip routing-table protocol rip查看路由表，发现RIP区域里出现了大量OSPF内部路由，而且下一跳在两台设备之间来回跳。原因其实不难理解：

假设A设备把OSPF路由引入RIP发给分支，B设备收到这条RIP路由后，又把它引入OSPF传回核心。核心收到一条“通过RIP学到的OSPF内部路由”，优先级可能把原来的OSPF直连路由给覆盖掉，形成环路和次优路径。

解决思路就是给重分发的路由打标记，再在另一侧重分发时把带标记的路由拒绝掉。配置片段大概是：

route-policy RIP2OSPF permit node 10 apply tag 100 route-policy OSPF2RIP deny node 5 if-match tag 100 route-policy OSPF2RIP permit node 10 apply cost 3

RIP引入OSPF时给所有路由加上tag 100；OSPF引入RIP时，先拒绝掉带tag 100的路由，这些路由本来就是从RIP发出来的，再引回去就是环路。剩下的路由再正常引入。原理不复杂，但如果不双侧配合，只做一半，环照样转。

5.3 度量值的“单位冲突”也要处理

RIP的度量是跳数，OSPF的度量是开销值。RIP路由重分发进OSPF时，如果不指定metric值，默认会变成1，也就是“一跳”，OSPF全网都会认为这条外部路由代价极低，全部优先走它。我在实验里就因为这个原因，核心设备的默认路由全被带偏到了分支侧。

我的处理是在重分发命令里通过route-policy或者直接指定cost，把引入OSPF的外部路由metric设置成一个合理值，比如10：

ospf 1 import-route rip 1 cost 10 route-policy RIP2OSPF

同理，OSPF引入RIP时，OSPF的开销值需要转换为跳数，默认转换规则经常不符合预期，手动指定一个合理的RIP成本更稳妥。做完之后，我在核心和分支各抓了一份路由表，确认每一类路由的来源、优先级、下一跳都符合设计预期，再继续往下做BGP部分。

6. BGP路径属性选路和手动聚合：跨域流量控制的两种手段

6.1 BGP邻居怎么建，决定了后面的选路策略

实验里园区边界和外部AS建立BGP会话，同时内部核心路由也要通过BGP对外发布。我使用环回口建立IBGP会话，配置里用peer 10.0.0.2 as-number 100这种方式，配合update-source LoopBack0。这样即使物理链路断开，只要环回口之间还有路径可达，BGP会话就不会断。

BGP的核心价值不在“通”，而在“选路”。实验里我模拟了两条到达同一外部AS的链路，一条带宽大、延时低，另一条带宽小、延时高，希望通过路径属性控制入向流量走主链路。

6.2 四个关键路径属性的优先级与配置位置

华为系BGP的选路顺序里，最常用的几个属性优先级大致是：

不同属性的配置位置完全不同，这是最容易搞混的地方。Local_Pref是在本AS的入方向通过route-policy修改的，控制的是“本AS路由器怎么选路出去”。AS_Path和MED通常是在向对端发布路由的方向上做修改，影响的是“对端设备怎么选路回来”。

我实验里用Local_Pref做了一个直观验证：在边界设备的入方向把主链路收到的BGP路由Local_Pref设为200，备链路设为默认100，然后查看本AS所有设备的路由表，发现去往外部AS的下一跳都指向主链路边界设备。

6.3 手动聚合：不抑制明细等于白聚合

外部AS引入了大量网段路由，如果不做聚合，边界设备要通告几十条明细路由，对端设备的路由表压力很大。我在边界设备上做了BGP手动聚合，把多个24位网段聚合成一条16位路由通告出去。

命令很简单：

bgp 200 aggregate 172.16.0.0 16 detail-suppressed

关键是后面的detail-suppressed——这个参数的意思是抑制明细路由通告，只发布聚合路由。我第一次只写了aggregate 172.16.0.0 16不加抑制，结果对端仍然收到全部明细，聚合只是“自己生了条聚合路由”，并没有达到减表目的。

还有一个必须说明白的点：普通手动聚合生成的聚合路由不携带AS_Path信息，对端无法通过AS_Path防环。如果聚合的明细路由来自不同的AS，最好加上as-set参数，让聚合路由携带一个无序的AS集合，防止路由环路。当然代价是聚合路由的属性会失去原始顺序，可能影响部分选路策略的精确性，所以要根据实际需求取舍。

7. 端到端验证与典型故障复盘：一根链路上的排查顺序

7.1 从PC到跨域服务器的完整验证链路

所有配置做完以后，我习惯从最末端PC开始逐步往上验证。第一步是PC能否获取正确IP，检查DHCP中继是否生效；第二步是PC到网关的连通性，验证VRRP虚拟IP；第三步是PC到核心和分支，验证OSPF和RIP重分发；第四步是跨域到外部AS，验证BGP和NAT。

我实测中抓到的几个典型故障和对应排查点：

7.2 排错顺序的“肌肉记忆”

综合实验里协议多，故障往往是多因素叠加。我总结出一条比较靠谱的排查顺序：二层看MAC、三层看路由、边界看NAT。

二层先确认链路聚合口的状态是UP，物理口都绑上去了；再看MSTP实例的根桥是否为预期设备；最后看VRRP状态是否为Master。三层打开路由表，按display ip routing-table protocol分别过滤OSPF、RIP、BGP路由，看每一类路由的下一跳和优先级是否符合设计。边界环节检查NAT会话表display nat session，确认内网PC访问外网的会话是否被正确创建。

这套顺序能覆盖实验里90%的问题。有一次我花了很长时间查跨域不通，最后发现是OSPF区域间路由没配全，核心设备根本没有去往外部AS那一侧的明细路由——这属于“三层路由表不完整”的问题，如果在看路由表那一步就多瞄一眼，能省很多时间。

7.3 最后一点个人体会

做这类综合实验，我的体会是：别急着把每个协议的配置都背下来，先把“谁负责什么”的全局图刻在脑子里。链路聚合、MSTP、VRRP解决的是二层的“可用性”，DHCP中继和NAT解决的是“可达性”，OSPF和RIP解决的是“内部互通”，BGP解决的是“跨域选路”。每一层出问题，症状都在PC上表现成“不通”，但排查路径完全不同。先定位是哪一层的问题，再动手查配置，比把每个协议从头到尾看一遍高效得多。这套思路，比记住任何一条命令都值钱。