阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 网络 「网络」欢迎转载，保留摘要，谢谢！

• Traceroute 原理和功能
• 命令格式
• 详细的使用举例
• 故障排除案例

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

遇到网络故障的时候，你一般会最先使用哪条命令进行排障？

除了Ping，还有Traceroute、Show、Telnet又或是Clear、Debug等等。

今天安排的，是Traceroute命令详解，还有经典排障案例哈。

Traceroute 原理和功能

traceroute是一个常用的Linux网络诊断命令，用于追踪数据包从源主机到目标主机的路径。它可以帮助确定网络中的延迟和丢包问题。

当发送一个数据包时，TTL的值被设置为1，数据包被送到网络上。当数据包到达安防个路由器时，路由器会删除TTL值并将数据包发送到下一个路由器。这个过程一直重复，直到数据包到达目标主机。如果数据包没有到达目标主机，目标主机将发回ICMPtimeexceeded消息，以此来指示从数据包到达目标过程中经过了多少个路由器。traceroute命令通过不断发送数据包并递增TTL的值，来确定到达目标主机前所经过的路由器数量。

Traceroute 命令用于测试数据报文从发送主机到目的地所经过的网关。 主要用于检查网络连接是否可达，以及分析网络什么地方发生了故障。

命令格式

traceroute 命令使用方式也非常简单，具体的命令格式可以参考如下：

traceroute [参数] [主机]

参数含义

traceroute 命令格式已经了解了，那么其中的参数都支持哪些设置呢？接下来具体看一下。

-d #使用 Socket 层级的排错功能。
-f #设置第一个检测数据包的存活数值 TTL 的大小。
-F #设置勿离断位。
-g #设置来源路由网关，最多可设置 8 个。
-i #使用指定的网络界面送出数据包。
-I #使用 ICMP 回应取代 UDP 资料信息。
-m #设置检测数据包的最大存活数值 TTL 的大小。
-n #直接使用 IP 地址而非主机名称。
-p #设置 UDP 传输协议的通信端口。
-r #忽略普通的 Routing Table，直接将数据包送到远端主机上。
-s #设置本地主机送出数据包的 IP 地址。
-t #设置检测数据包的 TOS 数值。
-v #详细显示指令的执行过程。
-w #设置等待远端主机回报的时间。
-x #开启或关闭数据包的正确性检验。

详细的使用举例

配置等待时间

traceroute 中的默认等待时间为3秒，要修改这个时间，可以使用 -w 选项。比如，我们将等待时间改为 1 秒：

traceroute -w 1 google.com

更改收发包的数量

默认情况下，traceroute 为一个跃点（hop）发送3个包，如果想更改此行为，可使用 -q 选项。

比如，我们我们将其改为4个数据包：

traceroute -q 4 google.com

指定最大跃点数

在traceroute中，单个查询的默认最大跳数为30，可以扩展到255。使用 -m 选项：

traceroute -m 4 google.com

指定 TTL

默认情况下，traceroute 将以第一个 TTL 开始，但您可以使用 -f 选项更改此行为。

如下例子，我们从第5个TTL开始跟踪 google：

traceroute -f 5 google.com

添加备用源IP地址

使用-s 选项添加备用 IP 地址：

traceroute -s 192.168.1.7 google.com

跟踪时禁用主机名映射到IP地址

如果出于某种原因希望在跟踪时禁用主机名映射，可以使用 -n 选项：

traceroute -n google.com

通过网关路由包

可以在要跟踪路由的域时，使用 -g 选项指定网关地址。比如，我们添加 192.168.1.7 作为网关地址：

traceroute -g 192.168.1.7 google.com

更改目标端口

可以使用 -p 来指定要跟踪的目标端口：

traceroute -p 29879 google.com

设置最大数据包长度

默认情况下，traceroute 跟踪的数据包长度为 60 字节（bytes），可以在目标地址后跟一个数字（即包大小）来修改：

traceroute google.com

禁用探测数据包碎片（probe packet fragmentation）

如果你不想允许探测数据包碎片化，有一种简单的方法来实现这个目的，使用 -F 选项：

traceroute -F google.com

故障排除案例

排障案例①:使用Traceroute命令定位不当的网络配置点

1、现象描述：

组网情况如下图所示：

某校园网中，RouterB和RouterC同属于一个运行RIPv2路由协议的网络，主机4.0.0.2访问数据库服务器5.0.0.2，用户抱怨访问性能差。

2、相关信息：

在主机上ping 5.0.0.2显示如下：

C:\Documents and Settings\c>ping -n 10 -l 1000 5.0.0.2  
  
Pinging 5.0.0.2 with 1000 bytes of data:  
Reply from 5.0.0.2: bytes=1000 time=552ms TTL=250  
Reply from 5.0.0.2: bytes=1000 time=5735ms TTL=250  
Reply from 5.0.0.2: bytes=1000 time=551ms TTL=250  
Reply from 5.0.0.2: bytes=1000 time=5734ms TTL=250  
Reply from 5.0.0.2: bytes=1000 time=549ms TTL=250  
Reply from 5.0.0.2: bytes=1000 time=5634ms TTL=250  
Reply from 5.0.0.2: bytes=1000 time=555ms TTL=250  
Reply from 5.0.0.2: bytes=1000 time=5738ms TTL=250  
Reply from 5.0.0.2: bytes=1000 time=455ms TTL=250  
Reply from 5.0.0.2: bytes=1000 time=5811ms TTL=250

3、原因分析

上面的Ping显示出一个规律，奇数报文的返回时长短，而偶数报文返回时长很长（是奇数报文的10倍多）。

可以初步判断奇数报文和偶数报文是通过不同的路径传输的。

现在我们需要使用Traceroute命令来追踪这不同的路径。在RouterC上，Traceroute远端RouterA的以太网接口5.0.0.1。

RouterC(config)#traceroute  

 Target IP address or host: 5.0.0.1  
Maximum number of hops to search for target [30]:10  
Repeat count for each echo[3]:8  
Wait timeout milliseconds for each reply [2000]:  
  
Type esc/CTRL^c/CTRL^z/q to abort.  
traceroute 5.0.0.1 ......  
1    6 ms  4 ms  4 ms  4 ms  4 ms  4 ms  4 ms  4 ms   4.0.0.1  
  。。。。。。（中间省略）  
5  20 ms  16 ms  15 ms  16 ms  16 ms  16 ms  16 ms  16 ms  3.0.0.2  
6  30 ms  278 ms  25 ms  279 ms  25 ms  278 ms  25 ms  277 ms  5.0.0.1  
RouterC(config)#

从上面的显示可看到，直至3.0.0.2，UDP探测报文的返回时长都基本一。

而到5.0.0.1时，则发生明显变化，呈现奇数报文时长短，偶数报文时长长的现象。

于是判断，问题发生在RouterB和RouterA之间。

通过询问该段网络的管理员，得知这两路由器间有一主一备两串行链路，主链路为2.048Mbps（s0口之间），备份链路为128Kbps（s1口之间）。

网络管理员在此两路由器间配置了静态路由。

RouterB上如下配置：

RouterB（config）# ip route 5.0.0.0 255.0.0.0 1.0.0.2  
RouterB（config）# ip route 5.0.0.0 255.0.0.0 2.0.0.2

RouterA上如下配置：

outerA（config）# ip route 0.0.0.0 0.0.0.0 1.0.0.1  
RouterA（config）# ip route 0.0.0.0 0.0.0.0 2.0.0.1

于是问题就清楚了。

例如RouterB，由于管理员配置时没有给出静态路由的优先级，这两条路由项的管理距离就同为缺省值1。

然后就同时出现在路由表中，实现的是负载分担，而不能达到主备的目的。

4、处理过程

可以有两种处理方法。

一个是，继续使用静态路由，进行配置更改 RouterB上进行如下更改：

RouterB（config）# ip route 5.0.0.0 255.0.0.0 1.0.0.2 （主链路仍使用缺省1）

RouterB（config）# ip route 5.0.0.0 255.0.0.0 2.0.0.2 100（备份链路的降低至100）

RouterA上进行如下更改：

RouterA（config）# ip route 0.0.0.0 0.0.0.0 1.0.0.1  

RouterA（config）# ip route 0.0.0.0 0.0.0.0 2.0.0.1 100

这样，只有当主链路发生故障，备份链路的路由项才会出线在路由表中，从而接替主链路完成报文转发，实现主备目的。

第二个是，在两路由器上运行动态路由协议，如OSPF，但不要运行RIP协议（因为RIP协议是仅以hop作为Metric的）。

5、建议和总结

本案例的目的不是为了解释网络配置问题，而是用来展示Ping命令和Traceroute命令的相互配合来找到网络问题的发生点。

尤其在一个大的组网环境中，维护人员可能无法沿着路径逐机排查，此时，能够迅速定位出发生问题的线路或路由器就非常重要了。

排障案例②：使用Traceroute命令发现路由环路

1、现象描述

组网情况如下图所示：

三台路由器均配置静态路由，完成后，登录到RouterA上Ping主机4.0.0.2，发现不通。

2、相关信息

RouterA# ping  4.0.0.2  

Sending 5, 100-byte ICMP Echos to 4.0.0.2,  
timeout is 2000 milliseconds.  
.....  
  
Success rate is 0 percent (0/5)  
RouterA# traceroute 4.0.0.2  
 Type esc/CTRL^c/CTRL^z/q to abort.  
traceroute 4.0.0.2 ......  
1  6 ms  4 ms  4 ms   1.0.0.1（RouterB）  
 2  8 ms  8 ms  8 ms   1.0.0.2（RouterA）  
 3  12 ms  12 ms  12 ms 1.0.0.1（RouterB）  
 4  16 ms  16 ms  16 ms 1.0.0.2（RouterA）  
 。。。。。。

3、原因分析

从上面的Traceroute命令的显示可以立即发现，在RouterA和RouterB间产生了路由环路。

由于是配置的是静态路由，基本可以断定是RouterA或RouterB的静态路由配置错误。检查RouterA的路由表，配置的是缺省静态路由：ip route 0.0.0.0 0.0.0.0 1.0.0.1，没有问题。

检查RouterB的路由表，配置到4.0.0.0网络的静态路由为：ip route 4.0.0.0 255.0.0.0 1.0.0.2――下一跳配置的是1.0.0.2，而不是3.0.0.1。这正是错误所在。

4、处理过程

修改RouterB的配置如下：

RouterB（config）# no ip route 4.0.0.0 255.0.0.0 1.0.0.2  

RouterB（config）# ip route 4.0.0.0 255.0.0.0 3.0.0.1

故障排除。

5、建议和总结

Traceroute命令能够很容易发现路由环路等潜在问题。

当路由器A认为路由器B知道到达目的地的路径，而路由器B也认为路由器A知道目的地时，就是路由环路发生了。

使用Ping命令只能知道接收端出现超时错误，而Traceroute能够立即发现环路所在――如果Traceroute命令两次或者多次显示同样的接口。

当通过Traceroute发现路由环路后，如果配置为：

• 静态路由：几乎可以肯定是手工配置有问题，如本案例所示。
• OSPF协议：可能是地址聚合产生的问题。
• 多路由协议：可能是路由引入产生的问题。