【Infoblox实战】DNS拓扑负载均衡失效？一次完整的排障记录与解决方案

📅 2026年05月12日 | 🏷️ Infoblox+NIO实战 | 🔧 故障排查系列

在企业网络架构中，Infoblox 与 F5 GTM 的联动是实现全局负载均衡的标准方案。本文记录了一次完整的拓扑负载均衡（Topology LB）失效排障过程，涵盖从 DNS 查询转发到 GTM 匹配的全部关键配置点，适合企业网络运维工程师参考。

🔍 问题描述

客户环境为 EVE-NG 模拟器，架构如下：

• 终端网段 12.12.12.0/24（模拟 DCA 站点）
• 终端网段 13.13.13.0/24（模拟 DCB 站点）
• DNS 转发器：Infoblox（NIO）
• GTM：F5 BIG-IP 15（WideIP + 拓扑记录）
• 期望：12.x 网段解析到 DCA 池，13.x 网段解析到 DCB 池

实际测试中发现，无论从哪个网段发起查询，GTM 均返回 Round Robin 结果，未按拓扑规则匹配预期的数据中心。

📋 排障过程

第一步：确认 GTM 收到的查询来源

在 GTM 上使用 tcpdump 抓包：

tmsh /util tcpdump -i CMB_Vlan -n port 53 -c 100

抓包结果显示，GTM 收到的 DNS 查询来源 IP 为 12.12.12.2（终端真实 IP），而非 Infoblox 的出口 IP。这说明终端直连 GTM 时，GTM 可以看到真实客户端 IP。

第二步：检查拓扑记录配置

# 查看拓扑记录
tmsh list gtm topology

# 输出：
gtm topology ldns: region /Common/DCA_regions server: pool /Common/web_DCA {
    order 1
}
gtm topology ldns: region /Common/DCB_regions server: pool /Common/web_DCB {
    order 2
}

拓扑记录使用了 region 模式（基于地理位置或自定义区域），而非直接的 subnet 模式。

第三步：检查 Region 定义

# 查看 Region 配置
tmsh list gtm region DCA_regions
tmsh list gtm region DCB_regions

# 输出：
gtm region DCA_regions {
    region-members {
        subnet 12.12.12.0/24 {}
    }
}
gtm region DCB_regions {
    region-members {
        subnet 13.13.13.0/24 {}
    }
}

Region 定义正确，包含了对应的 /24 网段。

第四步：检查 WideIP 的 LB Mode

# 查看 WideIP 配置
tmsh list gtm wideip a shibaolong.com

# 输出：
gtm wideip a shibaolong.com {
    pool-lb-mode topology
    pools {
        web_DCA { order 0 }
        web_DCB { order 1 }
    }
    topology-prefer-edns0-client-subnet enabled
}

发现问题！ WideIP 的 pools 中设置了固定的 order 值（order 0 和 order 1）。这会导致 GTM 在拓扑匹配之前就按照 pools 的 order 顺序选择池，完全绕过了拓扑记录。

第五步：检查 Pool 的 LB Mode

# 查看 Pool 配置
tmsh list gtm pool a web_DCA
tmsh list gtm pool a web_DCB

# web_DCA 输出：
gtm pool a web_DCA {
    alternate-mode    topology
    fallback-mode    topology
    load-balancing-mode topology
    members {
        DCA-INT-gsbankchina.com:/Common/Web_Ct_VS {
            member-order 0
        }
    }
    monitor min 1 of { http }
}

# web_DCB 输出：
gtm pool a web_DCB {
    alternate-mode    topology
    load-balancing-mode topology
    members {
        DCB-INT-gsbankchina.com:/Common/web_VS {
            member-order 0
        }
    }
    monitor min 1 of { http }
}

两个池的 load-balancing-mode 均已设置为 topology，这是正确的。

⚠️ 根本原因分析

根据 F5 官方文档，BIG-IP GTM 的拓扑负载均衡有两种实现方式：

本案例中 WideIP 使用了 pool-lb-mode topology，但 pools 中设置了固定的 order 值，导致 GTM 按照 pools order 而非拓扑规则选择池。

✅ 解决方案

方案一：清除 WideIP pools 的 order（推荐）

删除 pools 中固定的 order 值，让拓扑记录完全控制池的选择：

# 删除带 order 的 pools
tmsh delete gtm wideip a shibaolong.com pools { web_DCA }
tmsh delete gtm wideip a shibaolong.com pools { web_DCB }

# 重新添加（不带 order）
tmsh create gtm wideip a shibaolong.com pools add { web_DCA }
tmsh create gtm wideip a shibaolong.com pools add { web_DCB }

# 验证结果
tmsh list gtm wideip a shibaolong.com
# 应显示：
# pools {
#     web_DCA
#     web_DCB
# }
# （无 order 值）

方案二：改用 Pool 级拓扑（替代方案）

将 WideIP 的 LB Mode 改为 round-robin，由各 Pool 自身使用 topology 模式：

# WideIP 改回 round-robin
tmsh modify gtm wideip a shibaolong.com pool-lb-mode round-robin

# Pool 的 load-balancing-mode 保持 topology（已经是了）
# 确认 web_DCA 和 web_DCB 配置
tmsh modify gtm pool web_DCA load-balancing-mode topology fallback round-robin
tmsh modify gtm pool web_DCB load-balancing-mode topology fallback round-robin

方案二是 F5 官方推荐的用法，稳定性更高，推荐生产环境使用。

🔬 补充：LDNS 与 ECS 的区别

拓扑记录中的 ldns（Local DNS）指的是 GTM 收到的 DNS 查询的来源 IP，即 DNS 转发服务器的 IP，而非终端真实 IP。

• 直连 GTM：ldns = 终端真实 IP → 拓扑正常匹配
• 经 Infoblox 转发：ldns = Infoblox 出口 IP → 需要开启 ECS Forwarding 才能传终端真实 IP

如果使用 Infoblox 作为转发器，需要在 NIO 上开启 ECS（EDNS Client Subnet）功能，才能让 GTM 收到原始客户端 IP：

# Infoblox Grid DNS Properties → Queries
✅ Enable Recursive ECS
✅ Enable ECS Forwarding
IPv4 Source Prefix: 32  （传完整 /32 IP）
# 保存后 Restart DNS

📋 总结

• 拓扑记录 ldns: region 需要配合正确的 Region 定义使用
• WideIP 使用 topology 模式时，pools 中不要设置固定 order
• Pool 级拓扑（WideIP: round-robin / Pool: topology）是更稳定的方案
• 经 Infoblox 转发时需开启 ECS Forwarding，才能传递真实客户端 IP
• 使用 tcpdump 抓包是验证 GTM 拓扑匹配最直接的方法

📢 本文基于真实排障经历整理，献给所有在企业网络运维路上奋斗的工程师。
返回首页 | 安全分类