现象

1. 交换机与服务器直连建立 eBGP 邻居。
2. 服务器重启 BGP 程序，要花 30s-120s 的时间才能重新到Established 状态。
3. 抓包所见：
   1. 服务器程序发出 BGP notification 报文到交换机，随后双方四次挥手。
   2. 7s后服务端发起 TCP 连接，双方三次握手完成。
   3. 随后服务器发出 open 报文，交换机随即发出 TCP RST 将连接重置。
   4. 2s后交换机发起 TCP 连接，双方三次握手完成。
   5. 随后交换机发出 open 报文，服务器随即发出 TCP RST 将连接重置。
   6. 11s后，服务器发起 TCP 连接，双方三次握手，顺利交互 open 报文等后到达 Established 状态。
   7. 双方前两次 open 报文均与最后一次成功建立的 open 报文无差异。

需求

业务方需要解释为何两次RST后才能到达 Established 状态。

分析

查看文献及rfc4271发现：

Idle state:

Initially, the BGP peer FSM is in the Idle state. Hereafter, the BGP peer FSM will be shortened to BGP FSM. In this state, BGP FSM refuses all incoming BGP connections for this peer. No resources are allocated to the peer.

当邻居状态机处于 Idle 时，会拒绝来自邻居的传入连接。与抓包所见现象相符。

交换机及服务器侧记录邻居状态。

发现：

1. 交换机需要约9s的时间才能离开idle状态。
2. 服务器侧邻居状态大致变化情况：active -> idle -> active。

根因

1. 服务器第一次尝试连接时候交换机的邻居状态机尚处于 idle 状态。故而收到 open 报文后发送 RST 终结了来自服务器的连接。
2. 交换机的 RST 导致服务器侧邻居状态机进入了 idle 状态，故而当交换机离开 idle 状态发起连接时被服务器侧发出 RST 拒绝连接。
3. 交换机侧对邻居状态的实现有优化，当收到 RST 后不进入 idle 而进入 active 状态等待重连。
4. 最后，服务器状态机离开 idle ，发起连接，交换机处于 active ，连接成功建立。

处理

1. 服务器侧改进实现。
2. 与交换机厂商联系，确认是否可以降低停留在idle的时间。

感谢

感谢雨佳同学的预分析，为后续的分析节省了大量的时间。

感谢 DennisCai 同学、吴同学的各种实验、数据采集，验证了理论推测。