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/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
26540 packets input, 2129461 bytes, 0 no buffer
37306 packets output, 2872281 bytes, 0 underruns
NX-OS
R1# show ip interface E2/1 | include packets
Unicast packets : 6602/6611/0/6602/7753
Multicast packets : 19846/15636/0/19846/31272
Broadcast packets : 0/2/0/0/2
Labeled packets : 0/0/0/0/0
! Sent and Received packet counts after the ping test on R1
R1# show ip interface E2/1 | include packets
Unicast packets : 6602/6611/0/6602/7753
Multicast packets : 19846/15637/0/19846/31274
Broadcast packets : 0/2/0/0/2
Labeled packets : 0/0/0/0/0

3．使用 ACL 来检查是否收到了数据包
在排查丢包问题或联通性问题时，ACL 能够提供很多帮助。在一个 ACL 中配置一个匹配
源和目的 IP 地址的条目，可以用来检查数据包是否到达了目的设备。工程师的最佳做法是，在
ACL 中指定数据包所使用的协议，以及指定源和目的地址。举例来说，如果需要排查的流量是
R1 和 R2 之间的 ICMP 流量和 BGP 包，那么工程师就可以在 ACL 条目中匹配 ICMP 流量和 TCP
端口 179 的流量，同时把源和目的地址相应地设置为 R1 和 R2 的地址。在配置 ACL 时唯一需
要注意的是在 ACL 末尾要配置 permit ip any any 语句，否则这个 ACL 会丢弃所有其他数据包
并影响正常服务。
4．检查路径中的 ACL 和防火墙
在大多数部署环境中，边缘路由器或 IGW（Internet 网关）路由器上都会配置 ACL，来对
允许进入网络的流量实施限制。如果需要在这种配置了 ACL 的链路上建立 BGP 会话，工程师
需要确保这些 ACL 不会丢弃 BGP 包（TCP 端口 179）。
例 3-6 中展示了当 BGP 流量需要穿越链路时，ACL 的配置中应该放行的流量。本例不仅
展示了 IPv4 配置，还包含了 IPv6 访问列表的配置，以防需要建立 IPv6 BGP 会话。要想在接口
上应用 IPv4 ACL，工程师在所有平台上都需要使用命令 ip access-group access-list-name {in |
out}。要想在接口上应用 IPv6 ACL，工程师在 NX-OS 和 IOS 平台上需要使用接口配置命令 ipv6
traffic-filter access-list-name {in | out}，在 IOS XR 平台上需要使用接口配置命令 ipv6
access-group access-list-name {in | out}。

例 3-6 放行 BGP 流量的 ACL

NX-OS
R1(config)# ip access-list v4_BGP_ACL
R1(config-acl)# permit tcp any eq bgp any
R1(config-acl)# permit tcp any any eq bgp
! Output omitted for brevity
R1(config)# ipv6 access-list v6_BGP_ACL
R1(config-ipv6-acl)# permit tcp any eq bgp any
R1(config-ipv6-acl)# permit tcp any any eq bgp
! Output omitted for brevity
R1(config)# interface Ethernet2/1
R1(config-if)# ip access-group v4_BGP_ACL in
R1(config-if)# ipv6 traffic-filter v6_BGP_ACL in
IOS
R2(config)# ip access-list v4_BGP_ACL
R2(config-acl)# permit tcp any eq bgp any
R2(config-acl)# permit tcp any any eq bgp
! Output omitted for brevity
R2(config)# ipv6 access-list v6_BGP_ACL
R2(config-ipv6-acl)# permit tcp any eq bgp any
R2(config-ipv6-acl)# permit tcp any any eq bgp
! Output omitted for brevity
R2(config)# interface Gi0/1
R2(config-if)# ip access-group v4_BGP_ACL in
R1(config-if)# ipv6 traffic-filter v6_BGP_ACL in
IOS XR
RP/0/0/CPU0:R3(config)# ipv4 access-list v4_BGP_ACL
RP/0/0/CPU0:R3(config-ipv4-acl)# permit tcp any eq bgp any
RP/0/0/CPU0:R3(config-ipv4-acl)# permit tcp any any eq bgp
! Output omitted for brevity
RP/0/0/CPU0:R3(config)# ipv6 access-list v6_BGP_ACL
RP/0/0/CPU0:R3(config-ipv4-acl)# permit tcp any eq bgp any
RP/0/0/CPU0:R3(config-ipv4-acl)# permit tcp any any eq bgp
! Output omitted for brevity
RP/0/0/CPU0:R3(config)# interface Gi0/0/0/0
RP/0/0/CPU0:R3(config-if)# ipv4 access-group v4_BGP_ACL in
RP/0/0/CPU0:R3(config-if)# ipv6 access-group v6_BGP_ACL in
RP/0/0/CPU0:R3(config-if)# commit

工程师要为 BGP 配置两个 ACL 条目，以确保无论是本地路由器还是远端路由器发起 TCP
会话，BGP 包都不会被丢弃；当路由器为路径中间的传输设备时，也要这样配置。
与其说在边缘设备上配置 ACL，更多的部署方案是配置防火墙来保护网络免受无用流量和
恶意流量的侵害。相比较于在路由器和交换机上配置庞大的 ACL，部署防火墙是更好的选择。
防火墙可以配置在以下两个模式中：
? 路由模式；
? 透明模式。
在路由模式中，防火墙具有路由功能，并且它会被看作网络中的一台路由设备。在透明模
式中，防火墙并不会被直连设备看作是一台路由设备，而仅作为“线路中的阻挡物”。因此如果
建立 EBGP 会话时需要穿越透明模式的防火墙，工程师可能并不需要配置 ebgp-multihop。即使
需要配置 ebgp-multihop，也是因为路径中有其他的多跳设备，而不是因为防火墙，防火墙并不
会被算作一个路由跳数。
在有些部署方案中，网络工程师会在路由模式的防火墙上添加 NAT 设置。如果路由器或防
火墙上配置了 NAT，那么工程师在配置 BGP 对等体时，要使用转换后的 IP 地址，而不是远端
IP 地址。如果工程师把对等体配置为远端 IP 地址，同时路径中有一台 NAT 设备作为传输设备，
那么远端路由器在收到这个数据包时，数据包的源 IP 地址会是转换后的 IP 地址，而不是源路
由器发出数据包时的源 IP 地址。这会导致远端路由器重置 TCP 连接并发送 RST（重置）和 ACK
（确认）来作为 TCP 连接中 SYN（同步）包的回应。这是因为接收方路由器上为 BGP 连接配置
的 IP 地址是源路由器的 IP 地址，而接收到的却是与配置的对等体不同的另一个 IP 地址。
在图 3-2 所示拓扑中，路由器 R2 和 R3 中间部署了一台透明模式的防火墙。这时没有必要
为 EBGP 邻居配置命令 neighbor ip-address ebgp-multihop [hop-count]。
防火墙会为接口部署不同的安全级别。举例来说，在 Cisco ASA（自适应安全设备）防火
墙上，内部接口会被分配的安全级别是 100（最高安全级别），外部接口会被分配的安全级别是0（最低安全级别）。工程师需要通过配置 ACL，来放行从较低安全接口发往较高安全接口的流
量。这个规则对于路由模式的防火墙和透明模式的防火墙来说都一样。

工程师可以在透明模式的防火墙中为每个网络配置桥接组（Bridge Group），来减轻安全设
备的压力。工程师可以为属于一个桥接组的接口或 BVI（桥接虚拟接口）接口配置一个管理 IP
地址。
在例 3-7 展示的 ASA ACL 配置案例中，允许 ICMP 包和 BGP 包穿越防火墙。该配置案例
还展示了如何把 ACL 分配给接口。与 ACL 不匹配的其他流量都会被防火墙丢弃。

例 3-7 在 ASA 透明模式的防火墙配置中放行 BGP 流量

interface GigabitEthernet0/0
nameif Inside
bridge-group 200
security-level 100
!
interface GigabitEthernet0/1
nameif Outside
bridge-group 200
security-level 0
!
! Creating BVI with Management IP and should be the same subnet
! as the connected interface subnet
interface BVI200
ip address 10.1.13.10 255.255.255.0
!
access-list Out extended permit icmp any any
access-list Out extended permit tcp any eq bgp any
access-list Out extended permit tcp any any eq bgp
!
access-group Out in interface Outside

在名为 Out 的 ACL 中，放行 BGP 流量的这两个条目其实都是不需要的，但这样配置也是
不错的。需要注意的是，在排查 BGP 对等体翻动的问题时，防火墙 MTU 也是穿越防火墙发送
BGP 更新的一部分。本章稍后会在介绍 BGP 翻动问题的部分进行详细解释。
5．检查 TCP 会话
BGP 会话其实是 TCP 会话。因此为了确保 BGP 会话成功建立，工程师要确认 TCP 会话已
经成功建立。例 3-8 中展示了所有路由器上 TCP 端口 179 上的会话。需要注意的是，路由器会
监听端口 179。在 R3（IOS XR）上有两个 VRF-ID。VRF-ID 0x60000000 表示这是默认 VRF，
VRF-ID 0x00000000 表示这是多 VRF TCP pcb（协议控制块），而应用会使用 TCP 创建指定的VRF pcb。这里说的应用包括 BGP、LDP（标签发现协议）等。

注释设备只能为指定的 VRF pcb 建立 TCP 会话。

例 3-8 输出信息中可以看出 TCP 处于侦听状态

R1# show sockets connection tcp
! Output omitted for brevity
Total number of tcp sockets: 6
Active connections (including servers)
Protocol State/ Recv-Q/ Local Address(port)/
Context Send-Q Remote Address(port)
tcp LISTEN 0 *(179)
Wildcard 0 *(*)
tcp6 LISTEN 0 *(179)
Wildcard 0 *(*)
tcp ESTABLISHED 0 192.168.1.1(179)
default 0 192.168.2.2(15529)
R2# show tcp brief all
TCB Local Address Foreign Address (state)
0DFE19B0 192.168.2.2.15529 192.168.1.1.179 ESTAB
0F7D44F8 10.1.13.1.179 10.1.13.2.52005 ESTAB
0BB8FC40 0.0.0.0.179 10.1.13.2.* LISTEN
0D911608 0.0.0.0.179 192.168.1.1.* LISTEN
RP/0/0/CPU0:R3# show tcp brief
! Output omitted for brevity
PCB VRF-ID Recv-Q Send-Q Local Address Foreign Address State
0x101ad27c 0x60000000 0 0 :::179 :::0 LISTEN
0x101a521c 0x00000000 0 0 :::179 :::0 LISTEN
0x101ad62c 0x60000000 0 0 10.1.13.2:52005 10.1.13.1:179 ESTAB
0x10158cd0 0x60000000 0 0 0.0.0.0:179 0.0.0.0:0 LISTEN
0x101a5e30 0x00000000 0 0 0.0.0.0:179 0.0.0.0:0 LISTEN

如果 BGP 会话没有成功建立，同时 TCP 表中有一个旧条目显示为已建立状态，那么工程
师可以使用 tcb （TCP 控制块）来清除 TCP 会话，在 IOS 平台上需要使用命令 clear tcp tcb value，
在 IOS XR 平台上需要使用命令 clear tcp pcb value。这种旧条目问题会导致设备停止发送 BGP
存活消息，最终 TCP 会进入关闭状态。

注释 NX-OS 平台上不支持对 TCP 会话使用 clear 命令。clear 命令只能清除状态统计信息。

6．模拟一个 BGP 会话
在排查 BGP 对等体失效问题时，一个有用的排错技术是在 TCP 端口 179 上向目的对等体
IP 地址发起 Telnet 连接，并以本地对等体 IP 地址为源地址。这项技术能够帮助工程师确认两台
BGP 对等体设备之间没有阻塞或丢弃 TCP 包。这种测试有助于检查目的路由器上的 TCP 问题，也有助于对可能会阻塞 BGP 包的 ACL 或防火墙进行定义。
例 3-9 中展示了在 TCP 端口 179 上通过 Telnet 来检查 BGP 会话。在执行了这个测试后，
BGP TCP 会话建立成功，但 BGP 处于 OpenSent 状态。

例 3-9 在 TCP 端口 179 上使用 Telnet

NX-OS
R1# telnet 192.168.2.2 179 source loopback 0
Trying 192.168.2.2...
Connected to 192.168.2.2.
Escape character is '^]'.
ÿÿÿÿ9
Connection closed by foreign host.
IOS
R2# show bgp ipv4 unicast summary
! Output omitted for brevity
Neighbor AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.13.2 4 65535 1409 1329 5 0 0 20:00:13 0
192.168.1.1 4 65530 0 1 1 0 0 00:01:40 OpenSent
R2# show tcp brief
TCB Local Address Foreign Address (state)
0FE84118 192.168.2.2.179 192.168.1.1.5282 ESTAB
0FEE0558 10.1.13.1.62644 10.1.13.2.179 ESTAB

注释如果工程师配置了 BGP 认证，那么上述 Telnet 方法将无法正常工作。当路径中配置
了 ACL 或部署了防火墙时，这个测试会非常有用

如果 Telnet使用的源接口或 IP 地址不是远端设备上为 BGP 邻居配置的IP 地址，那么 Telnet
请求就会被拒绝。这也是另一种确认对等体设备上是否配置了正确 IP 地址的方法。
3.1.3 揭秘 BGP 通知
在工程师理解和排查 BGP 对等体失效问题或对等体翻动问题的过程中，BGP 通知都扮演
着至关重要的角色。当检测到错误时，BGP 设备会向对等体发送 BGP 通知。根据错误的类别，
BGP 通知可以在 BGP 会话建立之前发送，也可以在事后发送。每个消息都有固定长度的头部。
根据消息的类型，头部后面可能携带数据部分，也可能不携带。头部的相关字段展示如下；

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 标记 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 长度 | 类型 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

除了固定长度的 BGP 消息头部外，一个通知还包含以下字段；

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 错误代码 | 错误子代码 | 数据（长度可变） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RFC 4271 中定义了错误代码和错误子代码。表 3-1 中展示了所有错误代码、错误子代码及
其解释。

只要生成一个通知，错误代码和子代码都会携带在消息中。这些通知消息在工程师解决对
等体失效问题或对等体翻动问题时很有帮助。
在例 3-10 所示案例中，当对等体配置了错误的 AS 号时，设备向对等体设备发送了一个
BGP 通知。R2 收到的通知中展示出了收到通知的邻居设备，以及错误代码“2/2” — 这就是
错误代码/错误子代码的格式。从表 3-1 中可以看出，错误代码 2 表示 OPEN 错误消息，子代码
2 表示对等体配置了错误的 AS 号。其他重要的内容是末尾的通知数据：4 字节 0000FFFA。数
据部分的十六进制数值有助于工程师对问题进行深入了解，并且在本例中提供了正确的值。数
据部分指出 AS 号应该是 65530，而不是 65531。

例 3-10 BGP 通知

IOS XR
RP/0/0/CPU0:R3# configure terminal
RP/0/0/CPU0:R3(config)# router bgp 65535
RP/0/0/CPU0:R3(config-bgp)# neighbor 10.1.13.1
RP/0/0/CPU0:R3(config-bgp-nbr)# remote-as 65531
RP/0/0/CPU0:R3(config-bgp-nbr)# commit
Sep 19 15:57:52.153 : bgp[1046]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.1.13.1
Down - Remote AS configuration changed (VRF: default) (AS: 65531)
RP/0/0/CPU0:Sep 19 15:57:52.153 : bgp[1046]: %ROUTING-BGP-5-NSR_STATE_CHANGE :
Changed state to NSR-Ready
IOS
R2#
*Sep 19 15:55:34.859: %BGP-3-NOTIFICATION: received from neighbor 10.1.13.2 active
2/2 (peer in wrong AS) 4 bytes 0000FFFA
15:55:34.860: %BGP-5-NBR_RESET: Neighbor 10.1.13.2 active reset (BGP Notification
received)
15:55:34.866: %BGP-5-ADJCHANGE: neighbor 10.1.13.2 active Down BGP Notification
received
15:55:34.867: %BGP_SESSION-5-ADJCHANGE: neighbor 10.1.13.2 IPv4 Unicast topology
base removed from session BGP Notification received

需要注意的是，在例 3-10 中，通知消息有 4 字节的数据字段，取值为 0000FFFA，这个值
可以解析为 AS 号 65530。但如果工程师从 R2（Cisco IOS 路由器）向 R3（Cisco IOS XR 路由
器）发出类似的测试，R2 发出的通知消息中会有 2 字节的数据字段，标明 AS 号为 65535 （FFFF）。
因此工程师需要记住，对于错误 AS 的通知消息来说，IOS XR 路由器会发送 4 字节的数据字段，

而 Cisco IOS 路由器会发送 2 字节的数据字段。
有时 IOS 设备上的 BGP 通知消息可能让人比较迷惑。举例来说，通知中的错误代码/子代
码可能会是 2/8，而根据 RFC 4271 的定义，子代码 8 是未定义的。IOS 中有一些更新了的错误
子代码，详见表 3-2。

这些特殊的错误代码和子代码可能并不适用于其他平台和其他厂商的设备，它们只适用于
Cisco IOS 平台。
3.1.4 解码 BGP 消息
不同的 BGP 通知中包含庞大的数据部分，并根据通知的不同包含很多信息。这些信息无法
通过通知的错误代码/子代码进行读取。如果对等体发送了一些消息，接收方在消息中检测到了
错误，或者无法识别这些消息，BGP 就会为这些消息生成十六进制的 Dump 文件。工程师可以
通过分析这些十六进制的 Dump 文件来判断 BGP 路由器为什么无法处理这个消息。
由于所有数据都是十六进制格式的，因此解码这些数据的工作及其困难且会耗费大量时间。
但如果不这样做的话，工程师无法得知问题的根源并进行修复。
接下来仔细查看例 3-11 中展示的通知消息。本例所示的通知消息生成在日志消息中，并且
携带庞大的通知数据。在这个 Dump 文件生成之前发出的通知消息中，指出对等体配置了错误
的 AS 号，正确的 AS 号应该是 65535（FFFF）。因此工程师需要在 Dump 文件中检查的值主要
是 AS 号，也就是阴影部分标记出的 0xFFFF。

例 3-11 BGP 消息 Dump 文件

BGP-3-NOTIFICATION: sent to neighbor 10.1.13.2 active 2/2 (peer in wrong AS)
2 bytes FFFF
%BGP-4-MSGDUMP: unsupported or mal-formatted message received from 10.1.13.2:
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 003B 0104 FFFF 00B4 C0A8 0303 1E02 0601
0400 0100 0102 0280 0002 0202 0002 0641 0400 00FF FB02 0440 0280 78
BGP Message Decode:
BGP Marker: 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
BGP Length: 0x003B - 59 bytes
BGP Type: 0x01 - OPEN Message
OPEN Message
VERSION: 0x04 - 4
AS: 0xFFFF - 65535
HOLD TIME: 0x00B4 - 180
ROUTER ID: 0xC0A80303 - 192.168.3.3
OPTIONAL PARAMETERS LENGTH: 0x1E - 30 bytes
Opt Length: 28
Param Type: 2 - Optional Parameter
Param Length: 6
Cap Type: 0x01 - 1
Multi Protocol Capability
Cap Length: 0x04 - 4 bytes
AFI: 0x0001 - 1
Reserved Bits: 0x00 - 0
SAFI: 0x01 - 1
Opt Length: 20
Param Type: 2 - Optional Parameter
Param Length: 2
Cap Type: 0x80 - 128
Route Refresh Capability (old)
Cap Length: 0x00 - 0 bytes
Opt Length: 16
Param Type: 2 - Optional Parameter
Param Length: 2
Cap Type: 0x02 - 2
Route Refresh Capability (new)
Cap Length: 0x00 - 0 bytes
Opt Length: 12
Param Type: 2 - Optional Parameter
Param Length: 6
Cap Type: 0x41 - 65
4-byte AS Capability
Cap Length: 0x04 - 4 bytes
AS Number: 0.65531 (0x0000.0xFFFB)
Opt Length: 4
Param Type: 2 - Optional Parameter
Param Length: 4
Cap Type: 0x40 - 64
Graceful Restart Capability
Cap Length: 0x02 - 2 bytes
Restart flag: 0x8078 - 32888

IOS XR 可以帮助工程师弄清楚应该关注消息数据中的什么值，以及应该到哪里去找这些
值。命令 show bgp update in error neighbor ip-address detail 的输出内容中提供了更多有关异常
更新的信息。
例3-12 中展示了 R3 上收到的异常更新，工程师通过命令 show bgp update in error neighbor
ip-address detail 来进一步了解 BGP 消息中的问题。需要注意的是，本例的问题出在更新消息中的
的属性2 字段，并且属性2 中还有一个缺失的属性。解码 BGP 的过程依旧没有变化，详见例3-12。

例 3-12 IOS XR 平台上的异常 BGP 更新

RP/0/0/CPU0:R3# show logging | in MALFORM
bgp[1046]: %ROUTING-BGP-3-MALFORM_UPDATE : Malformed UPDATE message received
from neighbor 10.1.13.1 - message length 126 bytes, error flags 0x00000a00,
action taken "TreatAsWithdraw". Error details: "Error 0x00000800,
Field "Attr-missing", Attribute 2 (Flags 0x00, Length 0), Data []"
RP/0/0/CPU0:R3# show bgp update in error neighbor 10.1.13.1 detail
! Output omitted for brevity
VRF "default"
Neighbor 10.1.13.1
Update error-handling: Allow session reset
Malformed messages stored: 5 (current index: 0)
Malformed message #1
Received: Sep 20 02:53:02.269
Error flags: 0x00000a00
Discarded attributes: 0
Final action: TreatAsWithdraw
Error elements: 2
[1] Error 0x00000200, Field "Attr-data", Attribute 2 (Flags 0x40,Length 10)
Error data&colon; [40020a02020000272a00005d7a] (13 bytes)
Action: TreatAsWithdraw
[2] Error 0x00000800, Field "Attr-missing", Attribute 2 (Flags 0x00, Length 0)
Error data&colon; [] (0 bytes)
Action: TreatAsWithdraw
Reset/notification information:
Reason "None", Postit type "Update malformed"
Notification code 3, sub-code 3
Notification data [02] (1 bytes)
Message data&colon; 81 bytes
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
00510200 00003640 01010040 020A0202
0000272A 00005D7A 400304CE 7EEC28C0
07080000 5D7A797F 0040C008 10272A10
68272A7E 58272A9C A65E3327 2A18745D
30

在 NX-OS 平台上，BGP 消息并不会记录在日志中，而是必须使用调试程序（Debug）进行
收集。工程师可以使用命令 debug bgp packets 来查看设备收到了哪些 BGP 消息，以及哪些 BGP
消息可以被解码。例 3-13 中展示了如何在 NX-OS 平台上使用命令 debug bgp packets 来捕获
BGP 数据包。输出内容中展示的 BGP 包是 R1 和 R2 之间发送的 BGP OPEN 消息。一开始的数
据 Hexdump 中包含有 BGP 标记（Marker）。以 00460104.0046 开始的第二行是 BGP 长度字段，
后面跟着 01 表示这个消息是一个 BGP OPEN 消息。

例 3-13 NX-OS 平台上的 debug bgp packet

R1# debug logfile bgp
R1# debug bgp packets
! Below debug output shows the Hexdump of the BGP packet received.
R1# show debug logfile bgp
! Output omitted for brevity
18:24:04.560109 bgp: 65530 [8480] Hexdump at 0x84bc64c, 70 bytes:
18:24:04.560631 bgp: 65530 [8480] FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
18:24:04.560743 bgp: 65530 [8480] 00460104 FFFA00B4 C0A80101 29022742
18:24:04.560853 bgp: 65530 [8480] 00430302 01408000 02000104 00010001
18:24:04.560953 bgp: 65530 [8480] 40060078 00010100 41040000 FFFA0506
18:24:04.561051 bgp: 65530 [8480] 00010001 0002
! Output omitted for brevity
R1# undebug all

如果 NX-OS 设备之间正在交换的 BGP 更新和消息数量过多，工程是最好使用 Ethanalyzer
或 SPAN（交换端口分析仪）特性来捕获异常的 BGP 更新包，以便将来分析之用。
3.1.5 在 IOS XR 中排查进程阻塞的问题
IOS XR 是一个分布操作系统，每个组件（特性）都使用自己的一组线程来分别运行不同的
进程，每个线程都负责组件中不同的任务。与传统的 IOS 不同，如果路由器上的一个进程崩溃
了，IOS XR 并不会重启整个系统，而是会单独重启出问题的进程，不会影响其他进程的运行。
由于这是一个多线程的环境，线程会不断改变自己的状态。有些线程只运行很短的一段时间，
而有些需要运行很长时间。一些重要的低级别进程，比如内核线程，可能会阻塞一些高级别进
程的线程，这样它可以以更高的优先级来执行自己的任务。被阻塞的进程会导致不同的特性无
法正常工作或者完全无法工作。
在 IOS XR 中，BPM（BGP 进程管理器）和 BGP 进程负责创建 BGP 协议功能。一个 BPM
进程的主要任务是批量处理 BGP 路由器的进程，比如 BGP 进程，并检查和应用所有与 BGP 相
关的配置。当 BGP 运行在多实例模式时，它与另一个重要的进程共同把不同的 BGP 路由器程
序分布给相应的节点。
当工程师没有明确配置路由器 ID 时，BPM 进程还负责计算路由器 ID。它会与 NETIO、
TCP 和少量其他进程在内部进行交互，来执行系统必需的任务，并负责把路由放入 RIB（路由
信息库）中。图 3-3 中展示了这些进程在 RP（路由处理器）上相互交互的过程。

注释图 3-3 中并没有展示出所有进程。其他进程的讨论超出了本书范畴。

因此，如果这些进程中的任意一个在 RP 上或 LC（线卡）上被阻塞了很长一段时间，会
严重影响路由器上的 BGP 服务。接下来的内容中介绍了如何排查 IOS XR 平台上的 BGP 进程
问题。
1．检查 BGP 和 BPM 进程的状态
工程师可以使用命令 show process process-name [detail | location {LC/RP location | all}]来
检查 BGP 和 BPM 进程是否处于运行（Run）状态，在这条命令中，process-name 可以是 bgp
或 bpm，也可以是其他进程。当工程师需要检查线卡或备份路由处理器卡上的进程状态和信息
时，可以使用 location 选项。例 3-14 中展示了使用 show process 命令来检查 bgp 进程状态的案
例。在本例的命令输出内容中，最重要的字段是任务 ID（Job Id）、PID、复位计数（Respawn count）、
进程状态（Process state），以及进程下的线程状态。在例 3-14 中，复位计数是 6。如果 bgp 进
程不断崩溃、被恢复默认配置或重新配置的话，这个数值会增长。

例 3-14 show process bgp 命令的输出内容

RP/0/0/CPU0:R3# show process bgp
Job Id: 1046
PID: 827666
Executable path: /disk0/iosxr-routing-5.3.0/bin/bgp
Instance #: 1
Version ID: 00.00.0000
Respawn: ON
Respawn count: 6
Last started: Sun Sep 13 05:18:54 2015
Process state: Run
Package state: Normal
Started on config: default
Feature name: ON
Tag : default
Process group: v4-routing
core: MAINMEM
Max. core: 0
Placement: Placeable
startup_path: /pkg/startup/bgp.startup
Ready: 1.229s
Available: 7.849s
Process cpu time: 1.470 user, 0.610 kernel, 2.080 total
JID TID Stack pri state TimeInState HR:MM:SS:MSEC NAME
1046 1 392K 10 Receive 0:00:00:0099 0:00:00:0136 bgp
1046 2 392K 10 Receive 50:56:47:0715 0:00:00:0019 bgp
1046 3 392K 10 Receive 84:33:28:0736 0:00:00:0000 bgp
1046 4 392K 10 Receive 84:33:27:0646 0:00:00:0000 bgp
1046 5 392K 10 Receive 84:33:23:0086 0:00:00:0000 bgp
1046 6 392K 10 Sigwaitinfo 84:33:28:0606 0:00:00:0000 bgp
1046 7 392K 10 Receive 83:59:49:0874 0:00:00:0009 bgp
1046 8 392K 10 Receive 0:00:01:0529 0:00:00:0000 bgp
1046 9 392K 10 Receive 36:49:17:0309 0:00:00:0000 bgp
1046 10 392K 10 Receive 0:00:01:0689 0:00:00:0010 bgp
1046 11 392K 10 Receive 12:37:51:0414 0:00:00:0000 bgp
1046 12 392K 10 Nanosleep 0:00:00:0899 0:00:00:0030 bgp
1046 13 392K 10 Receive 84:21:24:0516 0:00:00:0000 bgp
! Output omitted for brevity

如果 BGP 进程崩溃了，工程师一定要知道是什么导致的崩溃。工程师可以检查最后发生的
时间或者把配置恢复到崩溃之前，这样做可以稳定 bgp 进程。
2．检查被阻塞的进程
工程师可以使用命令 show process blocked [location {RP/LC}]来查看设备上是否有被阻塞
的进程，以及这些进程是否对 BGP 进程带来了影响。最重要的进程包括 bgp、bpm、tcp 和 netio。
例 3-15 中展示了如何查看被阻塞的进程，以及这些进程进入这种状态的次数。在命令的输出内
容中，总是会有一些进程处于阻塞状态，比如 ksh 或 lpts_fm。工程师只需忽略这些进程就好。

例 3-15 show process blocked 命令的输出内容

RP/0/0/CPU0:R3# show processes blocked
Thu Sep 17 06:25:11.639 UTC
Jid Pid Tid Name State TimeInState Blocked-on
65542 200710 1 ksh Reply 121:14:38:0413 2 devc-ser8250
65555 217107 1 ksh Reply 121:14:28:0649 217106 devc-conaux
65692 680092 1 exec Reply 0:00:00:0079 1 kernel
289 643248 2 lpts_fm Reply 11:30:09:0743 331870 lpts_pa
65734 975046 1 show_processes Reply 0:00:00:0000 1 kernel

3．重启进程
如果出于某些原因，一个进程很长时间内都处于阻塞状态，工程师可以使用命令 process
restart [job-id | process-name]来重启这个进程。也可能有些进程被阻塞了很长一段时间，但却
不会造成什么影响，比如 devc-conaux。这个进程是负责控制台访问的。根据工程师正在排查
的问题、与问题相关的进程，以及问题发生的实际时间，工程师可以分析出进程被阻塞的时
间，并且把相关的进程进行重启。举例来说，如果 TCP 进程在 10 小时之前进入了阻塞状态，
就在同时 BGP 对等体失效了并且再也没有建立起来，那么把被阻塞的 TCP 进程进行重启看似
是合理的做法。
3.1.6 IOS XR 中的 BGP 追踪消息
IOS XR 中提供了 BGP 追踪功能，有助于追踪 BGP 问题。通过使用 BGP 追踪，工程师可
以在一定程度上查看当问题发生时，BGP 的行为历史。总的来说，BGP 追踪信息可以分为以下
两类：
? 非致命错误；
? 信息性消息。
非致命错误是可以自动恢复的。信息性消息用来记录事件中发送的错误消息。但它们并不
会提供包含有 BGP 所有行为的完整日志。致命错误总是会被自动记录到系统日志中，因此追踪
输出信息中是不包含致命错误的。
由于日志追踪消息是一个缓慢的过程，并且追踪缓存是储存在内存中的，因此设备不会追
踪成功发生的事件，或者某些事件的详细信息。储存在内存中的追踪消息也是有大小限制的。
当缓存占满后，以前的追踪日志会被覆盖。考虑到这个因素，错误追踪消息会与信息性追踪消
息储存在不同的缓存中。

每个用于调试 BGP 问题的 BGP 追踪消息都属于表 3-3 中的一类。

工程师可以使用命令 show parser dump | include (.*bgp.*trace)轻松找出与 BGP 相关的追
踪命令。这条命令会输出所有用于 BGP 追踪的 show 命令。
例 3-16 中展示了 BGP 追踪信息，工程师使用命令 show bgp trace 追踪 BGP 会话的建立。每
个追踪条目都以一个时间戳开始，接着是追踪缓存的名称。缓存名称指明了记录这个追踪消息的
进程，以及这是一个信息性追踪消息，还是一个错误追踪消息。分布式 BGP 路由进程和 BGP RIB
（bRIB）进程也会在名称中包含进程 ID。对于错误追踪消息来说，名称会以 err 结尾。例 3-16 中
同时展示了错误消息和信息性消息。

例 3-16 show bgp trace 命令的输出内容

RP/0/0/CPU0:R3# show bgp trace
! Output omitted for brevity
04:58:19.822 default-bgp/spkr-tr2-gen 0/0/CPU0 t21 [GEN]:546: nbr 10.1.13.1,
old state 7, new state 1, fd type 0, fd 0
04:58:33.871 default-bgp/spkr-tr2-sync 0/0/CPU0 t1 [SYNC]:8104: Nbr '10.1.13.1'
: Loc 2: Determined lport/fport 179/38338
04:58:33.871 default-bgp/spkr-tr2-gen 0/0/CPU0 t1 [GEN]:546: nbr 10.1.13.1,
old state 1, new state 2, fd type 1, fd 125
04:58:33.901 default-bgp/spkr-tr2-err 0/0/CPU0 t14 [ERR][GEN]:1300: OPEN
from '10.1.13.1' has unrecognized cap code/len 70/0 – Ignored
04:58:33.901 default-bgp/spkr-tr2-upd 0/0/CPU0 t14 [UPD]:1818: Updgrp change not
scheduled after open processing: nbr=10.1.13.1, nbrfl=0x8010000
04:58:33.901 default-bgp/spkr-tr2-gen 0/0/CPU0 t14 [GEN]:2222: calling
bgp_send_open, nbr 10.1.13.1, loc 4, data 0,0
04:58:33.901 default-bgp/spkr-tr2-gen 0/0/CPU0 t14 [GEN]:546: nbr 10.1.13.1,
old state 2, new state 4, fd type 1, fd 125
04:58:33.901 default-bgp/spkr-tr2-gen 0/0/CPU0 t14 [GEN]:546: nbr 10.1.13.1,
old state 4, new state 5, fd type 1, fd 125
04:58:33.901 default-bgp/spkr-tr2-gen 0/0/CPU0 t14 [GEN]:2295: calling bgp_send_
keepalive, nbr 10.1.13.1, loc 1, data 0,0
04:58:33.961 default-bgp/spkr-tr2-sync 0/0/CPU0 t19 [SYNC]:5610: Sent
NSR-Not-Ready notif to Rmf
04:58:33.961 default-bgp/spkr-tr2-upd 0/0/CPU0 t18 [UPD]:1376: Filter-group op
(Alloc) Tbl/Nbr(TBL:default (1/1)) fgrp idx 0.2 subgrp idx 0.1 updgrp 0.0 rtset 0
04:58:33.961 default-bgp/spkr-tr2-upd 0/0/CPU0 t18 [UPD]:2640: Filter-group op
(Filter-group Add Nbr new) Tbl/Nbr(Afi:IPv4 Unicast:Nbr:10.1.13.1)
fgrp idx 0.2 subgrp idx 0.1 updgrp 0.2 rtset 0
04:58:33.961 default-bgp/spkr-tr2-upd 0/0/CPU0 t18 [UPD]:2662: Created filtergrp 2
for nbr 10.1.13.1, afi 0. Subgrp version 0
04:58:33.961 default-bgp/spkr-tr2-upd 0/0/CPU0 t18 [UPD]:4213: Created subgrp 1
for nbr 10.1.13.1, afi 0 with version 0
04:58:33.961 default-bgp/spkr-tr2-ev 0/0/CPU0 t14 [EV]:1952: Inside scan_adjust_
estab_outstanding for nbr 10.1.13.1, nbr-down 0, state 2,
evt-in-nbrwait 0
04:58:33.961 default-bgp/spkr-tr2-gen 0/0/CPU0 t14 [GEN]:546: nbr 10.1.13.1,
old state 5, new state 6, fd type 1, fd 125
04:58:33.961 default-bgp/spkr-tr2-gen 0/0/CPU0 t14 [GEN]:549: Nbr '10.1.13.1'
established
! Output omitted for brevity

要想通过过滤只看错误消息或任何其他消息，比如 update（更新）或 event（事件），工程
师可以使用命令 show bgp trace trace-option，其中 trace-option 的取值可以是 error （错误）、event
（事件）或其他支持的 BGP 追踪过滤参数。
例 3-17 中展示了工程师使用命令 show bgp trace error 只查看 BGP 错误消息。错误追踪消
息中展示出路由器忽略了功能代码值 70，这个值表示增强型路由刷新功能。

注释第 7 章中会详细介绍增强型路由刷新功能

例 3-17 show bgp trace error 命令的输出内容

RP/0/0/CPU0:R3# show bgp trace error
6 wrapping entries (1826304 possible, 3840 allocated, 643 filtered, 649 total)
21:14:28.248 default-bgp/spkr-tr2-err 0/0/CPU0 t1 [ERR][SYNC]:284: pid 0 : Got my
local_node as 0x0
21:14:35.638 default-bgp/spkr-tr2-err 0/0/CPU0 t14 [ERR][GEN]:1300: OPEN from
'10.1.13.1' has unrecognized cap code/len 70/0 – Ignored
! Output omitted for brevity

3.1.7 NX-OS 中的 BGP 追踪消息
在 NX-OS 平台中，与所有事件和错误相关的追踪消息都会被储存为事件历史
（Event-History）。少量的事件历史追踪是默认就启用的，比如 BGP 事件或错误，但更为详细的
事件历史日志必须由工程师手动启用，工程师可以在 router bgp 配置模式中使用命令
event-history [cli | detail | events | periodic] [size {size_in_text | bytes}]。这条命令同时也用来设置
存储事件历史的缓存大小。例 3-18 中展示了 router bgp 配置模式下的 BGP 事件历史配置，包括
如何启用详细的事件历史日志记录，以及如何把事件历史日志导出为系统日志。

例 3-18 NX-OS 平台上的 BGP 事件历史

R1(config)# router bgp 65530
R1(config-router)# event-history ?
cli CLI event history buffer
detail Detailed event history buffer
events Events history buffer
periodic Periodic events history buffer
R1(config-router)# event-history detail size ?
disable Disabled the buffer
*Default value is disble
large Large buffer
medium Medium buffer
small Small buffer
R1(config-router)# event-history detail size medium
R1(config-router)# end
R1# show bgp event-history logs
bgp-65530 logs events
19:37:15.618509 bgp 65530 [8556]: [8566]: (default) neighbor 192.168.2.2 Up
19:37:07.425970 bgp 65530 [8556]: [8567]: (default) neighbor
192.168.2.2 Down - session cleared

表 3-4 中展示了 show bgp event-history 命令中各种选项的用法。

在排查 BGP 对等体问题时，在事件历史日志中查看 netstack 进程也很重要。netstack 是
NX-OS 中二层到四层协议栈的实现，它是 NX-OS 控制平面中的重要组成部分。如果 Nexus 设
备在建立 TCP 会话时出现了问题，很可能就是与 netstack 进程相关的问题导致的。命令 show
sockets internal event-history events 有助于确定某个 BGP 对等体 IP 地址的 TCP 状态转换。
例 3-19 中展示了命令 show sockets internal event-history events 的用法，工程师想要排查
的问题是 BGP 对等体 IP 地址 192.168.2.2 的 TCP 会话被关闭了，但没有收到任何 TCP 请求来
建立新的会话。

要想更深入地排查 netstack 问题，工程师可以使用命令 show tech netstack [detail]来收集与
问题相关的更多信息。
3.1.8 调试 BGP
运行调试程序总是排查任何网络问题的最后一步。如果工程师不谨慎对待的话，调试程序
有时会对网络带来影响。但当其他排错技术无法解决问题时，调试程序又是唯一的选择。

注释很多调试程序会输出大量信息，也就是说在调试输出内容中会出现庞大的日志消息。
如果在使用这种调试程序的时候启用了控制台日志特性，会对路由器的 CPU 带来巨大负担，可
能会导致失去管理连接、丢包，甚至会导致路由器或进程崩溃。在这种情况下，唯一的恢复手
段就是重启路由器。但如果工程师谨慎使用的话，调试程序可以解决问题并提供更快速的解决
方案。

当 BGP 对等体失效且所有其他排错步骤都无法解决问题，或者无法捕获 BGP 包时，工程
师就可以启用调试程序。调试程序可以检测到路由器是否生成并发送了必要的 BGP 包，以及是
否接收到了相应的数据包。
在 IOS 设备上，当某个 BGP 邻居失效了，工程师可以使用命令 debug ip bgp ip-address 或
debug bgp ipv4 unicast ip-address 来运行调试程序。NX-OS 设备上不需要使用 debug，因为 BGP
中的追踪消息中已经包含了足够的信息来排查问题。命令 debug bgp ipv4 unicast events 可以提
供与命令 show bgp event-history periodic 几乎相同的输出信息。
例 3-20 中展示出路由器 R2 进入了 Active（活跃）状态，因为远端主机没有进行响应。会话
从 Idle（空闲）状态进入了 Active 状态，但无法从 Active 状态进入 Established（已建立）状态。

例 3-20 debug bgp ipv4 unicast ip-address 命令的输出内容

R2# debug bgp ipv4 unicast 192.168.1.1
BGP debugging is on for neighbor 192.168.1.1 for address family: IPv4 Unicast
19:44:10.859: BGP: 192.168.1.1 active went from Idle to Active
19:44:10.860: BGP: 192.168.1.1 open active, local address 192.168.2.2
19:44:21.831: BGP: topo global:IPv4 Unicast:base Scanning routing tables
19:44:40.866: BGP: 192.168.1.1 open failed: Connection timed out;
remote host not responding
19:44:40.866: BGP: 192.168.1.1 Active open failed - tcb is not available,
open active delayed 10240ms (35000ms max, 60% jitter)
19:44:40.867: BGP: ses global 192.168.1.1 (0xF63BD98:0) act Reset
(Active open failed).
19:44:40.872: BGP: 192.168.1.1 active went from Active to Idle

例 3-20 的输出信息中还显示出会话的 tcb 不可用。这表示 TCP 会话没有建立起来。在 IOS
设备上，如果 TCP 会话无法建立，工程师可以启用命令 debug ip tcp transaction [addresssrc-or-dst-addr] [port port-num]，来检查 TCP 会话无法建立的原因。
在 IOS XR 设备上，工程师可以使用命令 debug tcp packet [v4-access-list acl-name]来限制调
试程序只输出那些与 ACL 相匹配的数据包。在 Nexus 设备上，工程师可以使用命令 debug sockets
tcp。尽管在 Cisco IOS 或 IOS XR 平台上没有过滤选项，但工程师可以把输出内容捕获到一个日
志文件中。例 3-21 中展示了 R1 和 R2 上的调试信息，用来检查它们之间的 TCP 协商过程。调试
程序的输出内容中显示出 R2 向 R1 发送了 SYN 包，R1 接收到了这个 SYN 包，但 R2 没有接收
到与这个 SYN 包相关的 SYN-ACK 包。这表示从 R1 到 R2 的方向上出现了 TCP 包丢失的情况。

例 3-21 IOS 和 NX-OS 上的 TCP 调试信息

NX-OS
R1# debug sockets tcp
20:22:18.687624 netstack: syncache_insert: SYN added for
L:192.168.2.2.42829 F:192.168.1.1.179, tp:0x8740cd4 inp:0x8740c0c
20:22:48.790993 netstack: tcp_connect: Originating Connections
with ports (Src 60250, Dst 179)
20:22:48.793718 netstack: tcp_notify: TCP: Notify
L: 192.168.1.1.60250, F: 192.168.2.2.179 of error Connection refused
20:22:51.813236 netstack: tcp_notify: TCP: Notify L: 192.168.1.1.60250, F:
192.168.2.2.179 of error Connection refused
IOS
R2# debug ip tcp transaction 192.168.1.1
20:18:27.194: TCP0: RETRANS timeout timer expired
20:18:27.195: 192.168.2.2:15033 <---> 192.168.1.1:179 congestion window changes
20:18:27.195: cwnd from 1460 to 1460, ssthresh from 65535 to 2920
20:18:27.196: TCP0: timeout #1 - timeout is 4000 ms, seq 2704785302
20:18:27.196: TCP: (15033) -> 192.168.1.1(179)
20:18:31.194: TCP0: RETRANS timeout timer expired
20:18:31.196: TCP0: timeout #2 - timeout is 8000 ms, seq 2704785302
20:18:31.196: TCP: (15033) -> 192.168.1.1(179)
20:18:39.194: TCP0: RETRANS timeout timer expired
20:18:39.196: TCP0: timeout #3 - timeout is 15999 ms, seq 2704785302
! Output omitted for brevity
*Oct 4 20:18:55.194: TCP0: state was SYNSENT -> CLOSED [15033 -> 192.168.1.1(179)]
20:18:55.198: TCB 0xD770800 destroyed

根据调试日志的内容，工程师可以在 R1 与 R2 之间的路径或接口上查看是否配置了造成丢
包的 ACL。
3.1.9 IPv6 对等体的排错
随着 IPv4 路由资源的耗尽，IPv6 地址的使用率渐渐赶了上来。大多数服务提供商已经更
新或准备更新它们的基础设施，使其成为双栈环境来同时支持 IPv4 和 IPv6 流量，并做好为客
户提供 IPv6 服务的准备。正在开发的新应用也都与 IPv6 兼容，或者完全运行在 IPv6 上。伴随
着这种发展趋势，工程师也需要具备为 IPv6 BGP 邻居关系进行排错的技术能力。
排查 IPv6 BGP 对等体关系问题的方法与在 IPv4 中排查 BGP 对等体关系问题的方法相同。

当 IPv6 BGP 对等体失效时，工程师可以按照以下步骤，为 IPv6 BGP 邻居排错。
步骤 1 检查配置是否正确，包括对等体的 IPv6 地址、AS 号、update-source interface-id、
认证密码、ebgp-multihop 等。
步骤 2 使用命令 ping ipv6 ipv6-neighbor-address [source interface-id | ipv6-address]来确认
可达性。
步骤 3 检查 TCP 连接，在 IOS 和 IOS XR 设备上使用命令 show tcp brief，在 NX-OS 设
备上使用命令 show socket connection tcp。对于 IPv6 来说，要检查 TCP 连接的源
和目的 IPv6 地址，并且其中一个端口号为 179。
步骤 4 与 IPv4 类似，路径中的 IPv6 ACL 也应该放行端口号为 179 的 TCP 流量，以及为
了检查可达性，还要放行 ICMPv6 包。
步骤 5 在IOS路由器上，工程师可以使用命令debug bgp ipv6 unicast ipv6-neighbor-address
来捕获 IPv6 BGP 包。在 NX-OS 和 IOS XR 设备上，调试命令保持不变，只不过
用来过滤调试输出结果的 ACL 要换成 IPv6 ACL。
3.1.10 案例研究 — 单会话与多会话
公司 A 正在与公司 B 合并。作为合并工作的一部分，两家公司要在每个站点使用 EBGP
交换各自的网络信息。公司 A 是一个多厂商网络环境，而公司 B 的网络中只有 Cisco 设备。在
一个站点中，两台路由器之间无法建立 EBGP 会话。客户 A 向 Cisco TAC（Cisco 技术支持中心）
提出服务请求，并且按照以下步骤执行了排错行为。
步骤 1 客户检查了两侧（A 和 B）的配置，均正确。
步骤 2 验证了可达性。
步骤 3 在端口 179 上执行了 TCP 连接测试，测试通过。
即使在所有验证都通过后，BGP 会话仍然无法建立。在公司 A 的路由器上，工程师看到了
一个 BGP 通知，表示不支持的/不兼容的功能，详见例 3-22。

例 3-22 公司 A 路由器上的 BGP 通知消息

*Oct 5 06:06:58.557: %BGP-3-NOTIFICATION: sent to neighbor 10.1.12.2
active 2/7 (unsupported/disjoint capability) 0 bytes
*Oct 5 06:06:58.557: %BGP-4-MSGDUMP: unsupported or mal-formatted message
received from 10.1.12.2:
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0039 0104 FDE9 00B4 0A01 0C02 1C02 0601
0400 0100 0102 0280 0002 0202 0002 0246 0002 0641 0400 00FD E9

这个通知消息清晰地指出一个对等体交换的功能无法获得另一个对等体的支持。通过使用
命令 show bgp ipv4 unicast neighbor ip-address，工程师发现一侧具有多会话功能，而另一侧不
支持。例 3-23 展示了两个 BGP 邻居之间的差别。

例 3-23 show bgp ipv4 unicast neighbor ip-address 命令的输出内容

Comp_A_R1# show bgp ipv4 unicast neighbor 10.1.12.2
BGP neighbor is 10.1.12.2, remote AS 65001, external link
BGP version 4, remote router ID 10.1.12.2
BGP state = Idle
Neighbor sessions:
0 active, is multisession capable
Stateful switchover support enabled: NO for session 0
! Output omitted for brevity
Comp_B_R2# show bgp ipv4 unicast neighbor 10.1.12.1
BGP neighbor is 10.1.12.1, remote AS 65000, external link
BGP version 4, remote router ID 0.0.0.0
BGP state = Idle
Neighbor sessions:
0 active, is not multisession capable (disabled)
Stateful switchover support enabled: NO
! Output omitted for brevity

这意味着一侧尝试在单会话模式中建立 BGP 会话，而另一侧尝试使用多会话模式。这种不
匹配的行为导致 BGP 会话无法建立。为了解决这个问题，工程师可以在公司 B 侧配置命令
transport multisession，也可以在公司 A 侧配置命令 transport singlesession。
接下来我们简单介绍一下 BGP 单会话和多会话功能。
1．多会话功能
所有最新的 Cisco IOS 软件都支持多会话功能，但默认并没有启用。通过使用这个功能，
路由器可以为指定邻居建立多会话，也就是针对每个地址家族建立会话。多会话模式可以用于
MP-BGP 会话，这时对等体之间会建立多 BGP 会话，而不是通过单会话为所有地址家族交换更
新消息。举例来说，如果一个邻居在 IPv4 地址家族和 vpnv4 地址家族中建立了会话，那么路由
器上共建立了两个 BGP 会话。这个功能为管理 BGP 会话提供了更为细致的粒度。使用多地址
家族的一个重要好处在于，当工程师需要增加地址家族的配置时，新的配置不会影响已有地址
家族的邻居关系配置。如果路由器上禁用了多会话功能，工程师可以使用命令 neighbor
ip-address transport multisession 进行启用。这条命令会在建立 BGP 邻居关系时，强制 OPEN
消息中只包含一个地址家族，这样就可以实现每个地址家族一个会话。
2．单会话功能
在单会话模式中，BGP 会在一个 OPEN 消息中添加多个地址家族。在单会话模式中，所有
地址家族的更新消息都是通过单个 BGP 会话进行交换的。所有较新的 IOS 版本都弃用了相关配
置命令，因此它在系统中也是隐藏的。单会话模式是形成邻居关系的默认模式。如果路由器默
认运行的是多会话模式，那么工程师可以使用命令 neighbor ip-address transport single-session
将其更改为单会话模式。

BGP路由器协议排错教程：BGP 对等体失效的问题相关推荐

BGP路由器协议排错教程：BGP 基本配置
在配置 BGP 时,最好从模块化的角度考虑配置信息.BGP 路由器上需要配置以下组成部分. ? BGP 会话参数:BGP 会话参数中提供了用来与远端 BGP 邻居建立通信所需的设置. 会话设置中包含 ...
BGP路由器协议排错教程：BGP 对等体翻动问题
完整版下载 2022年最新BGP路由协议排错教程指南-网络安全文档类资源-CSDN下载 BGP 对等体失效问题讨论的是当 BGP 邻居关系总是在 Idle(空闲)状态和 Active(活跃) 状态之间 ...
BGP路由器协议排错教程：缺失 BGP 路由的排错
完整版下载 2022年BGP路由协议排错全方面教程-网络安全文档类资源-CSDN下载我们已经全面介绍过从 BGP 对等体接收路由,以及把路由通告给其他对等体的完整过程. 这些知识能够为对等体之间路由 ...
BGP路由器协议排错教程：AS总结
1.15 允许 AS 允许 AS(Allow AS)特性允许路由器在一条路由的 AS-Path 中检测到自己 ASN 的情况下, 仍接收并处理这条路由.作为一种防环机制,路由器在 AS-Path 中看 ...
BGP路由器协议排错教程：BGP 路由通告的排错
工程师很容易对 BGP 路由通告产生误解,这是本章第一个需要解释清楚的概念. 4.1.1 本地路由通告问题假设现在有一台路由器,它要把网络 10.1.0.0/16 和 10.0.0.0/8 放到 B ...
BGP路由器协议排错教程：IBGP
当一个AS内需要使用多种路由策略,或者当一个AS要在多个AS之间提供传输联通性时, 就需要在一个 AS 内使用 BGP.如图 1-3 所示,AS65200 提供了 AS65100 和 AS65300 ...
BGP——边界网关协议简介
BGP简介目录 BGP简介 BGP协议的关注点 BGP的数据包 BGP的状态机 BGP工作过程 BGP的路由黑洞 BGP的防环机制--水平分割 BGP的基本配置 BGP的路由聚合 BGP的路由反射器 ...
如何在 Quagga BGP 路由器中设置 IPv6 的 BGP 对等体和过滤
在之前的教程中,我们演示了如何使用Quagga建立一个完备的BGP路由器和配置前缀过滤.在本教程中,我们会向你演示如何创建IPv6 BGP对等体并通过BGP通告IPv6前缀.同时我们也将演示如何使用前 ...
网络路由器协议（OSPF、RIP、BGP、IGRP、IS-IS）
一.OSPF.RIP.BGP.IS-IS的区别 (1).OSPF:(开放式最短路径优先)是一种链路状态路由协议,使用SPF算法(Dijkstra算法)计算路由,保证没有路由环路,使用带宽作为度量值,能 ...

BGP路由器协议排错教程：BGP 对等体失效的问题

BGP路由器协议排错教程：BGP 对等体失效的问题相关推荐

最新文章

热门文章