关键词：BGP、状态机、Idle、Connect、Active、OpenSent、OpenConfirm、Established、故障排查

第83篇：BGP 状态机：Idle→Connect→Active→OpenSent→OpenConfirm→Established

一、引言

BGP 状态机定义了 BGP 邻居会话从初始到建立的完整过程。BGP 邻居关系经历六个状态的逐步迁移，最终达到 Established 状态后才能进行路由交换。

理解 BGP 状态机的每个状态及其迁移条件，是排查 BGP 邻居故障的核心技能。当 BGP 邻居卡在某个中间状态时，通过分析当前状态和进入该状态的条件，可以快速定位故障根因——"BGP 邻居卡在哪，故障就在哪"。

二、核心概念

2.1 BGP 六种状态

2.2 各状态的核心特征

三、技术细节

3.1 Idle 状态

Idle 是 BGP 会话的初始状态。在此状态下，BGP 等待启动事件：

• BGP Start 事件：手动启动 BGP 进程或配置 BGP 邻居后触发
• 进入 Idle 后，BGP 重置所有计数器，选择最佳 BGP Identifier（Router ID），准备进入 Connect 状态

常见卡点原因： - BGP 进程未启动或未配置 - 邻居配置被删除（undo peer） - 管理员手动重置 BGP 会话（reset bgp all） - 最大 BGP 邻居数限制达到

3.2 Connect 与 Active 状态

这两个状态都围绕 TCP 连接的建立，是 BGP 故障最常见的卡点区域：

Connect ↔ Active 循环： - 如果 TCP 连接持续失败，BGP 在 Connect 和 Active 状态之间循环 - Connect 状态等待 Connect Retry Timer（默认 60 秒），超时进入 Active - Active 状态尝试发起 TCP 连接，失败后返回 Connect - 每次循环等待的时间遵循 Back-off 机制（逐步增加重试间隔） - 最大重试间隔受 BGP 重试定时器（Retry Timer，默认 120 秒）控制

为什么设计两个状态： - Connect：本端被动等待（监听对端连接或等待之前发起的 TCP 连接完成） - Active：本端主动发起 TCP SYN - 两者交替确保即使在一端主动、另一端被动的情况下也能建立连接

3.3 OpenSent 状态

TCP 连接建立后，本端发送 Open 报文并进入 OpenSent 状态：

迁移条件： - 收到对端的 Open 报文且参数协商成功 → OpenConfirm - 收到 Notification 报文 → Idle - Hold Timer 超时（对端未发送 Open）→ Idle - TCP 连接断开 → Idle

常见卡点原因： - 对端未发送 Open 报文（对端 BGP 未启动或未配置本端为 Peer） - Open 报文参数不匹配（AS 号、Router ID、Hold Time、版本） - 中间防火墙过滤了 BGP Open 报文（但允许 TCP 连接） - 对端 Router ID 与本地冲突

3.4 OpenConfirm 状态

Open 协商成功后进入 OpenConfirm，发送 Keepalive 并等待对端 Keepalive：

迁移条件： - 收到对端 Keepalive → Established - 收到 Notification → Idle - Hold Timer 超时 → Idle

常见卡点原因： - 对端未发送 Keepalive（对端 Open 协商后失败） - Keepalive 报文被中间设备过滤 - Hold Time 配置不一致导致双方协商结果不同

3.5 Established 状态

BGP 会话完全建立，可以交换 Update 报文：

维持条件： - 持续在 Hold Time 内收到 Keepalive 或 Update 报文 - TCP 连接保持活跃 - 不收到 Notification 报文

退出条件： - Hold Timer 超时（Hold Time 内未收到任何 BGP 报文） - 收到 Notification 报文 - TCP 连接断开 - 管理员手动重置（reset bgp peer） - 对端配置变更导致 Cease 通知

四、实战配置/案例分析

4.1 BGP 状态查看与诊断

# 查看BGP邻居状态总览
display bgp peer
  IPv4 Unicast Address     PeerState  Receives  Sends
  10.1.1.2                 Idle       0         0
  2.2.2.2                  Established 1234      1567

# 查看单个Peer的详细状态
display bgp peer 10.1.1.2 verbose
  Peer: 10.1.1.2
  State: Idle
  Description: BGP is idle
  Connect retry timer : 60(s)
  Keepalive timer : 60(s)
  Hold timer : 180(s)

# 实时监视BGP状态变化
terminal monitoring
terminal debugging
debugging bgp events
debugging bgp packet all

4.2 案例分析：卡在 Connect/Active 状态（最常见故障）

故障现象：BGP 邻居 10.1.1.2 状态在 Connect 和 Active 之间循环，始终无法进入 OpenSent。

排查步骤：

1. 理解当前状态的含义：Connect/Active 循环说明 TCP 连接无法建立。BGP 还没到报文协商阶段。

2. 检查 TCP 179 端口连通性：

[R1] telnet 10.1.1.2 179
  # 无法连接,TCP 179端口不可达
  # 尝试普通ping: ping 10.1.1.2 → 通(说明IP层可达,但端口被阻挡)

1. 检查 IP 路由：

[R1] display ip routing-table 10.1.1.2
  # 有到达10.1.1.2的路由,说明不是路由问题

1. 检查防火墙/ACL：

[R1] display acl all
  # 发现ACL 3000拒绝了TCP 179端口的流量
  rule deny tcp destination-port eq 179

1. 根因：防火墙 ACL 阻断了 TCP 179 端口的通信。

2. 修复：

[R1] acl 3000
[R1-acl-adv-3000] rule permit tcp destination-port eq 179

4.3 案例分析：卡在 OpenSent 状态

故障现象：BGP 邻居状态卡在 OpenSent，TCP 连接已建立但未进入 OpenConfirm。

排查：

1. TCP 连接已建立（否则不会进入 OpenSent），问题出在 Open 报文协商阶段。

2. 检查调试信息：

debugging bgp packet open
terminal debugging
 *Sep 01 10:00:01: R1/BGP/OPEN: Sent Open message to peer 10.1.1.2
 # 本端已发送Open,但长时间未收到对端Open
 # Hold Timer超时后回退到Idle

1. 检查对端 BGP 配置：

# 在对端R3上检查
[R3] display bgp peer 10.1.1.1
  # 对端未配置10.1.1.1为Peer!

1. 常见根因：
2. 对端未配置本端为 BGP 邻居
3. 对端的 AS 号与本端配置的不一致

4. 对端 Router ID 与本地冲突

5. 修复（在对端添加邻居配置）：

[R3] bgp 200
[R3-bgp] peer 10.1.1.1 as-number 100
[R3-bgp] peer 10.1.1.1 connect-interface GigabitEthernet 0/0/1

4.4 案例分析：Established 后频繁闪断

故障现象：BGP 邻居反复在 Established 和 Idle 之间切换，路由不断震荡。

排查：

1. 查看日志：

display logbuffer | include BGP
 *Sep 01 10:00:00: BGP%%: Peer 10.1.1.2 established.
 *Sep 01 10:02:30: BGP%%: Hold timer expired for peer 10.1.1.2.
 *Sep 01 10:03:00: BGP%%: Peer 10.1.1.2 established.
 *Sep 01 10:05:30: BGP%%: Hold timer expired for peer 10.1.1.2.

1. 现象规律：大约每 2.5 分钟断开一次，对应 Hold Timer（180 秒）超时。

2. 检查报文统计：

display bgp peer 10.1.1.2
  Keepalive: sent 1500, received 5    # 接收远少于发送

1. 根因：链路存在严重的单向丢包，Keepalive 报文到达对端但对端的回包丢失。

2. 解决方案：

# 方案1：排查并修复链路丢包问题（治本）
# 方案2：临时增大Hold Timer
[R1] bgp 100
[R1-bgp] timer keepalive 90 hold 270
# 方案3：启用BFD加速检测
[R1] bfd
[R1] bgp 100
[R1-bgp] peer 10.1.1.2 bfd enable

五、总结

思考

1. BGP 在 Connect 和 Active 状态之间循环时，为什么需要 Back-off 机制（逐步增加重试间隔）？如果不使用 Back-off 会发生什么？
2. 如果 BGP 邻居状态从 Established 突然回退到 Idle，可能的原因有哪些？按概率从高到低排列。
3. BGP 状态机中，从 OpenSent 到 OpenConfirm 的迁移需要满足什么条件？如果 Open 参数协商失败，BGP 会发送什么报文？随后回到哪个状态？

下篇预告：第84篇：BGP 路径属性：AS_PATH、Next_Hop、Origin