Ping和Trace指令的执行过程分析

ICMP协议

• 在这里，主要是使用两个指令来分析ICMP协议。

  • 先明白ICMP报文是在什么地方，什么环境下产生的？

  • 在明白ICMP报文的各个字段的具体含义和内容。

  • 最后，抓包实验惊醒测试，分析。

实验拓扑如下所示：

1、基本的路由配置如下：

下面来记录对应的实验流程，依次按照R1、R2、R3的配置顺序来对各个路由器进行配置。

R1#configure terminal 
R1(config)#line console 0
R1(config-line)#no privilege level 15
R1(config-line)#end

先对每台路由器使用如上的指令，关闭相对应的保护模式，下面开始分别的配置IP地址和静态路由：

R1上的配置如下所示：

R1>enable 
R1#configure terminal 
R1(config)#interface f0/0
R1(config-if)#no shutdown 
R1(config-if)#ip address 
R1(config-if)#ip address 10.1.1.2 255.255.255.0
R1(config-if)#exit
R1(config)#ip route 10.1.2.0 255.255.255.0 f0/0
R1(config)#end

R2上的配置如下所示：

R2(config)#line console 0
R2(config-line)#no privilege level
R2(config-line)#no privilege level 15
R2(config-line)#exit
R2(config)#interface f0/0
R2(config-if)#no shutdown 
R2(config-if)#ip address 1
*Mar  1 00:08:18.579: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:08:19.579: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R2(config-if)#ip address 10.1.1.1 255.255.255.0
R2(config-if)#exit
R2(config)#interface f0/1
R2(config-if)#no shutdown 
R2(config-if)#ip address 
*Mar  1 00:08:43.667: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
*Mar  1 00:08:44.667: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
R2(config-if)#ip address 10.1.2.2 255.255.255.0
R2(config-if)#exit
R2(config)#ip route 10.1.1.0 255.255.255.0 f0/0
R2(config)#ip route 10.1.2.0 255.255.255.0 f0/1
R2(config)#exit
R2#show ip 
*Mar  1 00:15:25.059: %SYS-5-CONFIG_I: Configured from console by console
R2#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.2.0 is directly connected, FastEthernet0/1
C       10.1.1.0 is directly connected, FastEthernet0/0
R2#

R3对应的配置如下所示：

R3#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#line console 0
R3(config-line)#no privile
R3(config-line)#no privilege level
R3(config-line)#no privilege level 15
R3(config-line)#end
R3#exit
R3>enable
R3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#interface f0/0
R3(config-if)#no shutdown 
R3(config-if)#ip address 
*Mar  1 00:11:56.387: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar  1 00:11:57.387: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up
R3(config-if)#ip address 10.1.2.1 255.255.255.0
R3(config-if)#exit
R3(config)#ip route 10.1.1.0 255.255.255.0 f0/0
R3(config)#exit
R3#sho
*Mar  1 00:12:35.595: %SYS-5-CONFIG_I: Configured from console by console

R3#show ip route      
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.2.0 is directly connected, FastEthernet0/0
S       10.1.1.0 is directly connected, FastEthernet0/0

如上所示对应的配置配置完毕。

2、下面来测试Ping指令的完整过程

2.1、相邻两台机器之间的对应的流程

现在，我们来查看我们R1路由器的arp缓存表（确保此时的缓存表中的值为空）：

除了自身的IP地址外，不存在其他的ARP条目信息。

R1#show arp 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.1.2                -   cc01.1f44.0000  ARPA   FastEthernet0/0

下面，我们在R1和R2之家进行抓包实验：

进行等待抓包：

我们在R1中输入如下的指令：

R1#ping 10.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 84/87/92 ms

对应的抓包结果为：

我们发现，我们一共是有8个ICMP包，其中有四个request包，有四个reply包，这样这报个包正好的构成了ICMP中的请求和回应的这两个过程。

但是我们看我们的指令可知，我们明明是ping了五个包？为啥抓到的只有4对？难道是被wireshark私吞了？

其实，不是。我们在一开发送request包的时候。我们发现，出现了一个arp的访问过程我们来详细查看这对arp的数据包：

我们发现，在一开始的时候出现了一个arp请求的过程，查阅资料后发现（查阅的博客链接）原来当ICMP协议从三层分装完后，发现对应的arp缓存表中不存在刚刚的对应的表项，那么路由器将会暂停ICMP的协议流程，先发送一个arp请求，补充完自身的路由信息后，在去完成相对应的ICMP的转发过程。

我们再次查看R1中的arp缓存表中的信息，内容如下：

R1#show arp     
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.1.2                -   cc01.1f44.0000  ARPA   FastEthernet0/0
Internet  10.1.1.1                9   cc02.5e6c.0000  ARPA   FastEthernet0/0

下面，我们来分析一下Ping指令中的ICMP的协议信息：

对应的request头信息和reply头信息如下所示：

request头信息：

reply头信息：

我们发现，他的头文件的内容分别是

文件头类型：	Type字段	code字段
request类型	8	0
reply类型	0	0

所以，我们现在可以大致的逆向出这个网卡在解析数据包的过程中的逻辑：

这里只是解析逻辑：
$$\begin{gathered} 解析ip数据包头部信息，发现Protocol=1,IP头部字段之后的数据存在一个ICMP的数据头 \\ 接着,我们解析下面的数据段的第一个字节的内容（这里面的内容便是type字段） \\ 当我们发现该字段的值为8，且下一个字段（code字段）的值为0时, \\ 该数据包的功能便是一个发送请求的功能，如果请求没有遇到问题，能够被对方接受， \\ 那么，我们接收方再对照着ICMP的协议规范发送表示相应的type的code值来表述此时的状态。 \\ 这样的过程，我们将其称之为回应。 \end{gathered}$$
所以，下面来这里一下Ping指令执行的过程：

2.2、非相邻的机器之间的流程

下面，再来分析，当ping指令从R1 --> R3时的过程：

对应的拓扑图如下所示：

我们对两个链路同时抓取，此时arp缓存表中除了自身的网卡对应的IP地址外，没有其他的信息：

两块网卡对应的信息如下所示：

10.1.1.0/24网段的网卡信息：

10.1.2.0/24网段网卡的信息：

下面，我们将展示一下每个路由器其自生的每块网卡的接口信息：

# R1 对应的接口信息
R1#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.1.2                -   cc01.1f44.0000  ARPA   FastEthernet0/0
Internet  10.1.1.1                4   cc02.5e6c.0000  ARPA   FastEthernet0/0

# R2 对应的接口信息:
R2#show arp 
Internet  10.1.2.1                8   cc03.7968.0000  ARPA   FastEthernet0/1
Internet  10.1.1.2                8   cc01.1f44.0000  ARPA   FastEthernet0/0
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.2.2                -   cc02.5e6c.0001  ARPA   FastEthernet0/1
Internet  10.1.1.1                -   cc02.5e6c.0000  ARPA   FastEthernet0/0

# R3 对应的接口信息：
R3#show arp
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.2.1                -   cc03.7968.0000  ARPA   FastEthernet0/0
Internet  10.1.2.2               10   cc02.5e6c.0001  ARPA   FastEthernet0/0

我们可以发现R1在ping路由器R3的时候，第一个ping包，被arp进程阻止，所以，我们在第一条线路上进行抓包时，发现了对应的一个arp解析过程，而他的第二个ping包则如愿的进入路由器R2中，但是，我们发现，当第二个ping包传入R2中的时候，但是并没有一个回应包；这是因为这个时候R2将此包进行了转发。何以见得？因为在第二个线路抓包的之后arp包 + ICMP包一共只有四个；没错，从R1传输到R2的第二个数据包，被转发到R3。由于R2的arp表中没有R3路由器对应的接口信息，于是，在R2传给R3的过程中又进行了一次arp解析。（这便是完整的Ping指令的流程了）；

2.3、实验二的注意事项

注意：

在做非相邻的路由器之间的传输实验室，配置静态路由使用的时ip route 网络号 子网掩码 下一跳地址的形式。因为这样，就会简化一个代理arp解析的过程。

3、traceroute指令的抓包实验

之前在一个博客中看到这样的一段话来描述traceroute协议：

trace就是相当于故意派人去西天如来那去请一本《道德经》,结果人家是信佛不信道的，消息就会被打出来；被打的消息传回来，你就知道西天是能够到达的。为什么不去去《心经》呢?因为UDP协议是无连接的;就是说这个人一派过去，你就得不到任何音信了。你无法判断他到底是半路走丢了还是真的遁入空门了；只有让人家打出来你才会得到消息;就像让徐福去海上寻仙岛，结果去了就不回来了，导致我们的秦始皇不知道他是否真的寻到了;

之前在实习的时候，曾今大概的做过相应的实验，下面我们模仿上述的过程，再来进行相应的traceroute的实验。

3.1、arp缓存表中存在相应的ip条目时的工作流程（trace指令主要的工作状态）：

实验流程：

在上述的实验中，用R1来traceroute路由器R3的内容，观察相应的数据包：

下面来查看对应的抓包过程：

第一条线路上的抓包结果：

第二条线路上的抓包结果为：

我们发现，每一次，我们都是发送udp包来进行第一次的试探，此时，IP协议中的TLL被设置为1，此时，ICMP的报错信息显示：Time to Live Exceeded in transmit这里很明显的TTL超时了;

然后，三个包之后，traceroute将对应的IP数据头中的TTL加一。直到最终的返回信息为port unreachable为止，至于为什么是到port unreacable为止呢？那是因为如果端口号可达的话，那就直接被路由器接受了，就不会出现一个返回的报错信息了，那traceroute也就失去了意义。

为什么每次相同的TTL值都是发三个包？

这个只是一种默认情况，我们可以在使用指令是对这个参数来进行修改。

对应的内容显示如下：

R1#traceroute 
Protocol [ip]: 
Target IP address: 10.1.2.1
Source address: 10.1.1.2
Numeric display [n]: 
Timeout in seconds [3]: 
Probe count [3]: 4
Minimum Time to Live [1]: 
Maximum Time to Live [30]: 
Port Number [33434]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Type escape sequence to abort.
Tracing the route to 10.1.2.1

  1 10.1.1.1 60 msec 60 msec 88 msec 68 msec
  2 10.1.2.1 108 msec 92 msec 88 msec 92 msec

这时，我们通过在第7行的数值的改变来改变每次发送的UDP数据的数量，对应的抓包如下所示（在R2到R3那条线路：）

我们通过抓包的情况可以发现，确实是抓到了四个包。（并且我们根据UDP上的数据可以看出 ，目的端口号的值一直在变，其实他可以是一个随机值。）

3.2、当arp缓存表中不存在相应的表项时，traceroute是否会被中断该行为，先进行arp寻址操作？

将缓存表中的内容清空，开始，验证，是否会存在这样的一个过程。

关闭模拟器后，重新配置相关的实验环境（由于不会清楚arp缓存表，只能这样处理clear arp-cache没有效果）

在R1中使用如下指令：

R1#traceroute 10.1.2.1 probe 4

我们来观察对应的抓包情况。
第一条线路：

我们发现，在进行UDP传输之前，会存在一个ARP的解析过程。

相对应的在第四个UDP包传送的时候，没有相应的ICMP包来进行返回，这是因为转发这个包，在第二条线路上也进行了arp解析过程，所以，我们在看第二条线路的抓包结果如下所示：

总结，traceroute的过程和ping极为相似。

4、总结ICMP协议：

实验是在如下是环境中完成的：

4.1、ICMP协议的功能：

ICMP是 Internet Control Message Protocol 的缩写，即互联网控制消息协议。它是互联网协议族的核心协议之一。它用于 TCP/IP 网络中发送控制消息，提供可能发生在通信环境中的各种问题反馈，通过这些信息，使网络管理者可以对所发生的问题作出诊断，然后采取适当的措施解决问题。

虽然ICMP 是网络层协议，但是它不像IP协议和ARP 协议一样直接传递给数据链路层，而是先封装成 IP 数据包然后再传递给数据链路层

所以，他是需要依赖于IP协议的数据头才能完成数据的转发，他只是在IP转发的过程中提供问题反馈的功能；

4.2、ICMP协议格式：

ICMP的协议格式如下：

32位
8	8	16
类型	代码	校验和
可变字段取决于ICMP的类型

4.3、两个指令的设计思想：

首先，在计算机网络中，协议就是用来约束数据的一种手段，通过约定俗称的协议内容来设计指令，在相对应的解析和封装的流程中实现数据的传输与通信。ICMP的主要功能便是进行差错检测，并将对应的报错信息发送给源IP地址，这个的设计就像是在编程的框架中的error报错信息一样，方便程序员知道具体是在哪出现了相应的报错信息。所以，这个我觉得才是报错信息，即ICMP协议功能的必要性和他的强大的地方：

下面的内容便是他们的设计大致的思路：：

4.3.1、ping指令：

完全的利用了ICMP协议的协议准则，使用对应该准则中提供的能够实现 “ 请求 ” 和 “ 回复 ”的这两个过程来完成数据间的传输，由于其并没有实际有效的数据传输，所以，常被用来测试网络的连通信。

编程细则，利用两个字节的字段来达成相应的数据封装和前面的IP层的封装，最终传入网络中，所以，只需要掌握相关的网络编程的驱动知识，完成ping指令的编程其实不是难事，更何况，面向对象语言的盛行，我们可以很轻松的做到这一点。

4.3.2、traceroute指令：

traceroute，动力的源泉在于UDP一直在搞事情，通过控制TTL和相对应的UDP数据包中的端口号，便可以很轻松的模拟出这样的一个指令。不过，对于这个指令最好还是以脚本的形式，这样也可以一定程度上的灵活性和便捷性。也会大大地提高开发的效率。