华三 L5000 V7版本

PC 访问 10.42.15.x（默认公网 VRF 监听器） → GSLB 正常调度，可以解析新 VRF 对应的域名 VIP； PC 访问 79.42.3.245（新建 VRF 的 DNS 监听器） → 这条 VRF 对应的出口链路不参与调度、选路逻辑没有引用这条链路。 核心原理：L5000 V7 GSLB / 智能 DNS（入链路 ILB）是【DNS 监听器 VRF、链路 VRF、链路组、DNS 映射、VIP 虚服务】强绑定关系；不同 VRF 之间链路隔离，不会跨 VRF 调度链路H3C

一句话：10.42.15 属于默认公网 VRF，调度的是公网链路池；79.42.3.245 属于新 VRF，GSLB 会只在该 VRF 内部找可用链路、链路组、健康链路，不会复用公网 VRF 的链路。

一、按顺序排查（L5000 V7，命令 + Web 对照）

1. 检查【79.42.3.245 这个 DNS 监听器】本身 VRF 绑定（最高频）

Web：负载均衡→智能 DNS→DNS 监听器

• 确认监听器 79.42.3.245，VPN 实例是你新建的 VRF，不是 default 公网 CLI：

display loadbalance dns-listener 79.42.3.245

❌ 坑：很多人只新建 VRF、接口划入 VRF，但 DNS 监听器忘记选对应 VRF，监听器还在公网 VRF，报文匹配逻辑错乱。

2. 检查【新出口链路】配置：链路绑定 VRF + 链路状态 + 健康探测

Web：负载均衡→链路管理→链路

1. 这条 79 段出口链路，链路配置里 VPN 实例必须和监听器同一个新建 VRF；
2. 查看链路状态：display loadbalance link，状态必须是active；
   • 如果是 inactive/unknown：健康探测失败、下一跳不通、接口 down、VRF 内无路由；
3. 链路探测：探测对象、探测源 VRF 要匹配，探测源不能跨 VRF。

命令查看链路详情：

display loadbalance link link-name xxx verbose

重点看：VPN instance、Link status、Probe status

3. 检查链路是否加入【对应 VRF 的链路组 link-group】（最容易漏！）

GSLB 入方向智能 DNS 调度，链路必须加入链路组，DNS 映射引用链路组，游离的单独链路不会被调度。

关键点：链路组本身也归属 VRF；公网链路组在 default，新 VRF 要单独新建链路组，把 79 这条链路加到这个 VRF 内的链路组，不能加到公网链路组。

CLI 查看链路组成员：

display loadbalance link-group display loadbalance link-group xxx verbose

• 链路组 VPN 实例 = 链路 VRF = DNS 监听器 VRF，三者必须一致。
• 链路没加入同 VRF 链路组 → 链路永远不会被 GSLB 选中，就是你描述 “新链路没有被引用” 的典型现象H3C

4. 检查 DNS 映射（dns-map）绑定链路组 / 调度策略

Web：智能 DNS→DNS 映射（dns-map），你的域名条目：

1. 这个域名 DNS 映射，引用的链路组是不是新 VRF 内的链路组，而不是公网 default 链路组；
2. 调度算法、权重、链路可用性过滤；
3. 【VIP 虚服务器池】：SLB 虚服务（服务器负载均衡 VS）也要归属同一个新建 VRF！

GSLB 选链路之后，返回的 SLB-VIP，VIP 所在 VS 的 VRF 如果和链路 VRF 不一致，也会异常。

display loadbalance dns-map display loadbalance virtual-server

重点：SLB 虚服务器 vpn-instance 必须和链路、监听器 VRF 统一。

5. VRF 继承开关校验（V7 有这个隐藏坑）

全局负载均衡里有 VRF 继承（vrf-inheritance）

• 关闭继承：链路不写 VRF 就归属 default 公网；
• 开启继承：链路自动继承虚服务的 VRF；

建议多 VRF 场景手动给链路、链路组、监听器、VS 全部显式指定 VRF，不要依赖继承，继承容易出现跨 VRF 匹配异常H3C

display loadbalance global | include inheritance

6. 健康探测源 VRF 坑

链路的健康探测，探测源必须在本 VRF 内，不能拿 default 公网地址去探测新 VRF 的下一跳；跨 VRF 探测直接失败，链路状态变成 inactive，直接不参与调度。

二、为什么 10.42.15（default 公网监听器）能正常解析域名？

10.42.15 属于 default 公网 VRF：

• 监听器 VRF=default
• 链路在 default 链路组，状态 active
• dns-map 引用 default 链路组 调度逻辑正常，所以不管域名是哪个，公网侧请求进来可以正常选链路、返回 SLB 的 VIP。

这个现象不能证明新 VRF 配置没问题，两套 VRF 调度域是隔离两套独立调度平面，互不干扰。

三、验证定位命令，直接抓调度决策（核心排障）

1. 模拟 DNS 请求，看 GSLB 选路结果（V7 支持 debug/statistics）

#查看智能DNS统计，命中、拒绝、选路计数 display loadbalance dns statistics #查看链路调度统计，看这条79链路有没有命中计数（命中计数0=完全没被引用） display loadbalance link statistics

如果这条 79 链路的调度命中计数器一直是 0：说明dns-map 根本没有引用包含它的链路组，或者链路状态 inactive，被过滤。

2. 打开调试（业务窗口，谨慎使用）

debugging loadbalance dns-map debugging loadbalance link-selection terminal debugging terminal monitor

用 79.42.3.245 作为 DNS 服务器去 nslookup 域名，看日志：

• 能不能匹配到 dns-map
• 匹配到的链路组是哪一个
• 链路状态检查是否 pass
• 选路算法候选链路列表（这里就能看到这条链路有没有进入候选池）

四、常见错误汇总（对照自查）

1. ✘ 新建链路 VRF 填了，但是没加到同 VRF 的链路组 → 游离链路，不会参与 GSLB 调度（最高概率）
2. ✘ 链路加入了【公网 default 链路组】，链路本身 VRF 是新 VRF → VRF 不匹配，链路直接跳过
3. ✘ DNS 映射 dns-map 引用的还是公网链路组，没有新建新 VRF 的 dns-map 条目
4. ✘ 79.42.3.245 监听器 VRF 配置错误，监听器还在 default
5. ✘ 链路健康探测失败，链路状态 inactive，调度直接剔除
6. ✘ SLB 虚服务器 VS 的 VRF 和链路 VRF 不一致，选路成功但 VIP 返回异常

五、最简正确模型（多 VRF 入链路 GSLB）

每一套 VRF 是一套独立平面，一一对应： DNS 监听器（VRF-A） → DNS 映射（引用链路组 A，VRF-A） → 链路组 A（VRF-A） → 成员链路（VRF-A） → SLB 虚服务 VS（VRF-A）

在L5000 V7上，全局负载均衡（GLB）的监听地址是否生效，取决于该地址是否被正确关联到对应的VRF和链路。你提到新出口链路未被引用，且新VRF的监听地址79.42.3.245“像没有用上”，排查思路如下：
1. 检查GLB监听地址配置
确认79.42.3.245是否已配置为GLB的监听地址，并绑定到新VRF：

display loadbalance global-server // 查看全局服务器及监听地址
display loadbalance virtual-server // 查看虚拟服务绑定的VRF

若监听地址未绑定VRF，默认在公网VRF，新VRF的流量无法命中。
2. 检查VRF与接口/链路的关联
新出口链路是否已加入新VRF：

display ip vpn-instance // 查看VRF实例
display interface brief // 确认新链路接口状态及VRF归属

若接口未绑定VRF，即使监听地址配置了VRF，回包路由也不通。
3. 检查路由及NAT
新VRF内是否有到监听地址网段的路由，以及源地址转换是否匹配新链路：

display ip routing-table vpn-instance <新VRF名>
display nat session verbose | include 79.42.3.245

若DNS请求从新链路进入，但回包走默认VRF，会导致解析失败或行为异常。
4. 抓包验证
在PC侧或设备上抓包，看DNS请求是否到达79.42.3.245，以及响应从哪个接口发出：

debugging ip packet vpn-instance <新VRF名> acl <匹配DNS>

或使用packet-capture功能直接抓取接口流量。
5. 检查GLB策略引用
确认GLB的调度策略、健康检查是否关联了新VRF的链路：

display loadbalance policy
display loadbalance link

若新链路未加入GLB的链路组，监听地址即使配置也不会参与调度。
常见原因：新VRF未在GLB监听地址中显式指定，或新链路未加入GLB的链路池，导致流量仍走默认VRF。建议先执行上述display命令，重点看监听地址的VRF归属和链路引用状态。