H3C S12508-S public-VRF

、第二条静态路由配置错误（最高概率）

含义：往 TZJT 路由表里写一条静态路由：目的 10.28.1.0/24，下一跳 10.28.1.1，下一跳在公网（public）查找出接口H3C。

❌错误：10.28.1.1和交换机 Vlan‑if1000（10.28.1.254/24）同属公网网段，但 10.28.1.1 并不是本设备直连下一跳。

你本意：把公网直连网段10.28.1.0/24注入 TZJT 路由表；不需要写一个外部下一跳 10.28.1.1，该网段是本机公网直连路由。

✅正确写法（把公网直连路由泄露进 TZJT）：

不带下一跳，只加public参数；代表：去往 10.28.1.0/24，直接去公网路由表递归查找出接口，利用本机公网直连路由转发，不需要指定下一跳 IPH3C。

2、第一条路由也要检查

含义：公网路由表增加 10.40.10.0/24，下一跳 10.40.10.1，在 TZJT 实例查下一跳。

⚠️隐患：TZJT 内 Vlan‑if2010 直连是10.40.10.0/23；你写的是/24，路由掩码小于直连掩码，路由表会优选更长掩码的直连，本条路由可以存在，但建议改成匹配实际直连掩码10.40.10.0 23，避免路由掩码不一致带来混淆。

验证排查命令

注意：这种静态路由双向泄露方式，不受 vpn‑target import/export 控制；RT 只控制 BGP‑VPNv4 路由，静态跨 VRF 泄露跟 RT 无关。

完整修正配置

常见后续踩坑

1. 路由表看到路由，但是业务终端互 ping 不通：检查终端网关；TZJT 内终端网关需要指向 Vlan‑if2010（10.40.10.1）；公网终端网关指向 Vlan‑if1000（10.28.1.254）。
2. 设备自身能 ping 通两端网段，终端不通：确认终端没有 ACL / 防火墙拦截跨网段 ICMP。
3. 该方式仅实现本机 S12508‑S 上两个平面互通；其他交换机 / 路由器不会自动学习这部分泄露路由，需要在其他设备上手动补充路由。

原理回顾：ip route‑static vpn‑instance xxx x.x.x.x public不写下一跳时，目的网段直接到公网全局路由表递归出接口，适合泄露本机公网直连网段到 VRF 内H3C。

Public平面路由泄露不生效，核心问题通常出在路由命令的写法或下一跳地址的有效性上。

首先，你配置的从TZJT指向Public的路由ip route-static vpn-instance TZJT 10.28.1.0 24 10.28.1.1 public，其下一跳10.28.1.1必须在Public路由表（即全局路由表）中可达，并且该地址不能是设备自身的接口IP。如果10.28.1.1是设备自己的地址，这条路由会因“自己指向自己”而无效。同时，在Public侧的回程路由ip route-static 10.40.10.0 24 vpn-instance TZJT 10.40.10.1中，下一跳10.40.10.1也必须是TZJT VRF内真实可达的对端设备地址。

其次，注意命令中public关键字的位置。在H3C设备上，从VPN实例指向Public的静态路由，有时需要在命令末尾加上public，或者使用global参数来明确指定出接口属于公网实例。如果下一跳地址本身就在Public中，正确的写法可能是ip route-static vpn-instance TZJT 10.28.1.0 24 10.28.1.1 public。如果下一跳是一个未绑定VRF的全局地址，部分版本需要写作ip route-static vpn-instance TZJT 10.28.1.0 24 10.28.1.1 global。

另外，务必分别检查两个路由表来确认路由是否真正生成。在Public下执行display ip routing-table，在TZJT下执行display ip routing-table vpn-instance TZJT。如果路由没有出现，说明配置未生效；如果路由存在但流量仍不通，则需检查安全策略或NAT转换是否影响了VRF标签的传递。

如果静态路由方式反复调试无效，可以改用route-replicate命令在VPN实例的IPv4地址族视图下直接引入Public的路由，这种方式在某些场景下更可靠。