BGP路由器协议排错教程：BGP 对等体翻动问题

完整版下载

2022年最新BGP路由协议排错教程指南-网络安全文档类资源-CSDN下载

BGP 对等体失效问题讨论的是当 BGP 邻居关系总是在 Idle（空闲）状态和 Active（活跃）
状态之间切换，并且无法进入 Established（已建立）状态。但当我们说 BGP 对等体翻动时，意
味着会话建立后 BGP 的邻居状态又发生了改变。在这种情况下，BGP 状态持续在 Idle 状态和
Established 状态之间翻动。BGP 翻动有以下两种状态。
? Idle/Active：在前一节中进行了讨论。
? Idle/Established：错误的更新消息、TCP 问题（多跳部署环境中的 MSS 大小）。
导致 BGP 对等体翻动的原因有以下这些：
? 错误的 BGP 更新消息；? 保持计时器超时；
? MTU 不匹配；
? 高 CPU 利用率；
? 接口和平台丢包；
? 不适当的控制平面限速。
3.2.1 错误的 BGP 更新消息
错误的 BGP 更新消息指的是从对等体那里接收到了已损坏的更新包。这种情况并不常见，
产生这种问题的原因有如下这些：
? 承载更新包的链路有问题，硬件有问题；
? BGP 更新包封装问题；
? 攻击者（黑客）发出的恶意更新包。
当 BGP 更新包已损坏时，路由器都会生成一个错误代码为 3 的 BGP 通知，错误代码详见
表 3-1。
例 3-24 所示为异常更新的案例，这个异常更新导致了 BGP 会话的翻动。相关信息中展示
出一个属性字段的长度要比更新包本身的长度还长，因此这是一个损坏的更新。解码后的 BGP
消息显示出 BGP 更新包的长度是 93 字节（0x005D），而属性类型 17（0x11）的属性长度等于
53572 字节（0xD144），这种情况是不可能会发生的，因为单个属性的长度不会超出总长度 93
字节。因此设备生成了通知代码 3/1，指明异常属性列表。

例 3-24 异常 BGP 更新

Nov 17 09:36:06.990 CET: %BGP-3-NOTIFICATION: sent to neighbor 10.1.13.2 3/1
(update malformed) 47 bytes D011D144 02030000 32E60000 12830000 B0
Nov 17 09:36:06.990 CET: BGP: 10.1.13.2 Bad attributes FFFF FFFF FFFF FFFF FFFF FFFF
FFFF FFFF 005D 0200 0000 4240 0101 0240 020C 0203 32E6 1283 B066 0101 5BA0 D011
D144 0203 0000 32E6 0000 1283 0000 B066 0101 0001 0049 4003 04D5 9080 C580 0404
0000 0001 C007 06FF 77AC 11F1 0815 781D F0
Nov 17 09:36:21.518 CET: %BGP-5-ADJCHANGE: neighbor 10.1.13.2 Up

3.2.2 保持计时器超时
保持计时器超时是一个导致 BGP 对等体翻动的常见原因。它表示路由器在保持计时器超
时之前，没有接收到或处理过生存消息或任何更新消息。这样的话，设备会发出一个通知消
息（代码 4/0）并关闭会话。在 IOS 设备上，生存消息是由 BGP I/O 进程发出的，BGP 路由
器进程负责对入站的存活消息进行解释。由保持计时器超时导致的 BGP 翻动问题可以归结为
以下原因之一。
? 接口问题。
? 物理联通性。
? 物理接口。
? 输入保持队列。
? TCP 接收队列和 BGP InQ。
? BGP InQ。
? 不匹配的 MTU。

1．接口问题
各种接口问题都可能会导致保持计时器超时，而使 BGP 会话翻动，比如物理层问题或接口
上的丢包问题。
2．物理联通性
如果问题与物理联通性有关，数据包无法通过线路正确地传输，或者有时候只会影响一个
特定模式的数据包。在这种情况下，工程师可以尝试在对等体 IP 地址之间发起 ping 测试，并
设置不同的数据包大小和模式。工程师可以把 TOS（服务类别）的值设置为 0 以外的其他值，
或者改变数据模式本身，比如设置值 0xaabb 而不是使用默认的值 0xabcd。如果问题与物理媒介
有关，那么工程师需要使用 show interface 命令来查看 CRC（循环冗余校验）错误和可靠性。
通常来说，根据问题发生的位置，这类错误都可以通过更换线缆、SFP（小型可插拔）模块、
线卡或机框来解决。
3．物理接口
有时接口在接收到一个数据包后，会在驱动器级别把数据包丢弃。最常见的原因是接口无
法处理数据包，因为接收流量的速率过高。工程师可以查看 show interface 命令输出内容中的
overrun 或 ignore 计数器数值。如果遇到了速率过高的情况，工程师需要对速率进行控制。
4．输入保持队列
这是指数据包到达了路由器，但却被接口的输入保持队列丢弃。这些数据包本应该由路由
器的 CPU 进行处理，或由被进程交换（由软件）进行处理。保持队列的大小是有上限的。在大
多数 Cisco 平台上，默认的输入保持队列大小为 75 个数据包，工程师最大可以将其配置为 4096。
推荐工程师把接口的输入队列大小设置为 1500~2000 之间的数值。工程师可以在 show interface
命令的输出内容中查看输入队列的丢包数量。工程师可以使用命令 hold-queue size in 来修改输
入队列的大小。
通常来说，任何运行 BGP 的路由器都有能力处理它接收到的所有 BGP 消息，而不必在输
入保持队列中丢弃 BGP 包。如果发生了丢包，问题通常不在于 BGP 包，而是路由器在接口上
接收到的其他进程交换流量或去往路由器的流量。SPD（Selective Packet Discard，选择性数据
包丢弃）会为高优先级流量提供拥塞优先级，比如 BGP。由于 BGP 包的 IP 优先级值为 6，位
于 SPD 的净空（headroom），就像在输入保持队列之外且优先级更高的额外队列。要想配置 SPD，
工程师可以使用命令 spd enable，然后使用全局配置命令 spd headroom headroom-size 设置 SPD
净空大小。SPD 配置是隐藏配置，但工程师可以从命令 show ip spd 的输出内容中查看这个值。

注释净空大小的设置能够为每个邻居放置至少 2 个数据包就足够了。

例 3-25 中展示了工程师应该在 show interface 命令的输出内容中查看的信息，以及如何配
置接口保持队列和 SPD。

例 3-25 show interface 命令和配置 hold-queue 与 spd 命令

R2# show interface gigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is iGbE, address is fa16.3e86.6c2b (bia fa16.3e86.6c2b)
Internet address is 10.1.12.2/30
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Auto Duplex, Auto Speed, link type is auto, media type is RJ45
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:04, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
355 packets input, 32292 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
876 packets output, 151705 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
1 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
! Configuring Input Hold Queue
R2(config)# interface GigabitEthernet 0/1
R2(config-if)# hold-queue 1500 in
R2# show ip spd
Current mode: disabled.
Queue min/max thresholds: 73/74, Headroom: 100, Extended Headroom: 75
IP normal queue: 0, priority queue: 0.
SPD special drop mode: none
! Configuring and verifying SPD
R2# configure terminal
R2(config)# spd enable
R2(config)# spd headroom 1000
R2(config)# end
R2# show ip spd
Current mode: init.
Queue min/max thresholds: 73/74, Headroom: 1000, Extended Headroom: 75
IP normal queue: 0, priority queue: 0.
SPD special drop mode: none

注释只有 Cisco IOS/IOS XE 平台支持 SPD 特性，IOS XR 或 NX-OS 平台不支持该特性。

5．TCP 接收队列
有时 BGP 存活消息到达了 TCP 接收队列，但没有被进一步处理，而是转移到了 BGP InQ
队列中。当工程师在命令 show bgp afi safi summary 的输出内容中看到某个 BGP 邻居的值为非
零值，说明有 TCP 消息正在队列中等待处理。当 BGP 邻居超时后，BGP InQ 队列是空的。BGP
I/O 进程有可能来不及运行。BGP I/O 进程负责把 TCP 接收队列中的消息放入到 BGP InQ 队列
中。当 BGP 保持计时器的值设置得非常低的时候、BGP 邻居过多的时候，以及 CPU 利用率很
高的时候，都有可能发生这种情况。
造成这种问题另一个可能的原因是在短暂的故障过程中，只丢失了一个 TCP 包。尽管 TCP
接收队列中还有其他数据包但路由器仍然在等待第一个包（TCP 必须要按顺序向路由器提交数
据包，否则就完全不提交）。发送方 BGP 路由器等待传输超时后会再次发送第一个数据包。如
果 BGP 保持计时器的值设置得比较低，就可能无法及时收到重传的数据包。这时唯一的解决办
法就是增加 BGP 的保持计时器值。快速重传（Fast Retransmit）特性也对这种情况有所帮助。
BGP 快速重传特性会在收到三次重复的 ACK 后，重新发送第一个数据包。因此更好的解决方
案是增加 BGP 的保持计时器，同时启用 BGP 快速重传特性。
最后，TCP 包还有可能会因为 CoPP 策略而被丢弃。如果 CoPP 策略中没有足够的带宽被分
配给 TCP 包，尤其是 BGP 包，数据包就会被丢弃。CoPP 策略的问题会在本章后文中进行讨论。
3.2.3 MTU 不匹配的问题
通常在建立 BGP 邻居关系的过程中，MTU（最大传输单元）并不是很大的问题，但 MTU
不匹配会导致 BGP 会话的翻动。由于以下因素，网络中设备上的 MTU 设置会有所不同：
? 不适当的规划或网络设计；
? 设备不支持巨型 MTU 或特定的 MTU 值；
? 未知的传输链路，比如 EoMPLS（可能无法对巨型 MTU 提供端到端的支持）；
? 由于应用需求而改变；
? 由于终端客户需求而改变。
BGP 会基于 TCP 计算出的 MSS（最大分段大小）来发送更新。如果没有启用 PMTUD（路
径 MTU 发现）协议，并且目的地在远端（不在同一个接口/子网上）的话，BGP MSS 值默认是
536 字节，这是 RFC 879 中的定义。因此如果两台交换机之间以 MSS 值 536 字节为基础，交换
大量更新消息的话，路由器会检测到拥塞，这会降低网络效率。原因是接口能够发送 3 倍的
MSS 值，但它必须把这些更新分段为 536 字节一段。如果 TCP 目的地设备在相同的接口上（也
就是非多跳 BGP 的环境中），TCP 会根据出向接口 IP MTU 的设置来计算 MSS 值。
RFC 1191 中定义了 PMTUD 是用来减少 IP 数据包在路径中被分片的几率，以此缓解快速
拥塞的情况。通过使用 PMTUD，源设备能够发现在到目的地的路径中最小的 MTU，然后决定
自己该发送多大的数据包。
PMTUD 是如何工作的？当源设备在生成一个数据包时，它会把 MTU 大小设置为出站接口
MTU 的大小，并设置 DF（不分片）位。如果路径中的设备在接收到这个数据包后，发现自己
出向接口的 MTU 小于这个数据包的大小，它就会丢弃这个数据包并向源设备发送 ICMP 类型 3
（目的地不可达）和代码 4（需要分片且 DF 位置位）的错误消息，并在下一跳 MTU 字段中提
供自己出站接口的 MTU 信息。当源设备接收到这个 ICMP 不可达错误消息后，它会把出站数
据包的 MTU 值修改为下一跳 MTU 字段中指定的值。这个过程会持续进行下去，直到数据包成
功抵达目的地为止。

BGP 也支持 PMTUD。PMTUD 可以使 BGP 路由器发现去往邻居的路径中最合适的 MTU
大小，以确保数据包交换的效率。在启用了 PMTUD 特性后，两个邻居之间最初的 TCP 协商过
程中，MSS 值等于（IP MTU－20 字节 IP 头部－20 字节 TCP 头部），并且设置 DF 位。因此 IP
MTU 值为 1500（等于接口 MTU），MSS 值为 1460。如果路径中有设备设置了较低的 MTU，
或者目的路由器设置了较低的 MTU，比如说 1400，那么最终 MSS 值会协商为 1400－40 字节
＝1360 字节。工程师可以使用以下公式之一来计算 MSS 值。
? 非 MPLS 的 MSS＝MTU－IP 头部（20 字节）－TCP 头部（20 字节）
? MPLS 上的 MSS＝MTU－IP 头部－TCP 头部－n×4 字节（其中 n 是标签栈中标签的
数量）
? 穿越 GRE 隧道的 MSS＝MTU－IP 头部（内部）－TCP 头部－[IP 头部（外部）＋GRE
头部（4 字节）]

注释 MPLS VPN 提供商应该把 MPLS MTU 至少增加为 1508（假设只有两个标签）或
MPLS MTU 1516（假设有 4 个标签）。

例 3-26 中展示了启用和不启用 PMTUD 情况下的 MSS 协商过程。工程师可以使用命令 ip
tcp path-mtu-discovery 来启用 PMTUD，这条命令适用于 IOS 和 NX-OS 设备。在 IOS XR 设备
上，工程师需要使用命令 tcp path-mtu-discovery。

例 3-26 TCP MSS 协商

! Test without PMTUD enabled on Nexus R1 (192.168.1.1)
R2# debug ip tcp transaction
TCP special event debugging is on
R2# clear ip bgp 192.168.1.1
R2#
! Output omitted for brevity
*Sep 27 02:05:48.996: Reserved port 25222 in Transport Port Agent for TCP IP type 1
*Sep 27 02:05:48.996: TCB0F54AA18 getting property TCP_STRICT_ADDR_BIND (19)
*Sep 27 02:05:48.997: TCP: pmtu enabled,mss is now set to 1460
*Sep 27 02:05:48.998: TCP: sending SYN, seq 342586080, ack 0
*Sep 27 02:05:48.998: TCP0: Connection to 192.168.1.1:179, advertising MSS 1460
*Sep 27 02:05:48.999: TCP0: state was CLOSED -> SYNSENT [25222 -> 192.168.1.1(179)]
*Sep 27 02:05:49.002: TCP0: state was SYNSENT -> ESTAB [25222 -> 192.168.1.1(179)]
*Sep 27 02:05:49.002: TCP: tcb F54AA18 connection to 192.168.1.1:179, peer MSS 536,
MSS is 536
! Output omitted for brevity
*Sep 27 02:05:57.952: %BGP-5-ADJCHANGE: neighbor 192.168.1.1 Up
R2# show bgp ipv4 unicast neighbor 192.168.1.1 | include max
Number of NLRIs in the update sent: max 6, min 0
sndwnd: 16616 scale: 0 maxrcvwnd: 16384
minRTT: 8 ms, maxRTT: 1000 ms, ACK hold: 200 ms
Datagrams (max data segment is 536 bytes):
! Enabling PMTUD on Nexus R1 (192.168.1.1)
R1(config)# ip tcp path-mtu-discovery
Path-mtu-discovery enabled
! Test without PMTUD enabled on Nexus R1 (192.168.1.1)
R2# clear bgp ipv4 unicast 192.168.1.1
! Output omitted for brevity
02:11:56.653: TCP: pmtu enabled,mss is now set to 1460
02:11:56.653: TCP: sending SYN, seq 2163041542, ack 0
02:11:56.653: TCP0: Connection to 192.168.1.1:179, advertising MSS 1460
02:11:56.655: TCP0: state was CLOSED -> SYNSENT [50640 -> 192.168.1.1(179)]
02:11:56.659: TCP0: state was SYNSENT -> ESTAB [50640 -> 192.168.1.1(179)]
02:11:56.660: TCP: tcb FB9C638 connection to 192.168.1.1:179, peer MSS 1444,
MSS is 1444
! Output omitted for brevity
*Sep 27 02:11:56.895: %BGP-5-ADJCHANGE: neighbor 192.168.1.1 Up
R2# show bgp ipv4 unicast neighbor 192.168.1.1 | include max
Number of NLRIs in the update sent: max 6, min 0
sndwnd: 17328 scale: 0 maxrcvwnd: 16384
minRTT: 8 ms, maxRTT: 1000 ms, ACK hold: 200 ms
Datagrams (max data segment is 1444 bytes):

在 IOS 和 IOS XR 路由器上，PMTUD 默认是启用的，而在 Nexus 设备上，它默认是禁用的。
根据例 3-26 的配置以及对于 PMTUD 的理解，MTU 的不匹配如何引起 BGP 翻动问题？如
果在从源到目的的路径中，MTU 有一些差异，并且阻塞了 ICMP 消息，PMTUD 就不会起作用，
从而会导致会话翻动。在源和目的路由器上配置好与 BGP 相关的配置后，TCP 协商成功，BGP
邻居关系进入到 Established（已建立）状态。现在 BGP 开始根据协商好的 MSS 值发送更新消
息，并且在这个消息中把 DF 位置位。如果路径中的设备，甚至是目的设备不能接受这个 MTU
较大的数据包，它就会向源 BGP 设备发送一个 ICMP 错误消息。目的路由器会等待 BGP 存活
消息或 BGP 更新包，直到保持计时器超时为止。在 180 秒后，目的路由器会向源设备发送一个
通知，其中携带着保持计时器超时这个错误消息。

注释当 BGP 路由器向一个 BGP 邻居发送更新消息时，它并没有发送 BGP 存活消息，但
这个邻居的存活计时器会被重置。

在图 3-4 中，R2 和 R4 都使用默认的 MTU 设置 1500，而 R1 的 MTU 被配置为 1400，并且
使用 ACL 阻塞了 ICMP 包。在为 BGP 建立 TCP 会话时，双方会发送的初始 MSS 值为 1460。由
于 R1 上出站接口的 MTU 值较低，因此它尝试向两台路由器返回 ICMP 不可达错误消息。但由于
ICMP 消息被阻塞，因此没有设备能够接收到 ICMP 错误消息。从而，两台路由器 R2 和 R4 通过
MSS 值 1460 建立了 TCP 连接。当路由器 R2 与路由器 R4 交换 BGP 表时，会发生以下两件事。

1．如果 BGP 只通告了少量几个前缀，并且 BGI 更新包小于 1360 字节，会话并不会超时。
2．如果 BGP 通告的前缀数量比较大，并且 BGP 更新包的大小超过了 1360 字节，BGP 会
话会在 BGP 保持计时器超时后持续翻动。
例 3-27 中展示了由于 MTU 不匹配导致的 BGP 翻动现象。R2 与 R4 之间建立了 IBGP 邻居
关系，与 R3 之间建立了 EBGP 邻居关系。R3 正在向 R2 通告 10000 条前缀。当 R2 尝试向 R4
发送更新时，BGP 会话开始翻动。

例 3-27 由于 MTU 不匹配导致的 BGP 翻动

NX-OS
! Blocking ICMP packets and setting MTU value of 1400
R1(config)# ip access-list BlockICMP
R1(config-acl)# deny icmp any any
R1(config-acl)# permit ip any any
R1(config-acl)# exit
R1(config)# interface Ethernet 2/1-2
R1(config-if-range)# mtu 1400
R1(config-if-range)# ip access-group BlockICMP in
R1(config-if-range)# ip access-group BlockICMP out
IOS
R2# show bgp ipv4 unicast summary
! Output omitted for brevity
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.1.13.2 4 65535 1006 8 10005 0 0 00:02:21 10001
192.168.1.1 4 65530 5 1006 10005 0 0 00:00:41 1
192.168.4.4 4 65530 4 14 10005 0 992 00:00:15 0
IOS
R4# show bgp ipv4 unicast summary
BGP router identifier 192.168.4.4, local AS number 65530
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.2.2 4 65530 3 5 1 0 0 00:01:16 0
R4# show bgp ipv4 unicast summary
BGP router identifier 192.168.4.4, local AS number 65530
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
192.168.2.2 4 65530 3 7 1 0 0 00:02:59 0
R4#
07:35:26.950: %BGP-3-NOTIFICATION: sent to neighbor 192.168.2.2 4/0
(hold time expired) 0 bytes
*Sep 27 07:35:26.952: %BGP-5-NBR_RESET: Neighbor 192.168.2.2 reset
(BGP Notification sent)
07:35:26.955: %BGP-5-ADJCHANGE: neighbor 192.168.2.2 Down BGP Notification sent
07:35:26.955: %BGP_SESSION-5-ADJCHANGE: neighbor 192.168.2.2 IPv4 Unicast topology
base removed from session BGP Notification sent
07:35:38.229: %BGP-5-ADJCHANGE: neighbor 192.168.2.2 Up

由于 MTU 不匹配导致 BGP 会话翻动还有以下几种可能性：
? 两台对等体路由器接口上的 MTU 不匹配；
? 两台对等体路由器之间的二层路径上没有一致的 MTU 设置；
? PMTUD 没有为 TCP BGP 会话计算出正确的 MSS；
? BGP PMTUD 可能会由于路径中的路由器或防火墙阻塞了 ICMP 消息而失败。
要想知道路径中是否存在 MTU 不匹配的问题，工程师可以通过执行扩展 ping 测试来进行
判断，也就是把数据包大小设置为出站接口的 MTU 值，并且设置 DF 位。同时，还要确保路径
中没有哪台设备阻塞了 ICMP 消息，这样 PMTUD 功能才能正常运行。工程师要仔细检查配置，
确保整个网络中的 MTU 保持一致。
3.2.4 高 CPU 利用率导致的控制平面翻动
一台路由器上的 CPU 会持续不断地执行多项任务。有些任务是低级别的，比如调度任务或
其他与内核相关的任务，有些任务是高级别的。但 CPU 有能力处理路由器上的大多数任务。当
一个进程意外地占去了过多的 CPU 资源，或者当 CPU 必须要处理数据包时，比如数据包的交
换处理，这时就会发生问题。以下原因会导致高 CPU 利用率：
? CPU 进程问题；
? 中断（流量处理）。
由于所有控制平面数据包都是由 CPU 进行处理的，并不是在硬件中进行交换，因此高 CPU
利用率会导致控制平面的数据包被丢弃或延迟。受影响的可能是 BFD（双向故障检测）或 BGP，
或任意其他控制平面的数据包。目的是 CPU 的数据包被称为 for-us 包。
例 3-28 中展示了命令 show process cpu sorted 的输出内容，用来检查路由器上的 CPU 利
用率。本例中99%表示总CPU利用率百分比，7%表示由中断带来的CPU利用率，SNMP ENGINE
进程是消耗了最多 CPU 资源的进程。这个输出信息展示了 1 分钟和 5 分钟的平均 CPU 利用率。

例 3-28 show process cpu sorted 命令的输出内容

Rtr# show process cpu sorted | exclude 0.0
CPU utilization for five seconds: 99%/7%; one minute: 84%; five minutes: 38%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
212 7157624761849980789 386 82.71% 70.16% 25.65% 0 SNMP ENGINE
8 9190575241399458158 656 1.51% 1.47% 1.47% 0 ARP Input
318 76225596 348324353 218 1.11% 0.43% 0.16% 0 OSPF Router 220
! Output omitted for brevity

使用命令 show processes cpu history 来检查 CPU 历史也是一种很好的做法，这样可以查看
最近 72 小时之内的 CPU 利用率图表。这种做法有助于工程师判断问题真正发生的时间，然后
调查在那个时间段中发生的事件，以此进行排错。
如果高 CPU 是由进程导致的，那么工程师一定要了解路由器上进程的角色。举例来说，
例 3-28 中显示出的高 CPU 利用率是因为 SNMP 引擎进程导致的。显然路由器上的 SNMP 进程
正在忙于做着什么事件。命令 show snmp 的输出内容中可以显示出 SNMP 进程正在处理多少数
据包。如果 SNMP 进程正在接收或发送过多数据包，SNMP 进程就会消耗很多 CPU 资源。
如果 CPU 由于中断升高的话，根本原因可能是以下这些：

? 过多需要交换处理的数据包；
? TTL 值为 1 的数据包；
? 过多的控制平面数据包。
交换处理需求过多是因为路由器上没有启用 CEF（Cisco 快速转发），或者 CEF 中没有相关
数据包的转发信息。如果工程师在全局启用了 ip cef，但没有在接口下配置 no ip route-cache cef
（有些特性需要在接口禁用 CEF），会导致从这个接口接收到的流量需要进行交换处理。同样地，
路由器内存不足也会导致路由器或线卡上的 CEF/FIB（转发信息库）变得不可用。因此在排查
过多的交换处理数据包问题时，工程师一定要注意检查路由器上的 CEF 配置和内存资源。
每个 IP 数据包中都有一个 TTL 值。TTL 值能够保证数据包不会进入循环状态，从而在三
层网络中引发问题。但数据包 TTL 值为 1 会对路由器的 CPU 带来影响。常规的控制平面数据
包，比如 OSPF Hello 包或 EBGP 会话的 BGP 存活包，TTL 值都为 1，但也有一些数据包是例
外。对于常规的 IP 数据包来说，如果它不是去往这台路由器的任何接口，而使去往这台路由器
身后的设备，并且它的 TTL 值为 1，这时就会由路由器的 CPU 来对这个数据包进行处理。由于
路由器不是数据包的最终目的地，因此 CPU 会丢弃这些包，并且为此消耗掉一些 CPU 资源。
再举一个组播应用的例子，如果组播应用被设置了错误的 TTL 值，就会导致这些组播数据包被
发送给 CPU 进行处理。
路由处理器上的 CPU 会负责处理控制平面的数据包，但如果这些数据包过多，则会淹没
CPU。举例来说，如果路由器上配置了 500 个 BGP 邻居，并且设置了较短的计时器，那么就会
有大量存活消息需要 CPU 进行处理，或者从不同的源设备向这台路由器配置了上百个 IP SLA
（服务级别协定）探针，导致有过多 ICMP 数据包需要 CPU 进行处理。大多数路由器的 CPU 有
能力处理这么多的数据包。但当外部黑客向路由器发送上千个 BGP 包，或恶意的虚拟主机向路
由器发送大量 ARP 请求包时，问题就出现了。这些情况都会导致流量淹没路由器的 CPU，并
影响路由器上运行的服务。
工程师可以使用以下方法来缓解由过多需要 CPU 进行处理的数据包带来的问题：
? 一经识别，配置一个 ACL 来阻塞这种数据包；
? 配置速率限制；
? 使用 CoPP（控制平面限速）。
工程师可以使用第 2 章介绍的工具，识别出需要 CPU 进行处理的数据包，以及它们的源和
目的地址，之后在接口上使用 ACL 来阻塞这些数据包。
配置速率限制是另一个限制特定流量影响 CPU 的方法。在流量速率到达了工程师配置的门
限值后，根据平台的不同，数据包会被硬件丢弃或软件丢弃。举例来说，6500 和 7600 平台使
用的是基于 MLS（多层交换机）的架构，它们提供了各种 MLS 速率限制器。比如工程师可以
使用命令 mls rate-limit 为 ICMP 重定向或组播流量配置 MLS 速率限制器，以此来对 CPU 提供
保护。
在 NX-OS 平台上有各种与平台相关的速率限制器，工程师可以使用命令 platform
rate-limit [access-log-list | layer-2 port-security | layer-2 storm-control | layer-3 control | layer-3
glean | layer-3 mtu | layer-3 multicast {directly-connected | local-groups | rpf-leak} | layer-3 ttl |
receive] packets 进行配置。工程师可以使用命令 show hardware rate-limit 来查看配置的速率限
制器。XR 平台使用 LPTS（本地数据包传输服务）来处理被限速的数据包。LPTS 不仅用于速
率限制，还用来执行控制平面限速。

3.2.5 控制平面限速
DoS（拒绝服务）攻击的形式多种多样，会同时影响服务器和基础设施。针对基础设施设
备的攻击可以以非常高的数据速率生成 IP 流。这些 IP 数据流中包含有去往 RP（路由处理器）
的控制平面的数据包。这些去往 RP的高速率恶意流量会强制控制平面花费大量时间来处理 DoS
流量。这种场景会导致以下这些问题。
? 线路协议的存活消息丢失，导致线路失效，并引起路由翻动和网络变迁。
? 路由协议的更新消息丢失，导致路由翻动和网络变迁。
? 将近 100%的 CPU 利用率会导致路由器死机，阻止它完成高优先级的处理任务，并带
来其他负面的影响。
? 当 RP 的 CPU 利用率接近 100%利用率时，用户 CLI（命令行界面）的响应速度会变得
非常慢，或者 CLI 死机。这会阻止用户采取正确的措施来应对攻击。
? 资源的消耗会带来负面影响，包括内存、缓存和数据结构。
? 数据包队列备份会导致路由器不加选择地丢弃重要数据包。
? 路由器崩溃。
CoPP（控制平面限速）特性提升了设备的安全性，因为它保护了 CPU（路由处理器）免受
无用和超量流量的影响，或者 DoS（拒绝服务）攻击的影响，并为去往 CPU 的流量分配更高的
优先级。不同类型的流量会被分类到不同的类别中，并且根据 policy-map 进行限速。如果
violate-action 设置为丢弃，那么超出的数据包就会被丢弃。如果设置为标记并转发，那么超出
的数据包会被转发。工程师之后可以使用 control-plane 配置下的命令 service-policy input
policy-name 把 service-policy 关联到控制平面。例 3-29 展示了在 IOS 路由器上配置 CoPP 策略的
案例，本例为 BGP 数据包提供了保护。其他没有被分类为 policy-map 中任意一类的数据包都属
于默认类。

例 3-29 在 IOS 上配置 CoPP

R2(config)# ip access-list extended CPP_BGP
R2(config-ext-nacl)# permit tcp any eq bgp any
R2(config-ext-nacl)# permit tcp any any eq bgp
R2(config-ext-nacl)# exit
R2(config)# class-map Protect_BGP
R2(config-cmap)# match access-group name CPP_BGP
! Define other class-maps for matching other traffic
R2(config)# policy-map CPP_Protection
R2(config-pmap)# class Protect_BGP
R2(config-pmap-c)# police cir 36000 3000 conform-action transmit violate action drop
! Configure Policing for other defined classes
R2(config-pmap-c)# control-plane
R2(config-cp)# service-policy input CPP_Protection
19:27:30.292: %CP-5-FEATURE: Control-plane Policing feature enabled on
Control plane aggregate path

一旦定义好 CoPP 策略，工程师可以使用命令 show policy-map control-plane 来查看匹配各
个类的流量，以及这些类中有没有违规流量。例 3-30 中展示了命令 show policy-map
control-plane 的输出内容。

例 3-30 show policy-map control-plane 命令的输出内容

R2# show policy-map control-plane
Control Plane
Service-policy input: CPP_Protection
Class-map: Protect_BGP (match-all)
215 packets, 15983 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: access-group name CPP_Protocols
police:
cir 36000 bps, bc 3000 bytes, be 3000 bytes
conformed 215 packets, 15983 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
transmit
violated 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
! Output for other defined classes follows
! Output omitted for brevity
Class-map: class-default (match-any)
69 packets, 19610 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any

例 3-30 中展示了在 Cisco IOS 路由器上手动配置 CoPP 的命令。
1．NX-OS 上的 CoPP
在 Nexus 平台上，NX-OS 会安装默认的 copp-system-policy 策略，来保护设备免受 DoS 攻
击和超量数据包处理的影响。NX-OS 的默认 CoPP 策略中提供了各种配置文件，它们分别拥有
不同的保护级别，其中包括下面这些。
? Strice（严格）：在这个策略中，常规类别的 BC 值设置为 250 毫秒，重要类别的 BC 值
设置为 1000 毫秒。
? Moderate（中等）：在这个策略中，常规类别的 BC 值设置为 310 毫秒，重要类别的
BC 值设置为 1250 毫秒。
? Lenient（轻微）：在这个策略中，常规类别的 BC 值设置为 375 毫秒，重要类别的 BC
值设置为 1500 毫秒。
? Dense（密集）：6.0(1)版本中引入了这个策略。
如果在初始设置中工程师没有选择具体的策略，NX-OS 会把 Strict（严格）配置文件关联
到控制平面上。用户也可以不从这些配置文件中进行选择，而是创建一个自定义的策略用于
CoPP。NX-OS 默认的 CoPP 策略会把策略分配到预先定义的几个类别中，如下所示。

? Critical（紧要）：IP 优先级值为 6 的路由协议数据包。
? Important（重要）：冗余协议，比如 GLBP、VRRP、HSRP 等。
? Management（管理）：所有管理流量，比如 Telnet、SSH、FTP、NTP、Radius 等。
? Monitoring（监控）：ping 和 traceroute 流量。
? Exception（例外）：ICMP 不可达消息和 IP 选项。
? Undesirable（无用）：所有无用流量。
由于 ICMP 消息也是会被限速的，因此当工程师从 Nexus 设备执行 ping 测试时，或者向
Nexus 设备执行 ping 测试时，会看到少量的 ICMP 丢包。例 3-31 中展示了系统第一次启动后的
Strict（严格）CoPP 策略示例。

例 3-31 Nexus 上的 CoPP Strict 策略

class-map type control-plane match-any copp-system-p-class-critical
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
match access-group name copp-system-p-acl-lisp
match access-group name copp-system-p-acl-ospf
! Output omitted for brevity
class-map type control-plane match-any copp-system-p-class-exception
match exception ip option
match exception ip icmp unreachable
match exception ipv6 option
match exception ipv6 icmp unreachable
class-map type control-plane match-any copp-system-p-class-important
match access-group name copp-system-p-acl-cts
match access-group name copp-system-p-acl-glbp
match access-group name copp-system-p-acl-hsrp
match access-group name copp-system-p-acl-vrrp
match access-group name copp-system-p-acl-wccp
! Output omitted for brevity
class-map type control-plane match-any copp-system-p-class-management
match access-group name copp-system-p-acl-ftp
match access-group name copp-system-p-acl-ntp
match access-group name copp-system-p-acl-ssh
match access-group name copp-system-p-acl-ntp6
match access-group name copp-system-p-acl-sftp
match access-group name copp-system-p-acl-snmp
match access-group name copp-system-p-acl-ssh6
! Output omitted for brevity
class-map type control-plane match-any copp-system-p-class-monitoring
match access-group name copp-system-p-acl-icmp
match access-group name copp-system-p-acl-icmp6
match access-group name copp-system-p-acl-mpls-oam
match access-group name copp-system-p-acl-traceroute
match access-group name copp-system-p-acl-http-response
! Output omitted for brevity
class-map type control-plane match-any copp-system-p-class-normal
match access-group name copp-system-p-acl-mac-dot1x
match exception ip multicast directly-connected-sources
match exception ipv6 multicast directly-connected-sources
match protocol arp
class-map type control-plane match-any copp-system-p-class-undesirable
match access-group name copp-system-p-acl-undesirable
match exception fcoe-fib-miss
policy-map type control-plane copp-system-p-policy-strict
class copp-system-p-class-critical
set cos 7
police cir 36000 kbps bc 250 ms conform transmit violate drop
class copp-system-p-class-important
set cos 6
police cir 1400 kbps bc 1500 ms conform transmit violate drop
class copp-system-p-class-management
set cos 2
police cir 10000 kbps bc 250 ms conform transmit violate drop
class copp-system-p-class-normal
set cos 1
police cir 680 kbps bc 250 ms conform transmit violate drop
class copp-system-p-class-exception
set cos 1
police cir 360 kbps bc 250 ms conform transmit violate drop
class copp-system-p-class-monitoring
set cos 1
police cir 130 kbps bc 1000 ms conform transmit violate drop
class class-default
set cos 0
police cir 100 kbps bc 250 ms conform transmit violate drop

在最新的版本中，为组播流量和二层流量添加了几个新的类别，且所有配置都是自动生效
的。工程师要记住，CoPP 策略不应该过于严格，应该根据网络设计和配置进行规划。举例来说，
如果符合 CoPP 策略的路由协议数据包的速率超出了限速速率，就连合理的会话都会被丢弃，
路由器就会检测到协议的翻动。如果工程师需要修改预先定义的 CoPP 策略，可以先复制一个
已有的 CoPP 策略分类，然后在它的基础之上编辑新的自定义策略。预定义的 CoPP 策略都无法
编辑。show running-config 命令的输出内容中是看不到 CoPP 策略的。工程师可以使用命令 show
running-config all 或命令 show running-config copp all 来查看 CoPP 策略。例 3-32 中展示了如
何查看 CoPP 策略配置，以及如何创建自定义的严格策略。

例 3-32 查看 CoPP 策略并创建自定义的 CoPP 策略

R1# show running-config copp
copp profile strict
R1# show running-config copp all
class-map type control-plane match-any copp-system-p-class-critical
match access-group name copp-system-p-acl-bgp
match access-group name copp-system-p-acl-rip
match access-group name copp-system-p-acl-vpc
match access-group name copp-system-p-acl-bgp6
! Output omitted for brevity
R1# copp copy profile strict ?
prefix Prefix for the copied policy
suffix Suffix for the copied policy
R1# copp copy profile strict prefix custom
R1# configure terminal
R1(config)# control-plane
R1(config-cp)# service-policy input custom-copp-policy-strict

命令 show policy-map interface control-plane 的输出内容中包含有 CoPP 策略的计数器。要
想查看汇总信息，工程师可以在这条命令后使用 include“class|conform|violated”进行过滤，
来查看有多少数据包符合限制，有多少违反了限制并被丢弃，详见例 3-33。

例 3-33 show policy-map interface control-plane 命令的输出内容

R1# show policy-map interface control-plane | include "class|conform|violated"
class-map custom-copp-class-critical (match-any)
conformed 123126534 bytes; action: transmit
violated 0 bytes; action: drop
conformed 0 bytes; action: transmit
violated 0 bytes; action: drop
conformed 107272597 bytes; action: transmit
violated 0 bytes; action: drop
conformed 0 bytes; action: transmit
violated 0 bytes; action: drop
class-map custom-copp-class-important (match-any)
conformed 0 bytes; action: transmit
violated 0 bytes; action: drop
conformed 0 bytes; action: transmit
violated 0 bytes; action: drop
conformed 0 bytes; action: transmit
violated 0 bytes; action: drop
conformed 0 bytes; action: transmit
violated 0 bytes; action: drop
! Output omitted for brevity

在最佳做法的推荐中，在每次 NX-OS 升级后，都应该使用 copp profile strict 命令，或者
至少在每次重大的 NX-OS 升级后使用。如果以前做过了 CoPP 策略的更改，那它必须被重新应
用一次。
从 NX-OS 5.1 版本开始，工程师可以配置一个门限值，当 CoPP 策略强制某个类别的流量
丢弃数据包时，设备就会生成系统日志消息。当这个流量类别中的丢包量达到了用户配置的门
限值，设备就会生成系统日志消息。工程师可以使用命令 drop threshold dropped-bytes-count
[level logging-level]来配置这个门限值。在例 3-34 中展示的配置中，工程师把日志门限值配置为
100 个丢包，并把日志级别定义为 7。同时本例中还展示了当丢包数量达到门限值时，设备生成
的系统日志消息。

例 3-34 生成系统日志消息的丢弃门限值

R1(config)# policy-map type control-plane custom-copp-policy-strict
R1(config-pmap)# class custom-copp-class-critical
R1(config-pmap-c)# logging drop threshold ?
<1-80000000000> Dropped byte count
R1(config-pmap-c)# logging drop threshold 100 ?
<CR>
level Syslog level
R1(config-pmap-c)# logging drop threshold 100 level ?
<1-7> Specify the logging level between 1-7
R1(config-pmap-c)# logging drop threshold 100 level 7
%COPP-5-COPP_DROPS5: CoPP drops exceed threshold in class:
custom-copp-class-critical,
check show policy-map interface control-plane for more info.

使用 NX-OS CoPP 策略配置的最佳做法建议如下所示。
? 默认使用 Strict（严格）CoPP 模式。
? 当机框中满载了 F2 系列模块或加载了更多的 F2 系列模块或其他 I/O 模块时，建议使
用 Dense（密集）CoPP 配置文件。
? 不建议禁用 CoPP 特性，如果需要的话，工程师可以调整默认 CoPP 策略。
? 工程师要监控意外的丢包行为，并且根据实际流量需求添加或更改模式 CoPP 策略。
? 工程师必须根据网络条件的变化，周期性地评估并调整 CoPP 策略。
2．本地数据包传输服务
与 IOS 和 NX-OS 不同，IOS XR 并不支持 CoPP 特性。它使用一种更好理解且更强大的特
性，称为 LPTS（本地数据包传输服务）。LPTS 是 IOS XR 系统完整的一部分，它提供了防火墙
和限速功能。它还决定了哪些 for-us 数据包需要发送给 CPU，哪些需要被丢弃。LPTS 在线卡
上提供了硬件限速器，用来限制发往 RP 的流量。
LPTS 的概念基础是自反 ACL（Reflexive ACL）和 Punt-Policer。它还使用 IFIB（内部 FIB）
来处理定向到特定节点的数据包。图 3-5 中展示了 IOS XR 上 LPTS 功能的工作原理。

PTS 提供了防火墙功能，它能够只允许去往工程师配置的应用/服务器进程的 for-us 协议
数据包进入路由器。LPTS 还会对进入线卡（LC）的 for-us 数据包进行限速，这样不符合限速
规则的数据包会被入向 LC 丢弃。LPTS 可以按需为特定的协议数据包部署动态流条目。举例来
说，对于本地路由器向对等体路由器发出的 ICMP Echo-Request 消息，LPTS 可以在 Pre-IFIB（压
缩版的 IFIB）中创建流条目，这样从对等体路由器那里接收到的 ICMP Echo-Reply 消息就会与
之相匹配。
如果 LC 接收到的 for-us 数据包是被分片了的，LPTS 只会根据组合后的分片来决定应该向
哪里传输这个数据包。LPTS 能够为被分片的 for-us 数据包提供重组功能。
LPTS 的一个重要功能是动态创建 ACL。这个功能是由配置驱动的，根据工程师配置的特
性或服务来执行，无需用户的干涉。例 3-30 中展示的状态信息来自于线卡 0/1/CPU0。如果工程
师没有指定位置选项的话，设备会显示活跃 RP 的状态信息。
LPTS 中有多个表，分别位于不同的位置，并且由硬件和软件进行维护。工程师一定要对
此有所了解，因为根据转发和 Punt 路径，丢包行为可能发生在任意一个表中。这些表包括下
面这些。
? Pre-IFIB （PIFIB））：由线卡上的出向 PSE（数据包交换引擎）TCAM 硬件进行维护。
? 软件 Pre-IFIB：和 RP 一样由线卡进行维护。软件 PIFIB 负责处理更复杂的检查和操作，
比如分片的重组。
? IFIB“薄片”：这些是经由 RP 分布的。当 PIFIB 不完整时，它是第二查询表。IFIB 表
分布在薄片中，比如 TCP 薄片、UDP 薄片、ISIS 薄片等。
以下步骤展示了 LPTS 中各种表是如何进行绑定的。
步骤 1 启动时，IFIB 表是空的，绑定表、PIFIB 软件和硬件表中有默认条目。
步骤 2 在工程师把设备配置完成后，LPTS IFIB 会被填充，同时绑定表和 PIFIB 表会
更新。
步骤 3 与配置条目（比如 BGP）相关的第一个消息匹配了 PIFIB 硬件表中的 any.any 条
目（未知状态）。
步骤 4 后续消息匹配更详细的条目。
步骤 5 随着对等体连接的建立和断开，增加和删除条目。
LPTS 还根据协议状态维护不同的流类别。比如 BGP 有以下三种状态。
? Unknown（未知）：使用 TCP 端口 179 的数据流，但还没有为这个源配置邻居。它对
应着 BGP-default 流类型。
? Configured（已配置）：使用对等体源地址的数据流，但会话还没有建立。它对应着
BGP-cfg-peer 流类型。在 router bgp 配置模式中配置了邻居命令，就会生成这样的
条目。
? Established（已建立）：使用 L3 和 L4 信息且状态为已建立的数据流。这种数据流会被
轻微地限速，它对应着 BGP-known 流类型。
例 3-35 中展示了命令 show lpts pifib hardware police [location location-id]和命令 show lpts
pifib hardware entry brief [location location-id]的输出内容。工程师使用这两条命令可以查看所
有发生的 BGP 状态。

例 3-35 LPTS 中的 BGP 状态

RP/0/0/CPU0:R3# show lpts pifib hardware police location 0/1/CPU0
-------------------------------------------------------------
Node 0/1/CPU0:
-------------------------------------------------------------
Burst = 100ms for all flow types
-------------------------------------------------------------
FlowType Policer Type Cur. Rate Def. Rate Accepted Dropped TOS Value
------------ ------- ------- ---------- ---------- --------- ------- ----------
BGP-known 106 Static 2500 2500 200 0 01234567
BGP-cfg-peer 107 Static 2000 2000 0 0 01234567
BGP-default 108 Static 1500 1500 5 0 01234567
! Output omitted for brevity
RP/0/0/CPU0:R3# show lpts pifib hardware entry brief location 0/1/CPU0
Node: 0/1/CPU0:
-------------------------------------------------------------
Offset L3 VRF id L4 Intf Dest laddr,Port raddr,Port
------ ---- ------------ ------ ------ --------- ----------------------
! Below entry shows Configured state
22 IPV4 default TCP any LU(30) any,179 10.1.13.1,any
! Below entry show Established State
24 IPV4 default TCP any LU(30) 10.1.13.2,57286 10.1.13.1,179
! Below entry shows Unknown State
142 IPV4 * TCP any LU(30) any,any any,179
! Output omitted for brevity

例 3-36 中展示了命令 show lpts ifib all brief 的用法，工程师使用它来查看不同薄片中的各
个条目。举例来说，邻居 10.1.13.1 的 BGP 条目就位于 BGP4 薄片下。工程师还可以在这条命
令末尾添加关键字 statistics，来查看数据包是被接受了还是被丢弃了，以及 IFIB（内部转发信
息库）中的丢弃计数器。

例 3-36 show lpts ifib all brief [statistics]命令的输出内容

RP/0/0/CPU0:R3# show lpts ifib all brief
Slice VRF-ID L4 Interface Dlvr laddr,Port raddr,Port
-------- -------- ------ --------- ---------- ----------------------------------
RAWIP4 default L2TPV3 any 0/0/CPU0 any any
RAWIP6 default ICMP6 any 0/0/CPU0 any,MLDLQUERY any
RAWIP6 default ICMP6 any 0/0/CPU0 any,LSTNRREPORT any
RAWIP6 default ICMP6 any 0/0/CPU0 any,MLDLSTNRDN any
RAWIP6 default ICMP6 any 0/0/CPU0 any,LSTNRREPORT any
BGP4 default TCP any 0/0/CPU0 10.1.13.2,179 10.1.13.1
BGP4 default TCP any 0/0/CPU0 10.1.13.2,57286 10.1.13.1,179
RP/0/0/CPU0:R3# show lpts ifib all brief statistics
Slice VRF-ID L4 Interface Accept/Drop laddr,Port raddr,Port
------ ------- ------ ---------- ----------- -----------------------------------
RAWIP4 default L2TPV3 any 0/0 any any
RAWIP6 default ICMP6 any 0/0 any,MLDLQUERY anyRAWIP6 default ICMP6 any 0/0 any,LSTNRREPORT any
RAWIP6 default ICMP6 any 0/0 any,MLDLSTNRDN any
RAWIP6 default ICMP6 any 0/0 any,LSTNRREPORT any
BGP4 default TCP any 0/0 10.1.13.2,179 10.1.13.1
BGP4 default TCP any 6/0 10.1.13.2,57286 10.1.13.1,179
Slice Num. Entries Accepts/Drops
-------- ------------ -------------
RAWIP4 1 0/0
RAWIP6 4 0/0
BGP4 2 6/0
Total 7 6/0

工程师可以使用命令 show lpts pifib brief [statistics]来查看 PIFIB（Pre-IFIB）软件表，其
中的统计信息会显示 Accept（接受）和 Drop（丢弃）计数器。通过使用关键字 hardware，工
程师可以查看基于硬件的 PIFIB 计数器，详见例 3-35。例 3-37 展示的软件 PIFIB 表中显示
10.1.13.1 和 10.1.13.2 之间建立的 BGP 会话接受了 100 个数据包，并且它还显示出各种类型数
据包的累计统计信息。

例 3-37 软件 PIFIB 表

RP/0/0/CPU0:R3# show lpts pifib brief statistics
* - Any VRF;
Type VRF-ID L4 Interface Accepts/Drops laddr,Port raddr,Port
---------- -------- ------ ------- ------------- ------------------------------
! Output omitted for brevity
IPv4 default TCP any 100/0 10.1.13.2,57286 10.1.13.1,179
IPv4 default TCP any 0/0 10.1.13.2,179 10.1.13.1
IPv4 * TCP any 6/0 any any,179
IPv4 * TCP any 1/0 any,179 any
! Output omitted for brevity
------------------------
statistics:
Type Num. Entries Accepts/Drops
------ ------------ -------------
ISIS 1 0/0
IPv4_frag 1 0/0
IPv4_echo 1 174/0
IPv4 15 182/0
IPv6_frag 1 0/0
IPv6_echo 1 0/0
IPv6_ND 5 0/0
IPv6 13 0/0
BFD_any 0 0/0
Total 38
Packets into Pre-IFIB: 361
Lookups: 361
Packets delivered locally: 361
Packets delivered remotely: 0

所有这些命令都可以使用关键字location，这样工程师可以查看指定线卡或RP上的计数器。

完整版下载

2022年最新BGP路由协议排错教程指南-网络安全文档类资源-CSDN下载

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

BGP路由器协议排错教程：BGP 基本配置
在配置 BGP 时,最好从模块化的角度考虑配置信息.BGP 路由器上需要配置以下组成部分. ? BGP 会话参数:BGP 会话参数中提供了用来与远端 BGP 邻居建立通信所需的设置. 会话设置中包含 ...
BGP路由器协议排错教程：BGP 对等体失效的问题
当一个已经配置好的 BGP 邻居并没有处于已建立状态的话,网络工程师就把这种情况称为 BGP 对等体失效.以下情况都有可能引发对等体失效的问题. ? 由于配置错误导致 BGP 会话停留在建立过程中. ...
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 对等体翻动问题相关推荐

最新文章

热门文章