摘要

  • AMS-IX将2023年11月22日至23日的事件起点归因于一个客户连接关系中的LACP帧泄漏：链路本地控制帧离开其相邻关系，影响共享对等互联交换结构上其他参与者的LAG状态，并伴随BGP会话反复断开与恢复。
  • 事件的问责重点在于边界不变量能否由实际运行的转发、ACL、配置生成、跨厂商测试、告警和回退机制强制执行；平台流量回升、下游网络迁移流量与最终客户恢复则必须作为三个不同层次分别证明。

一次边界失效，而非一个笼统的“互联网中断”

2023年11月的AMS-IX事件不宜被概括成一次没有技术边界的“大规模互联网故障”。公开材料所支持的范围更窄，也更具体：事件发生在AMS-IX阿姆斯特丹对等互联平台，一类通常只在相邻系统之间有意义的LACP控制帧越过客户连接边界，干扰了其他参与者的链路聚合状态。LAG状态变化继而伴随BGP会话抖动；在平台资源压力、缓冲区占满及控制面错误传播的共同作用下，故障又触及Juniper与Extreme设备上的不同控制表面。

这条因果链的起点、放大条件和下游后果必须分开。按照AMS-IX的归因，起点是来自一个客户连接关系的LACP帧泄漏，而不是RSVP，也不能被改写成某一厂商单独导致了全部后果。资源紧张、缓冲区状态以及RSVP Path Error行为属于后续放大过程。连接网络主动关闭会话、转移流量或使用其他路径，则属于损害限制和业务恢复过程。三者相互关联，却不是同一件事。

这种区分直接决定如何讨论责任。发出控制帧的客户设备控制了帧源；AMS-IX控制共享交换结构、端口配置、准入策略、ACL生成逻辑、设备软件组合、告警和事件处置；设备实现决定过滤规则与控制面消息在运行时如何表现；连接网络则决定自己是否拥有足够的备用传输、远程对等互联、容量和切换权限。最终用户并不控制这些层次中的任何一个。

因此，问责不能止于“哪个设备先发出了什么”。真正需要回答的是：为什么一个只应对相邻链路产生意义的帧能够离开原有关系；为什么非LACP端口没有受到等价的边界保护；为什么预期存在的ACL没有在所有设备与所有端口类型上形成一致结果；为什么一个客户侧事件能够改变其他参与者的LAG和BGP状态；以及运营方如何证明这些条件如今已被消除，而不是仅仅宣布了修复方向。

事件时间线：两个明确受影响区间

AMS-IX公布的第一个受影响区间始于2023年11月22日19:08 CET，结束于23:04 CET。在这段时间内，平台出现活跃的LACP与BGP会话抖动。所谓“抖动”不是一个抽象告警词，它意味着控制状态在稳定与失效之间反复变化：链路聚合关系可能重新协商，建立在这些连接之上的BGP会话则可能随底层状态变化而断开、恢复或再次断开。

AMS-IX报告称，平台流量在低点降至2.1 Tb/s。该数字显示交换平台承载的流量发生了显著下降，但它本身不能说明多少终端用户受到影响，也不能直接换算为多少应用失败、多少数据包丢失或多大经济损失。流量离开平台可能意味着业务中断，也可能意味着连接网络将流量迁移至其他传输或对等互联路径，还可能同时包含这两种情况。缺少端到端业务和客户侧测量时，不能把平台流量图当作完整损害清单。

AMS-IX还报告，IPv4 BGP会话从885个降至550个，IPv6会话从800个降至450个。这些是交换平台观察到的BGP会话指标，不是用户数、受影响公司数、失败应用数或受影响国家数。一个BGP会话可以承载众多前缀和流量关系，也可能在业务已由其他路径承接后仍处于关闭状态。反过来，会话保持建立也不自动证明端到端服务正常。因此，这些数字证明的是平台控制面的严重波动，而不是“整个欧洲互联网”受到普遍影响。

公开时间线并未在11月22日晚间的稳定后结束。AMS-IX记录的第二个受影响区间是2023年11月23日09:38至10:25 CET。第二天再次出现问题，使“恢复”这一概念变得更加严格：某一时刻的流量回升或会话数量增加，只能证明当时的平台指标有所改善，不能单独证明根因已经被持久消除。若事件在次日重现，运营者还需要说明临时缓解、平台稳定和永久修复之间的差别。

两个区间合计提供了一个重要的验证原则。事件结束时间是运营记录的一部分，但不是耐久修复的充分证据。耐久修复需要在相同边界条件、相同端口类型和相同厂商组合上验证规则能够持续执行，并且在资源压力、配置变更和软件升级后仍然成立。否则，“事件已关闭”描述的是运营状态，而不是控制已经得到独立证明。

LACP为何必须停留在相邻关系内

LACP用于协调相邻系统之间的链路聚合。它帮助两端判断哪些物理链路属于同一聚合关系、哪些成员可以承载流量，以及聚合状态是否发生改变。这种控制信息的意义依赖明确的邻接关系：一端发出的LACP帧应由直接相邻的另一端处理，而不应像普通客户数据帧那样穿过共享二层交换结构，抵达无关参与者。

AMS-IX将事件的启动条件描述为：客户设备生成了LACP包，但其连接使用的是一个非LACP端口；Juniper提供商边缘交换机没有把这些链路本地控制帧限制在原有关系内，而是将其传播出去。公开报告没有识别该客户，也没有披露客户设备型号，因此不能据此猜测客户身份、设备品牌、配置意图或操作动机。

非LACP端口并不会让边界要求消失，反而暴露出更关键的设计问题。如果共享平台允许某种端口配置绕过本应普遍适用的链路本地帧限制，那么安全属性就被错误地绑定到了配置标签，而不是绑定到帧本身。一个稳健的不变量应当是：无论客户端口被配置为静态聚合、动态聚合还是不聚合，来自客户侧的链路本地控制帧都不得越过该客户面对的边界去影响其他参与者。

这一点解释了为什么“客户不该在非LACP端口发送LACP帧”不能构成完整答案。客户配置与设备行为当然属于事件证据，但共享平台的隔离能力正是用来限制一个参与者的错误、异常或非预期行为。若隔离只在所有客户都完全遵守预期时有效，它就不是能够承担共享基础设施风险的隔离控制。

从泄漏帧到LAG与BGP抖动

当泄漏的LACP帧抵达其他参与者的连接时，它们可能被这些连接的链路聚合逻辑视作有关本地聚合关系的控制信息。按照AMS-IX的叙述，其他客户的LAG因此作出反应，LACP状态与BGP会话发生抖动。这里的关键不是一帧数据承载了多少流量，而是一个控制帧改变了接收系统对链路可用性和成员关系的判断。

BGP通常建立在底层连接能够稳定传输控制消息的前提上。若LAG成员状态反复变化，承载BGP会话的路径可能中断或重新收敛，BGP会话随之重置。会话重置又会引起路由撤销、重新通告和路径重算。即使每个协议分别按照自身逻辑运行，协议层之间的耦合仍可能让局部二层边界失效扩展为更广泛的可达性变化。

AMS-IX自己的技术文档讨论了拓扑切换后LACP可能造成BGP会话抖动，并建议使用较短计时器。其端口安全材料也把二层环路和未经允许的帧行为视为可能危及共享以太网的风险。这些文档帮助确定平台预期管理的控制表面，但不能倒推出2023年11月22日某一具体软件缺陷。文档说明“应当控制什么”，事件报告说明“当时观察到什么”，两类证据不能互相替代。

参与者记录、AS号、接口清单、端口类型和预期策略构成重要的责任账本。它们能够说明谁连接到哪里、平台认为应当应用什么规则、事件发生时哪些关系可能受到影响。然而，记录本身不会拦截数据帧。真正决定可达性的，是交换机实际转发了什么、ACL实际匹配了什么、LAG如何改变状态、BGP会话是否存活，以及备用路径是否真的可以承载转移后的流量。

预期ACL与实际ACL之间的缺口

AMS-IX表示平台已有用于缓解LACP风险的ACL，但相关客户位于非LACP链路上。公开报告还指出，Juniper侧的出站LACP ACL没有完全按预期运行，而Extreme SLX侧的出站ACL也没有表现出预期行为。对于SLX行为，AMS-IX称尚不清楚其原因究竟是软件缺陷，还是升级后语法发生变化。

这项不确定性必须原样保留。没有公开的准确软件版本、完整ACL语法、配置历史、升级记录、厂商分析或失败测试用例，就不能断言某一厂商存在特定缺陷，更不能据此分配法律责任。能确认的是，运营者预期存在的过滤结果与事件中的实际结果之间出现了差距，而且这一差距跨越了不止一种设备控制表面。

这也是配置意图不能代替配置合规证明的原因。配置系统可能生成了一条规则，设备也可能接受了这条配置，但“已生成”和“已安装”都不等于“能够阻止目标帧”。规则可能因方向、接口类别、协议匹配、设备语法、升级差异、优先级或硬件实现而产生不同效果。只有向实际端口注入可识别的测试帧，并从其他边界确认其不可见，才能验证隔离属性。

如果端口类型决定ACL模板，那么配置系统必须覆盖所有端口类型之间的转换：非聚合端口变为聚合端口、聚合方式发生变化、成员链路增减、设备迁移、厂商切换、软件升级、配置回滚，以及人工例外。每次转换都可能造成“记录已经更新，但运行规则尚未一致”的窗口。共享交换结构不能依靠人工记忆来关闭这些窗口。

因此，最重要的修复对象不是一条孤立ACL，而是一条端到端的配置保证链：平台策略明确禁止哪些帧跨越客户边界；配置生成器把该策略映射到每种设备和端口类型；设备接受并实际执行规则；遥测能够识别规则缺失或计数异常；回归测试能够在变更后重新证明隔离；回退程序能够恢复已知安全状态。

资源压力、缓冲区与RSVP Path Error的放大作用

AMS-IX将资源饥饿和缓冲区占满与RSVP超时错误联系起来。其叙述还称，受影响的Juniper设备发送Path Error消息，在Extreme SLX交换机上造成进一步问题。这一阶段发生在LACP与BGP抖动引发平台压力之后，应被理解为放大条件，而非初始原因。

RSVP-TE用于在MPLS环境中表达和维护流量工程相关状态，Path Error则属于其错误信令机制。协议标准能够解释这些消息的角色，但不能仅凭标准文本重建事件中每台设备的内部状态。公开材料没有给出完整的RSVP消息量、具体错误代码序列、缓冲区遥测、CPU或内存曲线，也没有提供厂商的最终根因报告。

因此，能够作出的审慎判断是：AMS-IX报告了一个跨厂商控制面级联，资源压力与Path Error行为扩大了由前序抖动造成的问题；不能说RSVP首先制造了LACP泄漏，也不能把这一精确级联推广为所有MPLS网络的固有结果。不同网络的拓扑、软件、策略、资源余量和保护机制不同，标准描述的可能行为不等于所有部署都会复现相同事故。

不过，这一放大过程仍然具有普遍的验证意义。跨厂商平台不能只在空载和正常消息速率下测试互操作性。真正的故障模式往往出现在控制状态频繁变化、缓冲区接近上限、错误消息突增、路由重新收敛和配置操作同时发生时。测试若只证明单一设备能够解析协议，而不证明整个平台在压力下保持边界和速率约束，就遗漏了最关键的系统风险。

跨厂商回归测试应当模拟链路本地帧误入、LAG成员连续变化、BGP会话重复重置、资源压力和错误信令突发，并观察不同厂商设备之间是否形成反馈回路。测试结果还应区分设备拒绝、限速、丢弃、告警和控制面保护行为。目标不是要求故障永不发生，而是证明一个局部输入不能在没有边界和阻尼的情况下持续扩大。

平台稳定、流量迁移与客户恢复是三种证据

事件期间，一些连接网络采取了自己的缓解措施。冻结证据所覆盖的记录显示，Total Uptime转移了流量并记录恢复情况；NFOrce关闭相关会话以缓解数据包丢失；EDPnet记录了服务影响、备用容量和恢复进展。这些记录证明部分连接方能够采取独立行动，但不能被扩展为所有参与者都拥有同等选择。

关闭AMS-IX会话或将流量转向其他路径，可以降低某个网络继续暴露于不稳定交换结构的程度。与此同时，这种操作会把流量压力转移到其他传输商、远程对等互联或私有互联路径上。备用链路若容量不足、路由策略未准备好或切换权限不明确，迁移本身也可能造成拥塞和延迟。因此，“存在备用路径”和“备用路径可在真实故障中承担流量”是两项不同主张。

RIPE Atlas分析提供了端到端和路径层面的观察。冻结材料允许得出的结论是：有些路径绕开了受损区域，有些路径失败或发生改变。这种测量有助于识别互联网是否以及如何绕行，但探针位置、目标选择、测量时间和路径可见性都有限。它不能枚举所有客户、所有应用或全部欧洲流量，也不能证明每次路径改变都由同一机制直接造成。

这些观察共同支持一种分层恢复模型。第一层是交换平台稳定：LACP、LAG、BGP和相关控制面指标不再继续抖动。第二层是流量位移：连接网络将部分业务转向其他可用路径。第三层是端到端客户恢复：实际服务重新达到可接受的可达性、性能和可靠性。平台流量回升不自动等于第三层，流量离开平台也不自动等于业务失败。

问责记录应明确每一层使用什么证据。平台层可以使用会话数量、端口状态、控制面错误率、缓冲区和流量数据；网络运营者层可以使用路由变化、会话撤销、替代路径容量及拥塞数据；最终服务层则需要应用可用性、客户遥测或端到端测量。把这些证据混在一张流量图里，会让“恢复”看起来比实际更确定。

备用传输的价值及其不平等条件

事件显示，独立传输和远程对等互联可以成为损害限制工具。连接网络若事先拥有另一家传输商、另一个交换点、远程对等互联服务或私有互联，并且预留足够容量，就可能在本地交换结构不稳定时撤销会话并迁移流量。这种能力使一个共享平台故障不必完全决定该网络的外部可达性。

但备用路径不是纸面拓扑。它至少包含四项可运行条件：路由策略允许切换；备用链路有足够容量；监控能够及时识别何时应切换；值班人员或自动化系统拥有执行权限。只满足其中一项，仍可能在事故中形成不可用的“名义冗余”。

备用能力还受到成本和组织结构约束。规模较大的网络可能更容易购买多处互联和备用容量，小型参与者则可能更依赖单一交换点或单一上游。公开材料不足以比较AMS-IX各参与者的商业条件，因此不能给出参与者级别的成本判断。但在控制设计上，应当承认不同网络的逃生能力并不均等，不能把平台隔离失败的后果简单归咎于下游没有绕行。

交换平台与连接网络承担的是互补责任。平台应阻止一个客户的链路本地控制信息跨越边界；连接网络则应评估自身对单一互联点的依赖，并测试可用的替代路径。后者不能替代前者：即使每个参与者都有备用传输，共享交换结构仍有义务验证隔离。前者也不能替代后者：再成熟的平台也无法保证永远不发生设备、软件、供电或操作故障。

从“修了什么”转向“怎样证明修复有效”

AMS-IX列出的后续动作包括：把ACL应用到非LACP链路；增强配置系统中的ACL创建；检查Juniper和Extreme设备上的出站LACP ACL；研究针对Slow Protocol BPDU的告警；以及修订技术邮件列表的沟通规则。这些措施回应了事件暴露出的多个控制缺口。

这些内容应当被称为已宣布的修复承诺，而不是已经得到独立验证的耐久修复。公开证据没有展示所有相关端口的当前配置快照、跨厂商测试结果、升级后的回归记录、告警演练结果或长期有效性数据。运营者说明准备采取哪些行动，具有重要证据价值，但声明不能自行证明实施范围和持续效果。

可验证修复首先需要一个明确的帧边界不变量：任何客户面对的端口，无论是否启用LACP，都不得把客户产生的LACP或其他受限链路本地控制帧转发给其他客户。这个不变量应当以平台策略、配置生成规则、设备级测试和持续监测四种形式同时存在。缺少任何一层，都可能让意图与运行状态再次分离。

其次，配置合规必须从静态检查扩展到行为检查。静态检查可以确认预期ACL是否出现在配置中；行为检查则要证明目标帧确实被正确方向、正确接口和正确硬件路径拦截。两者结合才能发现“配置存在但没有生效”“语法被接受但语义变化”或“某端口类别未被模板覆盖”等问题。

再次，跨厂商回归测试不能局限于一次修复窗口。任何涉及交换机软件升级、配置模板变更、端口迁移、ACL生成器修改或厂商组合变化的操作，都应重新运行关键测试。测试需要保留版本、输入帧、期望结果、实际结果和失败处置记录，使后续人员能够判断当前平台是否仍满足原有隔离保证。

告警设计也应围绕控制边界，而不只是围绕流量下降。若Slow Protocol BPDU或其他不应跨越端口的帧出现在不应出现的位置，平台应在其引发大规模LAG和BGP变化前发出告警。告警还需要经过演练，证明它能够到达有权限采取行动的人，并且不会因噪声过多而被忽略。

回退证据同样重要。配置变更或软件升级可能改变ACL语义，因此运营方需要证明能够恢复到经过验证的安全状态。回退计划应包含触发条件、配置与软件基线、执行权限、预计影响以及回退后的行为测试。没有实际演练的回退文件，只能说明存在计划，不能说明事故中一定可用。

最后，连接网络应测试替代传输或远程对等互联，而不仅是在网络图中画出备用线。测试要确认切换后的BGP策略、路径可达性、容量、时延和运维权限，并记录在主要交换会话不稳定时如何安全撤销或降低优先级。这样，平台隔离与下游逃生路径形成两个独立防线，而不是相互推卸风险。

沟通是控制面的一部分，但不是技术修复的替代品

事件期间的沟通决定连接网络能否及时判断应继续等待、主动撤销会话还是迁移流量。技术邮件列表规则、状态更新内容和时间戳因此属于事故控制的一部分。若状态消息只说“正在调查”，却没有说明受影响平台、会话行为、建议动作和下一次更新时间，参与者很难把平台信息转化为自身操作。

不过，沟通改善不能替代隔离修复。更快地通知参与者一个链路本地帧正在跨越边界，仍然意味着边界已经失效。有效的事件治理需要同时保留技术证据和决策证据：前者说明设备与协议发生了什么，后者说明何时识别问题、谁有权采取措施、为何选择某项缓解，以及何时认为可以恢复正常路由。

对外通报还应区分确定事实、运营归因和未决问题。事故时间、平台指标和观察到的会话变化属于可记录事实；LACP泄漏、ACL表现和跨厂商级联是AMS-IX给出的归因；厂商根因、客户设备详情、完整损害及永久修复有效性仍有未公开部分。清晰标注这些层次，有助于参与者据此行动，也能避免把初步判断固化成未经证明的结论。

问责不是先寻找法律过错，而是先定位控制与证据

基础设施问责可以在不指控疏忽、违法、违约、恶意或法律责任的前提下进行。它首先要求绘制控制地图：谁能产生输入，谁能限制输入，谁控制共享系统，谁实现协议行为，谁拥有备用路径，谁保存能够验证这些事实的记录。控制所在之处，通常也是需要提供证据之处。

在本事件中，身份未公开的客户控制帧源，但公开资料不足以判断该帧为何产生。AMS-IX控制共享交换结构和端口策略，因此需要证明平台如何阻止帧跨客户边界。Juniper与Extreme设备承载了不同控制行为，但缺少软件版本和厂商结论，不能从事件结果推断单方过错。连接网络控制自己的路由与备用路径，但其能力和容量各不相同。

这种方法避免两种误区。第一种是把所有责任归给“错误客户包”，忽略共享平台存在的目的就是限制单一参与者影响。第二种是因为平台出现故障就直接推定运营者或厂商存在法律过错。公开事实足以要求边界证明、配置合规和修复验证，却不足以裁定合同义务、注意标准、损失归属或责任比例。

最终，问责的单位不应只是机构名称，而应是可检验的控制承诺。例如，“LACP帧不会跨越客户边界”可以通过帧注入测试验证；“所有端口类型都应用ACL”可以通过配置与行为合规检查验证；“跨厂商级联受到控制”可以通过压力回归验证；“备用路径可用”可以通过演练和容量数据验证。可检验承诺比模糊的“系统已经加固”更接近运行现实。