负载均衡vpn路径问题

IRF 虽然管理面是一台设备，但报文物理转发还是分开在两台硬件框上，VPN（IPsec/SSL‑VPN）会话是硬件会话表，会话表 IRF 间同步，但出接口是物理硬件接口H3C。

1. 备框收到流量，必须跨 IRF 链路转发到主框出主干，VPN 极易会话不对称

• 下联 OSPF 会学习到路由，部分业务流量可能被 OSPF 哈希调度送到备设备进入；
• 但备框没有主干上行接口，VPN 封装报文只能走 IRF 堆叠链路跨到主设备，再从主设备主干接口发出；
• VPN 对入、出物理设备 / 路径对称敏感，跨框转发会出现：VPN 隧道能建立，但业务访问丢包、半边不通、隧道随机断流、NAT/IPsec 校验失败、ESP 报文异常丢弃。

2. 主设备整机故障，业务直接瘫痪，IRF 高可用失效

• 当前主干线缆仅接在 Master（主框）；
• 如果主设备整机断电 / 整机故障，IRF 会重新选举新 Master（原来备框升主），但是新主没有任何主干上行物理连线，所有 VPN、全部外网流量直接断；
• 下联 OSPF 邻居起来没有用，上行物理链路缺失，流量无出口，不会自动恢复，这是最大隐患H3C。

3. IRF 堆叠链路带宽压力大 大量流量跨设备（备→主）走 IRF 堆叠线缆，VPN 加密报文大包多，IRF 链路成为性能瓶颈，高负载场景丢包。
4. 路由层面现象：OSPF 邻居正常、路由表完整，但业务不通，只在 VPN / 经过 NAT 业务上体现，普通纯内网转发可能看不出问题。

✅ 可行整改方案（二选一，推荐方案 1）

方案 1（标准高可用，推荐）：主干上行双归，跨设备链路聚合

主干设备分别连线到 IRF主、备两台负载均衡物理接口，做静态聚合 / 动态 LACP 聚合。

• 聚合组成员包含主框接口 + 备框接口；
• OSPF 在聚合 VLANIF 上建立邻居；
• 无论流量落在 IRF 哪一台框，都可以本地直接上主干，VPN 报文入和出在同一台物理设备，路径对称；
• 主设备整机故障，聚合组自动剔除主框成员接口，备框继续承接主干流量，IRF 切换业务无损，VPN 会话可以平滑处理H3C。

这是 H3C IRF 官方标准组网：上下行都要跨成员做聚合，避免单向只接一台成员设备H3C。

方案 2 不改布线（临时妥协，不适合 VPN 生产环境）

如果物理布线无法新增主干到备框：

1. 配置冗余组 + track，监控主设备主干上行；主设备主干故障，强制整机业务倒换；
2. 但主设备整机硬件损坏场景依然不可用；
3. 必须保证所有业务路由全部强制走主设备，不能有流量落到备设备转发外网；
4. ⚠️强烈不建议 VPN 业务用这种模式，依然存在跨框 VPN 会话异常风险，只适合纯内网场景。

🧪 上线前验证测试（必做）

1. 手工 IRF 主备倒换：irf switchover，观察 VPN 隧道是否不断、业务访问正常；
2. 模拟主设备主干接口 shutdown，验证业务切换；
3. 模拟主设备整机断电，确认是否业务可用；
4. 抓包：看 VPN ESP 报文，确认入接口和出接口是否落在同一个物理框，避免大量跨 IRF 转发。

💡补充说明

你现在下联两组互联地址跑 OSPF 没问题，下联是双归的；短板完全在上行主干只接主框这一点，VPN 会放大这个缺陷，普通业务可能测试不出来，上线后高峰期会偶现故障。