首页 / 内容指南 / 当前文章

BGP Maximum Prefix exceeded：邻居关闭与重连循环排查

发布于 2026-08-26 · routecfg.com 编辑部

BGP 邻居原本 Established，收到路由后突然断开，日志出现 Maximum number of prefixes reached、Cease/Maximum Number of Prefixes Reached，随后每隔几分钟重连又再次关闭。这通常是最大前缀保护生效，不是普通 TCP 抖动。它用于防止对端泄漏全表或策略失控耗尽路由器资源，不能只通过无限调高阈值恢复。

本文目录（20 节）

先确认是哪一侧主动关闭

在两端保存邻居状态变化、Last Reset、Notification code/subcode、AFI/SAFI、当前/峰值前缀数量和配置阈值。RFC 4486 为 Cease 通知定义了 Maximum Number of Prefixes Reached 子码，有助于与管理员手工关闭、配置变更或资源耗尽区分。

抓包若可用，确认 NOTIFICATION 的发送方向和时间；日志中只看到“connection closed”不能证明本机触发。两端时钟必须同步，才能把路由更新峰值和会话重置关联。

Maximum Prefix 保护什么

最大前缀限制通常按邻居和地址族统计接收的前缀。当数量超过配置上限时，路由器可以告警、关闭地址族/会话，或按实现执行其他保护行为。它不是检查路由是否最终安装进 RIB，也不是限制本机向对端通告多少路由。

即使大量路由因策略或下一跳问题没有进入主路由表，接收侧的计数仍可能达到保护条件。排障要查看该邻居对应 AFI/SAFI 的接收/接受计数和实现定义。

找到触发的 AFI/SAFI

同一 BGP session 可承载 IPv4 unicast、IPv6 unicast、VPN、EVPN 等多个地址族。一个地址族的前缀异常可能触发会话级影响，具体取决于平台能力与配置。

逐个地址族查看启用状态、阈值、当前 prefix received/accepted 和最近增长。不要只看 IPv4 summary；EVPN Type-5 或 VPNv4 路由激增也可能是来源。

received 与 accepted 计数差异

平台可能分别展示对端发来的路由、入站策略后接受的路由和 best path/RIB 中安装的路由。maximum-prefix 的计数点可受实现选项影响。必须查 FRRouting 当前命令语义和运行配置，不能用另一个厂商经验推断。

保存 show bgp ... neighbor 详细信息和策略结果。若需要查看被策略拒绝的 received routes，确认是否启用了相应 soft-reconfiguration 或 Adj-RIB-In 能力及资源成本。

threshold 只是预警比例

maximum-prefix 配置常包含阈值百分比，用于在接近上限时提前告警。阈值不是新的硬上限。例如 limit 为 100000、threshold 为 80，通常意味着到 80000 时警告，到 100000 才执行超限动作。

监控应同时采集当前数量、硬限制和阈值，计算剩余空间。不要把 warning 日志误报为会话已经关闭，也不要等到 Cease 后才第一次观察增长。

warning-only 的边界

warning-only 可在超限时只记录警告而不关闭邻居。它适合临时观测或某些受控场景，但会放弃最关键的资源保护。如果对端持续泄漏，路由数量、内存和控制平面负载仍会增长。

不能把 warning-only 当作长期“修复”。启用前必须确认设备容量、泄漏上限和监控告警，并设明确回退时间。更优先的做法是修复入站策略或对端通告。

restart timer 为什么形成循环

某些配置可在 maximum-prefix 触发后等待指定时间自动重启邻居。若对端通告和本地策略未改变，重连后路由再次超过上限，会话就循环 Established→接收路由→Cease→等待→重连。

查看 Last Reset 和周期是否与 restart 参数一致。循环期间不要不断手工 clear，这会加剧更新风暴。应先在维护窗口阻止错误路由、修正过滤或调整经过容量评估的阈值，再恢复。

先判断是正常增长还是路由泄漏

业务扩张、全表规模增长、新租户或 EVPN endpoint 增加都可能导致长期稳定增长；策略误配、默认路由展开、错误 redistribution 或 route reflector 反馈则会造成突然跃升。

比较触发前后的前缀集合、来源 AS、下一跳、community、路径长度和 NLRI 范围。按聚合前缀、peer、route type 分布找出增长来源。不要把完整客户路由表直接粘贴到公开工单。

入站策略是否在正确地址族生效

route-map/prefix-list 可能绑定在错误方向、错误 AFI/SAFI，或更新后未执行 route refresh。配置存在不等于当前 Adj-RIB-In 已重新评估。

查看邻居地址族下实际 inbound policy 名称和计数器。修改后优先使用受控的 soft inbound/route refresh 重新应用策略；是否需要 hard clear 取决于设备能力和变更范围。

Route Refresh 与 Soft Reconfiguration

若双方支持 Route Refresh，本机可以请求对端重新发送路由，以便应用新入站策略。soft-reconfiguration inbound 保存额外的接收路由副本，便于查看/重算，但会增加内存。

不要为一次排障在所有全表邻居永久开启额外存储。根据 FRRouting 版本和设备资源选择，并在操作前估算路由数量与内存。

聚合与去聚合

对端从聚合前缀改成大量更具体前缀，会显著增加计数，即使覆盖的地址空间相同。检查是否撤销 aggregate、启用 redistribute connected/static，或策略允许了不该外发的 more-specific。

修复应在路由源头和边界同时进行：源头恢复合理聚合，接收侧保留最大前缀与 prefix-list/AS-path/community 保护。只在接收侧提高 limit 会掩盖泄漏。

Route Reflector 与环路保护

RR 环境中错误的 client 配置、策略或多路径可能放大可见路由，但 BGP 的 AS_PATH、ORIGINATOR_ID、CLUSTER_LIST 等机制用于防环。不要把重复路径数量与独立前缀数量混为一谈。

检查计数单位是 unique prefixes 还是 paths。Add-Path 等能力可能增加 path 数量，具体 maximum-prefix 是否按前缀或路径计数需查实现。

安全调整阈值

若确认增长合法，基于历史峰值、预测增长、设备内存、RIB/FIB 容量和故障冗余调整上限。保留预警空间，不要直接设置为当前值的十倍。对双机或 RR 还要考虑故障时路由集中到单节点的峰值。

变更前记录旧值和回滚命令，先在一条受控邻居验证。调整后监控内存、CPU、更新队列、RIB/FIB 安装和收敛，不以会话 Established 作为唯一成功标准。

手工恢复的安全顺序

第一步，保持错误邻居停止或受控，避免循环。第二步，确认触发 AFI/SAFI 和实际前缀源。第三步，在对端停止错误通告或本端修正入站策略。第四步，离线/受控计算预计接受数量。第五步，必要时调整经过容量评估的 limit。第六步，再清除 maximum-prefix 状态或恢复邻居。第七步，观察路由数量稳定后验证转发。

若平台支持自动 restart，修复窗口内可暂时禁用以避免反复重连；任何配置变更必须有回滚点并遵守网络变更流程。

监控与告警

为每个关键 peer/AFI 采集 current prefixes、limit、threshold、last reset reason、session uptime 和更新速率。告警应在预警阈值前触发趋势异常，并区分合法增长和瞬时爆发。

同时监控内存、BGP input queue、RIB/FIB、route installation failures 和 CPU。最大前缀未触发不等于资源安全，尤其在多路径或复杂属性场景。

一套逐层排查流程

第一步，确认 Notification 与主动关闭侧。第二步，定位 AFI/SAFI 和实际限制。第三步，区分 received/accepted/installed。第四步，比较前缀增长时间线。第五步，检查入站策略绑定与计数。第六步，识别泄漏、去聚合或合法增长。第七步，修复源头后受控 route refresh。第八步，根据容量调整限制并验证数据平面。

修复后测试正常数量、接近 threshold、超过 limit、策略拒绝、自动 restart 和回滚。不能在生产主动注入危险全表；应在实验环境或合成邻居完成超限测试。

常见错误

常见误区包括：把 Cease 当 TCP 故障；只看 IPv4；混淆 accepted 与 installed；把 threshold 当硬上限；长期 warning-only；自动 restart 未修源头；反复 hard clear；直接把 limit 提高十倍；只验证 Established 不检查路由与 FIB。

常见问题

Maximum Prefix 超限是谁的问题？

它说明接收侧观察到的路由数量超过本地策略上限。根因可能是对端泄漏、本端过滤失效、合法增长或阈值过旧，需要比较路由集合和容量。

warning-only 是否可以避免断线？

可以只告警而不执行关闭，但也失去资源保护。只能在容量明确、监控完善和时间受限的场景使用，不能替代过滤修复。

为什么自动重连后几分钟又断？

restart timer 恢复会话后，对端再次发送同一批超限路由，保护再次触发。先修通告/策略或安全调整限制，再恢复。

提高 maximum-prefix 会立即恢复吗？

取决于平台和邻居状态。可能需要清除超限状态或重启地址族。操作前先验证新上限符合内存与 RIB/FIB 容量。

入站 prefix-list 已修正为什么数量没变？

新策略可能尚未对现有路由重新评估，或绑定在错误 AFI/方向。检查运行配置和计数，按能力执行受控 route refresh/soft inbound。

总结

BGP Maximum Prefix 是资源与泄漏保护，不是妨碍建邻的无关限制。可靠排障要确认 Cease 方向、触发地址族、计数口径和路由增长来源，再修复策略或源头。阈值调整必须基于容量，恢复要避免 restart 循环，并用 RIB/FIB 和数据平面验证，才能既恢复会话又保留安全边界。

来源资料