摘要

  • BGP 最大前缀数是一种数量与容量控制，不是对单条路由合法性的判决。若动作被配置为关闭会话，第 N+1 条路由可能连同该会话此前提供的 N 条路由一起失去。
  • 可靠的策略必须说明针对哪个邻居和地址族、统计接收量还是策略接受量、余量依据是什么、越界后采取何种动作，并用会话、RIB、FIB 与数据包证据证明实际影响。

“只拒绝多出来的那一条”并不是默认事实

很多人第一次看到最大前缀数配置时，会自然地把它理解成一道门：前 N 条进入，第 N+1 条留在门外。这个直觉只适用于某些丢弃超额路由的实现和动作组合。若策略选择关闭会话，门并不是挡住后来者，而是把整个通道一起关闭。

这一区别决定了控制的真正风险。触发阈值的路由不必带有畸形属性，不必违反 RPKI 起源授权，也不必超出双方商业关系。它只需让某个计数器越过一个本地整数。随后，接收方可能发送 Cease 通知并关闭 BGP 连接。此前从这条连接学到的路由失去来源，路由器必须改选其他路径；没有替代者的目的地则可能直接失去可达性。

因此，最大前缀数并非单纯的配置卫生。它把容量估算转化为对一段路由关系的处置权限。这个权限可能保护有限的控制平面，也可能把一次数量偏差放大成大范围流量迁移。评价它不能只看阈值“够不够大”，还要看越界时谁失去什么。

协议给出的选择

RFC 4271 允许 BGP 发言者对从某个邻居接受的地址前缀数量设置本地上限。达到上限后，本地策略可以丢弃新收到的前缀而维持连接，也可以终止 BGP 连接。若因超出上限而终止连接，接收方应发送 Cease 通知。

RFC 4486 进一步定义了 Cease 子码 1：Maximum Number of Prefixes Reached。通知还可以携带 AFI、SAFI 和四字节上限值。它们把“会话断了”变成较精确的证据：这是数量边界被执行，而不是普通管理关闭、连接冲突或笼统的资源错误。

标准没有替运营者选择具体数字，也不可能替它选择。一个只应发布少量自有前缀的客户、一条交换中心对等连接和一条提供完整路由的上游，合理规模完全不同。接收设备的内存、CPU、收敛能力、替代路径和业务依赖也都是本地事实。标准留下选择空间，不等于允许没有解释的选择；相反，它要求运营者对自己的边界负责。

数量不能证明内容正确

最大前缀数回答的是：“来自这个来源的路由状态增长到什么程度时，接收方采取预定动作？”它不回答：“这些路由是否合法、是否符合商业关系、是否安全？”

低于阈值的路由集合仍可能包含错误起源、泄漏路径或不应接受的更具体前缀。超过阈值的集合也可能全部由正常增长构成，例如新增客户、合法拆分通告、并购后的地址整合、迁移或事件期间的流量工程。

前缀过滤、AS_PATH 策略、RPKI 起源验证、下一跳检查与 community 规则都在检验路由属性和关系。最大前缀数检验的是量。两类控制可以互补：即使每条路由形式正确，数量仍会消耗状态；即使数量不大，内容仍可能错误。但它们不能互相冒充。

若把最大前缀数称为安全控制，就必须先说出它保护的资源和假设的故障。它可以限制一次意外大表通告对路由进程内存、更新处理和收敛时间的压力，却不能验证发送者意图，也不能证明最后那条路由造成了损害。把越界直接描述成攻击，会让容量预算承担它没有证据支持的道德判断。

同一个数字可能统计不同的东西

阈值相同，不代表边界相同。关键问题往往是：计数发生在导入策略之前，还是之后？

FRRouting 的 BGP 文档说明，maximum-prefix 默认统计接受的前缀；启用 force 后，可以把被入站策略拒绝的前缀也计入，但这依赖保留相应的原始入站状态。该文档还明确提醒，销毁会话比拒绝不需要的前缀破坏性更大。

Junos 用两个控制区分口径。prefix-limit 面向接收到的前缀，accepted-prefix-limit 面向经过路由策略接受的前缀。后者可以配置关闭会话、丢弃超额路由或隐藏超额路由，不同动作保留的状态和恢复方式也不同。

策略前计数能够发现对方试图送来一张大得异常的表，即使本地过滤器最终会拒绝其中大部分。它观察的是输入压力，但也可能因为永远不会成为可用路径的状态而关闭一条有价值的会话。策略后计数更接近本地实际接受的路由规模，却可能让强过滤器遮住输入端承受的原始数量。

还要区分“前缀”与“路径”。ADD-PATH、VPN 地址族以及平台内部结构可能为同一目的前缀保留多条路径。运营者不能从命令名称推测设备版本的实际成本模型。若团队无法说清计数器包含什么，就无法说清阈值保护了什么。

四种动作，四种故障形态

告警保留会话和完整路由集，为人工判断争取时间，但不限制继续增长。告警是否有效，取决于它能否送达、有无明确负责人以及剩余容量能否覆盖响应时间。无人拥有的告警只是系统记录了自己的风险。

丢弃超额路由保留已经接纳的部分并维持会话，避免全量撤路由，却形成不完整视图。到达顺序可能决定哪些前缀被保留；计数回落后，设备也未必自动重新获取此前丢弃的路由，可能需要 route refresh 或显式重评。

隐藏超额路由保留信息但不让其参与常规选路，有利于后续恢复。然而，隐藏状态仍可能占用原本要保护的内存。若保护目标就是减少存储压力，这种动作需要特别验证平台实现。

关闭会话最果断地阻止来源继续输入，也把所有仅由该会话提供的可用路径一起撤走。流量可能转移到备份链路，路径可能变长，替代容量可能不足，还有些目的地可能完全没有备份。

厂商术语不足以替代状态核对。Cisco 的 maximum-prefix 指南记录了告警比例、默认关闭会话、仅告警模式和可选重启间隔。Arista EOS 文档则说明最大路由数越界可以禁用对等连接，而告警模式可以保留连接并丢弃后续路由。看似相近的选项，可能留下完全不同的路由集。

预算应从关系出发

RFC 7454 建议根据对等关系设置最大前缀数。对于本来只应提供有限路由的对等方，上限可以低于完整互联网路由表，从而在意外输出大表时触发保护；对于本来就应提供完整路由的上游，上限需要高于预期表规模，但仍不能超过接收设备的安全能力。

合理预算至少包含四项：关系允许的正常路由集合、实际观察到的波动与可信增长、特定平台可安全承载的状态，以及越界动作的业务代价。再为预算指定负责人、复核日期和紧急变更路径。单纯复制另一家网络的百分比，并没有回答其中任何一项。

RFC 4778 强调双方对预期交换的前缀数量进行协调，并为正常波动留出余量。上限若只存在于接收方配置里，却不在运维关系中可见，正常扩容也可能被误当成异常。RFC 7454 同时要求定期复核，因为路由数量不会永久静止。

余量最好用“能吸收多长时间的正常增长”和“能覆盖多大波动”表达，而不是一个脱离语境的比例。相同的 20%，对稳定关系可能是多年，对快速并网可能只有数周。余量过小会制造脆弱性，过大则让控制失去约束力。

定时重启可能把故障自动化

部分实现允许在 maximum-prefix 关闭后等待一段时间自动重建会话。若发送方已经撤回超额路由，这可以缩短中断；若条件没有改变，它会形成循环：建立、接收同一超额集合、再次越界、再次关闭。

经过若干分钟并不是修复证据。可靠恢复应能指出发生了什么变化：发送方撤回或过滤了超额集合，接收方经过授权修改了阈值，或者平台容量确实改变。人工 clear 也不天然更安全；若没有记录依据，它只是由人触发的同一次重试。

RFC 8538 建议在 Graceful Restart 语境下，把 maximum-prefix 的 Cease 情况视作 hard reset。其意义在于：这是有意执行的数量策略，不能像普通控制平面重启那样用静默保留陈旧路由来掩盖。恢复机制必须保留事件的真实含义。

证据必须从计数器走到数据包

配置截图只能证明团队曾打算设置某个数。完整证据链应首先保存每个邻居和 AFI/SAFI 的有效配置，包括 peer-group 继承、告警比例与动作；同时记录运行软件版本，以及该版本对“接收”“接受”“前缀”“路径”的权威定义。

越界时，需要保存最后一个被接受的更新、计数变化、Cease 代码和子码、可选 AFI/SAFI/上限数据、会话状态、空闲或重试计时器，以及可能被限频的日志。随后区分哪些路由被丢弃、隐藏、保留或撤销。

最后必须跟踪可达性。哪些目的前缀改变了最佳路径？RIB 是否真的选到了替代路径？它是否安装进 FIB？承接流量的接口与邻居是否有足够容量？关键目的类别的数据包探针是否成功？恢复前后总数相同，不能证明前缀、属性和下一跳相同；会话恢复 Established，也不能证明业务恢复。

最大前缀数成功与否，需要同时证明两件事：指定资源仍处于安全目标内，执行动作后的服务状态符合组织事先接受的取舍。计数器本身无法证明任何一件。

来源