摘要
- APNIC 将 AS132722 与 Intellium Technology Limited 关联，并把这个自治系统对象的行政状态记为 active。这证明号码资源的登记身份，不证明当前存在可见路由、已建立的交换会话或可用的客户服务。
- PeeringDB 为该 ASN 列出两条运营方声明的交换连接，Intellium 官网也介绍了公司的 IT 与通信业务。它们补充了身份和互联背景，但不能证明实时流量、可用容量、物理多样性、覆盖范围、韧性或性能。
先把四个常被混用的问题拆开
自治系统是向外部互联网呈现共同路由策略的网络或网络集合。自治系统号，也就是 ASN，是网络通过边界网关协议 BGP 交换可达性信息时使用的唯一标识之一。AS132722 因而适合用来界定一次路由讨论的对象，也适合在故障协同时确认应联系哪个登记主体。
但“有一个 ASN”与“某项服务正常”之间没有自动等号。号码资源登记回答归属与联系边界；互联目录回答参与者公开填写了哪些关系；公司网站回答企业如何描述自己的服务；实时路由、会话和应用状态必须由正在运行的系统给出。
如果把这些层次压成一个“正常”或“异常”的标签，判断很容易失真。登记对象可以准确而当前路由未知，交换连接可以被如实声明而此刻会话未被测量，服务介绍也可以真实却没有说明某位客户使用哪一个 ASN。公开资料最有价值的用法，是帮助提出下一组可验证的问题。
APNIC 记录的是唯一资源身份
APNIC 的 RDAP 记录准确覆盖 AS132722。对象使用 AS132722 这一 handle，名称为 ITL-AS-AP，国家字段为新西兰，登记主体为 Intellium Technology Limited。记录中的注册事件日期是 2013 年 4 月 2 日，最后变更事件为 2020 年 11 月 25 日，对象行政状态为 active。
这些字段可以有把握地支持一个狭窄结论：亚太地区互联网注册管理机构目前把这个自治系统号登记给哪一家机构。对象和联系人也为路由或滥用问题提供了可追踪的协调入口。号码资源保持唯一、归属准确、转移和维护记录清楚，本身就是互联网协作的重要基础。
这里的 active 不能翻译成“网络正在工作”。RDAP 不会探测某个前缀是否正在发布，不会判断从指定观察点能否看到路由，也不会测试客户应用是否在线。最后变更日期只说明这条登记记录保留的事件时间，不能概括此后网络设备、上游关系或服务配置发生的变化。
因此，注册管理机构更像账本和记录者，而不是对现实运行状态作最终裁决的系统。账本负责把资源和主体对应起来；实际路由是否存在，要看路由器、策略和独立观察结果。
PeeringDB 的两条连接是公开声明
PeeringDB 的网络接口为 AS132722 返回一条记录，网络名称是 Intellium Technology，网站字段指向 Intellium 的域名，网络类型标为 Cable/DSL/ISP，一般对等策略标为 Open。该行的 IPv4 与 IPv6 前缀数量字段都是零，IRR set、looking glass 和路由服务器 URL 字段为空。
这些零值和空值只能描述当前这条 PeeringDB 资料。它们不能推出 Intellium 没有发布路由、没有其他地址资源，或在任何环境都不具备 IPv6 能力。参与者维护的目录可能有选填字段，也可能与运行网络采用不同更新节奏。把“没有填写”写成“没有能力”，会越过证据边界。
另一组交换连接资料包含两行。第一行声明 AS132722 接入 APE，标注速率为 1,000 Mbps，列有 IPv4 地址、没有 IPv6 地址，并且没有路由服务器参与标记。第二行声明其接入 AKL-IX，标注速率为 10,000 Mbps，同时列有 IPv4、IPv6 地址，并带有路由服务器参与标记。
这两条记录适合用作检查清单。网络工程师可以逐项确认 ASN、交换点和地址是否仍属于当前设计，也可以询问相应的路由策略与会话负责人。它们让身份错误和实际路由故障更容易被分开调查。
然而，目录里的 operational 字样不是连续遥测。标注速率不是当前流量，也不是故障期间必然可用的余量；交换地址不显示某个客户的完整路径；两条逻辑连接更不等于光纤、电力、机房、上游和管理平面已经物理隔离。只有实际配置、会话数据和路径测量才能回答这些问题。
官网提供服务语境，不提供路径证明
Intellium 官网把公司描述为 IT 支持与通信服务提供者，导航中包括云、IT 支持、语音与互联网、网络安全、生产力和商业智能等项目。官网域名与 APNIC 联系信息所用域名、PeeringDB 网站字段能够形成有限的身份呼应。
这个呼应说明几份资料指向同一企业语境，却不能证明 AS132722 承载官网列出的所有服务。企业可能使用多个 ASN、接入商、云平台和交付路径。服务页面没有列出某个客户的前缀、交换连接、上游依赖或物理设施，也没有提供实时可用性、时延、容量或安全效果的测量。
在采购或事故分析中，最安全的表达不是“ASN 代表公司的全部业务”，而是“公开记录将 Intellium 与 AS132722 关联，并列出两条交换连接声明”。某项合同服务究竟经过哪个网络资源，仍需要服务方与客户用当前资料确认。
从公开记录走向运行证据
如果问题是“现在能否看到路由”，应查询带时间和观察点的路由收集器结果。如果问题是“BGP 会话是否建立”，应查看双方会话状态与策略。如果问题是“链路是否承载流量”，应查看接口计数器；如果问题是“客户服务是否可达”，还需要端到端测试以及 DNS、应用和外部依赖信息。
这些证据不能互相代替。看到一条路由不等于应用正常；看到会话建立不等于所有客户走这条路径；接口有流量也不证明高峰或故障时容量充足。每项结论都应保留观察时间、测试范围、位置和限制。
本篇所用四个公开来源不包含上述实时证据。因此能下的结论是“运行状态尚未由这组资料证明”，而不是“网络失效”。缺少测量不是故障证据，正如行政状态 active 也不是服务健康证明。
运营方、客户和事故响应者可以怎么问
运营方可先确认 AS132722 是否仍是预期路由身份，APE 与 AKL-IX 条目是否符合当前互联设计，条目中的地址是否仍分配给相应会话。随后再核对路由策略、会话状态和实际观察到的公告，避免用目录字段替代配置检查。
客户可要求明确合同产品使用哪个 ASN 和交付路径，哪些依赖由 Intellium 控制，哪些由接入商、云平台或其他第三方承担。若合同涉及可用性或恢复目标，可信材料应是有日期、范围和测量结果的测试，而不是 ASN 对象或交换端口速率。
事故响应者则应把证据分栏记录：登记身份、互联声明、路由观察、会话遥测、接口数据和服务测试。这样可以在路由、接入、DNS、应用及外部依赖之间逐步缩小范围，而不会因为一张目录表就提前归因。
需要重新评估的变化
- APNIC 中 AS132722 的登记主体、状态、联系人或事件历史发生变化。
- PeeringDB 的网络名称、策略、零值或空字段出现实质更新。
- APE 或 AKL-IX 连接被新增、删除，或协议与地址字段发生变化。
- Intellium 域名或官网服务描述发生重大调整。
- 出现带时间戳的路由、会话、流量或具体服务测试，能够直接回答当前运行问题。
监测记录应同时保存“什么时候看到”和“在哪一层看到”。登记更新、互联声明与实时观测都可能有价值，但它们回答的问题并不相同。只有在身份、声明和运行证据被明确关联后，才能把它们合并成更强的运营结论。