企业官网建设流程全解析

做网络的人，早晚都要跟BGP打交道。前阵子在某项目现场帮人排障，两个自治域之间的邻居关系一直起不来，两边配置看着都对，可邻居状态就是停在某个奇怪的位置上。我第一反应不是急着抓包，而是先问了一句：现在显示的是什么状态？因为BGP邻居关系的每一步建立，背后都是一台有限状态机在管理。BGP状态机把从配置邻居到正式宣告路由的过程拆成了六个状态，每一步从哪进、从哪出、触发什么事件、超时怎么办，都有明确规定。搞清楚这套状态机，不光能帮你理解BGP为什么这么设计，更重要的是——它能直接指导你排障。状态机就是BGP邻居关系的“病历本”，你在哪个阶段卡住，就说明问题出在哪一层。

1. BGP为什么要靠状态机管理邻居关系：先说清设计动机

很多人学BGP第一件事是背配置，peer一句、network一句，命令敲完就等着邻居Up。但真出了问题时，靠配置背得熟是解决不了的。前阵子那个项目就是典型例子：两边都配了EBGP对等体，接口能互通，TCP 179也能通，可邻居就是在Established之前反复跳。这种场景下，不看状态机根本没法定位问题。

BGP之所以设计成状态机，是因为它要解决的是一个非常棘手的分布式协商问题。两个对等体在不同自治系统里，彼此不知道对方什么时候准备好、支持什么特性、参数是否匹配。如果两边同时乱发消息，只会让协议根本没法收敛。状态机给了双方一个统一的“对话节奏”：每个阶段该做什么、不能做什么，全部提前定死。这和两个人打电话之前要先拨号、等待、对方接起、双方确认身份再讲话是一个道理。TCP三次握手管的是“连接能不能建立”，但TCP不管你是哪个AS、版本对不对、保活时间能不能接受，这些属于BGP自己的协商内容。BGP把协商过程拆成状态，就是为了在复杂网络环境下把失败点精确暴露出来。

另一个设计动机是容错。BGP运行在公网这种高延迟、高丢包、链路频繁抖动的环境里，连接随时可能断。如果没有状态机，一个瞬间的链路抖动可能导致对等体双方各自进入无法恢复的混乱状态。有了状态机，任何异常都会把会话打回初始状态，然后重新按流程走一遍。这是典型的“宁可从头再来，也不要处于不确定状态”的工程思路。

从运维视角看，状态机最大的价值就是排障可分而治之。看到邻居状态，你立刻能判断问题大概在哪一层：卡在Idle是协议启动层面，卡在Connect和Active是TCP建连层面，卡在OpenSent和OpenConfirm是参数协商层面。这种“看一眼状态就知道下一步查哪”的能力，是BGP排障效率的分水岭。下面的内容，我会把六个状态拆开讲，逐一说明每个状态里设备在干什么、什么事件会把它推向下一个状态、哪些坑最常踩。

2. 六个状态逐个拆解：每一步从哪来、到哪去、卡住什么样

先上一张总览表，然后我们逐个拆。这张表是BGP状态机的核心骨架，建议直接存下来当排障参考。

2.1 Idle：万事起点的静止状态

Idle是BGP的初始状态，也是所有异常结束之后回归的状态。在这个状态下，设备不会主动向对端发起任何TCP连接，也不会发送任何BGP报文，只是静静地等着“启动”信号。

什么会触发启动？最常见的是你在设备上配置了BGP对等体，或者手动执行了重启邻居的操作。设备收到Start事件后，会初始化BGP会话所需的所有资源——分配内存、初始化连接重试定时器、清空之前残留的会话信息，然后进入Connect状态。

这里有个容易被忽略的点：Idle状态下并不是什么都不做。协议会对启动行为做“退避处理”，防止反复重启造成CPU抖动。如果一个邻居反复建链失败，系统会把每次Start事件之后的等待时间逐渐拉长，这就是BGP的一种自我保护机制，和TCP的指数退避思路类似。所以不要看到邻居状态长期停在Idle就一味地重启，先想想是不是已经被退避计时器限制住了。

实际排障中，持续卡在Idle最常见的几种原因：邻居被管理员手动shutdown了，BGP进程没起来，或者对等体根本没有在正确的地址族下使能。这些都是配置层面的问题，大部分不是网络上出了问题。

2.2 Connect：等待TCP连接完成的过渡态

进入Connect状态后，BGP开始尝试与对端建立TCP连接，目标端口是179。这个状态下设备干的具体事情是：向对端发送TCP SYN报文，然后等待对端回SYN-ACK，完成三次握手。

如果TCP建链成功，设备会立刻把连接交给BGP上层：清除连接重试定时器，构造并发送自己的Open报文，然后进入OpenSent状态。如果TCP建链失败，或者建链迟迟没有完成，设备会启动连接重试逻辑，进入Active状态。

Connect状态通常持续得非常短，短到你抓包时很难捕捉到它，通常一闪而过。如果你在设备上频繁看到邻居处在Connect状态，多半意味着对端IP不可达、SYN被防火墙丢掉、或者TCP端口被ACL挡住。这个阶段的问题是“TCP层的问题”，先查路由、查ACL、查中间防火墙，不要把时间浪费在BGP配置上。

关于Connect状态的超时参数，不同设备默认值有差异，常见的是120秒左右，也有的设备默认32秒。这个计时器叫ConnectRetry，作用就是控制“TCP连不上多久以后重新尝试一次”。理解它的存在比背参数更重要。

2.3 Active：连接重试的“被动等”状态

Active是大家排障时见得最多的状态之一，也是误解最多的状态。很多人以为Active代表设备正在“积极地”尝试连接对方，其实恰恰相反。进入Active状态意味着本端主动发起的TCP连接尝试失败了，此时设备不会频繁地发起SYN，而是进入一种等待节奏：要么等对端主动发起TCP连接，要么等ConnectRetry定时器到期后再重试一次。

用大白话说，Connect是“我在主动敲门”，Active是“我敲了一次门没人应，先蹲在门口等一会儿，等对方敲门，或者过一阵我再敲一次”。

这里有个非常经典的坑：如果两端设备因为某些原因同时进入了Active状态，而各自的ConnectRetry定时器又几乎同时到期，那么它们会同时发起TCP连接，导致两边都收到对方的SYN。这种情况在协议上叫“连接竞争”。BGP对此有明确的处理机制：两侧都会各自建立TCP连接，然后通过Open报文的比较（比如比较Router-ID大小）来决定保留哪一个连接，丢掉另一个。这就是状态机设计里一个不显眼但极其关键的细节——“冲突消解”。

实际工程中，两端同时卡在Active通常意味着网络层有问题：对端地址不可达、TCP端口被中间设备过滤、或者EBGP的TTL跳数限制导致报文被丢弃。此时最有效的办法是在两端同时抓包，看SYN有没有到达对端。如果本端发出SYN后一直收不到SYN-ACK，那问题就在中间链路或对端防火墙，不要再去折腾BGP的配置了。

2.4 OpenSent：三次握手之后的第一次BGP对话

TCP连接建立之后，BGP就进入了OpenSent状态。这个状态下，设备已经把自己的Open报文发给了对端，正在等待对端的Open报文。

Open报文是BGP的自我介绍，里面携带了几个关键字段：BGP版本号（目前是4）、本端AS号、Hold时间（保活超时时间，默认180秒）、BGP Router-ID，以及可选参数（比如MP-BGP能力、多协议扩展等）。

收到对端的Open报文后，设备会做一系列校验：

• 版本号是否支持；
• 对端的AS号是否和自己配置的remote-as一致；
• Hold时间是否可以接受；
• Router-ID是否和自己冲突；
• 可选参数是否支持。

任何一个校验不通过，设备都会发送Notification报文并回到Idle状态，同时记录下失败原因。OpenSent阶段如果收到的是Notification，也会直接回Idle。

所以排障时看到邻居卡在OpenSent或者从OpenSent退回Idle，问题基本锁定在“参数协商”层面：AS号配错、Router-ID冲突、Hold时间不一致、版本不匹配。这个阶段TCP已经通了，抓包能看到双方的Open报文和Notification报文，错误码会直接告诉你原因。后面第4节我会具体演示怎么查。

2.5 OpenConfirm：双向确认后的最后一道门

OpenSent之后进入OpenConfirm，说明设备已经收到了对端的Open报文并且校验通过，自己也已经把Keepalive报文发出去了。现在唯一要做的事，就是等对端的Keepalive。

Keepalive是BGP的“保活”报文，内容非常简单，就一个BGP报文头。它的作用是告诉对端：我还活着，我认可刚才的参数协商结果。

在OpenConfirm状态下，如果收到对端的Keepalive，立即进入Established，邻居正式建立成功。这个过程很快，正常情况下你几乎看不到OpenConfirm状态，设备状态刷新时经常直接就跳到Established了。但如果你能持续观察到邻居卡在OpenConfirm，那最常见的两个原因：对端收到了你的Open但没回Keepalive（对端设备可能卡在OpenSent），或者对端发出的Keepalive被中间设备丢弃了。

值得注意的一点是Hold定时器在OpenConfirm阶段已经开始运行了。如果你一直收不到对端的Keepalive，Hold定时器超时后设备会认为对端失联，发送Notification并回到Idle。所以OpenConfirm不是无限等下去，是有时间上限的。

2.6 Established：邻居关系正式建立

Established是六个状态里唯一让人安心的状态。进入这个状态，说明BGP对等体关系正式建立，双方可以开始交换Update报文来通告路由了。此时设备会自动启动Keepalive定时器，周期性向对端发送Keepalive报文，同时每个收到的Update报文都会触发Hold定时器的重置。

拿到Established状态之后，后续的工作重心就从“邻居状态”转移到“路由通告和路由选择”上。Update报文里携带的网络层可达信息（NLRI）和路径属性（AS_Path、Next_Hop、LocalPref等）会成为BGP路由决策的输入。但要注意，Established不代表一劳永逸。如果Hold定时器超时、收到Notification、或者对端主动断开连接，状态会瞬间打回Idle，一切从头再来。

此时设备上能看到两个非常有用的信息：邻居持续在线的时间（Up/Down）和收发报文的计数（MsgRcvd/MsgSent）。如果Up/Down时间很短，说明邻居频繁翻动；如果MsgRcvd只增不减但路由却学不全，问题很可能出在路由策略上，而不在状态机层面。

3. 驱动状态迁移的核心事件与计时器：不只是“哪个状态能到哪个状态”

状态机看起来是状态之间的跳转，但真正驱动跳转的是事件和计时器。这一节把事件和计时器单独拎出来讲，因为这些才是BGP状态机的“发动机”。

3.1 事件是怎么触发的

BGP状态机里的触发事件可以分成四大类。

第一类是管理事件。管理员手动配置邻居、手动重启BGP、手动shutdown对等体，都会触发协议的启动或停止。这类事件是排障时最容易被忽视的——很多时候状态异常根本不是网络问题，而是有人在前一台设备上做了配置变更，忘了告诉你。

第二类是定时器事件。BGP内部有好几个定时器在并行跑，ConnectRetry定时器到期、Hold定时器到期、Keepalive定时器到期，每一种到期都会把状态机推向下一个动作。比如ConnectRetry到期后设备会重新发起TCP连接，状态从Active回到Connect。

第三类是TCP事件。TCP连接建立成功、TCP连接失败、TCP连接被重置，这些事件会直接决定状态在Connect、Active和OpenSent之间的移动。特别是“TCP连接成功但很快断开”这种情况，是排障里非常容易让人困惑的信号。

第四类是BGP消息事件。收到的Open报文有效、收到的Open报文无效、收到Keepalive、收到Update、收到Notification，每一条消息都会触发状态机做出响应。

理解这四类事件，排障时就能反过来推：当前状态说明什么事件没有发生？是没人触发管理事件，还是定时器还没到期，还是TCP事件没有到达？这样排查的思路会清晰很多。

3.2 三个关键计时器如何影响状态变迁

BGP有三个计时器，理解它们比理解任何一条配置命令都重要。

第一个是ConnectRetry定时器，控制TCP连接重试的频率。连接失败后，设备不会立刻疯狂重连，而是等这个定时器到期。这个设计是为了避免在链路抖动时产生报文风暴。有的设备默认120秒，有的设备默认32秒，知道存在差异就够了。实际调优时，如果链路恢复后希望邻居尽快起来，可以适当调小这个值；但如果链路本来就不稳定，调小反而会让设备刷大量SYN，浪费CPU。

第二个是Hold定时器，默认180秒。它在TCP连接建立成功后启动，作用是监控对端是否失联。只要在这个时间内收到对端的任何Keepalive或Update报文，定时器就重置；如果一直没收到，超时后设备判定对端失效，发Notification并回到Idle。Hold定时器是BGP自治愈能力的关键——没有它，一个静默宕机的对端会让本端永远停留在Established状态，错误地保留一堆过期路由。

第三个是Keepalive定时器，默认60秒。它控制本端发送Keepalive报文的周期。RFC建议Keepalive间隔是Hold时间的三分之一，所以默认180秒配60秒是最常见组合。Hold时间在Open报文里协商，双方取较小的值。如果协商出来Hold时间是0，意味着双方都不设置超时，这时候Keepalive也可以不发——这种配置极其危险，一旦对端设备宕机，本端永远不会感知，路由黑洞会一直存在，生产环境建议不要这么配。

三个计时器的关系可以用一句话概括：ConnectRetry管“连接建立不起来的重试节奏”，Keepalive管“我要定期告诉对方我还活着”，Hold管“对方如果一直没动静我什么时候判定它死了”。这套“主动保活+超时判定”的组合，是BGP状态机健壮性的基石。

3.3 一种很微妙的情况：两端同时处于Active

前面提过连接竞争，这里单独展开。两端同时处于Active时，两边都进入了“等待重试”的节奏。此时谁先到期，谁先发起TCP连接，这个顺序取决于ConnectRetry定时器的初始值和抖动偏移。如果两个设备几乎同时到期，就出现竞争。

BGP处理竞争的机制很有意思：两端的TCP连接都能建立起来，各自发送Open报文。然后设备会比较双方的Router-ID，保留Router-ID大的一方发起的连接，另一方则发送Notification并关闭多余的连接。从抓包上看，你会看到两端同时建立了两个TCP会话，各自传输了Open报文，然后其中一个被Notification关掉。初次见到这种现象的人，容易误以为是“设备抽风了”，其实这是BGP状态机设计中的正常流程，它的目的就是保证任何时刻双方只用一条TCP连接承载BGP会话。

这个机制对工程实践的启示是：当你看到两端都显示Active，不要立刻怀疑“状态机卡死了”，先检查ConnectRetry是不是配置得异常，再检查中间链路。两端同时Active且长时间不动，绝大多数是TCP层问题导致双方都无法完成三次握手，而不是BGP状态机本身故障。

4. 状态机驱动的排障思路：从现象到根因的完整链路

状态机最大的实用价值不在于“背状态名”，而在于它能帮你快速收敛问题范围。下面这几组排障思路，是我在实战中验证过很多次的套路，按顺序走基本不会跑偏。

4.1 先判断问题在TCP层还是BGP层

这是最核心的一条判断准则，也是状态机给排障带来的最大红利。

看邻居状态：如果状态停留在Idle、Connect、Active，问题几乎都在TCP连接建立之前——包括路由可达性、防火墙策略、ACL、TTL跳数限制、MTU问题。这一阶段做的事就是让两个设备能完成179端口的TCP三次握手，和BGP本身的参数完全无关。

如果状态已经进入OpenSent、OpenConfirm，TCP已经通了，问题是BGP层的参数协商——AS号、Router-ID、Hold时间、能力集。此时抓包看的是Open报文和Notification报文，而不是SYN和SYN-ACK。

记住一句话：状态没到OpenSent，先别怀疑BGP配置。这个习惯能帮你省掉大量无效操作。我就见过有人在邻居卡在Active时反复修改BGP计时器和过滤策略，结果最后发现是中间防火墙把179端口给拦了。

4.2 现象一：持续停在Idle状态

设备上看到邻居一直显示Idle，且你确认已经配置了邻居并启动了BGP，排查顺序如下。

先看协议进程是否正常启动。有些设备上BGP进程需要手动使能，配置了邻居但没启动协议，状态就会一直停在Idle。再看邻居是不是被手动shutdown了。很多设备的shutdown命令是“开关型”的，误操作一次就再也起不来，而且视觉上不容易察觉。

再看地址族是否匹配。EBGP邻居在IPv4单播地址族下需要activate，如果只配置了对等体关系但没在地址族下使能，状态同样卡在Idle。这个原因非常隐蔽，尤其是在配置了多地址族（IPv4、IPv6、VPNv4）的场景下，最容易漏。

确认以上都没问题后，把关注的焦点放到退避机制上。如果一个邻居反复建链失败，设备会拉长重试间隔，造成“看起来卡死”的假象。此时可以手工重置邻居关系（先停后启），观察是否好转。但如果网络根源问题还在，重置完很快又会回到老状态。

4.3 现象二：在Connect和Active之间来回跳

这是排障中非常经典的一幕：邻居状态刷新一两次就能看到变化，一会儿是Connect，一会儿是Active，始终进不了OpenSent。这几乎必然是TCP建链出现问题，而最常见的三个原因是路由不可达、TTL限制、端口过滤。

路由不可达先排查。确认本端有没有到对端地址的路由，对端有没有回程路由。这里有个隐藏坑：有时本端有路由，但对端的回程路由缺失，表现为本端发出SYN后一直不见应答，TCP连接始终半开。

TTL限制专门针对EBGP场景。EBGP默认TTL为1，只允许直连建立邻居。如果两个设备中间隔了路由器（多跳EBGP），必须显式配置eBGP多跳，把TTL放宽。否则SYN报文到了中间路由器就被TTL耗尽丢弃，对端根本收不到。

端口过滤最常见但也最容易忽略。很多防火墙默认行为是“允许已建立的连接返回”，但对入方向主动发起的179端口连接，如果没放行，SYN就会被静默丢弃。排这种问题，两端同时抓包是最直接的。本端能看到SYN一直在重传，对端却什么都收不到，基本就可以下结论是中间设备丢了。还有一种很隐蔽的情况是MTU问题，导致SYN报文被分片或丢弃，表现为小包能通、大包不通。可以通过调整TCP MSS或者接口MTU来验证。

4.4 现象三：停在OpenSent或OpenConfirm

TCP连接已经建立，但邻居就是迈不进Established，说明双方在BGP参数协商环节谈崩了。此时的状态通常会在OpenSent和Idle之间反复切，或者短暂停在OpenConfirm。排查重点看Notification报文里的错误码。

最常见的错误是AS号不匹配。本端配置的remote-as和对端Open报文里携带的真实AS号不一致，设备会发送Notification，错误码是“Bad Peer AS”。排障时确认一下两边到底属于哪个AS，然后检查配置。经常有人的配置是临时复制粘贴的，AS号还是上一个环境的残留，这种低级错误在项目现场出现的频率远超想象。

再有是Router-ID冲突。两台设备的Router-ID如果设置成同一个值，BGP会检测到并拒绝建立邻居，错误码是“Bad BGP Identifier”。这类问题常见于模板化批量配置，同一份配置模板在几十台设备上原样套用，Router-ID全是一样的可不好。

还有Hold时间协商问题。正常情况下协商会取小值，一般都能兼容，但如果某台设备配置了Hold时间为0而另一台没有，或者两端配置差异过大，也有可能导致协商异常。见面协商失败时抓包看Open报文里的Hold字段，就能确认是哪端的值有问题。

再有一个前面提到过的，能力集不匹配。如果一端启用了某种扩展能力，另一端完全不支持，可能在Open报文的可选参数阶段就协商失败。这种情况不太常见，但遇到老旧设备和新设备对接时要说起来也并非没有可能。

4.5 用抓包和日志验证的状态机排障示例

举个实际的现场案例来把上面的思路串起来。某项目里两台上游路由器建立EBGP邻居，A端状态显示Active，B端状态也显示Active，双方僵持了半个多小时。

我先在A端看邻居状态和路由表，确认A端到B端地址有路由，B端回程路由也正常。然后在A端抓包，能看到A端每隔一个固定周期发出SYN，但始终收不到SYN-ACK。接着去B端抓包，发现B端根本收不到A端发来的SYN，问题立刻被锁定在中间链路。

检查中间防火墙策略后，发现入方向只放行了TCP 80和443端口，179没放行。放行之后，邻居状态迅速从Active进入Connect，再进入OpenSent，最后停在Established。整个过程验证了前面说的判断准则：状态卡在Active，问题必然在TCP层，和BGP参数无关。后来我又用同样的思路处理过一个“OpenSent反复回Idle”的案例，抓包看到Notification的错误码是“Wrong Peer AS”，一查配置果然是AS号写错。这两次排障的共同点是：没有去逐条翻BGP配置，而是先让状态机告诉你问题在哪一层。

5. 状态机思想在真实网络中的工程延伸：对等体验证、防抖与协议健壮性

最后这一节聊聊状态机之外的东西。理解状态机之后，你会更容易看懂BGP在工程实践里那些看似“额外”的机制，它们其实都是在状态机的骨架上做增强。

5.1 对等体验证和TTL安全：把状态机的入口门槛加高

BGP邻居从Idle到Established，中间要过好几道关口。TCP建链是第一道，Open参数校验是第二道。为了安全，工程上还会在这两道关口上加强制手段。

TCP MD5认证和TCP-AO认证，是在TCP层给连接加锁。配置了认证之后，只有携带正确密钥的设备才能完成TCP握手，直接堵住伪造BGP对等体的攻击路径。因为认证发生在TCP层，如果密钥不对，SYN都建立不了，状态根本走不到OpenSent。

TTL安全机制（俗称GTSM）的思路更巧妙：既然EBGP直连场景下TCP报文从对端到本端只需要跳一次，那么凡是TTL大于1的报文，基本可以判定为来自更远的位置，直接丢弃。这个机制在防止“远端伪造邻居”的攻击上异常有效。它的状态机表现为：TCP事件永远无法触发，状态卡在Connect或Active，因为三层报文在到达BGP进程之前就被过滤掉了。如果你在配置了GTSM的邻居上看到连接始终起不来，优先检查对端过来的报文TTL是不是被中间设备改写过了。

5.2 Graceful Restart：让状态机“看起来没断”

BGP状态机的严格性带来一个副作用：只要TCP连接一断，状态立刻回到Idle，所有通过该邻居学到的路由全部失效，全网路由随之震荡。对大规模网络来说，一次几秒钟的链路抖动可能导致全网路由器的BGP路由表同时刷新，这个代价非常高昂。

Graceful Restart（优雅重启）就是针对这个问题的增强机制。它并没有改变状态机的结构，而是通过Open报文里的能力协商，让对端在一方短暂重启时“网开一面”：重启方进入Restart状态，对端则保留从它学到的路由，并打上过期标记，继续转发流量，等待重启方恢复。如果恢复得快，路由标记被清除，对端甚至不会感知到断流；如果超时，过期路由才会被删除，状态机回到正常流程。

这个机制的本质，是通过能力协商给状态机的“回退动作”增加了一个延迟缓冲。运营商的骨干网络几乎全部开了GR或者类似机制，就是为了避免单台设备的重启拖累全网。理解状态机，再回头看GR，你会发现它不是在推翻状态机设计，而是在状态机框架下做的精细化妥协。

5.3 配置调优时和状态机相关的经验值

最后给几个实际调优的经验值，都是我在项目里验证过的，不是学院派的理论。

第一，连接重试定时器设置成多大，取决于链路稳定性。在光纤专线这种稳定链路上，默认值就够；在无线桥接这种高抖动链路上，建议适当调大重试间隔，否则设备会频繁发起SYN，造成无谓的CPU消耗和日志刷屏。我见过有设备因为重试太频繁，日志缓冲直接被撑爆，排障时连有效日志都找不到。

第二，Keepalive和Hold时间不建议随意改小。很多网工为了让故障发现更快，把Hold时间从180秒改成30秒，Keepalive从60秒改成10秒。这么做确实能加速故障感知，但代价是每10秒就要多一次Keepalive报文，在远程链路或大量邻居的场景下，报文量增长非常客观。而且Hold时间太短，一旦对端CPU繁忙导致处理延迟，就可能误判对端失联，反而导致邻居频繁翻动。我的习惯是除非有明确要求，否则保持默认值180/60，通过其他监控手段来感知链路故障。

第三，重置邻居操作要谨慎。现场排障时很多人习惯用“重启BGP邻居”来试图刷新状态，但这个操作会直接触发Stop事件，把状态从Established打回Idle，所有通过该邻居学到的路由全部瞬间失效。建议先观察和抓包，确认是协议层面的问题再重置。如果只是想重新触发协商，有的设备支持软重置，只重新通告路由而不打断邻居状态，对现网的影响要小得多。

最后说一个我自己习惯用的判断技巧。每次看到BGP邻居异常，我第一眼看的永远是“这个状态持续了多久”。如果状态在短时间里反复横跳，说明链路或配置问题在持续存在；如果状态很稳定地卡在某个位置，那多半是某个条件一直不满足。这两种情况对应的排查路径完全不同。用状态机加时间维度来审视BGP邻居关系，排障会越来越有章法，而不是靠猜。这套方法论在BGP上适用，在其他依赖状态机的协议上其实也通用。