Comcast 2021 中断与路由表容量问责测试

摘要

ThousandEyes 报告了 2021 年 11 月 8 日和 11 月 9 日发生的两起不同 Comcast 中断。第一次大约始于 2021 年 11 月 8 日太平洋时间晚 9:44，约在晚 10:48 结束；第二次大约始于 11 月 9 日早 5:05，约在早 6:15 结束。[1]
在第一次事件期间，外部测试显示穿越 Comcast 的 Sunnyvale 核心的路径出现了丢包。一些起初使用其他路径的流量仍然成功传输，但在被重路由到 Sunnyvale 后又失败。该顺序是对观察到的转发路径的证据，而非一份完整的内部 Comcast 拓扑或配置记录。[1]
第二次事件的观察范围更广。ThousandEyes 报告称，尽管端点与加州相距较远，一些美国中部和东部流量仍被暂时导向 Sunnyvale。部分路径在完整丢包与可达之间来回变化，其行为被分析为可能与控制平面抖动相关。[1][3]
后续的 ThousandEyes 复盘将该事件归因于无意间超出路由表限制。[2] 公开材料并未识别具体设备、表、配置阈值、软件行为、命令、变更负责人、厂商或审批流程。因此该“路由表限制”说明应被归因于可见证据边界，而不应被表述为完整的 Comcast 事故后评估。
路由表限制本身是一项问责控制，因为运营者可以测量表占用率、增长速率、预留冗余、告警阈值、故障行为和恢复过程。相关测量在 Comcast 内部是否存在或是否有效，公开材料并未披露。
重路由并不总能产生独立路径。被重定向到受损 Sunnyvale 核心的已观测流量也出现了失败。因此连续性依赖的是故障域隔离，而不仅仅是存在另一条路由计算结果。[1]
ARIN 对 AS7922 的 RDAP 记录提供了网络资源归属背景。[9] 它并未揭示 Comcast 路由器中实时安装的路由，也未显示内部 route-reflector 状态、拓扑、表利用率或某个具体数据包的转发结果。
IETF 文档说明了 BGP 的运行、收敛、路由反射、平滑变更与故障检测机制。[10]-[20] 这些文件提供了控制术语和后续或通用设计背景。它们不能证明 Comcast 在 2021 年 11 月采用了哪些机制，也不能成为回溯定责的事实认定。
FCC 中断报告规则为符合条件的通信中断建立了问责记录。[7][8] 当前公开来源并未披露 Comcast 针对本次事件的保密报送。报告义务不能被视为公开技术复盘。
证据支持可度量的运营结论，而非指控。Comcast 控制了其内部路由容量、拓扑、告警、变更流程、客户沟通和恢复。外部观测者控制了其测量方法。监管方控制了报告要求。现有记录并未确立故意行为、过失、法律责任或个人责任。

问责问题

2021 年 11 月的事件之所以重要，并非因为“网络”这个抽象概念中断，而是因为具体流量路径停止转发、一些替代计算将流量再导向同一受损核心，以及网络状态变化后恢复了服务。这是可观察到的运营序列。与其问“一个大型运营商是否会中断”，更有用的是更窄的问责问题：其路由表容量和失败域行为是否可事前验收。

关键问题在于，治理路由表容量与失败域行为的控制是否可在事件发生前被检验。运营者可以知道某个设备或进程支持多少条路由，也可以知道当前占用、状态增长速率、用于收敛保留的容量、告警阈值和硬阈值处的行为，以及冗余控制元素是否共享同一上限。运营者还可以测试失败节点或区域是否会使流量进入真正独立的路径，也可以留存告警触发、操作人、变更内容和转发恢复的证据。

公开证据未揭示 Comcast 对这些问题的答案。ThousandEyes 提供了来自其观测点的外部观测，并在后续将事件归因于路由表限制。[1][2] 但它未公开 Comcast 的配置归档、内部遥测、审批记录或完整故障复盘。Comcast 的架构页面显示其网络庞大且分布式，但并非这两起事件的复盘文件。[5][6] 因而，问责分析必须区分可观测内容与仍在运营者内部证据边界内的部分。

这种区分并非拒绝分析，而是定义正确的责任边界。Comcast 控制了该限制被触发以及恢复执行的内部系统；ThousandEyes 控制了其测量与解读，而非 Comcast 路由器。ARIN 控制 AS7922 注册记录的准确性与可用性，但不控制 Sunnyvale 核心中安装的路由。[9] FCC 控制报告要求与取证规则，但不控制实时转发决策。[7][8]

由此得出的实务命题是：连续性主张必须可验证。容量、拓扑和恢复应能在运行系统中展示。架构图可显示多个节点，路由协议可计算多条路径，注册库可准确标识一个自治系统，但这些单一事实都不能单独证明在路由表到达上限时流量会避开同一受损域。

两起事件的取证时间线

该时间线基于外部测量，必须始终保持这一属性。路径监测平台只看到来自选定观测点的部分测试，能揭示丢包、路径变化和重复模式，但不能看到每条内部命令、每张表中的每条路由或每个客户会话。下列时间线仅记录观察事实，而非将其误转为虚拟内部日志。

时间	证据事件
11 月 8 日 9:44 之前（太平洋时间）	公开材料未识别到触发性变更、表增长事件、设备告警或内部维护动作。外部后续分析所使用的路径在观测到丢包前运行正常。
大约 9:44 PM	ThousandEyes 将第一次中断的起始时间定在该时段。流量经过 Sunnyvale 核心的测试开始出现丢包。[1]
大约 9:44–9:46 PM	部分 Sunnyvale 外部邻近路径持续可用。该观察很重要，因为表明故障最初并未立即统一影响所有测量路径。[1]
大约 9:46 PM 起	部分流量被重路由到 Sunnyvale 后也出现了同样的完全丢包。公开记录显示路径先变化再失败，但未显示引起每次变化的内部决策或路由条目。[1]
大约 10:48 PM	第一次观测中断结束。先前被重路由的路径返回到原路径，但仍有部分经过 Sunnyvale 的流量使用了另一组 Sunnyvale 节点。公开材料未识别修复命令或确切收敛顺序。[1]
两次事件之间	公开材料未披露是否存在持续共享状态、是否尝试过变更，或两次事件是否有同一直接触发因素。两次事件表现类似，但相似性不能证明存在单一不中断的内部原因。
11 月 9 日大约 5:05 AM	第二次中断开始。ThousandEyes 观察到某些经过 Sunnyvale 的路径出现完整丢包。[1]
第二次事件期间	一些来自美国其他地区的流量被重定向至 Sunnyvale 并失败。芝加哥到芝加哥的流量是用于说明该意外地理路径的示例之一。[1]
第二次事件期间	部分测量路径在丢包与可达之间交替。ThousandEyes 将这种变化行为讨论为可能由控制平面抖动引起。[1]
大约 6:15 AM	第二次观测中断结束，受影响路径再次到达目的地。公开材料未披露恢复是由回滚、容量调整、进程重启、撤销路由还是其他动作触发的。[1]
后续复盘	ThousandEyes 的年度复盘将事件归因为无意间超过路由表限制。[2] 该后续说明了所指机制，但未提供完整的内部根因树。

该时间线支持三点结论。第一，两个事件在时间上分离，不应在缺乏内部证据时合并为一次持续中断。第二，Sunnyvale 核心在观测到的故障中居于核心位置。第三，当替代计算引导流量进入同一受损核心时，重路由可能扩大受影响范围。

它不支持“所有 Comcast 用户都离线”“所有路径都经过 Sunnyvale”或“该限制同样影响每台路由器”的结论。它也未揭示是否是硬上限导致路由被拒绝、撤销、刷新或反复重算。它未说明该表是 BGP 路由信息库、转发表、平台特定结构，还是其他控制平面资源。上述区分仍然是关键未知。

外部路径证据能确立什么

外部测量最有力的价值在于描述转发结果。测试从已知观测点向已知目的地发送流量，记录跳点和丢包，并在事件前、中、后比较路径。当多次测试共享受影响接口或位置时，证据可识别出共同的可观测故障点。ThousandEyes 将该方法定义为在平台上聚合观测以识别流量与路由中断。[4]

对 Comcast 首次事件而言，Sunnyvale 外的成功路径与穿越 Sunnyvale 的失败路径对比形成了有意义的边界，表明故障随路径放置发生。当部分邻近流量后续被重定向到 Sunnyvale 并失败时，该序列显示替代路由并未脱离受损域。[1]

第二次事件又出现了地理异常。部分端点位于美国中部或东部的流量被观察到经过 Sunnyvale。技术上路径有效不必然意味着在故障时在操作上可接受。BGP 与内部路由系统在既定策略和可用状态下选择路径；它们并不理解客户对地理本地性“应当如此”的直觉预期。[10] 因而问责控制不是直觉，而是可测试的策略与拓扑要求。

外部路径证据有边界。可见跳点未必解答所有封装、内部标签、路由反射或等价多路径问题。非响应接口会使解读更复杂。单一观测点看到的路径不能代表全网。命名跳点处的丢包也不总说明该响应接口本身导致丢包。ThousandEyes 结论应理解为“测量方观测”，而非“对所有路由器的特权接入”。

这些边界使得交叉佐证与留存更重要。运营者可以保留自身的路由状态、接口计数器、表占用率和变更记录，并与独立路径数据并行对齐。后续复盘便可检验某次外部路径变更是否对应已知的内部事件。没有这类联动证据时，外部方可识别失败域，但难以重建完整控制序列。

路由表容量是连续性控制

路由系统存储多类状态。BGP 发言者接收更新、应用策略、选择路径并发布被允许的结果。[10] 实现可以将接收路由、接受路由、已选路由与转发表分放在不同结构。路由反射器可减少全量内部 BGP 邻居网状的需求，但同时也成为路由信息分发路径的一部分。[12] 硬件和软件都对内存、转发表、进程资源和支持路由数量设有限制。

因此，“路由表限制”一词需要精确化。配置上限可以是有意的保护线。平台容量可成为硬工程边界。进程可能在未达到名义路由数时先耗尽内存。会话 maximum-prefix 特性可能阻断会话或提醒运维。转发表与控制平面表可能有不同容量。当前冻结公开证据未说明 Comcast 网络发生的是哪一种情况。

这类不确定性不意味着容量不可审计。运营者可以记录每个相关表的身份、支持和配置上限、正常占用、峰值占用、保留收敛余量和预期增长；并设置低于失败点的预警阈值，测试告警链路。还可以模拟受控增长，验证系统是只拒绝超出部分、保护已建转发、重启进程、撤销路由还是引发抖动。

预留容量应按故障场景定义，而非按平均日常定义。收敛期间路由器可能临时保留旧路径和新路径。维护可能带来备选路径出现。策略错误可能放大接受状态。路由反射器变更可能改变路径可见性。正确的冗余裕量应包含瞬时状态和运营者可动作时间。

一套可用的容量记录至少应包含六项测量：

每个路由与转发结构的当前占用；
硬件平台上限及任何较低的配置上限；
受控收敛期间观测到的最高瞬时占用；
告警阈值与经验证的告警传递时长；
告警与硬阈值处的文档化行为；以及
恢复流程，包括恢复流量前需满足的证据清单。

11 月事件让这一套记录具有现实意义，因为故障并未局限于原本已在 Sunnyvale 的流量。部分流量被重定向到该核心后在其中失败。[1] 如果某个节点或集群的表限制在收敛中会吸引更多路径，那么该限制就成为冲击半径控制。容量测试不仅要问“单个设备是否可撑住”，还要问“其部分故障下，其余网络如何响应”。

公开证据未给出 Comcast 缺少这些测量。证据仅表明后来被引用了“超出限制”以及外部可见路径失败。可得出的问责结论是：相关测量应可供复核，而不是“未被证明缺失”。

为什么重路由并非独立韧性

网络常被描述为具备韧性，因为流量可以走另一条路径。但最重要的问题是：独立于什么？两条路径可用不同接口，却共享同一反射器、软件版本、表上限、供电域、核心骨干或配置源。新的路径计算因此可能仍保留同一基础故障。

第一次 Comcast 事件给出具体示例。部分 Sunnyvale 外部流量最初仍可用；当它被重定向到 Sunnyvale 后也失败。[1] 协议找到了路径，但该路径仍进入受损域。从用户视角看，第二次计算并未带来连续性。

失败域分析应跨层次进行。物理层看链路、站点与电力系统是否独立。控制层看路由分发与决策过程是否能独立失效。容量层看备用节点是否有独立且足够的表冗余。运营层看是否一项变更、自动化系统或审批会影响所有替代路径。可观测层看生产控制平面受损时，监测是否仍然可用。

Clos 架构核心可提供多条路径和横向扩展能力。ThousandEyes 在解读该事件时提及 Comcast 的脊叶式架构。[1] 该架构背景解释了节点级与织物级行为的重要性，但并未披露受影响核心的具体生产拓扑，也不能证明所有路径共享单一控制依赖。

正确的验证既有对抗性，也应受边界约束。运营者可以移除节点、隔离路由反射器、限制表容量、延迟更新，并观察流量去向。测试应确认备用路径不重回原始物理和逻辑故障域，具备充足容量，且不会产生意外地理绕行。结果应从网络内外的转发平面测量中保留。

韧性并不在于拓扑图上有多条线，而在于受测故障下替代路径能够承载业务。

收敛、路由反射与路径变化

BGP 不会瞬时更新整个互联网或大型内部网络。路由器在不同时间接收变化、应用本地策略并发布新结果。RFC 4277 会审视收敛行为及路由变更后可能出现的延迟或瞬态状态。[11] 路由反射器通过允许客户节点不再建立完整内部网状会话，改变了自治系统内的传播结构。[12]

ThousandEyes 在第二次事件中观察到部分 Comcast 路由路径在完全丢包与正常可达之间切换，并将其可能原因归于控制平面抖动。[1] 公开证据未展示具体更新链路，但它说明为什么收敛行为必须纳入容量复盘。靠近上限的系统在旧新路径共存或会话重置并重新填充状态时，行为可能不同。

平滑重启与平滑关闭机制处理的是特定过渡问题。RFC 4724 描述了在某些 BGP 重启期间保持转发状态的方法。[13] RFC 6198 规定了有意关闭会话时降低流量损失的要求，RFC 8326 规定了平滑关闭机制。[15][19] 这些文档并未证明该机制在 Comcast 事件中相关、可用或已部署。

它们说明“协议已经收敛”并非完整的运营标准。一次收敛事件可同时出现丢包、瞬态环路、陈旧状态或违反预期本地性的路径变化。经测试的网络应定义每类故障的可接受收敛时延和丢包，并定义当控制平面资源、而非链路资源到达限制时应如何处理。

路由反射需要具体证据，因为逻辑冗余仍可能共享分发状态。运营者应明确每个反射器的依赖客户端、备用反射器是否有独立容量、一个反射器失状态时如何选择路径，以及上限告警如何改变传播。本文并未断言路由反射导致了 Comcast 事件，而是指出了路由表限制型复盘应检视的依赖类型。

检测必须在其上报的故障中存活

快速检测只有在告警能够送达运营者并准确指向受影响控制面时才有价值。BFD 可以快速检测某些转发路径故障。[14] 它并不足以单独诊断路由表限制。设备遥测可报告表占用率与进程健康；路由采集器和外部路径测试可揭示可达性变化；客户报告可显示服务症状。每个来源只看到事件的一部分。

有问责性的监测设计应串接这些层。表告警应说明受影响结构、当前值、配置上限和趋势。路由告警应说明状态变更。路径告警应说明受影响目的地和区域。客户影响系统应将网络事件与受影响服务对接，但不得声称超出证据支持的用户规模。

监测还需要独立的传递链路。如果告警、面板、认证或事件沟通依赖同一受损网络，运营者可能失去恢复所需工具。公开的 Comcast 资料未说明这是否发生。它仍是从故障类别推导出的可测连续性要求，而非对该事件的臆测指控。

外部测量提供了独立现实校验。ThousandEyes 在 Comcast 发布详细说明前即可比对成功与失败路径。[1][4] 运营者也可用类似外部证据，验证内部所谓“绿灯”状态是否对应真实转发。最终恢复门槛应要求内部稳定与来自多区域的外部可达性同时满足。

该门槛可避免常见收口错误：控制进程重启但转发仍不稳定却被宣告恢复。Comcast 时间线中的可见结束状态是受影响路径再次到达目的地。[1] 公开材料未披露 Comcast 的内部“恢复完成”判定标准，因此无法进行一对一比较。该事件仍然说明转发证据为何必须纳入标准。

注册记录与运行现实

ARIN 的 RDAP 将 AS7922 记录为一个已注册的自治系统资源。[9] 这类记录有意义，可帮助运营者和调查者识别与某号码资源对应的组织、维护联系人，并区分网络身份。准确性、唯一性与有效记录有助于协同。

该记录并不直接运行 BGP。它不会保存 Comcast 路由器的完整路由表，不会选择路径，不会执行表阈值，也不会将芝加哥流量从加州转向其他地方。上述结果来自运行中的软件、已安装状态、拓扑与运营策略。

该区分避免两类误读。第一类是把归属注册当作全部内部行动的证明。看到 AS7922 在路径中可确认网络上下文，但不能确认故障背后的人员、配置或法律责任。第二类是因为注册记录不能直接执行转发而否定其价值。当前有效记录在归属与协调中仍然有用，即使它不是路径控制系统。

网络问责取决于将记录层与运行现实层连接。资源标识、设备清单、路由策略、表遥测、变更记录和外部路径观测应指向同一运营事件。当这些关联被保留，复盘才能区分“谁控制了哪个决策”，而不是假定单一数据库管理全部网络。

报告问责与保密证据

FCC 的 Part 4 规则及相关指引为符合条件的通信中断建立了报告与留档要求。[7][8] 这些规则承认地理范围、持续时长、用户规模和公共安全影响可影响监督判断。同时也保护未公开的中断信息。

本文没有 Comcast 针对 2021 年 11 月事件的保密 NORS 报送。因此无法说明 Comcast 是否将根因、按监管定义计入的用户数、阈值是否达标，或向 FCC 提供了何种补救信息。

这一边界重要，因为报送与公开复盘面向不同对象。监管方可接收不宜公开的敏感基础设施细节。客户和依赖运营商仍需足够公开信息来理解故障性质并评估连续性。问责不要求公开可被攻击的拓扑细节，但要求对外界给出可信的故障类别、范围、恢复和可测预防说明。

有价值的公开记录可以说明路由状态表限制被触发、给出受影响控制域的适当层级描述、列出观测与恢复窗口、解释为何重路由进入同一域，并披露后续调整控制的措施。无需披露具体工程师姓名或敏感路由配置。

公开包缺少这些细节会限制结论，但并不证明 Comcast 未按规报告或未完成整改。它表明外部重建在技术上主要依赖外部测量。

控制方与证据义务

问责应基于实际控制，而非与标题距离。

Comcast 控制内部路由容量。运营者可盘点平台，设置或接受上限，监测占用率，预留冗余并测试故障行为。证据包括设备与软件清单、表遥测、限制配置、告警以及容量测试结果。

Comcast 控制拓扑与路由分发。运营者可设计核心失败域、路由反射关系、路径偏好与地理约束。证据包括已批准拓扑、路由策略、依赖关系映射和故障注入结果。公开资料未披露这些材料。

Comcast 控制变更与恢复。运营者可授权变更、分阶段推进、保留前后状态、执行回滚并验证转发。证据包括工单、审批、差异、命令日志、事件决策及外部恢复测试。

供应商控制其产品内的行为。路由器或软件供应商可定义容量、告警和故障模式。公开来源未识别具体供应商或产品，因此本文不能归责于特定供应商义务或缺陷。

外部观察者控制测量质量。ThousandEyes 控制其观测点、测试、路径解读与发布分析。[1]-[4] 它的证据可显示模式，但应披露边界并与内部数据对比。

客户只能控制自身的连续性选择。企业客户可用多个接入商、路径或应用区域来降低依赖，这可减轻耦合风险，但并不转移 Comcast 内部路由状态的责任。部分住宅或公共服务用户未必有可行替代。

ARIN 控制其记录的准确性与可用性。它不控制 Comcast 的内部路由。[9]

FCC 控制报告规则与受保护的监督记录。它不控制将路径引导经过 Sunnyvale 的具体路由决策。[7][8]

该分配并非声称每一方都失败。它是用于评估特定控制所需证据的映射。

可量化的整改

最有力的整改方案将该事件中的未知转化为反复执行的测试。

1. 定义所有相关上限。对每个路由与转发结构，记录平台上限、配置上限、当前占用、预期增长和紧急预留。若平台公开了不同层级状态，应拆分已接收、已接受、已选定和已安装状态。若单一总路由数较小但内部结构先崩溃，则不能仅以表头进行合规。

2. 建立多级告警。预警阈值应留足调查时间，再触发硬告警。告警需包含受影响结构、当前值、变化速率、相关邻居或进程及安全处理建议。告警交付还应通过独立管理链路验证。

3. 测试瞬态冗余。容量模型应纳入正常增长外，还要计入维护、路由重收敛、会话恢复和策略回滚期间产生的额外状态。测试应测峰值，而非只看稳定后的最终表。

4. 验证失败行为。在受控环境中接近或超过配置上限，并记录系统反应。是否拒绝新增路由、重置会话、撤销已有路由、重启进程、维持转发或产生抖动？未记录并验证的失败模式说明容量说明不完整。

5. 映射共享控制依赖。备份节点应检查是否共享同一反射器、配置系统、软件版本、表上限、供电域和管理链路。一个看似“可切换”的目标若共享同一限制资源，则不具备独立性。

6. 测试地理本地性。定义某类流量在指定故障场景下应保持在何种区域。利用内外部测量验证本地路径未在未授权情况下被重定向到遥远且受损的核心。

7. 联动控制平面与转发证据。某条控制表路由存在并不必然保证成功转发。恢复应要求成功转发测试、可接受丢包率，以及来自多区域的稳定路径验证。内部路由状态与外部路径证据应按时间对齐。

8. 分离触发、检测、响应和恢复时间点。发起事件可能早于第一条告警。外部观测者可能先察觉症状，再到运营者识别原因。回滚可能先于全局路径稳定。复盘应记录每个时间戳和证据来源，不宜将其压缩为单一中断时长。

9. 复核路由反射与收敛行为。对使用路由反射的区域，应测试客户端行为、备份反射器容量、路径可见性和状态重建。[12] 对不同计划故障定义可接受收敛与丢包标准。[11] 平滑机制可在相关场景下评估，但不应默认其能解决表资源耗尽问题。[13][15][19]

10. 保持控制平面术语精确。RFC 7908 定义了路由泄漏行为，RFC 8212 与 RFC 9234 处理显式策略与关系感知控制。[17][18][20] 本文冻结证据聚焦的是内部路径变化与表限制。运营者不应将每个意外重路由都称为路由泄漏，因为错误标签会把整改导向错误控制点。

11. 演练事故管理依赖链。当生产核心受损时，监测系统、认证服务、状态页、客服、工程沟通和变更链路应保持可用。演练应包含主网络可达性丧失的场景。

12. 发布有边界的技术说明。公开报告应标明故障类别、时间窗口、受影响控制域、恢复方式和已验证整改，且不泄露敏感拓扑细节。报告应区分可测事实、内部发现和未解决问题。

每项措施都应有通过条件。“监测表大小”不是通过条件。可执行的条件应为：“在定义的冗余区内告警，并在测试时限内通过独立链路送达，同时证明可在硬阈值前恢复足够冗余。”“具备冗余”也不是通过条件；“在隔离 Sunnyvale 核心故障时，指定流量在不跨越该受限域前提下维持可达，且丢包低于既定阈值”才可验证。

控制措施还应明确负责人和复核日期。容量会随客户、对等点、前缀、服务和流量工程策略变化。一次年度通过测试不能代表长期安全。复核结果应标明测试时间、所用软件与拓扑版本，以及未清除的例外项。

上述提议并非证明 Comcast 未执行这些措施。它们是与外部观测失败和既定限制机制直接相关、可度量的控制清单。

后续标准是背景而非裁决

源集中的若干 IETF 文档要么晚于事件，要么属于通用化总结。RFC 8212 说明当外部 BGP 策略未显式配置时应默认拒绝。[18] RFC 9234 说明 BGP Roles 与 Only-to-Customer 属性用于减少特定路由泄漏。[20] 两者都未确立内部路由表限制的直接原因，也未证明 Comcast 2021 年的配置。

RFC 7454 汇总了 BGP 运营和安全实践。[16] RFC 6198 与 RFC 8326 讨论平滑关闭要求与信号。[15][19] RFC 5880 定义了 BFD。[14] 它们帮助界定策略、计划变更和检测问题，并不能被当作公共证据证明 Comcast 违规清单。

该区分可防止复盘后见之明偏差。标准能说明某些控制是已知且可行，但不能证明其在具体平台上的合同要求、配置状态或已可阻止本次事件。此类结论必须有额外证据支撑。

本文使用标准来定义可量化替代方案，而不是用它们制造过失认定。

本文不应混淆的事项

2021 年 11 月事件并非 Comcast 的 2017 年与 Level 3 相关的 BGP 路由泄漏事件。该事件涉及外部泄漏路由和不同机制。也不是 Comcast 的 2018 年光纤中断事件——那一事件属于物理损伤和更具体公告组成的不同恢复记录。也不是 2023 年与 CitrixBleed 相关的客户数据事件，那是边缘设备暴露与身份记录问题。

本文也不把所有重路由都等同为路由泄漏。路由泄漏具有特定的域间策略含义。[17] 2021 年该材料显示的是内部或由运营商控制的路径变化，以及流量进入受损核心。没有相关路由通告和关系证据，直接称为路由泄漏缺乏依据。

该中断也不是注册机制失败。ARIN 的 AS7922 记录可帮助识别网络资源。[9] 正确注册无法阻止路由表达到限制，表限制也不会使注册记录错误。

最后，该中断也不是攻击事件。现有冻结来源未确立恶意行为、未授权访问、蓄意中断或刑事故意。

核心不确定性

精确的表和阈值仍未知。触发状态变化、设备、软件、命令和负责角色也仍未知。每个 Sunnyvale 节点的拓扑与表占用仍未知。完整的客户与服务影响范围也未知。

内部告警时序、响应决策、恢复方式与事后整改未见于公开材料；任何保密事故报送内容也不可用。无任何来源表明供应商缺陷、个人失误、过失、法律责任或量化损失。

这些缺口限制了责备叙事，却未阻断运营问题。可观测路径和已归因为限制的故障仍能明确指出完整复盘所需的证据。

结论

Comcast 的 2021 年中断显示，容量边界将网络连续性转化为问责测试。ThousandEyes 观察到两起围绕 Sunnyvale 核心的事件。先前走 Sunnyvale 的流量失败，部分此前可用流量在重路由到 Sunnyvale 后也失败。第二次事件中，不同区域的路径也被导向同一区域，并有时在丢包与可达间切换。[1][3]

后续复盘将该事件归因为无意间超出路由表限制。[2] 该解释未披露具体触发器，但定义了可控的测试面。路由表占用、阈值、瞬态冗余、失败行为、拓扑依赖、告警、回滚与转发恢复都应可被测量。

该事件也说明“图纸”和“图示”不足以代替证明。ARIN 可准确记录 AS7922。[9] BGP 可以计算新路径。[10] 拓扑可包含多个节点，但若运行状态接近上限或替代路径仍落回同一受损域，连续性仍会失败。

因此问责依据的是运营控制证据。Comcast 控制路由系统及恢复；外部观察者控制其测量；监管者控制报告要求；供应商可能控制产品行为，但公开材料未识别具体厂商；客户仅控制其可实际采用的替代方案。

可辩明的结论既不是认为某项标准会阻止该中断，也不是认为运营者从不可能故障。它是：连续性主张应依托可测冗余、独立失败域、持久监测、边界清晰公开说明和外部验证恢复。对大型网络而言，韧性不在于“有第二条路由”，而在于当主故障域失效时，第二条路由真的能工作。

Comcast 的 2021 年中断成为路由表容量问责测试

摘要