EIGRP在建立邻居关系时，会先校验双方的K值配置。K值一共五个，分别对应带宽、负载、延迟、可靠性以及MTU（严格来说第五个K值默认不参与计算），只有两端K值完全一致，邻居表才能正常建立。一旦不一致，路由器会持续弹出类似“K-value mismatch”的告警日志，而且邻居关系会不断翻动，表象上看起来像是链路问题，实际却是最简单的配置问题。面对成千上万行日志，靠肉眼逐条翻看既费时又容易漏掉关键信息，用Ruby写一个脚本来做自动分析是不错的选择。
EIGRP K值不匹配的原理与日志特征
在动手写代码之前，先要搞清楚K值不匹配时日志长什么样。Cisco设备上典型的一行日志如下：
%DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.1.1.2 (GigabitEthernet0/0) is down: K-value mismatch
这行日志包含几个关键信息：进程号（100）、邻居地址（10.1.1.2）、本地接口（GigabitEthernet0/0）以及具体的故障原因（K-value mismatch）。我们的分析脚本就是要把这些字段提取出来，再做统计汇总。
默认配置下，EIGRP的K值为K1=1、K2=0、K3=1、K4=0、K5=0。如果有人在某台设备上执行了metric weights命令修改了其中任何一个值，邻居校验就会失败。值得注意的是，K值不匹配时邻居不会进入正常的Down状态并静默，而是会反复尝试建立又立刻被拒绝，因此日志里往往会出现同一邻居在短时间内大量重复的告警，这也正是需要自动化分析的原因。
用Ruby解析日志并提取关键字段
Ruby的正则表达式能力非常适合处理这类文本提取任务。核心思路是：逐行读取日志文件，用正则匹配EIGRP邻居变更日志，提取进程号、邻居IP、接口和原因，然后判断原因是否为K值不匹配。下面是基础实现：
EIGRP_KVALUE_PATTERN = /
%DUAL-5-NBRCHANGE:\s+
EIGRP-IPv4\s+(\d+):\s+ # EIGRP进程号
Neighbor\s+(\d+\.\d+\.\d+\.\d+)\s+ # 邻居IP地址
\((.+?)\)\s+ # 本地接口名
is\s+(up|down):\s+ # 状态变化
(.+) # 具体原因
/x
def parse_line(line)
m = line.match(EIGRP_KVALUE_PATTERN)
return nil unless m
{
asn: m[1],
neighbor: m[2],
interface: m[3],
state: m[4],
reason: m[5].strip
}
end
def analyze(path)
results = []
File.foreach(path) do |line|
record = parse_line(line)
results << record if record
end
results
end
records = analyze(ARGV[0] || "syslog.txt")
kvalue_issues = records.select { |r| r[:reason].include?("K-value mismatch") }
puts "共解析日志 #{records.size} 条，其中K值不匹配 #{kvalue_issues.size} 条"
kvalue_issues.each do |r|
puts "AS#{r[:asn]} 邻居 #{r[:neighbor]} 接口 #{r[:interface]} 状态 #{r[:state]}"
end这段代码里用了x修饰符让正则可以分行书写并添加注释，可读性大大提高。File.foreach是逐行惰性读取，即使日志文件有几个GB也不会一次性占满内存，这一点在处理生产环境的syslog时非常重要。
需要注意的是，不同IOS版本的日志格式略有差异，比如IPv6的EIGRP日志前缀是EIGRP-IPv6。如果环境中同时存在两种协议，建议在正则里把IPv4改成IPv[46]，或者在提取结果中保留协议类型字段，避免统计时混在一起。
统计汇总与结果输出
单纯的逐条打印意义不大，真正的价值在于统计。实际排障时我们最关心两件事：哪些邻居出现K值不匹配的次数最多（说明最紧急），以及不匹配的告警集中在哪个时间段（说明是否与某次配置变更相关）。Ruby的group_by和sort_by组合起来非常顺手：
def summarize(issues)
summary = issues.group_by { |r| [r[:asn], r[:neighbor], r[:interface]] }
summary.map do |key, records|
{
asn: key[0],
neighbor: key[1],
interface: key[2],
count: records.size,
first_seen: records.first,
last_seen: records.last
}
end.sort_by { |s| -s[:count] }
end
summarize(kvalue_issues).each do |s|
printf("AS%-6s %-16s %-22s 告警 %4d 次\n",
s[:asn], s[:neighbor], s[:interface], s[:count])
end排序后输出的是一张按告警次数降序排列的清单，排在前面的邻居就是优先处理对象。运维同学拿到这份清单，直接登录对应设备执行show ip protocols查看当前K值配置，再与邻居设备比对，通常几分钟能确认根因。修复方法也很直接：在EIGRP进程下用metric weights 0 1 0 1 0 0把两端配置改回一致的默认值即可。
如果还想进一步定位时间规律，可以在解析时把日志时间戳一并提取，然后按小时分桶统计告警数量。用一个小哈希表就能实现，配合Ruby标准库里的Date或Time类处理时间格式即可。此外，还可以把汇总结果输出为CSV，方便导入Excel或与其他监控系统的数据做交叉比对。
脚本扩展与实用建议
这个脚本还有很多可以扩展的方向。比如加上多文件支持，用Dir.glob遍历整个日志目录；或者接入net-telnet、net-ssh等gem，发现告警后自动登录设备抓取show ip protocols的输出，进一步确认K值配置差异，实现从“发现告警”到“定位根因”的闭环。
另一个常见坑是日志去重。有些日志收集系统会把同一行日志重复转发，导致统计次数虚高。可以在解析后用记录整体内容做一次去重，或者按时间戳加邻居IP组合去重。还有一个建议：在输出报告时把本地接口和邻居IP放在一起展示，因为K值不匹配是双向问题，你需要知道往哪台设备的哪个接口方向去查，单看IP容易忽略本端配置才是被改动的那个。
总体来说，用Ruby处理这类结构化程度较高的网络日志，开发效率很高，几十行代码就能替代大量人工排查工作。掌握这种“正则提取加统计汇总”的思路后，还能迁移到OSPF邻居翻动、BGP会话中断等其他网络告警的分析场景中，非常值得网络工程师掌握。