企业官网建设流程全解析

做路由策略实验的人很多，但真正把“路由策略”和“策略路由”掰扯清楚、能把实验做到位的人，说实话不多。我去年做一次割接演练时，就因为在"过滤路由"和"引导流量"这两个需求上选错了工具，结果明明是同一张拓扑，调了大半天才发现思路从一开始就偏了。这篇文章就是基于那次经历，以及之后我反复搭建的"路由策略实验练习"环境，把完整的实验思路、配置细节、验证方法和踩坑点全部梳理出来。适合刚学完基础路由协议、准备上手动手做实验的网工，也适合那些理论上懂个大概、但一敲命令就找不到北的朋友。

顺便说一句，这几年大家都在提PBR策略路由，这确实是热点，但如果你连Route-Policy和PBR各自的适用场景都没分清楚，盲目跟风上策略路由，反而会把组网弄得极其复杂。所以这篇文章不只是操作手册，更是一份"决策手册"。

1. 路由策略与策略路由：实验前必须想明白的两条路

先说一个最常见的误解：很多人以为"路由策略"就是"策略路由"，反正都是"策略"，差不多。但我可以负责任地告诉你，这两个东西解决的是完全不同的两类问题，实验设计思路也完全不同。

路由策略（Route-Policy / Filter-Policy）的核心动作是"过滤"和"修改属性"。它管的是路由表本身，比如我通过BGP从邻居学到100条路由，我只想留10条进路由表，其他90条扔掉；或者我学到的路由cost是50，我想把它改成200再去参与选路。这时候用路由策略。

策略路由（PBR，Policy-Based Routing）的核心动作是"改路"，但它不管路由表，它直接绕过路由表，基于流量的特征（源地址、目的地址、协议、端口等）强行指定下一跳。最典型的场景是：我有两条出口链路，想按照"源IP"来分流，比如办公区走运营商A，服务器区走运营商B。传统的路由表只能按目的地址查，做不到按源地址选路，这时候PBR就登场了。

打个比方。路由策略就像公司HR在筛简历：收到的应聘邮件（路由）先过一遍过滤器，符合条件（permit）的留下进入人才库（路由表），不符合的（deny）直接丢弃，还可以给留下的简历打上不同的等级标签（修改属性）。策略路由则像前台接待员：他来办事，不看你的简历，直接根据你今天穿什么颜色的工牌（流量的源地址、端口特征），把你引导到对应的办事窗口。简历内容（路由表）根本不重要。

这个区别直接决定了实验拓扑怎么搭。如果是练路由策略，你得搭一个能传播大量路由的环境，核心观察点是"路由表里到底进了哪些条目"。如果是练PBR，你得搭一个多出口的环境，核心观察点是"流量实际走了哪条物理链路"。

我见过不少实验练习者，拓扑里就两台路由器直连，每条链路就两三条路由，然后试图练Route-Policy的过滤——能练，但效果很差，因为路由太少，permit/deny之后看不出区别，几个节点匹配的感觉完全建立不起来。所以实验环境的设计要贴合你想验证的那条原理。

2. 实验环境搭建：用EVE-NG还是真机，拓扑怎么画

工欲善其事，必先利其器。路由策略实验的载体，我首推EVE-NG，其次GNS3，要是条件所限用华为eNSP也没问题。真机当然也行，但真机动不动就是三层设备，端口少、价格高，做多路由器互联实验很受限制。

我用的是EVE-NG跑华为vEOS镜像（AR1、AR2、AR3）+ 三台Cloud连接虚拟主机。拓扑如下：

• R1：模拟局域网内部路由器，连接两个业务网段A（192.168.10.0/24）和B（192.168.20.0/24）
• R2：核心路由器，同时连接R1和两个"上游出口"——ISP1方向（模拟运营商A）和专线方向（模拟总部专线）
• R3：模拟ISP1侧路由器，提供一些公网路由和一个"外网服务器"网段

这个拓扑的精妙之处在于：R2正好处在一个"多路由来源+多出口"的位置，既能练路由策略（从R3学到的路由怎么过滤、怎么改属性），又能练PBR（来自R1不同网段的流量如何分别走两条出口）。一张拓扑，两个实验共用，省事。

在EVE-NG里，我习惯给设备配好管理地址（通常是192.168.100.x），用SecureCRT批量打开窗口。这一步看起来很基础，但实际做实验时窗口多了很容易乱，我的技巧是把每台设备的标签写清楚，比如"R2-CORE"、"R3-ISP1"“R1-LAN”，窗口底色也设置不同，一眼就能对上。

实验前先把三台路由器的基础配置完成：接口IP、loopback、OSPF或者ISIS把二个网段宣告进核心。R1和R2跑OSPF，R2和R3之间跑BGP（模拟运营商间互联），这样能同时体会动态协议里路由策略的用法。注意，R2到R3之间起BGP是为了后面实验BGP路由策略（比如AS号过滤、cost修改），如果你只练PBR，那R2和R3之间跑静态路由也行，灵活调整。

拓扑完成后，第一件事不是急着配策略，而是先看"没有任何策略时流量怎么走"。这一步很关键：你得先有一个干净的baseline，知道默认路径长什么样，后面策略下发后才有对比。

从R1去往R3方向的服务器，默认走哪条路？取决于R2的路由表里哪条路由更优。如果R2到ISP1和到专线的两条路由都是直连线路，OSPF和BGP在选路时会按协议优先级、cost来定，最终大概率是走OSP或BGP学到的某一条。这个默认行为记录下来，后面所有实验的对比都以这个为基准。

3. 实验一：用IP前缀列表和Route-Policy过滤路由，先把"路由表"管起来

这个实验的目标很朴素：R2从R3通过BGP学到了一批路由，我们只允许其中一部分进入R2的路由表，或者在学习的同时修改它们的cost和community值。这属于典型的路由策略（Routing Policy）范畴。

3.1 为什么用ip-prefix而不是ACL来匹配路由

很多人做路由过滤，一上手就写access-list，这是个习惯性问题。ACL在设计之初主要是匹配报文用的，对路由条目的匹配支持并不是先天优势，尤其是在匹配"前缀长度精确范围"时，ACL极其别扭。而IP前缀列表（ip ip-prefix）天生就是干这个的，它支持"匹配某前缀+匹配掩码长度范围"，我们看一个例子：

[R2] ip ip-prefix ALLOW index 10 permit 192.168.10.0 24

这条命令的意思是：只匹配前缀192.168.10.0、且掩码长度为24位的路由条目。如果想匹配掩码在24到28之间的路由，可以写：

[R2] ip ip-prefix ALLOW index 10 permit 192.168.10.0 24 less-equal 28

这里的less-equal 28就限定了掩码长度上限。ACL如果要实现同样的功能，你得针对每个掩码长度写一条rule，繁琐且容易漏。所以我的建议是：路由匹配统一走ip-prefix，ACL留给PBR或数据流匹配用。

3.2 Route-Policy的结构化配置：node与if-match的关系

配置Route-Policy时，华为的语法让我一度很困惑，后来想通了就不难了。它的核心结构是"节点（node）+匹配条件（if-match）+动作（apply）"：

route-policy ONLY-A permit node 10 if-match ip-prefix ALLOW apply cost 100

这里有几个点必须说清楚：

• node 10不是优先级数值，而是节点的编号，用于排序。匹配时从最小的node开始，从小到大逐个检查。匹配到node 10且条件是permit，就执行apply并结束。
• permit/deny的作用和ACL不同。在Route-Policy中，permit表示"允许这条路由通过策略"，deny表示"拒绝这条路由进入下一环节"（比如不进路由表）。但注意，如果某个node是deny，而且没有匹配到它之前的所有节点，那路由会被拒绝。
• 如果在一个node里写了if-match但路由不匹配该条件，策略不会直接结束，而是跳到下一个node继续判断。这个"跳转"行为很多人第一次做实验时会忽略，导致"为什么写了permit node 10之后，其他路由也进去了"的困惑。

我们把实验场景拆开来看。假设R2从R3收到如下路由：

• 192.168.10.0/24
• 192.168.20.0/24
• 192.168.30.0/24
• 10.1.0.0/16

我们只想让192.168.10.0/24和192.168.20.0/24进路由表，其余都拒绝。配置如下：

[R2] ip ip-prefix LAN10 permit 192.168.10.0 24 [R2] ip ip-prefix LAN20 permit 192.168.20.0 24 [R2] route-policy ONLY-LAN permit node 10 [R2-route-policy] if-match ip-prefix LAN10 [R2-route-policy] route-policy ONLY-LAN permit node 20 [R2-route-policy] if-match ip-prefix LAN20

注意，这里我写了两个node，都是permit。如果路由匹配node 10，就通过（apply没有写，所以不修改属性）；如果不匹配node 10，就跳到node 20再判断；如果两个node都没匹配上，这条路由会被隐式的deny拒绝。这就是华为策略末尾默认deny all的规则。所以不需要额外写一个deny node。

在BGP场景中，调用方式是在peer视图下：

[R2-bgp] peer 10.0.3.3 route-policy ONLY-LAN import

这样R2从R3（10.0.3.3）收到的所有路由都会经过该策略。实验时你可以用display bgp routing-table观察过滤前后的路由数量变化，用display ip routing-table看最终进路由表的条目。

3.3 修改路由属性：从"过滤"到"影响选路"

路由策略的另一个大用途是修改路由属性。比如我希望从R3学到的一条路由cost变成500，以便让R1日后选路时不走这条路径，但又不希望完全删除它——这时候可以用apply cost。

[R2] route-policy SET-COST permit node 10 [R2-route-policy] if-match ip-prefix LAN10 [R2-route-policy] apply cost 500

如果是在BGP里，还能改local-pref、MED、community等。实验时我建议三件套都试一遍：

• apply cost 500：影响IGP选路（OSPF里对应改cost）
• apply local-preference 200：影响BGP选路（越大越优，默认100）
• apply community 100:200：给路由打团体标签，为下游设备做二次策略匹配提供依据

做完修改动作后，在R2上display bgp routing-table 192.168.10.0 24能看到local pref等属性变化，这就是策略生效的直接证据。写实验报告时，这些前后对比数据非常有说服力。

4. 实验二：PBR策略路由实战，从"看路由表"到"强行改路径"

这一部分就是热搜词里提到的PBR策略路由。PBR的核心概念我已经在第1部分讲过了，现在直接进入实验。沿用上面的拓扑：R1下面带着网段A（192.168.10.0/24）和网段B（192.168.20.0/24），R2连着两条出口，一条走10.0.2.2（ISP1方向），一条走10.0.3.2（专线方向）。

需求：网段A的所有流量走ISP1方向，网段B的所有流量走专线方向。用传统路由表实现吗？不可能，因为传统路由表里查目的地址，A和B访问同一个目的地址，下一跳必须相同。只有PBR能实现这种基于源地址的选路。

4.1 华为的流分类三板斧：ACL + 流分类 + 流行为

华为设备上做PBR，通常用traffic classifier（流分类）+ traffic behavior（流行为）+ traffic policy（流策略）三位一体。步骤拆开看其实不复杂：

第一步：用ACL识别源网段

[R2] acl number 3001 [R2-acl-adv] rule 5 permit ip source 192.168.10.0 0.0.0.255 [R2-acl-adv] acl number 3002 [R2-acl-adv] rule 5 permit ip source 192.168.20.0 0.0.0.255

这里用高级ACL匹配源地址，0.0.0.255是通配符，相当于只关心前三段。

第二步：定义流分类（Classifier）

[R2] traffic classifier C-A [R2-classifier-C-A] if-match acl 3001 [R2-classifier-C-A] traffic classifier C-B [R2-classifier-C-B] if-match acl 3002

第三步：定义流行为（Behavior）——指定下一跳

[R2] traffic behavior B-ISP1 [R2-behavior-B-ISP1] redirect ip-nexthop 10.0.2.2 [R2-behavior-B-ISP1] traffic behavior B-MPLS [R2-behavior-B-MPLS] redirect ip-nexthop 10.0.3.2

注意，这里redirect ip-nexthop的地址必须保证是直连可达的（否则PBR无法解析下一跳），这也是实验中最容易翻车的地方：下一跳写了一个非直连地址，策略配置了却不生效。

第四步：配置流策略（Policy）并应用到接口

[R2] traffic policy PBR-POLICY [R2-policy-PBR-POLICY] classifier C-A behavior B-ISP1 [R2-policy-PBR-POLICY] classifier C-B behavior B-MPLS [R2] interface GigabitEthernet0/0/0 [R2-GigabitEthernet0/0/0] traffic-policy PBR-POLICY inbound

关键点来了：PBR的应用方向是inbound还是outbound？这取决于流量从哪个接口进入设备。我的拓扑中，R1的流量从R2的GigabitEthernet0/0/0进入，所以在那个接口上应用inbound方向的策略。如果说反了，策略永远不会被匹配。这个细节我见过太多人栽过跟头，写实验报告时一定要把这个方向搞明白。

4.2 思科路由器的PBR对照：route-map的简洁风格

如果你手边的是思科设备，实现同样的需求配置会更简洁：

interface gigabitethernet0/0 ip policy route-map PBR-POLICY ! access-list 101 permit ip 192.168.10.0 0.0.0.255 any access-list 102 permit ip 192.168.20.0 0.0.0.255 any ! route-map PBR-POLICY permit 10 match ip address 101 set ip next-hop 10.0.2.2 route-map PBR-POLICY permit 20 match ip address 102 set ip next-hop 10.0.3.2

思科的route-map逻辑和华为的traffic policy逻辑异曲同工，但语法上route-map在一个节点里同时有match和set，语义更像"如果匹配条件，那么就执行动作"。思科的策略同样要应用到接口的inbound方向。

如果是H3C设备，PBR的NQA联动和递归下一跳很出名，配置风格又略有不同，但核心思路都是"匹配特征+指定下一跳"。

4.3 PBR不生效的三个典型原因

这个实验我做过十几遍，每次都有学生或同事问"为什么我配置了策略流还是按原来的路走"，我很确定问题基本出在这三处：

1. 下一跳不可达：redirect的地址必须是直连路由可解析的，设备不支持把流量扔给一个它无法路由到达的下一条。
2. 应用方向错误：PBR应用在数据流进入设备的那个接口的inbound方向，不是出接口方向的outbound。有些人的理解是"流量要往ISP走，那就应该在去往ISP的那个接口上做"，这个理解是错的。PBR必须在流量刚进设备、还没查路由表之前做决定。
3. ACL匹配的源方向搞反了：在R2接口的inbound方向做PBR，ACL里的source应该是来自R1的源地址（例如192.168.10.0/24），而不是目的地址。如果你写成了destination指向某个公网网段，大概率匹配不到。

还有一个容易被忽略的问题：PBR的匹配优先级是顺序匹配，先到先得。如果你的ACL 3001写成了一条permit ip any any，那后面的3002永远不会被查。所以规则顺序一定要小心。

4.4 PBR实验的验证方法：别只盯着ping

策略下发后，怎么验证真的走了指定链路？我推荐至少三种手段联合验证：

第一：traceroute路径法。从R1发起traceroute到10.0.2.2或一个远端网段，观察路径中R2之后的下一跳是谁。如果网段A的流量经过10.0.2.2而网段B经过10.0.3.2，基本能确认PBR生效。但要注意，traceroute不一定能直观看到R2之后的第二跳（有时只显示第一跳），需要在R2上开启icmp超时消息的发送权限。

第二：display traffic policy statistics。在R2上执行：

[R2] display traffic policy statistics inbound interface GigabitEthernet0/0/0

正常能看到C-A和C-B两个分类的匹配计数在增长。如果某个分类计数一直是0，说明ACL没匹配成功。

第三：接口计数器法。如果两个出接口都有计数功能，在R1上大流量ping或打流，同时观察R2去往两个出口方向的接口的Input/Output bytes变化。哪个接口的计数器涨得快，流量就走哪。这是最无语的"物理层验证"。

5. 实验三：PBR结合路由策略的混合场景，实现"先选路再改路"

题目叫"路由策略实验练习"，那我把两个内容交叉起来做一个更有代表性的综合实验。需求是这样：网段A的流量走ISP1方向，并且在ISP1方向学到的某条路由上，我们要把它的cost调高，使网段A流量到达R3后也不被认为是一条环路或较优路径。

这种混合场景在真实组网里很常见：既要有PBR按源地址分流，又要用Route-Policy影响某个方向上的路由优劣。两个策略是不同层面的：PBR在转发平面工作，Route-Policy在控制平面（路由协议）工作。

实验步骤可以分两块写：

块一：PBR分流（和实验二相同），把网段A送去ISP1。

块二：在R2与R3的BGP邻居上应用route-policy，对从R3方向学到的10.0.0.0/22之类的路由打上MED 200或community标记。这样一来，即使ISP1方向和专线方向同时学习到10.0.0.0/22，R2也会因为MED值不同而选择更低cost的一侧作为回程路径。

[R2] route-policy FROM-ISP1 permit node 10 [R2-route-policy] if-match ip-prefix TO-ISP [R2-route-policy] apply med 200 [R2-bgp] peer 10.0.3.3 route-policy FROM-ISP1 import

这里的IP前缀列表TO-ISP先定义好要匹配的10.0.0.0/22。

综合验证要点：

• 在主机侧 ping 服务器，观察来回路径的对称性
• 在R2上用display bgp routing-table查看MED对比
• 同时观察R2不同接口的流量计数

说实话，这个混合场景一出来，才算真正把"路由策略"和"策略路由"融会贯通了。很多面试题问得天花乱坠，其实就是考察你有没有跑通这种左右互搏的脑子。

6. 命令之外的辅助工具与调试技巧：让实验看得更透

实验做得好不好，往往不在配置本身，而在调试手段。我总结几个必须掌握的调试和排障技巧，这是普通教科书里不爱仔细讲的部分。

6.1 华为的debug和display组合拳

• display ip routing-table protocol bgp：只看BGP学到的路由，快速确认过滤结果。
• display bgp routing-table statistics：看BGP路由总数和过滤情况，能直观看到策略生效前后条数差异。
• debug ip packet（华为为debug ip packet，思科为debug ip policy）：PBR场景下，打开debug后能看到匹配ACL的报文动作。华为的debug ip packet输出很冗长，我建议结合ACL做过滤式debug，只关注特定源地址：

<R2> debugging ip packet acl 3001

这样只会打印源地址是192.168.10.0/24的报文，日志量小很多。

• display policy-based-route（早期版本叫display ip policy-based-route）：查看PBR配置和匹配次数。这个命令在某些版本上有差异，建议先display traffic policy查一下全局配置状态。

6.2 抓包：用Wireshark实锤转发路径

如果你想确认PBR真的把流量转给了某个具体的下一跳，更硬的证据是抓包。在EVE-NG的链路两端挂Wireshark，或者用Cloud连接真实网卡，抓取ICMP报文，看源目的IP对不对，看MAC地址是否下一跳设备的MAC。

我记得有一次调试一个PBR不生效的问题，display计数显示匹配了，traceroute结果也对不上，后来用抓包一看，下一跳虽然指对了，但出接口因为某种原因又做了一次路由表查询，结果绕了一大圈。这类"看似生效实则没生效"的隐性bug，只能靠抓包来确认数据面的真实走向。

6.3 用静态路由保底：给PBR一个"兜底出口"

在做PBR实验的拓扑里，我强烈建议先配置好静态默认路由（或OSPF/BGP兜底路由），确保在没有启用PBR时环境也能通。然后再下发PBR策略覆盖特定流量。这种"先全通，再局部改路"的渐进式验证思路，能极大降低实验排障难度。策略配错了，回退也比较简单——移除traffic-policy即可。

7. 延伸思考：从网络实验到Linux策略路由的相通性

如果你把路由策略实验练熟了，会发现Linux服务器上的策略路由逻辑和它几乎一模一样，只是名字不同。Linux用ip rule定义"策略"（rule），用ip route ... table X定义"路由表"（table）。

比如，实现"来自10.0.0.0/8的流量走table 10的默认路由"：

ip rule add from 10.0.0.0/8 lookup 10 ip route add default via 10.1.1.1 dev eth1 table 10

这条rule和华为的traffic classifier C-A if-match acl 3001本质上是同一个思路：先匹配流量特征，再指定转发规则。

我建议学习者在做完网络设备实验后，找一台Linux虚机把同样需求实现一遍。跨平台之后你会发现，所有策略类技术的底层思维是一致的：分类（classification）+ 动作（action）+ 应用位置（application point）。把握住这个三角，任何厂商的文档都能举一反三。

8. 实验报告怎么写：让一张拓扑讲清三类结论

最后聊一个容易被忽视的问题——实验记录。很多人实验做完，截图一截就完事了，但真正有价值的实验报告应该把"为什么"写清楚。

我的习惯是每个实验记录三件事：

1. 策略配置前后的路由表/bgp表对比：把display结果贴出来，标注出变化条目，这是"证据链"。
2. 一项原始需求对应一条配置逻辑：比如"让A网段走ISP1"，对应的就是ACL 3001里source是A网段、behavior把nexthop指向10.0.2.2。这样事后回看，每个配置都有据可查。
3. 验证方法及结果截图：至少包含display policy统计、traceroute路径、接口计数三张图。数字对比是实验报告的灵魂，没有验证的实验等于白做。

另外，每次实验结束时我都会把配置清理干净，重新回到baseline状态，再开始下一个实验。保持每次实验的"单变量原则"——只改动一个策略因素，其他都不变——这样得到的结论才可信。

这套"路由策略实验练习"的完整流程走下来，你基本就拥有了独立设计、调优和排障的能力。别再对着厂商白皮书死记硬背了，拓扑搭起来，命令敲下去，你才能真正理解策略的路由世界是什么样。