BGP路由器协议排错教程：通用的排错方法

本章涵盖了以下内容：
? 辨别问题；
? 理解变量；
? 复现问题；
? 与平台相关的数据包捕获工具；
? 事件监控/追踪。
找到问题并缩小问题范围并不是一件容易的事。因此，我们说故障排除也是一项技术。当
工程师能够按照逻辑接近问题的根源，并彻底检查每一项内容时，每个问题都可以得到快速解
决。大多数网络问题不像它们看起来的那么复杂，反而是更为简单的网络问题解决起来往往会
很复杂，因为人们往往对这种问题没有一个清楚的定义，或者没有一个正确的理解。下面几点
有助于工程师理清问题，并进一步进行故障排除。
1．描述一下问题是什么样的？
2．是什么导致了这个问题？
3．这个问题可以复现吗？
本章将会详细透彻地讨论这些问题。

2.1 辨别问题
在排错过程中最重要的信息就是确定问题的具体描述，这也是工程师首先需要完成的工作。
模糊或普适的描述会让排错工作向错误的方向发展。
在 Internet 连接无法正常工作时，最常见的问题描述是这样的：“不能上网了”或者“网断
了”。在刚听到这样的问题描述时，你可能一开始会想 Internet 连接怎么会中断？是所有人都无
法连接 Internet，还是只有这一个用户？真正的问题如果是用户无法访问某几个特定的网站，那
么故障很可能与 DNS 服务器有关，或者与公司的 Internet 网关有关。如果 DNS 服务器无法把
网站域名解析为 IP 地址的话，用户确实无法访问网站。
如果用户对问题的描述并不清晰，网络工程师可能会开始检测网络的状态，而不是关注实际导致问题的故障，比如上一段文字中描述的 DNS 服务器故障。在确定了故障后，工程师应该
对故障进行记录。记录文件在所有网络部署中都至关重要，它能够有助于故障诊断、断网分析，
并且能够在将来发生类似问题时，减少网络的中断时间。“没有记录就是没有发生”这种说法是
正确的。
在大多数情况下，工程师的关注点在于解决问题，而不是理解问题。正确的排错工作是在最短
时间内提出可行的解决方案。因此，定义问题、记录问题和理解问题对于减少断网时间非常重要。
2.2 理解变量
有关物理介质的一个有名的网络规则是这样说的：“对于所有行为来说，都有一个相等且相
反的反应”。在计算机网络领域中，可以说：“所有事件（反应）都是某些行为的结果”。这句话
的意思是所有网络事件（预期的或意外的）都是一个或多个触发行为的结果，比如配置变更、
软件或硬件变更。这个规则适用于所有重要或微不足道的断网现象。对于所有网络意外来说，
都会有一个触发行为，触发行为可能是手动触发，也可能是某个网络事件或外部工具的触发。
上述这些都是明显的触发行为。还有一些不明显的触发行为，比如 IPC（内部处理器通信）故
障或 FSM（有限状态机）错误等。这些不明显的触发行为可能也不会出现明显的特征，比如系
统日志消息，这种触发行为可能会被称为缺陷或者 Bug。
举例来说，网络中的一台路由器崩溃宕机了，它的崩溃可能是由硬件或软件故障导致的。
说到硬件故障的话，比如路由器上的 DRAM（动态随机访问内存）可能会出现问题，或者主板
本身可能会出现故障，这些都会导致路由器整个宕机。导致软件故障的原因可能是新配置的变
更或软件缺陷。类似地，路由器的高 CPU 利用率可能会导致远端设备上的链路翻动现象。工程
师在考虑触发行为的同时，还要认真考虑其他变量。这些变量包括流量模式、流量负载、路径
数量等。这些变量与问题的触发行为同样重要。因为可能只有当特定类型的流量穿越路由器时，
才会引发问题，或者可能只有在上班时间，路由器上的流量负载高时才会发生问题。比如一个
TCP 流进入路由器时，这个来自特定 IP 地址且去往指定目的端口号的 TCP 流匹配了一个 ACL
条目，路由器遭遇了崩溃。在这种情况下，匹配了 ACL 条目的流量就是触发行为，但这个拥有
特定 IP 地址和目的端口号的具体 TCP 流是变量。
工程师可以在识别出问题后，使用替代方法来暂时消除问题，但这可不是一劳永逸的维修
做法。如果引发问题的具体触发行为（比如触发问题最主要的事件）还未可知，那么工程师就
无法实施 RCA（Root Cause Analysis，根本原因分析），也无法准备适当的维修方案。比如一个
用户报告说在进行了最后一次配置变更后，他就无法对路由器进行管理访问了。除非已知且确
认了最后一次的配置变更内容，否则即使在重启路由器后问题解决了，用户也仍有可能重复相
同的错误。工程师应该确认配置的变更是否为有效配置。错误的配置可能会阻塞合法流量并导
致网络中断，比如用户配置了错误的 ACL。
如前所述，记录文件在调查网络中断原因的过程中扮演着非常重要的角色。记录引发问题
的触发行为与记录用户对问题的描述同等重要。下次再发生类似的问题时，工程师会很快知道
这是一个已知的问题，还是一个新的问题。
2.3 重现问题
现在我们已经清楚了记录的重要性，其中包括详细的问题描述、与问题相关的变量，以及导致问题发生的触发行为。但如果记录中导致问题发生的事件只是一次性事件，那么基于这个
问题的 RCA 可能并不是经过了验证的，并且可能只是一个基于设想的假说。对于在成功记录问
题及其解决方案的文档中，这个问题应该随时都能够通过相同的触发行为重现。不同的触发行
为会展示出相同或不同的反应。举例来说，两个不同的触发行为可以导致一个相同的问题，或
者同一个触发行为可以展示出两个不同的问题。因此，保持一致性是成功记录且解决问题的关
键。如果工程师观察到的反应不同，那么问题可能也并不相同。
对问题进行模拟也并不是一项轻松的工作。工程师需要花费很多精力来搭建实验环境、实
施配置，并模拟多种触发行为。而且，有时这真的需要一些运气。重现问题的前三次尝试至关
重要，工程师可能尝试一次就重现了问题，也可能需要多尝试几次。
如果问题无法在实验环境中重现，有时值得在生产环境中留出时间窗口来研究这个问题。
在规划时间窗口时，建议把流量引导到备用设备上，以减少终端用户的断网时间；如果问题与
流量相关，或者只在路由器转发流量时才会出现问题，那么也只有让用户经历断网了。
2.3.1 搭建实验环境
与生产环境相比，实验环境中的资源更少。生产环境中的上百台路由器和交换机，以及其
他设备都无法在实验环境中体现出来。根据具体的问题，工程师应该只关注拓扑中的相关部分，
并且根据这部分拓扑来搭建并配置实验环境。
工程师是根据对问题的假设和理解来选择拓扑中的相关部分的。这并不是暗示说最少的步
骤总是能够帮助重现问题。有时工程师需要扩大实验环境的规模，使之接近生产环境。
图 2-1 展示了服务提供商为客户 A 和客户 B 部署的 MPLS VPN（多协议标签交换虚拟专用
网）拓扑。服务提供商在其核心网络中使用了 MPLS 和 MPLS TE（流量工程）。在这个拓扑中，
当 R7 和 R14 之间的链路出现故障，导致 R1 和 R14 之间的 MPLS TE 通道翻动后，客户 A 的两
个站点之间出现了可达性问题。

 尽管图 2-1 所示的拓扑并不大，但也很难在实验环境中设置这么多台路由器来重现这个
问题。那么工程师应该如何搭建实验环境呢？在搭建实验环境之前，最重要的步骤是理解并列出实验拓扑的需求。对于这个案例来说，至少需要两台 PE（运营商边缘）路由器和两台
CE（客户边缘）路由器。由于 TE 是这个问题中的变量，因此工程师也要在实验环境中部署
TE。在实验环境中，工程师会直接在两台 PE 路由器之间配置 TE 隧道，但在图 2-1 所示拓扑
中，R1 与 R14 之间有多条路径；因此工程师至少要设置两条不同的路径。这样一来，核心网
络中还需要添加两台路由器来模拟两条不同的路径。至此工程师就总结出了重现问题所需的
拓扑需求。图 2-2 展示了可以用来重现问题的实验环境。

在确定了实验拓扑后，下一个任务是确定重现问题的硬件和软件需求。工程师有必要使用
与生产环境完全相同的软件版本，因为其他软件版本上可能没有类似的问题，或者问题已经被
修复了。
工程师需要根据多种因素来选择硬件。举例来说，一个问题可能存在于特定的硬件上，但
与之相关的特性和配置却可以无差别地运行在不同的硬件上。在现代网络技术中，很多特性都
是基于软件被编程到硬件中的。这是因为基于硬件的数据包交换速度要快于基于软件的交换。
在硬件级别进行处理的特性称为 PD（Platform Dependent，与平台相关的）特性，在软件级别进
行处理的特性称为 PI（Platform Independent，与平台无关的）特性。举例来说，在 Cisco ASR1000
或 ASR9000，甚至 Nexus 7000/9000 系列平台上，大多数控制平面的功能都是 PI 特性，大多数
数据平面的功能都是 PD 特性。
如果问题与 PI 特性相关，那么工程师实际使用的硬件就无关紧要了。PI 问题可以在虚拟
环境中进行重现，比如使用 GNS3 或 Cisco VIRL（虚拟 Internet 路由实验室）等工具，工程师
只需要使用与生产环境相同的软件版本。

注释 ：工程师可以使用多种模拟器，但 Cisco VIRL 提供了一个规模可扩张且特性可扩
展的网络设计和仿真环境。VIRL 中包含多个 Cisco 网络操作系统虚拟机（IOSv、IOS-XRv、
CSR1000v、NX-OSv、IOSvL2 和 ASAv），并且能够与第三方厂商的虚拟机相集成。Cisco
VIRL 中包含多种独有的功能，比如“现场可视化”功能，它能够从运行的模拟器中实时创
建协议图。 

要想模拟出 PD 问题，工程师需要使用与生产环境完全相同的硬件和软件。这是因为一台
路由器上不同的线卡拥有不同的结构、不同的寄存器设置和 ASIC 芯片，这些都是用来对硬件
进行编程的。因此工程师要根据具体的问题，以及相关特性所涉及的部件，来选择使用物理硬
件还是虚拟环境。

2.3.2 配置实验设备
在使用适当的软硬件把实验环境搭建起来后，下一步是配置实验设备。从使用的特性看来，
工程师应该尽量配置与生产环境中相同的特性。
在图 2-1 所示拓扑中，ISP 使用 OSPF（最短路径优先）作为其 IGP，并且使用了 MPLS LDP
（标签分发协议）、MPLS TE（流量工程）和 BGP v4 地址家族，以及 VRF（虚拟路由转发）；
工程师应该在实验环境中配置所有这些特性，并且要尽量与生产设备上的配置相同。如果可能
的话，使用真实配置是最好的做法。尽管工程师有可能需要基于实验环境来更改接口编号，但
使用真实配置有时能够发现与网络地址相关的问题，尤其有助于检查 BGP 路由策略、访问列表、
ACL 之类的特性。同时这样做也省去了重新规划整个实验环境的时间。
这些只是搭建实验环境所需的最少特性，有时在实验设备上只实施最小配置可不够用。有
可能路由器全局配置中的其他特性，或者接口配置模式中的其他配置是引发问题的触发条件。
以 QoS 策略配置为例，它虽然与 MPLS 功能无关，但却可能会引发问题。因此只要条件允许，
建议工程师总是使用与生产环境相同的配置。
为了重现问题，工程师还可以在实验设备中增加配置。也就是在设备上配置各种特性来耗费
更多的系统资源，这种做法也在问题的重现中扮演了重要角色。还有一点有时也有助于重现问题，
那就是使用流量生成设备或软件来模拟流量，比如 Cisco 的 TREX，工程师可以用它来实现应用
模拟，或者与第三方厂商合作，比如 IXIA 和 Spirent（思博伦），这些厂商的产品都能够用于生成
流量。除此之外，这些设备还有助于扩大模拟环境，因为它们也可以模拟二层和三层协议。
然而，并不是所有人都能够在自己的实验环境中用的起 IXIA 或 Spiren 之类的设备。网上
也有一些其他的工具和应用能够用来生成流量，其中一个应用就是 Iperf。Iperf 最常见的用途是
测量网络的吞吐量，它也能够生成 TCP 和 UDP（用户数据报）流。一些 Cisco 设备上有一款自
带的工具，称为 TTCP（测试 TCP）工具，它也能够在客户端/服务器（传输/接收）模式中模拟
TCP 流。例 2-1 中展示了如何使用 TTCP 来模拟从路由器 R1 发往路由器 R6 的 TCP 流。在这个
案例中，R6 是接收侧，R1 是传输侧

! TTCP on Receive side
R6# ttcp
transmit or receive [receive]:
receive packets asynchronously [n]:
perform tcp half close [n]:
receive buflen [32768]:
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
rcvwndsize [32768]:
ack frequency [0]:
delayed ACK [y]:
show tcp information at end [n]: y
ttcp-r: buflen=32768, align=16384/0, port=5001
rcvwndsize=32768, delayedack=yes tcp
ttcp-r: accept from 12.12.12.1
ttcp-r: 23658496 bytes in 155593 ms (155.593 real seconds) (~148 kB/s) +++
ttcp-r: 7197 I/O calls
ttcp-r: 0 sleeps (0 ms total) (0 ms average)
Connection state is CLOSEWAIT, I/O status: 1, unread input bytes: 1
Connection is ECN Disabled
Mininum incoming TTL 0, Outgoing TTL 255
Local host: 6.6.6.6, Local port: 5001
Foreign host: 12.12.12.1, Foreign port: 58747
Connection tableid (VRF): 0
Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x31E05897):
Timer Starts Wakeups Next
Retrans 1 0 0x0
TimeWait 0 0 0x0
AckHold 7198 27 0x0
SendWnd 0 0 0x0
KeepAlive 8273 0 0x31E142E8
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
iss: 3992454486 snduna: 3992454487 sndnxt: 3992454487 sndwnd: 4128
irs: 1163586071 rcvnxt: 1187244569 rcvwnd: 32696 delrcvwnd: 72
SRTT: 37 ms, RTTO: 1837 ms, RTV: 1800 ms, KRTT: 0 ms
minRTT: 1 ms, maxRTT: 300 ms, ACK hold: 200 ms
Status Flags: passive open, retransmission timeout, gen tcbs
Option Flags: none
Datagrams (max data segment is 536 bytes):
Rcvd: 44795 (out of order: 7177), with data: 44764, total data bytes: 23658496
Sent: 51276 (retransmit: 0 fastretransmit: 0),with data: 0, total data bytes: 0
! TTCP on Transmit side
R1# ttcp
transmit or receive [receive]: transmit
Target IP address: 6.6.6.6
calculate checksum during buffer write [y]:
perform tcp half close [n]:
send buflen [32768]:
send nbuf [2048]:
bufalign [16384]:
bufoffset [0]:
port [5001]:
sinkmode [y]:
buffering on writes [y]:
show tcp information at end [n]: y
ttcp-t: buflen=32768, nbuf=2048, align=16384/0, port=5001 tcp -> 6.6.6.6
ttcp-t: connect
ttcp-t: 23625728 bytes in 155584 ms (155.584 real seconds) (~147 kB/s) +++
ttcp-t: 722 I/O calls
ttcp-t: 0 sleeps (0 ms total) (0 ms average)
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled
Mininum incoming TTL 0, Outgoing TTL 255
Local host: 12.12.12.1, Local port: 58747
Foreign host: 6.6.6.6, Foreign port: 5001
Connection tableid (VRF): 0
Enqueued packets for retransmit: 24, input: 0 mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x31E05892):
Timer Starts Wakeups Next
Retrans 9470 1748 0x31E059BA
TimeWait 0 0 0x0
AckHold 0 0 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0
Linger 0 0 0x0
iss: 1163586071 snduna: 1187232168 sndnxt: 1187244568 sndwnd: 32768
irs: 3992454486 rcvnxt: 3992454487 rcvwnd: 4128 delrcvwnd: 0
SRTT: 300 ms, RTTO: 303 ms, RTV: 3 ms, KRTT: 0 ms
minRTT: 0 ms, maxRTT: 843 ms, ACK hold: 200 ms
Status Flags: retransmission timeout
Option Flags: higher precendence
Datagrams (max data segment is 536 bytes):
Rcvd: 51252 (out of order: 0), with data: 0, total data bytes: 0
Sent: 45270 (retransmit: 1769 fastretransmit: 525),with data: 45268,
total data bytes: 23926320

注释 工程师应该总是首先配置接收节点，这样当传输方向确定后，目的设备就已经做好
准备并且已经在监听指定端口了（在这个案例中，这个指定端口是 5001 — 这也是 TTCP 使用
的默认端口）。

OS XR 设备上也提供了这个特性，但 NX-OS 设备上无法使用。例 2-2 展示了在 IOS XR
平台上使用 ttcp 特性的 CLI 命令。
例 2-2 在 IOS XR 平台上使用 TTCP 工具

RP/0/0/CPU0:XR_R1# ttcp ?
align Align the start of buffers to this modulus (default 16384)
buflen Length of bufs read from or written to network (default 8192)
debug Enable socket debug mode(cisco-support)
format Format for rate: k,K = kilo{bit,byte}; m,M = mega; g,G = giga
fullblocks (Receiver) Only output full blocks as specified by buflen
host Host name or Ip address(cisco-support)
multi Number of connections(cisco-support)
nbufs (Transmitter) Number of source bufs written to network
(default 2048)
nobuffering (Tranmitter) Don't buffer TCP writes (sets TCP_NODELAY socket
option)(cisco-support)
nofilter Don't filter icmp errors(cisco-support)
nonblock Use non-blocking sockets(cisco-support)
offset Start buffers at this offset from the modulus (default 0)
password MD5 Password to be used for tcp connection(cisco-support)
port Port number to send to or listen at (default 5001)
receive Receive mode(cisco-support)
sockbuf Socket buffer size(cisco-support)
source Source/Sink a pattern to/from network(cisco-support)
timeout Stop listening after timeout seconds(cisco-support)
touch (Receiver) "touch": access each byte as it's read
transmit Transmit mode(cisco-support)
udp Use UDP instead of TCP(cisco-support)
verbose Verbose: print more statistics(cisco-support)
vrfid Use this VRF to connect(cisco-support)
RP/0/0/CPU0:XR_R1# ttcp receive
ttcp-r: thread = 1, buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: socket
! Output omitted for brevity
RP/0/0/CPU0:XR_R6# ttcp transmit verbose host 1.1.1.1
ttcp-t: thread = 1, buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp ->
1.1.1.1
ttcp-t: socket
! Output omitted for brevity

 IOS 和 IOS XR 的 CLI 命令存在差异，具体就是在 IOS XR 中并没有使用逐步配置的方式，
而是把各个选项作为命令的一部分。如果工程师没有定义任何选项，设备将会按照默认值来执
行操作。IOS XR 上的 TTCP CLI 命令中提供了更多的选项。举例来说，工程师可以为 TCP 连接
设置 MD5 密码，可以指定 TCP 流的源，等等。在 IOS XR 平台中，工程师也可以使用 TTCP
来发送 UDP 流，但在 Cisco IOS 中无法实现该操作。
前文所讨论的工具都提高了成功重现问题的可能性。

2.3.3 触发事件
在实验环境搭建并配置完成后，有趣的部分才真正开始。根据文档的记录，一一查看在问
题发生前所经历的一系列事件，并在实验环境中尝试各种触发行为。

在图 2-1 中，引发问题的触发行为可能是链路的翻动。在任何网络中，每时每刻都有可能
发生链路翻动。因此，别指望在实验环境中只触发一条链路的翻动行为就可以重现问题。因此
重现问题是需要时间的，并且在设备发生问题之前需要多次引发触发行为。
以模拟内存泄露问题为例，这是在实验环境中重现问题时最复杂的那一类。工程师需要在
实验环境中多次尝试引发触发行为（如果已知触发行为的话）。多次尝试相同的触发行为，或者
结合尝试各种不同的触发行为，都是一项繁琐而枯燥的工作。对于这种情况最好使用自动工具，
这类工具可以持续触发某种事件，或在一段时间内持续触发。工程师可以使用不同的脚本语言
来编写自动工具 — 比如 Perl、Expect、TCL 等。
如果工程师需要根据一个事件把触发行为实体化的话，最好的选择是使用 Cisco EEM
（Embedded Event Manager，内嵌事件管理器）。在 EEM 中，工程师可以自行配置根据一个事件
所触发的特定行为。举例来说，工程师可以编写这样一个 EEM 脚本，即在路由器遭遇了 BGP
会话翻动或高 CPU 利用率时，捕获一系列命令的输出信息并将其保存在 bootflash 中。

注释 第 6 章会进一步介绍 EEM。

2.4 嗅探器 — 数据包捕获
数据包层面的排错很复杂，而且当工程师不知道设备会收到或传输哪种数据包时，排查就更
加困难了。工程师最重要的是要知道数据包是否真的到达了设备，这时可以关注以下三个方面：
? 传输方路由器；
? 接收方路由器；
? 传输媒介。
这就是嗅探（Sniffing）概念的用武之地。嗅探是指拦截在传输介质中进行传输的流量，并
进行协议或数据包分析的技术。嗅探技术不仅仅可以用于网络故障排查这一个目的，而且还可
以帮助网络安全专家分析网络中的安全漏洞。在嗅探过程中，工程师需要把安装了 Wireshark
等数据包捕获工具的 PC，连接到一台网络设备（如交换机）上。大多数情况下，这台交换机能
够对接口收到的数据包进行镜像，并将这些镜像数据包发送给自己连接的 PC。图 2-3 展示了在
交换机上设置嗅探捕获的方式。

 

在 Cisco 设备上，嗅探功能被称为 SPAN（交换机端口分析仪）特性。源端口称为被监控端口，目的端口称为监控端口。不同平台上的 SPAN 功能会有一些区别，接下来的几小节中将介
绍不同平台上的 SPAN 功能。
2.4.1 Cisco IOS 上的 SPAN
包括 Cisco 6500 或 Cisco 7600 系列设备在内的多层交换机/路由器，几乎所有 Cisco Catalyst
交换机都支持 SPAN 特性。在开始配置 SPAN 之前，工程师需要先分清源端口和目的端口。工
程师可以配置一个或多个端口，并监控这些接口接收到的流量，但只能配置一个目的端口。工
程师可以使用命令 monitor session session-number [source | destination] interface interface-id 来
配置 SPAN 特性。
例2-3演示了如何在Cisco 7600系列路由器上设置SPAN会话，同样的配置也适用于Catalyst
交换机。SPAN 会话 1 的源端口是 GE2/5，目的端口是 GE1/1。也就是说，从 GE2/5 端口进入的
所有流量都处于监控下，并且都会被发送到 GE1/1 端口，GE1/1 端口所连接的 PC 上安装了
Wireshark 软件，它会负责捕获端口上接收到的数据包。工程师还可以选择要捕获入站端口哪个
方向上的数据包，在端口名称后面使用可选关键字[both | rx | tx]进行指定。本例中使用的源端
口是一个物理接口。源端口也可以是 VLAN 端口，也就是说所有去往 SVI 端口的流量都可以被
监控并发送给指定的目的端口。

例 2-3 SPAN 的配置

R1# configure terminal
R1(config)# monitor session 1 source interface GigabitEthernet2/5 both
R1(config)# monitor session 1 destination interface GigabitEthernet1/1

 工程师还可以配置根据过滤器执行的流量捕获，比如指定 VLAN 或 ACL（访问控制列表），
这时需要使用命令 monitor session session-id filter [vlan vlan-id | ip access-group acl]进行配置。
当工程师需要捕获具体的流量时，这种做法非常有用。
要想对SPAN 会话进行确认，工程师可以使用命令 show monitor session session-number。例 2-4
展示了配置的 SPAN 会话。要记住，当目的端口被指定用于 SPAN 后，这个端口上就不会在运
行任何协议了，端口会运行在杂合模式中。注意，在命令 show interface GigabitEthernet1/1 的
输出内容中，这个端口显示为处于“monitoring”（监控）状态。

例 2-4 确认 SPAN 会话

R1# show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
Both : Gi2/5
Destination Ports : Gi1/1
MTU : 1464
Egress SPAN Replication State:
Operational mode : Distributed
Configured mode : Distributed

R1# show interface GigabitEthernet1/1
GigabitEthernet1/0/7 is up, line protocol is down (monitoring)
Hardware is Gigabit Ethernet, address is 2c54.2d68.1207 (bia 2c54.2d68.1207)
MTU 1998 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 18/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000BaseTX SFP
! Output omitted for brevity

2.4.2 Cisco IOS XR 上的 SPAN
并不是所有 IOS XR 平台都支持 SPAN 特性。只有 ASR9000 和 CSR 路由器能够支持流量
监控或 SPAN 功能。Cisco CRS（运营商路由系统）平台从 XR 4.3.0 版本开始支持该特性，Cisco
ASR9000（汇聚服务路由器 9000）系列平台从 XR 3.9.1 版本开始支持该特性，并在 4.0.1 版本
中增强了该特性。Cisco 12000 系列（也就是运行 IOS XR 的 GSR [吉比特交换机路由器]路由器）
设备不支持流量监控功能。IOS XR 支持以下两种类型的流量监控方式：
? 三层流量监控；
? 基于 ACL 的流量监控。
在三层流量监控中，目的端口是由 IP 地址指定的，而不是由接口指定的，因为设备需要通
过路由来决定应该把被监控数据包发送到哪个接口。
注释 Cisco CRS（Cisco 运营商路由服务）路由器不支持二层 SPAN。
例 2-5 展示了如何配置三层流量监控功能。在这个案例中，工程师配置了一个名为 test 的
SPAN 会话，目的 IP 地址为 10.1.1.1。在源端口 GE0/1/3/1 上，工程师应用了名为 TEST 的 SPAN
会话，并指定只捕获入方向的数据包；也就是 rx-only。工程师还可以（可选）指定要镜像的字
节数，也可以（可选）指定只捕获 IPv6 或 IPv6 数据包。

例 2-5 配置三层流量监控

RP/0/RP0/CPU0:CRS(config)# monitor-session TEST ipv4
RP/0/RP0/CPU0:CRS(config-mon)# destination next-hop 10.1.1.1
RP/0/RP0/CPU0:CRS(config-mon)# exit
RP/0/RP0/CPU0:CRS(config)# interface gigabitEthernet0/1/3/1
RP/0/RP0/CPU0:CRS(config)# ip address 192.168.10.1 255.255.255.0
RP/0/RP0/CPU0:CRS(config-if)# monitor-session test ipv4 direction rx-only
RP/0/RP0/CPU0:CRS(config-if)# exit
RP/0/RP0/CPU0:CRS(config)# commit

要想检查配置的监控会话，工程师可以使用命令 show monitor-session name status detail。
例 2-6 中通过命令 show monitor-session name status detail errors 展示了监控会话 test 的状态。
Status（状态）应该总是为 Operational（运行）状态，但如果监控会话中发生了错误，命令的输
出内容中也会有所显示。
例 2-6 监控配置的流量监控状态要想检查配置的监控会话，工程师可以使用命令 show monitor-session name status detail。
例 2-6 中通过命令 show monitor-session name status detail errors 展示了监控会话 test 的状态。
Status（状态）应该总是为 Operational（运行）状态，但如果监控会话中发生了错误，命令的输
出内容中也会有所显示。
例 2-6 监控配置的流量监控状态

RP/0/RP0/CPU0:CRS# show monitor-session test status detail
Monitor-session TEST (IPv4)
Destination next-hop IPv4 address 10.1.1.1
Source Interfaces
-----------------
GigabitEthernet0/1/3/0
Direction: Rx-only
ACL match: Enabled
Portion: Full packet
Status: Operational

基于 ACL 的流量监控为 IOS XR SPAN 功能添加了一个有趣的用法。在 ACL 中，工程师可
以使用 permit（允许）和 deny（拒绝）语句来决定常规流量的行为：转发或丢弃；使用关键字
capture 来决定数据包是否会被镜像到目的接口；但最主要的行为还是取决于 ACL 的应用方向。
如果工程师在入方向上应用 ACL，SPAN 就会镜像所有流量，包括被 ACL 丢弃的流量。换句话
说，SPAN 会话会一直对流量进行监控。如果工程师在出方向上应用 ACL，SPAN 会话会监控
由 permit 语句放行进而被转发的流量，而不去监控由 deny 语句拒绝而被丢弃的流量。
例 2-7 中展示了如何配置基于 ACL 的流量监控。在这个案例中，管理员创建了名为 TEST
的 SPAN 会话，目的接口为 GE0/1/0/2。注意，目的接口也可以设置为 IPv4 或 IPv6 地址。接着
工程师创建了名为 SPAN_ACL 的 ACL，其中放行从任意源去往主机 1.1.1.10 地址的流量，并
拒绝其他所有流量。

例 2-7 配置基于 ACL 的流量监控

RP/0/RP0/CPU0:CRS(config)# monitor-session TEST
RP/0/RP0/CPU0:CRS(config-mon)# destination interface GigabitEthernet0/1/0/2
RP/0/RP0/CPU0:CRS(config-mon)# exit
RP/0/RP0/CPU0:CRS(config)# ipv4 access-list SPAN_ACL
RP/0/RP0/CPU0:CRS(config)# permit ipv4 any host 1.1.1.10 capture
RP/0/RP0/CPU0:CRS(config)# deny ipv4 any any
RP/0/RP0/CPU0:CRS(config)# interface gigabitEthernet0/1/3/0
RP/0/RP0/CPU0:CRS(config-if)# ip address 192.168.10.1 255.255.255.0
RP/0/RP0/CPU0:CRS(config-if)# monitor-session TEST
RP/0/RP0/CPU0:CRS(config-if)# acl
RP/0/RP0/CPU0:CRS(config-if)# ipv4 access-group SPAN_ACL ingress
RP/0/RP0/CPU0:CRS(config-if)# exit
RP/0/RP0/CPU0:CRS(config)# commit

注意在第一条 ACL 条目的最后有一个关键字 capture，表示这个流量会被捕获。匹配不包
含关键字 capture 的 ACL 条目的流量不会被发送给嗅探器。SPAN 会话 TEST 会与 acl 子命令
一起被分配到源接口 GE0/1/3/0 下。这条命令指明要根据全局接口 ACL 来镜像流量。随着把
SPAN 会话 TEST 分配到接口，ACL 也被绑定到该接口的入方向上。
ASR9000 也支持流量监控功能，可以用于伪线和基于二层的流量监控。其他 XR 平台不支
持该特性。
2.4.3 Cisco NX-OS 上的 SPAN
Cisco Nexus OS（NX-OS）上的 SPAN 特性与 Cisco IOS 别无二致。根据硬件平台的不同，
NX-OS 和 IOS 平台上每个监控会话所支持的接口数量可能会有所不同。比如每个会话中可以配
置 128 个源接口和 32 个目的接口。所有 VDC（虚拟路由器）都支持两个活跃的会话。

注释 不同的 Nexus 平台可能会支持不同数量的活跃会话，每个会话可能会支持不同数量
的源接口和目的接口。工程师在使用该特性前应该查询具体的平台产品文档，以便确定具体的
数量限制。

例 2-8 展示了在 Cisco NX-OS 上的 SPAN 配置。在例 2-8 中，工程师在目的接口上配置了
命令 switchport monitor，使用命令 monitro session session-number 配置了 SPAN 会话，并在子
命令中配置了源和目的接口。
例 2-8 Cisco NX-OS 上的 SPAN 配置 

N7k-1(config)# interface Ethernet4/3
N7k-1(config-if)# switchport
N7k-1(config-if)# switchport monitor
N7k-1(config-if)# no shut
N7k-1(config)# monitor session 1
N7k-1(config-monitor)# source interface Ethernet4/1
N7k-1(config-monitor)# destination interface Ethernet4/3
N7k-1(config-monitor)# no shut
N7k-1(config-monitor)# exit

注释 源接口也可以是一个接口范围或一个 VLAN 范围。

需要注意的是，在监控会话配置下，工程师配置了 no shutdown 命令。默认情况下，监控
会话处于关闭状态，并且需要工程师使用 no shut 命令手动启用 SPAN 会话的功能。
例 2-9 中展示了监控会话的状态。在这个案例中，rx、tx 和 both 部分都可以看到接口 Eth4/1。
工程师可以手动在配置中指定源接口的方向，在没有指明时默认为双向（both）。管理员还可以
（可选）使用 filter vlan 命令在监控会话下过滤 VLAN。
例 2-9 检查 SPAN 会话

N7k-1# show monitor session 1
session 1
---------------
type : local
state : up
source intf :
rx : Eth4/1
tx : Eth4/1
both : Eth4/1
source VLANs :
rx :
tx :
both :
filter VLANs : filter not specified
destination ports : Eth4/3

 注释 读者可以在思科官方网站上查询文档，获得在 Cisco IOS、IOS XR 和 NX-OS 平台上
使用 SPAN 特性的更多信息。

2.4.4 远程 SPAN
远程 SPAN（RSPAN）是 SPAN 的扩展，区别在于目的端口位于几跳之外的远端交换机上，
目的端口也就是连接用来捕获流量的主机的交换机端口。图 2-4 所示的拓扑展示了跨越多台交
换机的远端 SPAN 环境。交换机 SW1 是源交换机，SW3 是目的交换机。

 

在两台交换机之间用来承载 SPAN 流量的 VLAN 称为 RSPAN VLAN，工程师需要在 VLAN
配置模式下使用remote-span命令进行配置。实际流量是在连接在SW1的多台主机之间传输的，
比如 H1 和 H2。被监控的接口是 GE0/0。在源交换机 SW1 上，工程师把目的接口设置为 RSPAN
VLAN；在目的交换机上，工程师把源接口指定为 RSPAN VLAN。这是因为当数据包到达目的
交换机时，数据包会通过 RSPAN VLAN 进行传输，因此被镜像的数据包是通过这个 VLAN 接
收到的。
工程师要在路径中所有交换机的 Trunk 端口上放行 RSPAN VLAN。如果二层网络启用了修
剪特性，工程师要通过命令 switchport trunk prning vlan remove rspan-vlan-id 把 RSPAN VLAN
排除在外。
例 2-10 展示了源交换机和远端目的交换机上的远程 SPAN 会话配置。在这个案例中，SW1
的端口 GE0/0 上连接着被监控主机，RSPAN VLAN 为 30，主机 H3 连接在 SW3 的端口 GE0/1
上，并跨越 SW2 捕获流量。

例 2-10 RSPAN 的配置 

SW1# configure terminal
SW1(config)# vlan 30
SW1(config-vlan)# name RSPAN_Vlan
SW1(config-vlan)# remote-span
SW1(config-vlan)# exit
SW1(config)# monitor session 1 source interface GigabitEthernet0/0 rx
SW1(config)# monitor session 1 destination remote vlan 30
SW1(config)# end
SW3# configure terminal
SW3(config)# vlan 30
SW3(config-vlan)# name RSPAN_Vlan
SW3(config-vlan)# remote-span
SW3(config-vlan)# exit
SW3(config)# monitor session 1 destination interface GigabitEthernet0/1
SW3(config)# monitor session 1 source remote vlan 30
SW3(config)# end

只有当两台交换机之间的 Trunk 链路上没有放行 RSPAN VLAN 时，RSPAN 才会出现问题。
在这种情况中，不仅 RSPAN 无法正常工作，对交换机也会造成影响，因为交换机的 CPU 会不
停丢弃被监控的流量。