BGP路由器协议排错教程：BGP 对等体失效的问题
当一个已经配置好的 BGP 邻居并没有处于已建立状态的话，网络工程师就把这种情况称为
BGP 对等体失效。以下情况都有可能引发对等体失效的问题。
? 由于配置错误导致 BGP 会话停留在建立过程中。
? 由网络迁移或事件触发的失效，或者由软件或硬件升级触发的失效。
? 由于传输问题导致维护 BGP 的存活消息传输失败。
? CPU 利用率过高。
? 处理过程受阻或被卡住。
? 防火墙或 ACL 的错误配置。
? 软件缺陷。
失效的 BGP 对等体状态分为两种：Idle（空闲）状态和 Active（活跃）状态。从对等体状
态的角度看来，这两个状态可能会指向以下问题。
? Idle（空闲）状态。
? 没有去往对等体的路由。
第 3 章 排查对等体问题
64
? Active（活跃）状态。
? 没有去往对等体地址的路由（却少 IP 联通性）。
? 配置错误，比如更新源（update-source）缺失或配置错误。
? Idle/Active 状态。
? TCP（传输控制协议）连接已建立，但 BGP 协商失败；比如 AS 号配置错误。
? 路由器不认同对等体的参数。
图 3-1 所示拓扑展示了排查 BGP 对等体问题时的排错逻辑和步骤。在这个拓扑中，R1 和
R2 是内部 BGP（IBGP）邻居，R2 和 R3 是外部 BGP（EBGP）邻居。R1 运行 NX-OS 系统，
R2 运行 Cisco IOS 系统，R3 运行 IOS XR 系统。
排错的第一步应该是检查配置并理解设计思路。很多时候 BGP 会话无法建立就是因为基本
配置中出现了错误。根据图 3-1 所示拓扑，例 3-1 中展示了 IBGP 和 EBGP 会话的运行配置。
注释 在 Nexus 平台上要想配置 BGP，工程师需要先使用命令 feature bgp 来启用 BGP
特性。只有启用了这条命令，NX-OS 平台上与 BGP 相关的 configuration 和 show 命令才能正
常工作。
例 3-1 所有路由器上的 BGP 配置
R1# show running-config bgp
feature bgp
router bgp 65530
router-id 192.168.1.1
address-family ipv4 unicast
network 192.168.1.1/32
neighbor 192.168.2.2
remote-as 65530
update-source loopback0
address-family ipv4 unicast
R2# show running-config | section router bgp
router bgp 65530
bgp router-id 192.168.2.2
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 10.1.13.2 remote-as 65535
neighbor 192.168.1.1 remote-as 65530
neighbor 192.168.1.1 update-source Loopback0
!
address-family ipv4
network 192.168.2.2 mask 255.255.255.255
neighbor 10.1.13.2 activate
neighbor 192.168.1.1 activate
neighbor 192.168.1.1 next-hop-self
RP/0/0/CPU0:R3# show running-config router bgp
router bgp 65535
bgp router-id 192.168.3.3
address-family ipv4 unicast
network 192.168.3.3/32
!
neighbor 10.1.13.1
remote-as 65530
address-family ipv4 unicast在配置好新的 BGP 邻居后，工程师应该检查以下配置参数：
? 本地 AS（自治系统）号；
? 远端 AS 号；
? 对等体地址之间的可达性；
? 检查网络拓扑和其他文档；
? 路由策略规划，即使与 BGP 邻居的建立没有直接关系。
工程师一定要理解对等体之间 BGP 包的流经路径。BGP 包的源 IP 地址要能够反映出向接
口的 IP 地址。当路由器接收到一个 BGP 包时，它会把这个数据包的源 IP 地址与 BGP 邻居表
中的地址进行比对。如果 BGP 包的源 IP 地址与邻居表中的 IP 地址不相同，路由器就无法把这
个 BGP 包与这个邻居关联到一起，因此会丢弃这个 BGP 包。
在大多数实施案例中，IBGP 对等体都是配置在路由器环回接口上的。要想建立 IBGP 对等
体会话，工程师应该明确把环回接口指定为源。工程师可以使用命令 neighbor ip-address
update-source interface-id 来检查是否已经为对等体配置了正确的源接口。
如果 EBGP 对等体之间间隔了多跳设备，那么工程师需要配置适当的跳数。这时工程师要
确保在命令 neighbor ip-address ebgp-multihop [hop-count]中配置了正确的跳数。如果工程师没
有明确指定 hop-count（跳数）参数的话，IBGP 会话的默认 TTL 为 255，EBGP 会话默认的 TTL
为 1。工程师只有在 IOS 路由器上可以查看 TTL（生存时间），详见例 3-2。要注意 TTL 值对于
IBGP 会话和 EBGP 会话来说是不一样的。在 IOS XR 或 NX-OS 设备的命令输出信息中看不到
TTL 信息。
例 3-2 IBGP 会话和 EBGP 会话的 TTL 值
R2# show bgp ipv4 unicast neighbor 192.168.1.1 | in TTL
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
R2# show bgp ipv4 unicast 10.1.13.2 | in TTL
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1注 释 如 果 工 程 师 配 置 了 命 令 neighbor ip-address ttl-security ， 就 不 需 要 配 置
ebgp-multihop 命令了。第 9 章中会更详细地讨论 TTL 安全。
在建立 EBGP 对等体会话时，如果设备距离对等体只有 1 跳，但却使用环回接口建立会话，
工程师就需要使用命令 neighbor ip-address disable-connected-check。这条命令会禁用连接校验
机制，当 EBGP 对等体不属于同一个直连网段时，这个机制默认会阻止它们建立 EBGP 会话。
还有一个配置（虽然是可选的）对于成功建立 BGP 会话也很重要，这就是对等体认证配置。
认证密码的错误配置或输入错误都会导致 BGP 会话建立失败。
3.1.2 检查可达性
在检查完配置后，工程师必须还要确认对等体 IP 地址之间的可达性。如果设备通过环回接
口建立对等体连接，那么工程师必须要执行环回接口与环回接口之间的 ping 测试。如果工程师
在执行 ping 测试时没有把环回接口指定为源接口，那么出站的物理接口 IP 地址就会作为数据
包的源 IP 地址，而不是使用路由器的环回接口 IP 地址。
例 3-3 展示了 R1 和 R2 之间的环回接口 ping 测试。
例 3-3 以环回接口作为源接口的 ping 测试
NX-OS
R1# ping 192.168.2.2 source 192.168.1.1
PING 192.168.2.2 (192.168.2.2) from 192.168.1.1: 56 data bytes
64 bytes from 192.168.2.2: icmp_seq=0 ttl=254 time=4.809 ms
64 bytes from 192.168.2.2: icmp_seq=1 ttl=254 time=5.524 ms
64 bytes from 192.168.2.2: icmp_seq=2 ttl=254 time=8.882 ms
64 bytes from 192.168.2.2: icmp_seq=3 ttl=254 time=4.643 ms
64 bytes from 192.168.2.2: icmp_seq=4 ttl=254 time=6.091 ms
--- 192.168.2.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 4.643/5.989/8.882 ms
IOS
R2# ping 192.168.1.1 source loopback0
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/5/8 ms工程师必须为所有 IBGP 会话和 EBGP 会话检查联通性。例 3-3 成功检查了对等体 IP 地
址之间的联通性。但如果联通性检查失败，工程师可以参考接下来的内容，进一步定位问题
出现的位置，确认联通性问题是出现在转发路径中，还是回程路径中。接下来更详细地介绍
以下内容：
? 弄清楚丢包的位置和方向；
? 检查数据包是否被重传；
? 使用 ACL（访问控制列表）来检查是否收到了数据包；
? 检查路径中的 ACL 和防火墙；
? 检查 TCP 会话；
? 模拟一个 BGP 会话。
1．弄清楚丢包的位置和方向
shwo ip traffic 命令的输出信息有助于工程师弄清楚丢包的方向。这条命令的输出信息中有
一部分描述的是 ICMP（Internet 控制消息协议）包，它会显示出设备接收和发送的 Echo-Request
和 Echo-Reply 数量。首先，工程师要确保源设备和目的设备上的发送和接收计数器是稳定的。
如果计数器持续增长，工程师将很难判断 ICMP Echo 包是否真的到达了另一端，或者另一端是
否发出了 Echo-Reply 包。在这种情况下，工程师可以使用 ACL 或数据包捕获工具来检查设备
是否收到了 Echo 包，以及设备是否发出了 ICMP Echo-Reply 包。如果计数器没有增长，工程师
可以使用源 IP 地址（比如环回接口 IP 地址）向目的 IP 地址发起 ping 测试。ping 测试完成后，
无论成功与否，工程师都可以通过命令 show ip traffic | include echo 来检查输出信息。源设备
上已发出 Echo 包（Echo-Request）计数器增加的数量应该与目的设备上已接收 Echo 包计数器
增加的数量相同。同时，目的设备上已发出 Echo-Reply 数量的增量也应该与源设备上已接收
Echo-Reply 数量的增量相同。
例 3-4 中展示了命令 show ip traffic 的输出信息，以此帮助工程师确认丢包的方向是从 R2
到 R1 的方向。这是因为 R1 上的 Echo-Reply 发送计数器没有增加，而 R2 上的 Echo 接收计数
器的数值增加了。
例 3-4 show ip traffic 命令的输出信息
NX-OS
R1# show ip traffic | include echo
Redirect: 0, unreachable: 0, echo request: 10, echo reply: 5,
Redirect: 0, unreachable: 0, echo request: 5, echo reply: 5,
! This is the Source Router
R1# ping 192.168.2.2 source 192.168.1.1
PING 192.168.2.2 (192.168.2.2) from 192.168.1.1: 56 data bytes
Request timed out
Request timed out
Request timed out
Request timed out
Request timed out
--- 192.168.2.2 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss
round-trip min/avg/max = 3.482/3.696/3.904 ms
R1# show ip traffic | include echo
Redirect: 0, unreachable: 0, echo request: 15, echo reply: 5,
Redirect: 0, unreachable: 0, echo request: 5, echo reply: 5,
IOS
R2# show ip traffic | include echo
10 echo, 14 echo reply, 0 mask requests, 0 mask replies, 0 quench
Sent: 0 redirects, 0 unreachable, 55 echo, 10 echo reply
! Notice the below echo reply counter is not incrementing in the Sent section.
R2# show ip traffic | include echo
15 echo, 14 echo reply, 0 mask requests, 0 mask replies, 0 quench
Sent: 0 redirects, 0 unreachable, 55 echo, 10 echo reply注释 在 IOS XR 平台上，工程师可以使用命令 show ipv4 traffic 来查看 ICMP 包的计数器。
要想知道 R2 为什么没有向 R1 发送 ICMP Echo-Reply 包，工程师可以查看 R2 上的路由表
和 CEF 表。工程师还应该查看 R2 的接口配置，确认是否会有 ACL 丢弃了 ICMP Echo-Reply。
如果在检查了上述信息之后工程师仍然无法找出原因，那么可以使用我们在第 2 章中介绍的数
据包捕获工具来做进一步的排错。
2．检查数据包是否被重传
如果链路上确实发生了丢包，工程师可以在执行 ping 联通性测试时把超时时间设置为 0，
来确认数据包是否真的离开了路由器，或者对方路由器是否收到了数据包。这个测试的目的是
为了把数据包发送出去，确保计数器往上增长，但并不真的期待从对端收到反馈。
在工程师执行了超时时间为 0 的 ping 测试后，已发送数据包计数器的数值应该会增长，涨
幅会与 show interface 命令输出内容中已发出 ping 包的数量相同。路由器在发出 ping 包的同时
并不期待收到任何响应。
例 3-5 展示了超时时间为 0 的 ping 测试。从输出内容中我们可以看到 R2 接口 GE0/1 的已
发送计数器增加了，但已接收计数器并没有增加。需要注意的是，在 Nexus 平台上，工程师需
要使用命令 show ip interface interface-id 来查看数据包的发送和接收计数器，而不是使用命令
show interface interface-id。
例 3-5 超时时间为 0 的 ping 测试
IOS
R2# show interface Gi0/1 | in packets
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
26540 packets input, 2129461 bytes, 0 no buffer
37292 packets output, 2870820 bytes, 0 underruns
R2# ping 10.1.12.1 timeout 0 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.12.1, timeout is 0 seconds:
..........
Success rate is 0 percent (0/10)
R2# show interface Gi0/1 | in packets
5 minute input rate 1000 bits/sec, 0 packets/s