多机房组网路由收敛慢的排查顺序，核心是从数据面现象反推控制面状态：先确认丢包范围，再沿着物理链路、邻居关系、路由策略、计时器、硬件转发表逐层定位，多数情况下半小时内能找到根因。
先分清是控制面收敛慢，还是数据面本来就在丢包
很多运维一遇到跨机房访问卡顿,就默认是路由收敛问题，结果折腾半天发现是光模块老化。开搞之前，先花三分钟回答一个问题：当前是路由表切换慢，还是数据包压根没走对路？
- 看现象：跨机房ping丢包是持续性的，还是只在链路切换瞬间出现，持续丢包更像是物理层问题。
- 看监控：记录核心交换机上BGP邻居状态翻转次数、OSPF邻居状态变化时间点，对比业务故障时间线。
- 看路径：用
mtr或traceroute连续跑几轮，观察中间跳的地址是否变化，路径稳定但丢包，基本排除路由收敛问题。 - 看接口：登录设备执行
display interface，重点看CRC errors和input errors计数，只要在增长，先处理物理层。
业内专家指出,相当一部分"路由收敛慢"的工单，最终定位是光纤收发器故障或光模块发光功率衰减，路由协议只是背锅侠，数据面没确认清楚就调协议参数，等于白干。
BGP路由收敛慢怎么排查？从邻居关系开始
确认是控制面问题后,BGP场景按下面的顺序走，多机房组网大多跑BGP，收敛慢的瓶颈往往出在邻居状态感知不及时。
第一步：看邻居是否还在Established状态
执行display bgp peer（华为）或show bgp summary（思科），留意State列，如果邻居经常在Established和Connect之间跳变，说明物理链路或对端设备有问题。
第二步：检查Keepalive和Holdtime
BGP默认Keepalive 60秒，Holdtime 180秒，假设链路凌晨三点闪断，设备可能撑满180秒才把邻居置为Down，再花几十秒重新建连，业务中断早就超时了，查看show bgp neighbor输出里的Last state change和Last reset字段，能判断这次收敛等了多久。
第三步：盯Update消息的流动
抓包是判断BGP收敛慢在哪一跳的关键,在两台机房边界路由器上分别
tcpdump -i 接口 port 179，观察三种情况：
- 对端发了Update,本机没收到中间链路或策略丢弃。
- 本机收到Update,但BGP路由表没变化入方向策略过滤或RIB处理慢。
- 本机路由表变了,但转发面还是旧路径硬件转发表下发问题。
OSPF和BGP哪个收敛快？场景不同答案不同
行业共识认为,同规模网络里OSPF收敛速度比BGP快，但跨机房场景多数还是得用BGP，原因在于设计目标和适用场景互相错位。
| 对比项 | OSPF | BGP |
|---|---|---|
| 收敛触发 | Hello/Dead间隔，秒级感知故障 | Keepalive/Holdtime，分钟级感知故障 |
| 路由计算 | SPF算法，区域内收敛快 | 逐条选路，配合路由反射器有延迟 |
| 适用距离 | 数据中心内部、同城园区 | 跨地域、跨运营商、多机房互联 |
| 故障切换 | 配合BFD可达毫秒级 | 依赖BFD和邻居关系重建 |
同城双活数据中心组网常遇到一个纠结：内部跑OSPF收敛快，但跨机房专线想用BGP做策略控制，折中方案很成熟接入层跑OSPF，核心和专线跑BGP，中间做双向路由引入，这样机房内部故障靠OSPF秒级收敛，跨机房链路故障由BGP处理。
如果非要让BGP收敛快点,把BFD开起来最直接，业界标准做法是给BGP会话绑定BFD，检测时间压到100毫秒到300毫秒，收敛速度能追上OSPF。但前提是设备CPU扛得住，老设备建议先在测试环境压测。
路由策略和过滤器：慢收敛的隐藏元凶
设备状态、邻居关系、计时器都查过一遍没发现问题？把目光转到策略上。多数情况下，BGP收敛慢不是协议本身慢，而是策略把路由更新卡住了。
常见的坑有三个：
- 前缀列表过长：对端发来10万条路由，本机用5000行的前缀列表逐条匹配，CPU直接飙高，检查
display cpu-usage，如果BGP进程吃满单核，基本就是这个原因。 -
正则表达式误配
：AS-Path过滤规则写得太宽或太窄，导致路由反复接收、撤回。show ip bgp regexp能看到匹配命中的路由数量。 - Route-Refresh全量重发：修改出口策略后执行
refresh bgp all，会把整张路由表重新发一遍，大路由表场景下，几十秒到几分钟的延迟很正常，尽量改成soft-reconfig或route-refresh按需触发。
抓包验证方法很直接：在边界设备上tcpdump -i 公网口 tcp port 179，观察Update消息间隔，如果两条Update之间间隔好几分钟，说明对端策略处理是瓶颈，如果本地不断在发Notification，说明路由在反复震荡。
计时器与硬件转发表：最后两步别漏掉
策略检查完仍然慢,剩下两个方向：控制面计时器不合理，以及数据面表项下发延迟。
控制面计时器调整要落地
BGP场景下,把Holdtime从180秒降到30秒，配合Keepalive 10秒，代价是邻居稳定性下降，链路抖动时路由翻转更频繁。不建议为了收敛速度牺牲稳定性，优先上BFD。
OSPF场景下,检查Dead interval，默认40秒（广播网）意味着邻居断联后要等40秒才重算路由，改短到10秒以内能加速收敛，但同样会增加协议报文开销，按实际情况权衡。
FIB下发慢会吃大亏
控制面路由表已经更新,但数据面还是走老路，问题出在硬件转发表，执行以下确认：
- 芯片FIB表项是否快速更新：
display fib对比路由表更新时间。 - 是不是有大量策略路由或ACL导致硬件处理不过来。
- 老旧的接入交换机在新路由表下发期间,可能丢包数秒甚至更久。
硬件能力不足时,改造方案有两条路：更换支持快速刷新FIB的设备，或通过等价路由和流量调拨让业务绕过慢速节点。
把排查顺序串起来：一套可复用的操作路径
按下面这个顺序走一遍,基本不会漏：
- 确认现象范围：ping跨机房VIP，
mtr持续30秒，记录所有跳的丢包率。 - 检查物理端口：
display interface看CRC错误，display transceiver看光模块收发功率。 -
检查路由邻居
：BGP看display bgp peer，OSPF看display ospf peer，确认状态是否稳定。 - 核对路由表变更时间：
display routing-table结合监控看变更时间戳。 - 抓包定位策略问题：在收发双方抓179端口报文，观察Update消息间隔。
- 检查计时器和BFD：确认BFD会话是否正常建立，Holdtime是否过大。
- 确认FIB下发状态：对比RIB和FIB，确认硬件表项刷新延迟。
每一步都有具体的命令和判断标准,不需要靠猜，这套顺序在多个同城双活项目里验证过，最快的一次，从反馈故障到定位是BGP策略过滤问题，只用了二十分钟。
小结
多机房组网的路由收敛慢,排查顺序决定了效率。先看数据面，再看邻居，最后调策略和硬件，这是业内通用的基本盘，多数故障不是协议本身慢，而是链路抖动、策略错误或硬件刷新跟不上，搞清楚了这一点，你手里的设备命令才会真正起到作用。
Q&A：多机房组网路由收敛慢排查中常见的疑点
北京多机房组网，BGP邻居频繁抖动，应该先查什么？
先查物理层,北京机房多的区域，跨楼宇或跨园区的光纤链路容易受施工影响，优先看光模块收发光功率和端口CRC错误计数，其次是检查专线两端设备的MTU是否一致，MTU不匹配会导致BGP报文被分片或丢弃，表现为邻居反复重置。
OSPF和BGP哪个收敛快，能否统一用OSPF？
同一网络范围内OSPF收敛快于BGP,因为OSPF靠Hello机制秒级感知故障，而BGP默认Holdtime较长，但跨机房组网通常涉及业务隔离和路由策略，OSPF在跨域控制上不如BGP灵活，主流方案是OSPF用于机房内部，BGP用于机房之间，两者做路由引入，兼顾速度和控制力。
多机房组网方案费用受哪些因素影响？
费用主要由专线带宽、设备规格和运维复杂度三块构成，专线部分受运营商和距离影响较大，同城双活比跨省便宜；设备部分取决于是否需要双机冗余、是否支持BFD和快速FIB刷新，具体报价需要结合机房位置和业务量向服务商咨询，但以上三块是议价时的核心依据。