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 展示了可以用来重现问题的实验环境。