MSR3620（Comware7）PBR 负载分担不生效，node20 流量全部走 Dialer0

你的错误配置：

核心问题 1：命令语法错误（最主要原因）

apply loadshare output-interface 后面不能再分行写多条apply output-interface，这种写法不识别多出口负载分担；Comware7 的 PBR 策略路由，多出口负载分担的正确写法是在一条apply loadshare output-interface后面一次性跟多个出接口。

你当前配置等价于：先开启 loadshare 标记，第一条 apply output-interface Dialer0 被优先解析，后面 G0/0 被忽略，所以永远只走 Dialer0，不会负载分担。

❌错误写法（你现场）

✅正确写法

核心问题 2：PBR 负载分担默认基于五元组哈希，会话保持（流粘性）

同一个源目 IP + 端口的一条 TCP/UDP 长连接，全程固定走同一条链路，不会包包轮询。

现象：测试的时候如果只开 1 条长连接，永远只走 Dialer0；必须多源 / 多目的多流，才能看到分流。 哈希算法默认：hash-mode sip-dip-sport-dport-protocol（五元组）。 可以修改哈希因子，比如改为仅源 IP 哈希，同网段不同终端更容易分流：

核心问题 3：Dialer 接口（PPPoE 拨号）的特殊限制

Dialer 是虚拟拨号接口，使用 PBR apply loadshare output-interface 把 Dialer + 物理 GE 一起做负载分担有两个坑：

1. Dialer 接口必须保证拨号在线，Dialer 接口协议 up；如果 PPPoE 掉线，负载分担会自动切换到存活接口；
2. PBR 负载分担是转发层面重定向，不会自动处理 NAT！两个出口必须分别配置 NAT，否则 G0/0 出去的流量无法做地址转换，能分流但是业务不通。

⚠️重点：PBR 只是控制出接口，不会自动选对应出接口的 NAT，必须基于出接口做 NAT 策略。

核心问题 4：ACL、策略应用位置检查

1. acl 3002，确认匹配的流量确实命中 node20：

看 node20 的 hit 计数是否在增长；如果 hit=0，ACL 匹配失败，流量直接走普通路由表。 2. PBR 必须应用在内网入接口（流量进入路由器的方向），不能应用在外网出口接口。

完整修正后配置

配套检查命令

补充：故障排查顺序

1. 修改 PBR node20 的apply loadshare为正确单行多接口格式，保存。
2. 查看display policy-based-route fenliu statistics确认 node20 有报文命中。
3. 确认 Dialer0 PPPoE 在线、G0/0 外网链路正常。
4. 确认两个出口都配置对应的 NAT。
5. 多台终端同时上网测试（单条流不会切换链路，属于正常机制）。

备选方案（推荐生产双出口，比 PBR 负载分担更稳定）

MSR3620 推荐用NQA + 静态路由 + 等价路由 ECMP做双出口负载，自带链路健康检测，链路故障自动切流；PBR 的 loadshare 在混合 Dialer 虚拟接口场景下稳定性弱于 ECMP。

简短总结

1. 语法错误：多条apply output-interface分行写，后面接口无效；正确写法apply loadshare output-interface Dialer0 GigabitEthernet0/0写在一行。
2. PBR 负载分担是按流（五元组）分担，不是按数据包轮询，单条长连接不会切链路，多终端才能看到分流。
3. Dialer 虚拟接口 + 物理 GE 做 PBR 负载分担，两个出口都要配置 NAT；PBR 只管出接口，不会自动匹配 NAT。
4. 用display policy-based-route fenliu statistics看命中计数，确认流量是否匹配 node20。

你的观察是准确的，在当前的 PBR 配置下，流量确实不会在 Dialer0 和 GigabitEthernet0/0 之间做负载分担。问题的根源在于，对以太网接口（GigabitEthernet0/0）使用 apply output-interface 是无效的，这导致了负载分担逻辑无法成立。

为什么 loadshare 没有生效？

H3C 的策略路由中，apply output-interface 和 apply next-hop 的使用场景有严格区分：

• 对于以太网接口：必须使用 apply next-hop 来指定下一跳 IP 地址，不能直接用 apply output-interface 指定出接口。系统无法为一个以太网接口“直接”指定出接口，它需要明确的下一跳 IP 来解析二层地址（ARP）。

• 对于 PPP 类接口（如 Dialer）：可以使用 apply output-interface，因为 PPP 是点对点协议，不需要下一跳 IP。

你的 node 20 中混合使用了两种接口类型：

由于 GigabitEthernet0/0 的 output-interface 配置无效，系统实际上只识别到了一个有效的出接口 Dialer0。loadshare 命令的前提是需要有多个有效的下一跳或出接口。只有一个有效出接口时，负载分担自然无法启动，所有流量都从 Dialer0 发出。

如何修正配置

方案一：改为 apply next-hop（推荐）

将 GigabitEthernet0/0 的配置改为指定其下一跳 IP。假设 GigabitEthernet0/0 连接的对端网关 IP 为 x.x.x.x：

注意，当混合使用 output-interface 和 next-hop 时，loadshare 命令需要同时指定 output-interface 和 next-hop，或者根据实际情况调整。更清晰的做法是，如果两个出口都可以用下一跳表示，就统一使用 next-hop：

但 Dialer 接口的对端 IP 可能是动态的，所以混合使用是常见的。正确的混合配置格式应为：

这样系统才能识别到两个有效的转发路径。

方案二：调整快速转发表项

在某些场景下，即使配置正确，快速转发（Fast Forwarding）也可能导致负载分担行为不符合预期。可以尝试在系统视图下关闭快速转发的负载分担功能：

该命令可以避免因快速转发表项导致的路径选择异常，但在某些网络拓扑中可能会引入三层环路风险，建议在测试环境验证后使用。

替代思路：基于用户的负载分担

如果 PBR 的负载分担配置始终难以达到预期，可以考虑使用 H3C 针对多出口场景提供的基于用户的负载分担功能。该功能可以在 Dialer 接口下直接开启，让系统自动根据用户（源 IP）进行负载均衡，无需复杂的 PBR 匹配规则。

这种方法配置更简单，适用于多个 PPPoE 出口的典型负载分担场景。

① 出接口 G0/0 必须有完整路由 + NAT

• GigabitEthernet0/0 这条出口，必须有默认路由 / 明细路由，不能只靠 PBR
• 两条出口都要配置 NAT，ACL3002 的网段在 G0/0 转发时，必须匹配 nat 策略，否则包出去回不来，你肉眼看到流量只走 Dialer0。

② Dialer 口特殊注意

Dialer 是虚拟拨号口，使用apply loadshare output-interface引用 Dialer 时：

• Dialer 接口状态必须Up；
• 拨号获取到公网 IP；
• 注意：PBR 指定出接口方式，不做 ARP 代理，G0/0 如果是静态 IP 直连运营商，必须确保对端可达；

建议优先用下一跳负载 apply loadshare next-hop x.x.x.x y.y.y.y，比直接绑定出接口更稳（Dialer 动态获取 IP 场景推荐 next-hop）

③ PBR 应用位置

PBR 要在内网入接口应用：ip policy-based-route fenliu

不是在外网出口接口。 本地路由器自身产生的流量，需要额外全局：ip local policy-based-route fenliu（内网用户不需要这条）

④ ACL 检查

acl 3002：确认是permit 内网需要负载的网段，没有 deny；display acl 3002看命中计数。

双出口都做缺省路由默认就是负载均衡

如果你是有规划的，A,段走1出口，B段走2出口

acl 3000     AB互访流量

rule permit source A des  B   

acl 3001

rule permit source A

acl 3002

rule permit source B

policy-based-route fenliu permit node 1
if-match acl 3000
policy-based-route fenliu permit node 2

if-match acl 3001

apply next-hop 1出口ip

policy-based-route fenliu permit node 3

if-match acl 3002

apply next-hop 2出口ip

然后接口下调用就行