STP根保护是交换网络里保护根桥地位的一道重要防线，当某个开启了根保护的端口收到更优的BPDU时，端口会被置为不一致状态并阻断流量，直到违规条件消失且恢复计时器到期才重新参与转发。这个恢复时间的长短直接影响故障收敛速度和误伤概率，配置得太短可能导致端口反复震荡，配置得太长又会让故障恢复变慢。用Ruby写一个自动化脚本来管理和优化这个参数，是网络运维中很实用的一个技巧。
STP根保护的工作原理与恢复时间的作用
生成树协议（STP）通过BPDU报文选举根桥，正常情况下根桥位置是规划好的。但如果网络中混入了一台优先级更高的交换机，它发出的更优BPDU会冲击现有拓扑，导致重新收敛甚至次优路径。根保护的作用就是阻止这种事情发生：在接入层端口上开启后，一旦该端口收到比当前根桥更优的BPDU，端口立即进入root-inconsistent状态，相当于被强制阻塞。
被阻塞的端口并不会永远卡死。交换机内部有一个恢复计时器，默认大多数厂商设为30秒。计时器到期后，端口会重新监听BPDU，如果之前的违规设备已经撤掉，端口恢复正常转发；如果更优BPDU还在，端口再次被置为不一致状态，如此循环。由此可见，恢复时间间隔实际上决定了检测周期，是整个保护机制的关键参数。
恢复时间的取值需要在两个极端之间找平衡。设置成5秒这种很小的值，端口探测频率高，故障恢复快，但网络中偶发的BPDU抖动可能引起端口频繁震荡，造成MAC表和ARP表反复刷新。设置成120秒这种较大的值，端口状态稳定，但如果违规是误判，业务中断时间会被拉长。一般建议在接入密集、终端设备复杂的场景用60秒左右，在数据中心等高可靠环境用30秒甚至更短。而用脚本批量下发这些差异化配置，正是Ruby擅长的事情。
用Ruby的Net::SSH实现配置下发
Ruby的标准库本身不带SSH功能，需要先安装Net::SSH这个gem。在终端执行gem install net-ssh即可完成安装，这个库依赖很少，安装过程通常很顺利。它的优势在于可以在代码里精确控制每个命令的执行节奏，方便针对不同厂商交换机做适配。
下面这段代码演示了连接一台Cisco风格的交换机，先查看当前根保护状态，再修改恢复时间间隔，最后保存配置。脚本里用了块形式的会话通道，逐条发送命令并收集回显，这样能准确判断每一步是否执行成功。
require 'net/ssh'
# 交换机连接信息
host = '192.168.0.1'
user = 'admin'
pass = 'your_password'
Net::SSH.start(host, user, password: pass) do |ssh|
# 打开交互式shell通道
channel = ssh.open_channel do |ch|
ch.request_pty do |pty, success|
raise '申请PTY失败' unless success
end
ch.send_channel_request('shell') do |sh, success|
raise '打开Shell失败' unless success
end
commands = [
'configure terminal',
'spanning-tree portfast bpduguard recovery 60',
'interface range gigabitEthernet 0/1 - 24',
'spanning-tree guard root',
'end',
'write memory'
]
ch.on_data do |c, data|
puts data
end
# 逐条下发命令，间隔给设备留出处理时间
commands.each do |cmd|
ch.send_data(cmd + "\n")
sleep 0.5
end
sleep 2
ch.close
end
channel.wait
end代码中sleep 0.5这一步看似多余，实际很关键。交换机处理CLI命令需要时间，如果命令发得太快，回显会互相交错，甚至触发设备端的限速保护。另外要注意，恢复时间间隔在不同设备上的命令语法差异较大，思科设备上通常是errdisable recovery interval配合原因配置，华为设备则是error-down recovery interval，写脚本前务必核对手上设备的命令手册。
批量部署与错误处理优化
单台设备的配置脚本只是基础，真实场景往往要面对几十上百台交换机。直接串行连接会让脚本执行时间长得难以接受，Ruby的线程机制可以轻松实现并发。下面是一个基于线程池的批量版本，同时限制并发数量避免把跳板机的连接数耗尽。
require 'net/ssh'
require 'json'
# 设备清单放在JSON文件里，便于维护
devices = JSON.parse(File.read('devices.json'))
# 控制并发数，避免连接风暴
MAX_THREADS = 10
queue = Queue.new
devices.each { |d| queue.push(d) }
workers = Array.new(MAX_THREADS) do
Thread.new do
while (dev = queue.pop(true) rescue nil)
begin
Net::SSH.start(dev['ip'], dev['user'], password: dev['pass'],
timeout: 10) do |ssh|
result = ssh.exec!('show spanning-tree summary | include root')
puts "#{dev['ip']}: #{result.strip}"
ssh.exec!("errdisable recovery interval #{dev['interval'] || 60}")
end
rescue Net::SSH::AuthenticationFailed
puts "#{dev['ip']}: 认证失败，请检查账号密码"
rescue Errno::ECONNREFUSED
puts "#{dev['ip']}: 连接被拒绝，设备可能离线"
rescue => e
puts "#{dev['ip']}: 未知错误 #{e.message}"
end
end
end
end
workers.each(&:join)这个版本还有几个可以继续优化的地方。第一，密码明文放在JSON文件里不安全，建议改用环境变量或者Ruby的加密库处理，更规范的做法是接入企业现有的密钥管理系统。第二，exec!方法适合执行单条命令，但有些设备需要在使能模式下才能改配置，此时还是得用前面交互式通道的写法，发送enable和特权密码。第三，执行结果应该落盘保存，方便事后审计，简单做法是把输出追加写入日志文件。
验证配置效果与常见坑
配置下发完成不代表工作结束，验证环节同样重要。脚本里可以追加一条show errdisable recovery命令，解析回显确认恢复定时器的实际值。Ruby的正则处理回显文本非常方便，比如用result.scan(/interval\s+(\d+)/)就能提取出数值并和预期值比对，不一致时输出告警。
实践中有几个容易踩的坑值得提醒。一是根保护和BPDU保护经常被混为一谈，前者防的是更优BPDU抢根桥，后者防的是端口根本不该收到BPDU，两者触发的errdisable原因不同，恢复命令也可能不同，脚本里要分开处理。二是部分老旧设备固件不支持修改恢复间隔，命令会直接报错，脚本必须捕获错误而不是中断整个批处理。三是修改恢复时间属于影响网络行为的操作，建议先在测试环境跑通脚本，再分批次推到生产环境，每批之间观察端口状态变化，确认没有异常震荡再继续扩大范围。按这个流程走下来，一套稳定可复用的STP根保护自动化配置方案就成型了。