摘要
- 7 月 20 日 10:48 UTC，一则 AfNOG 邮件列表帖子给出一行检查命令，把
as-TelOneZW的重复成员直接排到了输出顶部。 - BTW 随后重新查询 AFRINIC，得到 24 行
members:、21 个不同 ASN；AS37183 出现三次，AS37123 出现两次。 - 按 RPSL 的集合语义，重复行不会增加新的不同成员。它说明记录存在冗余，不说明发生了中断、路由泄漏或前缀被拒。
- AFRINIC 的公开指南称，上游和转接服务商会查询 IRR 来更新路由过滤器，因此这类小异常应当被当作数据维护信号，而不是被渲染成事故。
多出来的是三行文本，不是三张网络。
这正是周一那则 AfNOG 邮件的价值所在。S. Moonesamy 查询 AFRINIC WHOIS，整理 as-TelOneZW 的成员并按出现次数排序。最上方的结果很直观：AS37183 有三行，AS37123 有两行。
帖子没有给出重复产生的原因，只说很可能存在合理解释。BTW 在帖子发布后再次查询，复现了同样的当前状态：24 条成员声明，去重后为 21 个 AS 号。对象描述为“TelOne ASNs”，维护者标识是 AS8668-MAINTAINER，数据源为 AFRINIC。
这不是停机通报，也不是攻击告警。它是一处范围很窄、任何人都能复核的策略数据冗余。
记录变长了，集合没有变大
RFC 2622 对 as-set 的定义很明确：members 属性列出 AS 号或其他 AS 集合。既然对象表达的是“集合”，AS37183 写三次也仍然只是一个成员，AS37123 写两次同理。按不同 ASN 计算，成员数仍为 21。
因此，现阶段能下的技术结论十分有限。AfNOG 帖子和实时记录都没有证明某条路由被丢弃、某个前缀出现错误起源、流量路径发生改变，或生成的过滤配置已经损坏。遵循集合语义的展开结果，不会因为同一 ASN 重复出现而凭空增加一个不同成员。
但也不能反过来断言所有工具的处理过程完全一致。有的工具会先去重再生成配置；有的可能把原始行保留在中间文件、差异报告、审计记录或监控界面里。公开证据只证明输入存在冗余，并没有测量每一种解析器的行为。
两个重复 ASN 也分别对应不同组织。AFRINIC 的实时注册信息把 AS37183 关联到 Utande Internet Services (Pvt) Ltd，把 AS37123 关联到 Telecontract Pvt Ltd，两者都在津巴布韦。它们出现在以 TelOne 命名的集合中，不足以证明所有权、子公司关系或当前商业安排。AS-set 描述的是路由策略成员范围，不是企业股权结构。
“没有造成故障”不等于“不值得治理”
IRR 记录位于声明和执行之间。网络在 RPSL 中表达路由策略，其他系统则可能据此生成过滤规则。RFC 2622 说明，这套语言可以在 AS 层面描述策略，并为底层路由器配置提供依据。AFRINIC 自己的指南也写明，上游与转接服务商会查询路由注册库来更新过滤器，以维持 BGP 信息的稳定与一致。
这次重复没有证明过滤器出错。它揭示的是另一件事：输入数据可以在不改变集合数学结果的情况下发生漂移。
小异常因此有诊断价值。重复有效 ASN 通常是幂等的，容易被忽略；但它可能提示更新流程只做追加而没有对账，可能有两条管理路径同时修改对象，也可能根本没有最终校验。这里的“可能”不能写成“事实”。帖子没有变更历史，也没有根因调查。
真正该问的不是“三行重复是否让互联网掉线”，而是“同一维护流程还会漏掉什么”。重复的有效成员往往不会改变结果；过期成员、漏掉的成员或误加的嵌套集合，却未必同样宽容。
清理之前，先确认策略意图
维护者首先应核对 21 个不同成员是否仍全部属于预期范围，再追查三行冗余是怎样进入对象的，最后才决定是否提交干净版本。直接删掉重复行可以让文本整齐，却不能证明剩余成员就是正确策略。
检查机制也应拆成两层。一层比较原始成员行数与直接成员去重数；另一层展开嵌套集合、保存时间序列，并区分重复、缺失对象、异常新增和展开失败。RIPE 数据库关于集合成员查询的说明提醒运营者：最终结果可能来自递归展开，不能只盯着当前对象上肉眼可见的几行。
对消费 IRR 数据的网络来说，生成的过滤器还应保留来源信息：查询了哪一个注册库、何时查询、怎样展开、是否复核。这样做不会把 IRR 变成绝对真相，却能在输入有误时快速还原路径。
AfNOG 这则帖子之所以值得报道，不是因为它发现了大事故，而是因为它提供了一个便宜的控制测试。三行冗余没有改变 21 个不同成员，却足以检验路由策略数据是否经过对账、审阅和持续观察——最好在下一次错误不再这么无害之前完成。