| 完整版下载 | 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 Up3.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 any
RAWIP6 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下载 |