企业官网建设流程全解析

1. 实验前先理清这两件事

1.1 路由策略（Routing Policy）和策略路由（PBR）到底差在哪

做“路由策略实验练习”最容易踩的第一个坑，就是把“路由策略”和“策略路由”混为一谈。这俩名字太像了，很多教材还喜欢放在同一章，但它们的处理对象完全不同：路由策略管的是“路由表里有哪些路由、路由怎么传递”，策略路由管的是“数据包实际怎么走”。

打个比方，路由策略是一个“安检员”，站在路由更新的必经之路上，检查这条路由能不能进路由表、能不能发给邻居、能不能从一种协议引入到另一种协议。它操作的是一张张“路由清单”，修改的对象是路由属性（比如优先级、开销、标记），不会去管单个数据包怎么转发。策略路由则像一个“交警”，站在设备转发路径的十字路口，直接对数据包下命令：你从哪个接口进来的、你是这个网段的，就给我走有线那条链路，不用管路由表里下一跳是谁。

实操中的区别也很直观。你在设备上配了一条过滤规则，周围邻居的路由表发生变化、收不到某些网段了，这是路由策略在“安检”；而你让网段的用户上网走出口A、网段走出口B，同一时间用户访问同一个网站却走了不同的物理链路，这是策略路由在“指挥交通”。

这个实验练习把两者都覆盖了，我是推荐你这么做的：先用一台路由器把过滤、重发布、属性修改这些“路由策略”玩明白，再配置“PBR策略路由”做基于源地址的流量分流。顺序很重要，先懂策略，再做分流，否则后面调不通时你根本分不清是路由通告的问题还是PBR优先级的问题。

1.2 这个实验涉及的核心技术点

这个实验练习需要你至少掌握五块内容：ACL（访问控制列表）、前缀列表（Prefix-List）、路由策略工具（华为叫Route-Policy，思科叫Route-Map）、路由重发布（Redistribute）、以及PBR的报文分类和下一跳设定。ACL和前缀列表都是“过滤器”，但两者的出身不同：ACL最早是为包过滤设计的，用来匹配源地址、目的地址、协议和端口；前缀列表是专门为路由匹配发明的，按照IP前缀和掩码长度两个维度精确匹配路由条目，还能用ge/le参数控制掩码范围。做路由策略实验时，我的实战习惯是：匹配路由优先用前缀列表，匹配数据流优先用ACL，这样符合各自的定位，出问题时也更好排查。

路由策略工具是这套实验的灵魂。华为环境下Route-Policy由if-match子句、apply子句和节点（node）组成，每个节点内部又分permit和deny模式；思科Route-Map则用match和set对应。节点之间按序号从小到大匹配，匹配到哪个节点就执行哪个节点的动作，不再往下走。这个“按序匹配、先到先得”的逻辑，是整个路由策略实验最核心、也最容易被忽略的规则。

PBR方面，重点在于理解“接口方向”和“优先级”。传统路由是查路由表最长匹配，PBR则直接按策略先匹配。华为设备的PBR可以用流策略（traffic-policy + traffic classifier）实现，也可以直接配policy-based-route，思科则是在接口下挂route-map。无论哪种，本质都是三件事：流量分类、设定动作（比如set ip next-hop）、接口应用。

2. 实验拓扑与规划

2.1 拓扑设计：三台路由器就能撑起全场

路由策略实验我用的是最精简的三台路由器拓扑（如果你在eNSP或者EVE-NG里搭，5分钟就能完成），三台设备环环相连，中间没有任何多余链路。R1与R2直连，R2与R3直连，每台路由器都宣告一个自己的环回口网段，再在两两之间的物理链路上规划一个网段，让OSPF或IS-IS能在这个环境里跑起来，也方便后面演示重发布和路由过滤。

具体地址规划可以参考下面这张表，拿走直接用：

选择三台设备是有讲究的。两台路由器只能做单点直连，没法完整演示“一台中间设备同时从两侧接收路由、再决定如何向两侧通告”的过程；四台以上又会让实验复杂度上升，排查难度变大，初学者容易怀疑人生。三台的拓扑刚好把R2变成“中转站”，你可以在R2上同时做路由接收过滤和路由通告过滤，还能在R2上配置PBR，让从R1来的流量通过不同路径转发，一站全练完。

2.2 IP与路由协议规划：先跑通再说策略

IP规划好后，我先在R1、R2、R3上把基础接口地址全部配完，然后启用OSPF，让全网的路由先“裸奔”起来，确保所有LoopBack网段都能互相Ping通。然后再关闭部分接口检查路由表，或者只在R2和R1、R2和R3之间各建一个OSPF邻居，让R1到R3的路径必须经过R2。

裸奔的目的有二：一是验证物理链路和接口配置没有低级错误，二是为后面的过滤实验留下一个“过滤前状态”。做路由策略实验最大的忌讳就是“还没跑通就加策略”，一旦策略加完不通，你分不清是策略本身的问题、还是基础路由就存在问题。我见过太多学员在eNSP里R1和R3一直Ping不通，查了半天策略，最后发现是R2的OSPF没起来，白白浪费一下午。

协议选择上，推荐用OSPF，因为它收敛快、邻居状态好排查，display ospf peer这条命令一眼就能看出邻居是否Full。当然如果你想练得更深，同样拓扑下换成IS-IS或BGP也完全成立，BGP环境下还能继续玩AS-Path属性过滤和团体属性，进阶空间很大。

3. 路由策略实验：控制路由的“进”与“出”

3.1 前缀列表：路由过滤的最佳搭档

前面的准备完成后，开始第一个正式实验：让R3只能从R2学到部分网段。比如R2上有三条核心路由，我现在想让R1宣告的172.16.1.0/24网段通过，但把R1的192.168.1.0/24网段过滤掉，就轮到了前缀列表出场。

先在R2上定义IP前缀列表，命令如下：

# 在R2上配置 ip ip-prefix EXT-ONLY permit 172.16.1.0 24

这条命令的意思是：只允许精确匹配172.16.1.0/24的路由。如果想让子网掩码范围放宽，可以用ge和le参数：

ip ip-prefix EXT-ONLY permit 172.16.0.0 16 ge 20 le 28

这条的含义是：匹配前缀为172.16开头的网段，掩码长度从20位到28位之间都算匹配，也就是172.16.16.0/20、172.16.32.0/24这类网段都会命中，而172.16.0.0/16本身因为掩码小于20就不满足条件。这个特点是用ACL很难实现的，因为ACL配通配符掩码时没法表达“掩码范围”的语义，前缀列表天生就是干这个的，所以路由匹配场景我永远优先用它。

有了匹配工具，接下来把这个前缀列表追加到OSPF协议的入方向过滤上，让该策略对从R3方向进入R2的路由生效，控制路由接收动作按计划执行：

# 在R2的OSPF进程下配置 ospf 1 filter-policy ip-prefix EXT-ONLY import

配置完成后在R2上执行display ip routing-table，你会看到R3环回口的路由悄然消失，R1的环回口路由依旧存在。再把R3上的OSPF配置修改，过滤通告方向的场景通过filter-policy ip-prefix EXT-ONLY export实现，或者直接在R1与R2的二层链路上，用silent-interface接口命令配合过滤让邻居关系断开。

这里有一个关键的坑必须提醒：不要在R2上对OSPF进程做全局的filter-policy export，除非你非常清楚OSPF的LSA泛洪机制。因为OSPF是链路状态协议，邻居关系建立后，过滤export实际上只是“过滤路由表项进入路由表”，LSA依然会通告出去，邻居学到的条目可能仍然存在。这也是为什么做路由策略实验时，基础理论要先过关，不然你会拿着display ospf lsdb命令看半天也理解不了“为什么我过滤了但LSDB里还有”。

3.2 Route-Policy重发布实验：把直连路由批量引进OSPF

第一关通过后，加大一点难度：在R2上把直连路由（包括LoopBack）重发布进OSPF，同时只允许特定网段被发布，其他网段一律拦住。华为用Route-Policy配合重发布命令实现，思科用Route-Map + Redistribute实现，思路完全一致。

先在R2上定义ACL，抓取需要的网段：

# 在R2上配置 acl number 2000 rule 5 permit source 172.16.2.0 0.0.0.255 rule 10 deny

再定义Route-Policy：

# 在R2上配置 route-policy DIRECT-TO-OSPF permit node 10 if-match ip address acl 2000

最后在OSPF进程下引入直连路由，应用这个策略：

# 在R2的OSPF进程下配置 ospf 1 import-route direct route-policy DIRECT-TO-OSPF

配置完成后，在R1上看这台R2发布过来的路由，你会发现只有172.16.2.0/24这一个“直连网段”被引入，R2物理接口的网段（如10.0.23.0/24）反而没有被发布。为什么？原因在于ACL匹配的是路由前缀，而R2的直连路由包含物理接口网段和LoopBack网段，你只允许了LoopBack网段，物理接口网段在rule 10里被deny了，策略生效，后续动作停止。

这个实验真正想让你理解的是“重发布的方向性”。路由策略是分方向的，重发布进OSPF时，方向是“从其他协议进程流向OSPF进程”，在R1上看到的条目就是R2过滤后的结果；重发布出OSPF则在其他方向生效。实际操作时注意在R1上执行display ospf routing和display ip routing-table对比查看，前者看OSPF数据库里的LSA，后者看真正安装进路由表的条目，两者一致才能说明过滤成功，不一致就检查filter-policy的位置是否放错了。

3.3 控制路由通告：在R2上“按下”不需要的路由

重发布做完，再回来做一个反向练习：在R2上用Route-Policy的apply子句修改路由的属性，然后专门观察R3收到后的表现。比如把R1的环回口路由在重发布过程中打个“标签”，然后把开销改成50：

# 在R2上配置 acl number 2001 rule 5 permit source 172.16.1.0 0.0.0.255 route-policy SET-METRIC permit node 10 if-match ip address acl 2001 apply cost 50 apply tag 100 ospf 1 import-route ospf route-policy SET-METRIC

这里注意：如果你在R2上把R1的OSPF路由通过import-route ospf的方式再引入一遍，可能形成路由反馈，这在OSPF中默认是不允许的。更稳妥的做法是在重发布直连或静态路由时应用这个Route-Policy，或者把实验换成在R2上同时运行OSPF和IS-IS，再把一个协议的路由重发布进另一个协议，这样既能体现属性修改，又不会出现自环式的路由混乱。

我建议你在这个环节做一个“双协议重发布”的组合实验：R1、R2跑OSPF，R2、R3跑IS-IS，R2上用Route-Policy把OSPF引入的路由重发布到IS-IS时，利用apply cost修改开销值；反过来IS-IS重发布进OSPF时，if-match匹配上某条路由，再apply tag标记。在R2和R1上分别查看路由表，就能直观看到同一前缀因为属性变化产生了不同的选路结果。

4. PBR策略路由实验：让流量不走寻常路

4.1 策略路由和路由策略在实验中的实战区别

前面实验都在“改路由”，接下来换挡做“改转发”。PBR策略路由的原理其实很简单：当数据包进入设备时，先按策略匹配，匹配上了就按策略指定的下一跳转发，不再查找路由表；匹配不上，才回落回正常的路由表转发路径。这里的“先”和“优先级”是整个PBR的灵魂。

我用一个最经典的实验场景来说明：R1下面接了两台PC，网段分别是192.168.10.0/24和192.168.20.0/24，R2上连着两条出口链路（模拟两条链路分别接R3和R4），我现在要求“网段的流量走R3出局，网段的流量走R4出局”。如果是传统路由，无论哪个网段访问同一个目标，选路结果都一样，出口只有一个；PBR就是为了打破这种“一视同仁”的局面。

华为设备上配置PBR的方式主要有两种。老手法是接口下直接应用policy-based-route，新手法是基于流策略的traffic-policy + traffic classifier，后者更符合现代设备的转发架构，也更便于你日后对接防火墙、负载均衡的配置习惯。思科对应的就是ip policy route-map。做这个实验时我推荐你先把traffic classifier的写法练熟，因为它在实际项目中是主流。

4.2 基于源地址的PBR分流：一个命令看清流量走向

下面是华为设备配置PBR的具体命令，我先用基于流策略的写法示范：

先在R2上定义流分类，匹配源地址为192.168.10.0/24的流量：

# 在R2上配置 acl number 3001 rule 5 permit ip source 192.168.10.0 0.0.0.255 traffic classifier VOICE if-match acl 3001

再定义流行为，指定下一跳：

# 在R2上配置 traffic behavior TO-R3 redirect ip-nexthop 10.0.23.3

最后把流分类和流行为绑定成流策略，并应用到接口入方向：

# 在R2上配置 traffic policy PBR-VOICE classifier VOICE behavior TO-R3 interface GigabitEthernet0/0/0 traffic-policy PBR-VOICE inbound

配置完成后的验证命令是关键。我在R2上执行display traffic policy applied-record查看策略命中情况，再在R1上分别Tracert两个不同网段的源地址访问同一个目标，观察路径差异。通过这个实验你会看到一个很有意思的现象：流量在第一跳R2就被“拐弯”了，最终路径完全由PBR决定，网络上所有传统路由选路规则都退居二线。

4.3 PBR的调试思路：为什么流量不按策略走

PBR实验最常见的现象是：“配置完成后，策略一点效果都没有”，所有流量还是按老路径转发。这个坑90%的初学者都踩过，而且踩进去之后感觉天都塌了。我列一下完整的排查步骤，每一步都照着做：

第一步查接口方向。PBR只能应用在入方向，你如果配在出方向，华为设备会直接报错，但你别以为报错就停了，有些版本会静默失效，流量照走，策略无感，很多人就在这一步卡住。确认接口inbound命令敲进去了。

第二步查匹配条件。用display traffic classifier statistics查看分类器的命中计数，如果命中计数为0，说明ACL没有匹配到流量，这时候去看ACL里规则的顺序和通配符掩码，最常见的问题是源网段子网掩码换算错了，把/24写成了0.0.255.255，导致匹配范围比预期大了无数倍。

第三步查下一跳。redirect ip-nexthop指定的地址必须是路由器本地直连路由表中的可达地址。如果你指定的下一跳在路由表里没有条目，PBR不会报错，而是把所有流量都“扔掉”，表现为断网。这比策略失效还恐怖，因为外部表现为链路中断，你会先去查链路、查接口，根本想不到是PBR在作祟。

第四步确认PBR和路由表的优先级顺序。设备和转发流程中，入方向PBR的优先级高于路由表，所以它是一把“先斩后奏”的利器；但我还是建议你在设计中尽量保持“策略兜底，路由为主”的思路，让大部分流量走正常路由，PBR只处理那10%需要特殊分流的场景，这样故障时好回退、好排查。

5. 验证方法与排查技巧实录

5.1 常用验证命令：一眼看出策略是否生效

整套实验做完，验证是最后一道工序，也是考试一般不会明说却最值钱的部分。华为设备上我常用的命令是这些，建议你全部敲一遍，并记录输出对比：

# 查看路由表是否安装预期路由 display ip routing-table # 查看ACL匹配计数 display acl 3001 # 查看流策略应用记录和命中次数 display traffic policy applied-record display traffic classifier statistics # 查看Route-Policy内部匹配情况 display route-policy # 查看OSPF协议路由和LSDB状态 display ospf routing display ospf lsdb

这条命令组合的核心价值在于“从匹配到落地全程可观测”。比如你在Route-Policy里配了if-match和apply，但不知道究竟匹配了哪几条路由、应用了哪个属性，display route-policy会告诉你每个节点的匹配状态，display ip routing-table会告诉你最终结果，两层一对比，问题锁定就快了。

另外强烈建议你养成抓包的习惯。PBR实验出问题时，用Wireshark或华为的报文统计功能在R2的入接口和出接口各抓一次包，对比报文的IP头——尤其注意源地址和下一跳MAC地址的变化，很多时候策略明明命中了，但因为流量被正常转发，只是你没看到效果。抓包的直观性远超命令行，一次失败实验配上抓包记录，排查效率翻倍。

5.2 常见问题速查表：路由策略实验的“避坑手册”

我把这些年做实验和带新人时踩过的坑整理成一张速查表，贴在工位上，每次做实验前扫一眼，至少能帮你省下大半天的排查时间：

这里特别把“OSPF过滤后LSDB仍能看到路由”单独拎出来说。链路状态协议的特点是“所见即所得”，邻居间同步的是LSDB，不是路由表；你在入方向做filter-policy，禁止的只是把某条路由“安装”到本地路由表，LSA依然会收到、依然会存进LSDB。实验时如果你只看了display ospf lsdb就以为过滤失败，可能还要再花半个小时怀疑人生。这个知识点在BGP里同理，理解“路由表”和“协议数据库”是两回事，对以后的排障非常有帮助。

5.3 进阶扩展：路由策略还能这么玩

基础实验跑通后，如果你想继续深挖，有几个方向我强烈推荐。第一个是BGP环境下的路由策略，一台路由器连接两个AS，通过Route-Policy控制引入的AS路径、设置LOCAL_PREF和MED属性，然后观察BGP选路的变化，这套能力在大规模网络中非常实用。第二个是双出口环境下，把PBR和NAT结合，内网两个网段分别走两条出口链路，并分别做源NAT，实现出口负载均衡和故障快速切换，这也是中小型企业网络的常见需求。

第三个方向是策略打标签后联动其他技术。我最推荐的是把路由策略实验和“路由引入加Tag、再用Tag做过滤”结合起来，这也是生产环境中最经典的“一次打标、多处引用”套路。先给特定路由打个internal tag，然后在边界设备上再用if-match tag过滤，只放行带标签的路由；后续要调整策略时，只需要改一个标签，不用翻遍整个设备集群改几十条ACL。这个思路会让你真正理解“路由策略不只是写几行命令，而是在设计一套控制逻辑”。

我个人在实际操作中的体会是：路由策略和PBR这类实验，不要指望“配完就完”，更不要指望“照抄命令就能懂原理”。每次实验前花十分钟想清楚这个策略要解决什么问题——是过滤路由、修改属性、还是重定向流量；实验后把display命令的输出截图保存，再写一句“为什么”的注释，积累两周后你会发现，排障速度和理解深度都上了一个台阶。最后再分享一个小技巧：所有实验尽量先用eNSP或EVE-NG这类模拟器反复跑通，再考虑在物理设备上落地；模拟器里随便怎么折腾都不会有现实代价，但你在模拟器里养成的“先验证后上线”的习惯，到了生产环境里是真的能救命的。