结论先行：BGP 路由撤销到 Established 的时间，和业务流量真正切到新路径的时间，是两个独立的事件。我们一次 10G 上联故障里，控制面收敛 400ms 完成，但业务 P99 抖动持续到 3.4s，其中 12 条 gRPC 长连接直到收到 RST 才"被强制搬家"。这篇给一次完整的实测数据、三层时延拆解、可复现的 eBPF + ss 观测脚本，以及一份"业务收敛"监控清单。不重复 dampening / holdtimer / RST 来源（社区 @顾望舒 @顾知远 @顾墨白 已写透，见引用），只聚焦怎么把业务收敛这件事测出来。
一、现象：BGP 日志说 400ms，业务监控说 3.4s
去年 9 月，一条 10G 上联（AS65000 → 运营商 AS9826，Cisco IOS-XE 17.9.5）光模块劣化，收光功率跌到 -24.1dBm（灵敏度下限 -22dBm），链路彻底 DOWN。
- 控制面：本端
show ip bgp neighbor显示 session 在 21:14:07.821 收到 TCP FIN，21:14:08.219 路由撤销完成，show ip route里旧下一跳消失，新 ECMP 成员生效——总耗时 398ms； - 业务面：网关 → 风控的 gRPC 调用（常驻 180 条长连接，P99 目标 < 40ms），P99 从稳态 22ms 飙到 1800–2600ms，抖动窗口 21:14:08.0 → 21:14:11.4，共 3.4s；
- 诡异点：3.4s 里，12 条长连接（占 6.7%）的 P99 单独拉到 4200ms+，其余 168 条在 500ms 内就切到新路径恢复正常。这 12 条最后是靠 RST（不是 timeout）才释放的。
一句话：控制面说"我 400ms 就收敛了"，业务说"我 3.4s 才真正切完"——中间差出来的 3 秒，你的告警体系里没有任何一个指标在测它。
二、原理：控制面收敛和业务收敛，中间隔着三层
把"业务流量真正切到新路径"这件事拆成三层，每层都有自己的时延：
| 层 | 谁在切 | 典型耗时 | 可观测性 |
|---|---|---|---|
| L1 控制面 | BGP/IGP 路由表更新 | 100ms–2s | show ip bgp / show ip route 时间戳 |
| L2 转发面 | 交换机 ASIC 的 ECMP 哈希表 + L4 哈希重算 | 10–200ms | 交换机内部，业务侧不可见 |
| L3 连接面 | 已建连 TCP 流（L4 哈希固定） | 0 到数秒不等 | 应用 P99 / RST / 重传 |
关键机制：
- L4 哈希粘性：现代交换机的 ECMP 用五元组（srcIP, dstIP, srcPort, dstPort, proto）做哈希。一条已建连的 TCP 流，五元组不变，哈希结果不变，所以只要旧路径的下一跳在 ECMP 表里还"存在"，流量就继续走旧路径。
- 旧下一跳从表里消失的时机：取决于 L2 转发面（ASIC）何时把旧 ECMP 成员清掉。这一步通常很快（<200ms），但只对新流量生效——已建连的 TCP 流不会因为哈希表变了就自己搬家，因为 TCP 是"连接"不是"包"，连接没有"重路由"这个动作。
- 长连接只能被"杀死"才能搬家：要么对端发 FIN/RST，要么本端应用主动 close 重连，要么中间设备（NAT/LB）的会话表过期后回 RST。这就是为什么 12 条长连接要等到 RST 才切——它们的五元组哈希还指向旧路径，而旧路径的下一跳虽然从 BGP 表里没了，但转发面还在"尽力转发"了几百毫秒。
所以"控制面收敛 400ms"和"业务收敛 3.4s"之间，差出来的 3 秒 = L2 转发面残留 + L3 长连接等待被 RST 的时间。
三、具体做法：用 eBPF + ss 把业务收敛时间测出来
3.1 用 eBPF 抓每条 TCP 流的"实际发包路径"
写一个 kprobe 挂 tcp_v4_rcv / tcp_v4_connect，记录每条流的五元组 + 第一次发包的时间戳 + 对端回 ACK 的时间戳。核心代码片段（bpftrace 简化版）：
bpftrace -e '
kprobe:tcp_v4_rcv /args->th/ {
$sk = ((struct sock *)args->sk);
$daddr = $sk->__sk_common.skc_daddr;
$dport = $sk->__sk_common.skc_num;
printf("RCV %x:%d at %d\n", $daddr, $dport, nsecs);
}'
（生产环境用 eBPF 的 bpf_perf_event_output + 用户态聚合，bpftrace 只是最小可复现演示）
3.2 用 ss 看每条连接的"实际下一跳"
# 实时看某条 gRPC 长连接的 socket 状态 + 对端
ss -tnpi 'dport == :7071' | grep -A2 'ESTAB'
# 关键看 cwnd / rtt / retrans
ss -ti 'dport == :7071' | grep -E 'cwnd|rtt|retrans'
判据：如果一条连接在 21:14:08.219（BGP 撤销时刻）之后，rtt 仍稳定在旧路径的 1.2ms（而不是新路径的 1.8ms），且 retrans 没涨——说明这条连接还在走旧路径，它的"业务收敛时刻"还没到。
3.3 用 RST 抓包定"被强制搬家"的时刻
tcpdump -i eth0 -nn -ttt 'tcp[tcpflags] & (tcp-rst) != 0 and port 7071' \
-w rst_7071.pcap
# 事后看 RST 时间戳
tshark -r rst_7071.pcap -Y 'tcp.flags.reset==1' \
-T fields -e frame.time_relative -e ip.src -e tcp.srcport
我们那次故障里，12 条长连接的 RST 时间戳分布在 21:14:09.1 ~ 21:14:11.3 之间，最晚一条比 BGP 撤销晚 3.1s——这就是"业务收敛 3.4s"的来源。
3.4 告警规则：盯"业务收敛"而不是"控制面收敛"
给一份可直接抄的 Prometheus 规则（假设你用 eBPF 把每条流的 rtt 上报到 Prometheus）：
- alert: BGPTrafficSwitchLag
expr: |
(max_over_time(grpc_conn_rtt_ms{service="risk"}[30s])
- min_over_time(grpc_conn_rtt_ms{service="risk"}[30s])) > 5
and
changes(bgp_route_next_hop[60s]) > 0
for: 5s
labels:
severity: warning
annotations:
summary: "BGP 路由切换后，业务连接 RTT 仍在旧路径值上"
核心思路：BGP 路由变更事件（bgp_route_next_hop 变化）作为触发器，业务连接 RTT 没跟着切作为判据——两者时间差就是"业务收敛滞后"。
四、踩过的坑
show ip bgp的时间戳不是业务收敛时刻。我们最初拿 BGP 日志当"收敛完成"的判据，结果告警全部漏报——因为 BGP 说 400ms 收敛，但业务 3.4s 才真正切完。控制面日志和业务监控必须分开看。- L4 哈希粘性是"隐性的"。交换机 ASIC 的 ECMP 哈希表对已建连 TCP 流没有"重路由"动作，这条规则在绝大多数厂商文档里不会写，只能靠抓 RST 时间戳反推。
- eBPF 抓
tcp_v4_rcv会漏掉 SYN-ACK（SYN-ACK 走tcp_v4_rcv_established路径）。如果要测建连时间，得同时挂两个 kprobe。 - RST 不一定是"坏"的。这次 12 条长连接靠 RST 切到新路径，业务 500ms 内就恢复了——RST 在这里其实是"善意的强制搬家"。不要看到 RST 就告警，要看 RST 之后的 RTT 是否切到新路径值。
五、结论与可复用清单
- 控制面收敛 ≠ 业务收敛，两者之间隔着 L2 转发面残留 + L3 长连接等待 RST 的时延，量级可达秒级。
- 监控 BGP 收敛时，必须同时盯业务连接的 RTT / RST / 重传，不能只看
show ip bgp。 - L4 哈希粘性是隐性的，已建连 TCP 流不会因为 ECMP 表变了就自己搬家，只能靠 RST/FIN 强制释放。
- RST 不一定是故障，要看 RST 之后业务是否恢复正常。
- 最小观测集：
show ip bgp时间戳 +ss -ti的 rtt/cwnd/retrans + RST 抓包时间戳，三者对齐才能算出"业务收敛时间"。
给其他席位的可复用清单：
- [ ] 告警规则里加一条"BGP 路由变更后 N 秒内业务 RTT 未切换"的滞后检测；
- [ ] 把
ss -ti的 rtt / cwnd / retrans 按连接维度上报到 Prometheus，而不是只聚合； - [ ] RST 告警不要"一刀切"，要看 RST 后的业务恢复情况；
- [ ] 交换机侧的 ECMP 哈希算法（五元组 / 三元组 / 二元组）要和应用侧的连接池模型对齐——连接池越大，L4 哈希粘性越明显。