摘要

  • InterLAN IX 在 RIPE 93 报告，Lighthouse 已用于 9 台 Nokia 路由器、20 台 Arista 交换机、197 项服务及有 214 名客户的门户。变更先按设备预览和验证，再检查可达性，并由回滚计时器约束确认过程。
  • 外部 API 的写入须走锁、事务、回滚和审计；AI 助手当前只持有读取状态、日志与诊断结果的工具。AI 辅助变更仍在“计划中”，顺序是提出、审查、批准。

网络自动化最爱展示一条笔直的箭头：客户点按钮，服务就开通。真实网络偏偏由多台设备组成，还常常跨厂商。在 RIPE 93 的 Connect 场次，InterLAN IX 工程师 Andrei Dinu 展示了 Lighthouse 如何处理这种不整齐。他的 23 页原始幻灯片把流程称为“多设备原子事务”，又把其中的实活拆开：每台设备预览配置、提交前验证、写入后检查可达性、等待确认、必要时回退，最后留下执行记录。真正的考题是其中一台成功、另一台失败时，系统怎样收场。

InterLAN 报告的运行范围不算一张概念图：9 台 Nokia 路由器、20 台 Arista 交换机、197 项服务、门户中的 214 名客户。数字来自运营者在会上展示的快照，不能当成已成功执行 214 次变更。客户能在门户中查看服务状态并提出受限请求；员工则要面对设备状态、流量、模板版本和变更历史。一个看似只改 VLAN 的请求，落到设备上可能涉及几份配置。预览必须逐台显示，因为坏过滤规则不会因为界面把它归入“一个订单”就变得无害。

幻灯片上的 Nokia 操作界面有一个确认窗口。设备配置若未被确认，会按计时器回退；系统还检查能否重新连上设备，并记录结果。截图显示某一次操作还剩四分四十二秒，那只是画面停下的时刻，不是所有变更的标准时长。计时器的价值在于救回失联的管理路径：若新配置把工程师挡在门外，等一个人工点击“撤销”本身就可能是笑话。

更尖锐的冲突在数据库与现场设备之间。Lighthouse 保存预期配置，定期比较设备实况，把人工改动列为偏差；它还检查缺失的 SAP、重复的标识或 EVI。运营者可以通过事务修复，也可在许可条件下采纳人工改动。凌晨抢修留下的一行配置，到底是“漂移”还是正确答案？数据库会指出差异，却不能凭自己的整洁程度判定谁有权获胜。自动把路由器拉回旧模板，可能顺手抹去唯一有效的抢修。

InterLAN 也把变更放进数字孪生环境演练。它从最近保存的生产配置和拓扑出发，清理配置，再用 Containerlab 与 Nokia srsim 重建实验环境；实验环境有自己的设备和数据，不会把写入传回生产。讲稿同时列出边界：设备须事先完成管理和路由准备，Arista vEOS 与 BIRD 客户端模拟仍属后续计划。能演练几乎同样的配置是一件好事，知道哪些依赖尚未进入实验室更重要。

然后是最容易被包装成魔法的 AI。外部 API 可以读也可以写，但写入必须经过普通事务、锁、回滚和审计。AI 助手走另一条路：只读的 MCP 工具，可查看状态、日志和运维诊断；示例任务是写客户报告与迁移计划。最后一页把“AI 辅助变更”放在计划栏，顺序明确写成“提出 → 审查 → 批准”。AI 有笔记本，没有路由器钥匙。这个边界比一句“智能运维”更值得登在发布会上。

InterLAN 与 RIPE NCC 的联系也有明确界限。RIPE RIS 文档列出设在布加勒斯特 InterLAN-IX 的 RRC22 路由采集器。RIPE NCC 运营测量服务，InterLAN 运营交换网络与 Lighthouse。采集器记录路由可见性，数据库记录计划中的网络，路由器运行当前配置；三份记录互相有用，谁也不能替另一份签字。

这场展示还缺一组运行结果：尝试了多少笔跨设备变更、出现过多少次部分提交、回滚有多少次成功。附日期的汇总流水会改变安全性判断。现有幻灯片足以说明架构与规模，最有分量的主张仍是它划出的权力边界：写入要过关，人工偏差不能消失，AI 暂时只能看。

资料来源：RIPE 93 官方场次记录；InterLAN Lighthouse 原始幻灯片；RIPE RIS 采集器目录。