BGP邻居卡在Active或OpenSent：TCP 179、AS号与路由策略排查清单
先在两端同时查看邻居详细状态、最后复位原因、通知代码和运行配置。确认邻居地址可达，源地址与对端配置一致，TCP 179 双向未被 ACL、防火墙或控制平面策略阻断。Active/Connect 阶段重点抓 TCP SYN；OpenSent/
本文目录（16 节）
直接答案
先在两端同时查看邻居详细状态、最后复位原因、通知代码和运行配置。确认邻居地址可达，源地址与对端配置一致，TCP 179 双向未被 ACL、防火墙或控制平面策略阻断。Active/Connect 阶段重点抓 TCP SYN；OpenSent/
一、先理解六个状态的诊断边界
RFC 4271 定义了 Idle、Connect、Active、OpenSent、OpenConfirm 和 Established。Idle 表示状态机尚未开始或已因错误回到起点；Connect/Active 主要围绕 TCP 连接建立；OpenSent 等待对端 OPEN；OpenConfirm 等待 KEEPALIVE 或 NOTIFICATION；Established 才能正常交换 UPDATE、KEEPALIVE 和 NOTIFICATION。
Active 不是“本端正在主动发起所以正常”的同义词。RFC 对 Active 的描述是状态机尝试通过监听和接受 TCP 连接来获取对端。若状态在 Connect 与 Active 间循环，先查传输层。若短暂进入 OpenSent 又回 Idle，应查 OPEN 校验或对端发回的通知。
二、收集两端同一时间窗口的证据
同时保存两端的邻居摘要、详细邻居信息、路由进程日志、接口状态、路由表和配置差异。至少记录：本地与远端 ASN、邻居 IP、会话源地址、当前状态、状态持续时间、重试次数、最后通知、Hold Time、启用的地址族和软件版本。
抓包时只过滤相关地址与 TCP 179，避免捕获无关流量和敏感 UPDATE。观察 SYN 是否发出、对端是否 SYN-ACK、三次握手后谁先发送 OPEN、是否立即出现 FIN、RST 或 BGP NOTIFICATION。两端时钟应同步，否则日志很难对齐。修改前导出运行配置和计数器，保留回滚点。
三、Active状态先查IP可达性
从实际 BGP 源地址测试对端，而不是只从任意接口 ping。检查最长前缀匹配、VRF、策略路由、ECMP、返回路径和邻居 IP 是否落在正确接口。使用 Loopback 建邻时，两端必须都有到对方 Loopback 的路由；静态路由若递归失败，TCP 根本不会开始。
ICMP 成功不能证明 TCP 179 可用，ICMP 失败也可能只是被策略丢弃。应结合路由查找、带源地址的连通性测试和抓包判断。特别检查链路本地 IPv6 的接口作用域、重复地址，以及网络命名空间或 VRF 中执行命令的位置。
四、确认TCP 179与双向安全策略
BGP 使用 TCP 端口 179。抓包只看到重复 SYN，通常意味着对端未监听、返回路径错误或中间设备丢包；收到 RST 往往说明目的主机可达但没有匹配会话或服务未接受；握手完成后立即关闭则继续查 BGP 层。
检查两端接口 ACL、主机防火墙、云安全组、CoPP/CPPr 和中间防火墙。策略必须允许正确源、目的地址与 TCP 状态，不能只单向放行目的端口 179。NAT 会改变邻居看到的地址，通常不应放在 BGP 对等体之间；确实存在 NAT 时，必须确认两端邻居定义与认证使用的地址完全一致。
五、update-source与对端邻居地址必须一致
设备可能从出接口地址发起 TCP，而对端配置的是 Loopback 邻居；对端便会把连接视为未知来源。配置 update-source 后，确认源地址真实存在、处于 up 状态，并且对端到该源地址有返回路由。
抓包中的源 IP 是最直接证据。不要只看配置中出现了 update-source，因为模板可能没有应用到目标邻居或地址族。双端同时主动连接还可能产生连接碰撞，RFC 4271 使用 BGP Identifier 进行处理；偶发一次碰撞不等于故障，但持续震荡要检查重复 Router ID、地址配置和实现日志。
六、eBGP多跳与TTL问题
直接连接的 eBGP 和基于 Loopback 的多跳 eBGP 对 TTL 预期不同。若对端不是一跳可达，需要在两端按设计启用 eBGP multihop，并设置足够但不过度宽松的跳数。只在一端修改可能仍然失败。
抓包对比发出与接收 TTL，并检查中间实际跳数。GTSM/TTL Security 与普通 multihop 机制有不同验证逻辑，混用时需依据具体实现文档配置。不要把 TTL 设置为最大值当作永久修复，这会扩大不必要的接收范围；应以拓扑和安全模型确定。
七、OpenSent阶段核对ASN与OPEN参数
TCP 建立后，双方首先交换 OPEN。RFC 4271 的 OPEN 包含版本、My Autonomous System、Hold Time、BGP Identifier 和可选参数。remote-AS 写错、对端使用不同 local-AS、Router ID 非法或能力协商不兼容，都会在这个阶段触发错误并回到 Idle。
查看双方 NOTIFICATION 的错误码和子码，不要只看“OpenSent”。核对四字节 ASN 的显示与兼容配置，确认 confederation 成员与外部 ASN 的视角一致。若使用 MD5/TCP-AO 等认证，密钥、算法和应用范围必须两端相同；认证失败有时会表现为 TCP 无法稳定建立，需要结合平台日志确认。
八、OpenConfirm与Hold Timer
OpenConfirm 等待 KEEPALIVE 或 NOTIFICATION。若在此处循环，检查两端协商出的 Hold Time、报文是否被控制平面限速、设备 CPU 是否拥塞，以及中间设备是否异常终止空闲 TCP。RFC 4271 说明收到 KEEPALIVE 后才转为 Established；Hold Timer 到期则发送对应通知并释放连接。
不要在证据不足时随意把 Hold Time 调得很大。较大的计时器可能只是延迟故障发现。先确认 KEEPALIVE 是否发出和到达、进程调度是否正常、接口是否丢包，再按稳定性目标调整。BFD 可以加快故障检测，但不能修复 ASN、策略或 TCP 建链错误。
九、Established但收不到路由是另一类问题
会话 Established 证明 TCP 与 BGP 基本协商完成，不代表一定接收或发送前缀。检查正确 AFI/SAFI 是否在邻居上启用、网络是否存在于本地 RIB、聚合或 redistribute 条件是否满足，以及 inbound/
RFC 8212 更新了 eBGP 缺少策略时的默认行为：遵循该规范的实现，在没有显式 Import Policy 时不会把路由纳入决策，在没有显式 Export Policy 时不会加入 Adj-RIB-Out。升级后出现“会话正常、零路由”，不要为了恢复而启用不安全的全放行模式；应建立最小、明确、可审计的前缀和 ASN 策略。
十、路由收到但未进入转发表
收到的 BGP 路由还要经过策略、有效性和最佳路径选择。检查路由是否被过滤、AS_PATH 是否含本地 ASN、NEXT_HOP 是否可达、RPKI 状态和更优管理距离的路由。Adj-RIB-In 有前缀但 Loc-RIB 没有，与根本没收到 UPDATE 是不同故障。
使用具体前缀逐层查看 received、accepted、best path 与 FIB，而不是只看总数量。生产设备上执行显示“received-routes”的命令前确认平台是否需要预先保存入站策略前路由，避免误以为命令空白就是对端没发。
十一、按状态选择最小修复
- Idle：确认邻居没有被 shutdown，路由进程和目标地址族已启用。
- Connect/Active：修复路由、源地址、TCP 179、ACL、防火墙、TTL 或对端监听。
- OpenSent：修复 local-
AS/ remote- AS、认证、Router ID、能力或 OPEN 通知错误。 - OpenConfirm：检查 KEEPALIVE、Hold Timer、控制平面负载与连接中断。
- Established 无路由：补齐地址族和显式进出策略，检查前缀生成条件。
- 有路由不转发：检查下一跳、最佳路径、RIB/FIB 与数据平面。
每次只改变一个有证据支持的变量。能做软重配置时不要清整个 BGP 进程；必须硬复位时安排维护窗口，并监控邻居恢复、路由数量和流量路径。
十二、修复后的验收
连续观察至少数个 Hold Time 周期，确认会话稳定在 Established，重试和通知计数不再增加。核对双方接收与发送前缀数量、预期测试前缀的属性、NEXT_HOP 和实际转发路径。进行一次受控链路或会话恢复测试，记录收敛时间。
安全验收同样重要：TCP 179 只对预期对端开放；import/export policy 明确拒绝未授权前缀；最大前缀、RPKI/IRR 过滤和路由泄漏保护按设计存在；日志不包含认证密钥。最终报告应写清根因处于网络层、TCP 层、OPEN 协商还是策略层。
FAQ
BGP显示Active是否说明本端配置成主动模式？
不是。Active 是 BGP 有限状态机的一个状态，表示仍在尝试获取对端 TCP 连接。它不等于日常语言中的“主动端”，长期停留应检查 TCP 建链与邻居匹配。
ping通为什么BGP仍然Active？
ping 只证明特定 ICMP 路径可能可用。BGP 还要求正确源地址、双向 TCP 179、对端监听、返回路由、TTL 和安全策略。应使用带源地址测试并抓取 TCP 握手。
OpenSent最常见检查项是什么？
先看 NOTIFICATION，再核对双方 ASN、邻居地址、认证、Router ID、Hold Time 和能力协商。OpenSent 已越过基本 TCP 建链阶段，不应继续只调整防火墙。
Established但零前缀是否要清会话？
通常不需要。先检查地址族、前缀生成、入站和出站策略。符合 RFC 8212 的实现若缺少显式 eBGP 策略，可能保持会话却不导入或导出路由。
可以临时全放行所有BGP路由验证吗？
不建议在生产上这样做，可能造成路由泄漏。应使用一个受控测试前缀和最小明确策略验证，并保留默认拒绝、最大前缀和来源校验。
总结
BGP 邻居故障应由状态决定下一步：Active 之前查 IP 与 TCP 179，OpenSent 查 OPEN 参数和通知，OpenConfirm 查 KEEPALIVE 与计时器，Established 后再查地址族和路由策略。两端同步日志与窄范围抓包能避免盲目清会话。最后用显式 import/export policy、测试前缀和真实转发路径完成验收，才能证明会话与路由都真正恢复。
参考资料
- RFC Editor — RFC 4271, A Border Gateway Protocol 4: https:
/ / www. rfc- editor. org/ info/ rfc4271/ - RFC Editor — RFC 8212, Default External BGP Route Propagation Behavior without Policies: https:
/ / www. rfc- editor. org/ info/ rfc8212/ - FRRouting Documentation — BGP: https:
/ / docs. frrouting. org/ en/ latest/ bgp. html