EIGRP在网络中出现路由丢失且本地无可行后继时，会向所有邻居发起查询。如果某些远端邻居因链路拥塞或设备性能问题无法及时回复，活跃状态就会进入Stuck-in-Active，导致相关路由长时间不可用。通过合理限制查询范围，可以让查询只在必要的邻居之间传递，从而缩短SIA计时器超时风险并加快收敛。下面我们使用Ruby语言构建一个简单的配置优化工具，自动分析拓扑并生成查询范围相关的优化配置。
理解EIGRP SIA与查询范围的基本原理
EIGRP的弥散更新算法依赖可靠的查询与应答机制。当某条路由的前继跳失效，路由器进入主动状态并向邻居发送Query报文。邻居若没有该路由的可行后继，会继续向外转发查询，这就形成了查询泛洪。如果网络层级较深，末端设备响应慢，中心路由器可能在SIA计时器（默认三分钟）内收不齐应答，从而将邻居重置。
查询范围优化的核心在于截断不必要的查询路径。常见手段包括将边缘路由器配置为EIGRP stub，或利用汇总路由屏蔽明细查询。Ruby脚本的价值是依据实际拓扑计算出哪些节点适合设为stub、哪些链路应当用summary阻断查询，而不是由工程师凭经验逐台登录设备修改。掌握这一原理后，我们才能把优化逻辑转化为代码。
从协议层面看，stub路由器不会向核心转发查询，它只宣告自身直连或重分发的路由。汇总路由则让中间路由器在收到针对明细网段的查询时，因为本地只有超网条目而直接回复不可达，不再继续扩散。Ruby程序需要采集每台设备的邻居列表与接口网段，才能判断这两种手段的适用位置。
用Ruby解析拓扑并识别查询边界
我们假设拓扑信息已经导出为JSON，包含设备名、接口IP、掩码以及邻居关系。Ruby内置的JSON库可以轻松载入，随后用哈希结构建立邻接表。下面的代码演示了如何读取数据并找出叶子节点，也就是只有一个EIGRP邻居且未连接其他分支的设备，这类设备最适合配置为stub。
require 'json'
# 读取拓扑文件
topology = JSON.parse(File.read('topology.json'))
# 构建邻接表
adj = {}
topology['devices'].each do |dev|
adj[dev['name']] = dev['neighbors']
end
# 找出叶子节点：邻居数量为1且自身无下游网段
leaf_nodes = []
topology['devices'].each do |dev|
if adj[dev['name']].size == 1
leaf_nodes << dev['name']
end
end
puts "建议设为stub的设备: #{leaf_nodes.join(', ')}"
上面的脚本只是第一步。真实环境中，还要考虑设备是否承载重分发路由，或者是否属于双归属接入。如果是双归属，即便邻居数为二，也可在两块上行都配置stub以阻断下行查询。我们可以在Ruby中增加权重判断：若设备的所有邻居都处于网络上层，且自身不转发其他EIGRP路由，则同样纳入stub候选。
除了stub识别，查询范围优化还需要定位适合做汇总的链路。比如分支路由器下方有十个连续子网，核心侧只需知道超网。Ruby可以计算接口网段的共同前缀，生成summary地址。这样当核心丢失某明细路由时，分支直接用汇总条目应答，查询不会下钻。下列代码展示了一个简单的前缀归并函数。
# 将多个网段合并为汇总地址（简化示例，仅处理/24连续段）
def summarize(networks)
base = networks.first.split('.')
common = base[0..2]
"#{common[0]}.#{common[1]}.#{common[2]}.0/22"
end
branches = ['10.1.4.0', '10.1.5.0', '10.1.6.0', '10.1.7.0']
puts "汇总路由: #{summarize(branches)}"
生成并验证优化后的路由器配置
得到stub候选与汇总地址后，下一步是输出真实可用的EIGRP配置片段。Ruby的字符串模板非常合适做这件事。我们遍历设备列表，对叶子节点输出eigrp stub connected，对汇聚节点输出summary-address命令。这样工程师直接拷贝到设备即可，避免逐行手写。
configs = {}
leaf_nodes.each do |name|
configs[name] = "router eigrp 100n eigrp stub connectedn"
end
topology['devices'].each do |dev|
if dev['role'] == 'aggregate'
summary = summarize(dev['subnets'])
configs[dev['name']] = "interface GigabitEthernet0/0n ip summary-address eigrp 100 #{summary}n"
end
end
configs.each do |k, v|
puts "=== #{k} ===n#{v}"
end
生成配置后不能立即上生产，需要在离线环境验证。我们可以用Ruby再写一个轻量模拟器：读入配置与拓扑，检查是否还有非stub叶子向核心转发查询。模拟逻辑是，若某设备被标为stub，则其邻居收到查询时应直接丢弃而不继续外发。通过断言测试，能发现遗漏的边界设备。
例如下面这段校验代码，会遍历邻接表确认每个stub的下游不再有查询出口。如果校验失败，脚本会报出具体设备名，提示人工补配。这种用Ruby把分析、生成、校验串起来的方式，比单纯手工配置更安全，也方便在拓扑变更后重新跑一遍脚本，保持查询范围始终最优。
leaf_nodes.each do |node|
adj[node].each do |nbr|
if leaf_nodes.include?(nbr)
abort("错误：stub设备 #{node} 与另一stub #{nbr} 互连，查询仍可能环路")
end
end
end
puts "校验通过：查询边界配置合理"
整体来看，Ruby凭借灵活的数据处理和清晰的语法，很适合做这类网络配置辅助工具。它把原本依赖个人经验的EIGRP查询范围优化，变成了可重复执行的脚本任务。当网络规模扩大或调整频繁时，这种方法的优势会更加明显，既能减少误操作，也能显著缩短路由收敛时间。
RubyEIGRP_SIAquery_scoping修改时间：2026-08-13 23:15:34