Summary

  • Ondřej Caletka 在 RIPE 92 报告：会议网络开始丢弃 ASPA 判为无效的路径后，一度无法通过 IPv6 到达 CZ.NIC。网络只有一家上游；上游送来的最佳路径经过一处未列入签名授权的提供者，本地路由器看不到备选路径。
  • CZ.NIC 更新 ASPA 授权后，Caletka 称约十分钟便恢复。会场随即争论：当这家上游是最后出口，过滤器究竟应放在哪一层？

过滤器没有出错，它忠实地删掉了该删的东西。麻烦是，删完以后路由表空了。RIPE 92 期间，Ondřej Caletka 和会议网络团队为自己的 ASN 签署 ASPA 对象，又开始在路由器上拒绝 ASPA 无效路径。很快，来自 CZ.NIC 的另一位 Ondřej 报告：从会场走 IPv6，连不到他那边。Caletka 没把这段经历藏进值班记录，而是在周五的全会上讲了出来。

官方逐字稿中的网络结构很小：一条上游连接，收完整 BGP 表，没有默认路由。上游送往 CZ.NIC 的最佳路径经过 AS6939，即 Hurricane Electric。它提供免费 IPv6 转接服务，却未出现在相关 ASPA 提供者名单里。ASPA 看见不合理的关系，会场路由器便拒收。上游只把最佳路径传给会场；另一条获授权的路即使存在，也没有送到这台路由器眼前。安全规则赢了，连通性输了。

修复动作很短。CZ.NIC 的操作者把 AS6939 补进自己的 ASPA 提供者列表；Caletka 说，约十分钟后新数据就进入路由信息库。RIPE NCC 的操作说明点明这项工作的难处：注册平台不会替 ASN 持有人猜出现实中的上游关系。名义上的对等方若同时承担转接角色，也得如实列入；关系一变，签名对象也要跟着改。免费转接仍然是转接，不会因为合同没写就自动消失。

台下没有统一鼓掌宣布答案。Job Snijders 认为应该修正目的地一侧的授权或转接关系，别把验证本身当问题；Caletka 盯住的是单上游客户的视角：上游没给第二条路，客户就无法选择它。Gert Doering 建议保留来自最后上游的路，在对等连接处做过滤。这场争论比一句“遇到无效路由就丢弃”有价值得多：规则放在哪里，决定谁先断线。

RIPE NCC 的员工页写明，Caletka 平日搭建培训实验环境。到了 RIPE 93，他又开设ASPA 教程，议程包括配置验证与排查失败。爱丁堡的这个例子足够当第一题：先问上游到底给了几条路，再按下“拒绝”。