摘要

  • FORT 的默认提供者上限是4,000。固定发布代码在合并两份列表时，先检查输入长度之和，再进行去重；不同提供者AS的最终数量不是这一步唯一衡量的量。
  • 超过合并上限时，函数返回空指针与零计数。类型说明将这种结果用于撤回，但本文没有观察到真实客户受影响、路由器收到撤回或资源登记被取消。

两份列表各有2,500个提供者AS，而且列出的AS完全相同。数学上的并集仍然只有2,500个。在 FORT 的固定发布代码里，这两个输入却可能先撞上默认4,000的上限：合并函数首先看到的是5,000，而不是去重后的2,500。

这是一个函数输入的条件推演，不是本文找到的一对真实ASPA对象。它假设两份有序列表已经通过其余检查，并且进入同一客户AS的合并路径。重要的不是有人拥有数千个上游，而是软件把哪一种数量当作预算。

LACNIC 于2026年9月9日发布的ASPA介绍，将 FORT 列为已有的实现之一。ASPA提供的是客户AS对提供者AS的授权关系数据，不能与只核对路由起源的ROV混为一谈。本文据此回看 FORT 的列表处理，而不重复讨论采用比例或路由器协议默认值。

所审查的是7月16日发布的1.7.0.experimental，以及发布标签解析到的固定提交 c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e。它不是9月的新版本，也不是对所有当前安装的盘点。这里的结论来自文档和代码，没有运行 FORT、向生产系统查询或发布合成ASPA。

同一个上限，两条处理路径

使用文档给出 aspa.max-providers 的默认值4,000、可配置范围0至16,380，并说明它约束每轮验证中同一客户AS在所有RPKI树里的提供者数量。配置代码独立写明默认值与范围。这些首先是本实现的配置值，本文不把它们称作标准强制的协议上限，也不把零解释为“无限制”。

单个对象先遇到自己的检查。object/aspa.c 中的 parse_providers，在分配提供者数组和把对象交给后续处理之前，判断单份列表是否超过配置上限。单份列表内部还必须按AS编号升序排列，不能重复，也不能把客户自身列为提供者。因此，跨列表的重叠与单份列表内部的重复，是不同问题。

客户级合并在 db_table.c 中出现。数据库按客户身份保存ASPA项；遇到同一客户的既有项时，add_aspa 调用 merge_providers。后者先令 m 等于 old->count 加 new->count，然后检查既有提供者指针是否为空，或 m 是否超过配置限值。任一条件成立，就返回空指针和零计数。

只有通过这道检查，函数才按 m 分配合并空间，并运行有序列表的去重循环。相同AS编号在这一阶段只保留一次，但这个较小的结果来得比预算判断晚。add_aspa 随后把合并结果赋给新存入的客户项，并释放被替代的提供者存储。类型头文件说明，空指针与零计数用于撤回。

这个处理顺序支持一个窄而明确的结论：关口限制了两份当前输入的合并容量，不只限制最终不同AS的数量。它也与防御性分配预算相符，因为下一步分配的空间就是两份输入的长度之和。不过，这只是从代码结构作出的解释，不是维护者说明过的动机，更不是性能测试。不能因此直接把这道检查叫作缺陷。

不等于把全周期的原始条目全部相加

old->count 可能已经来自更早一次去重。它不是永远保持原始对象条目总数的计数器。

仍以默认上限为例，若向一个健康的目标项依次合并三份完全相同、各有1,500个AS的列表，前一次检查的和为3,000，去重后又回到1,500；再并入第三份，检查的和仍是3,000。原始三份列表合计4,500个条目，并不意味着这个特定的顺序会超过4,000。

这同样是条件化的函数序列，不是对实际RPKI树处理分组的保证。它说明“全周期原始条目总数”“两份当前输入长度之和”和“不同提供者AS数”至少是三种度量。只写一个“提供者数量”，可能掩盖它们的差别。

数值条件还是严格的“超过”。两份长度之和恰好等于4,000，不会因这一个数值判断而进入空结果分支；其他条件和检查仍须另论。反过来，一个空结果也不能自动归因于超限，因为既有指针为空是另一个分支条件。本文没有审计所有合并顺序，也不宣称所有空标记都不可恢复。

谁应解释这个预算

对维护者来说，先限制分配空间有合理的工程依据。对运营者来说，最终并集里的成员数又是最容易理解、也最容易从结果里统计的量。两者都可以有用，但回答的不是同一个问题。

一个可讨论的改进是把保护对象说清楚：这里约束的是合并时的两输入容量，还是希望约束去重后的成员数量？澄清文字或调整处理顺序是不同选择，本文没有报告其中任何一种已经采用，也没有建议运营者直接提高上限。

更重要的是，不把类型说明里的“撤回”扩写成一次已发生的网络事件。源码中的空结果与撤回约定，不证明下游会话实际交付了什么，更不证明路由器采取了何种策略或转发发生变化。缓存没有保留一组提供者数据，也不是登记机构取消了客户AS的编号或资源资格。这个故事关乎知识进入软件结果的计数规则，不是一份事故通报。

来源

  1. LACNIC 的ASPA介绍
  2. FORT 1.7.0.experimental 发布页
  3. 固定提交的参数说明
  4. ASPA对象提供者解析
  5. 客户项合并与计数顺序
  6. 配置默认值和范围
  7. ASPA提供者类型与撤回约定