icmp协议不可达.docx

icmp协议不可达.docx

《icmp协议不可达.docx》由会员分享，可在线阅读，更多相关《icmp协议不可达.docx（5页珍藏版）》请在冰豆网上搜索。

icmp协议不可达

竭诚为您提供优质文档/双击可除

icmp协议不可达

　　篇一：

tcpip详解-卷一-协议-6.5icmp端口不可达差错

　　6.5icmp端口不可达差错

　　最后两小节我们来讨论icmp查询报文—地址掩码和时间戳查询及应答。

现在来分析一种icmp差错报文，即端口不可达报文，它是icmp目的不可到达报文中的一种，以此来看一看icmp差错报文中所附加的信息。

使用udp（见第11章）来查看它。

　　udp的规则之一是，如果收到一份udp数据报而目的端口与某个正在使用的进程不相符，那么udp返回一个icmp不可达报文。

可以用tFtp来强制生成一个端口不可达报文（tFtp将在第15章描述）。

　　对于tFtp服务器来说，udp的公共端口号是69。

但是大多数的tFtp客户程序允许用connect命令来指定一个不同的端口号。

这里，我们就用它来指定8888端口：

　　指定主机名和端口号

　　试图得到一个文件

　　25秒后大约

　　connect命令首先指定要连接的主机名及其端口号，接着用get命令来取文件。

敲入get命令后，一份udp数据报就发送到主机svr4上的8888端口。

tcpdump命令引起的报文交换结果如图6-8所示。

　　图6-8由tFtp产生的icmp端口不可达差错

　　在udp数据报送到svr4之前，要先发送一份aRp请求来确定它的硬件地址（第1行）。

接着返回aRp应答（第2行），然后才发送udp数据报（第3行）（在tcpdump的输出中保留aRp请求和应答是为了提醒我们，这些报文交换可能在第一个ip数据报从一个主机发送到另一个主机之前是必需的。

在本书以后的章节中，如果这些报文与讨论的题目不相关，那么我们将省略它们）。

　　一个icmp端口不可达差错是立刻返回的（第4行）。

但是，tFtp客户程序看上去似乎忽略了这个icmp报文，而在5秒钟之后又发送了另一份udp数据报（第5行）。

在客户程序放弃之前重发了三次。

　　注意，icmp报文是在主机之间交换的，而不用目的端口号，而每个20字节的udp数据报则是从一个特定端口（2924）发送到另一个特定端口（8888）。

　　跟在每个udp后面的数字20指的是udp数据报中的数据长度。

在这个例子中，20字节包括tFtp的2个字节的操作代码，9个字节以空字符结束的文件名temp.foo，以及9个字节以空字符结束的字符串netascii（tFtp报文的详细格式参见图15-1）。

　　如果用-e选项运行同样的例子，我们可以看到每个返回的icmp端口不可达报文的完整长度。

这里的长度为70字节，各字段分配如图6-9所示。

　　ip数据报

　　icmp报文

　　icmp报文的数据部分

　　以太网首部

　　14字节ip首部20字节icmp首部8字节ip产生差错的数据报首部20字节udp首部8字节

　　图6-9“udp端口不可达”例子中返回的icmp报文

　　icmp的一个规则是，icmp差错报文（参见图6-3的最后一列）必须包括生成该差错报文的数据报ip首部（包含任何选项），还必须至少包括跟在该ip首部后面的前8个字节。

在我们的例子中，跟在ip

　　首部后面的

　　前8个字节包含udp的首部（见图11-2）。

　　一个重要的事实是包含在udp首部中的内容是源端口号和目的端口号。

就是由于目的端口号（8888）才导致产生了icmp端口不可达的差错报文。

接收icmp的系统可以根据源端口号（2924）来把差错报文与某个特定的用户进程相关联（在本例中是tFtp客户程序）。

　　导致差错的数据报中的ip首部要被送回的原因是因为ip首部中包含了协议字段，使得

　　icmp可以知道如何解释后面的8个字节（在本例中是udp首部）。

如果我们来查看tcp首部

　　（图17-2）,可以发现源端口和目的端口被包含在tcp首部的前8个字节中。

　　icmp不可达报文的一般格式如图6-10所示。

　　（3）类型（0~15）代码

　　）0未用（必须为检验和8字节

　　ip首部（ip8包括选项）+原始数据报中数据的前字节

　　图6-10icmp不可达报文

　　在图6-3中，我们注意到有16种不同类型的icmp不可达报文，代码分别从0到15。

icmp端口不可达差错代码是3。

另外，尽管图6-10指出了在icmp报文中的第二个32bit字必须为0，但是当代码为4时（“需要分片但设置了不分片比特”），路径mtu发现机制（2.9节）却允许路由器把外出接口的mtu填在这个32bit字的低16bit中。

我们在11.6节中给出了一个这种差错的例子。

尽管icmp规则允许系统返回多于8个字节的产生差错的ip数据报中的数据，但是大多数从伯克利派生出来的系统只返回8个字节。

solaris2.2的ip_icmp_return_data_bytes选项默认条件下返回前64个字节（e.4节）。

　　tcpdump时间系列

　　在本书的后面章节中，我们还要以时间系列的格式给出tcpdump命令的输出，如图6-11所示。

　　图6-11发送到无效端口的tFtp请求的时间系列

　　时间随着向下而递增，在图左边的时间标记与tcpdump命令的输出是相同的（见图6-8）。

位于图顶部的标记是通信双方的主机名和端口号。

需要指出的是，随着页面向下的y

　　坐标轴与真正的时间值不是成比例的。

　　当出现一个有意义的时间段时，在本例中是每５秒之间的重发，我们就在时间系列的两侧作上标记。

当udp或tcp数据正在被传送时，我们用粗线的行来表示。

　　当icmp报文返回时，为什么tFtp客户程序还要继续重发请求呢？

这是由于网络编程中的一个因素，即bsd系统不把从插口（socket）接收到的icmp报文中的udp数据通知用户进程，除非该进程已经发送了一个connect命令给该插口。

标准的bsdtFtp客户程序并不发送connect命令，因此它永远也不会收到icmp差错报文的通知。

　　这里需要注意的另一点是tFtp客户程序所采用的不太好的超时重传算法。

它只是假定5秒是足够的，因此每隔5秒就重传一次，总共需要25秒钟的时间。

在后面我们将看到tcp有一个较好的超时重发算法。

　　tFtp客户程序所采用的超时重传算法已被RFc所禁用。

不过，在作者所在子网上的三个系统以及solaris2.2仍然在使用它。

aix3.2.2采用一种指数退避方法来设置超时值，分别在0、5、15和35秒时重发报文，这正是所推荐的方法。

我们将在第21章更详细地讨论超时问题。

　　最后需要指出的是，icmp报文是在发送udp数据报3.5ms后返回的，这与第7章我们所看到的ping应答的往返时间差不多。

　　篇二：

tcpip详解-卷一-协议-9.3icmp主机与网络不可达差错

　　9.3icmp主机与网络不可达差错

　　当路由器收到一份ip数据报但又不能转发时，就要发送一份icmp“主机不可达”差错报文（icmp主机不可达报文的格式如图6-10所示）。

可以很容易发现，在我们的网络上把接在路由器sun上的拨号slip链路断开，然后试图通过该slip链路发送分组给任何指定sun为默认路由器的主机。

　　较老版本的bsd产生一个主机不可达或者网络不可达差错，这取决于目的端是否处于一个局域子网上。

　　4.4bsd只产生主机不可达差错。

　　我们在上一节通过在路由器sun上运行netstat命令可以看到，当接通slip链路启动时就要在路由表中增加一项使用slip链路的表项，而当断开slip链路时则删除该表项。

这说明当slip链路断开时，sun的路由表中就没有默认项了。

但是我们不想改变网络上其他主机的路由表，即同时删除它们的默认路由。

相反，对于sun不能转发的分组，我们对它产生的

　　icmp主机不可达差错报文进行计数。

　　在主机svr4上运行ping程序就可以看到这一点，它在拨号slip链路的另一端（拨号链路已被断开）：

　　键入中断键停止显示

　　在主机bsdi上运行tcpdump命令的输出如图9-2所示。

　　图9-2响应ping命令的icmp主机不可达报文

　　当路由器sun发现找不到能到达主机gemini的路由时，它就响应一个主机不可达的回显请求报文。

　　如果把slip链路接到internet上，然后试图ping一个与internet没有连接的ip地址，那么应该会产生差错。

但令人感兴趣的是，我们可以看到在返回差错报文之前，分组要在internet上传送多远：

　　ipinternet上该地址没有连接到

　　从图8-5可以看出，在发现该ip地址是无效的之前，该分组已通过了6个路由器。

只有当它到达nsFnet骨干网的边界时才检测到差错。

这说明，6个路由器之所以能转发分组是因为路由表中有默认项。

只有当分组到达nsFnet骨干网时，路由器才能知道每个连接到internet上的每个网络的信息。

这说明许多路由器只能在局部范围内工作。

　　参考文献[Ford,Rekhter,andbraun1993]定义了顶层选路域（top-levelrouting　　

domain），由它来维护大多数internet网站的路由信息，而不使用默认路由。

他们指出，在internet上存在5个这样的顶层选路域：

nsFnet主干网、商业互联网交换（commercialinternetexchange:

　　cix）、nasa科学互联网（nasascienceinternet:

nsi）、sprintlink以及欧洲ip主干网

　　（ebone）。

　　篇三：

tcpip详解-卷一-协议-11.6icmp不可达差错（需要分片）

　　11.6icmp不可达差错（需要分片）

　　发生icmp不可达差错的另一种情况是，当路由器收到一份需要分片的数据报，而在ip首部又设置了不分片（dF）的标志比特。

如果某个程序需要判断到达目的端的路途中最小mtu是多少—称作路径mtu发现机制（2.9节），那么这个差错就可以被该程序使用。

　　这种情况下的icmp不可达差错报文格式如图11-9所示。

这里的格式与图6-10不同，因为在第2个32bit字中，16~31bit可以提供下一站的mtu，而不再是0。

　　（3）类型

　　（0）未用必须为（4）代码检验和8字节

　　下一站网络的mtu

　　ip首部（包括选项）+原始ip数据报中数据的前8字节

　　图11-9需要分片但又设置不分片标志比特时的icmp不可达差错报文格式

　　如果路由器没有提供这种新的icmp差错报文格式，那么下一站的mtu就设为0。

新版的路由器需求RFc[almquist1993]声明，在发生这种icmp不可达差错时，路由器必须生成这种新格式的报文。

例子

　　关于分片作者曾经遇到过一个问题，icmp差错试图判断从路由器netb到主机sun之间的

　　拨号slip链路的mtu。

我们知道从sun到netb的链路的mtu：

当slip被安装到主机sun时，这是slip配置过程中的一部分，加上在3.9节中已经通过netstat命令观察过。

现在，我们想从另一个方向来判断它的mtu（在第25章，将讨论如何用snmp来判断）。

在点到点的链路中，不要求两个方向的mtu为相同值。

所采用的技术是在主机solaris上运行ping程序到主机bsdi，增加数据分组长度，直到看见进入的分组被分片为止。

如图11-10所示。

　　分片

　　分片icmp回显请求

　　用tcpdump观察分片

　　图11-10用来判断从netb到sun的slip链路mtu的系统

　　在主机sun上运行tcpdump，观察slip链路，看什么时候发生分片。

开始没有观察到分片，一切都很正常直到ping分组的数据长度从500增加到600字节。

可以看到接收到的回显请求（仍然没有分片），但不见回显应答。

　　为了跟踪下去，也在主机bsdi上运行tcpdump，观察它接收和发送的报文。

输出如图

　　11-11所示。

　　图11-11600字节的ip数据报从solaris主机ping到bsdi主机时的tcpdump输出

　　首先，每行中的标记（dF）说明在ip首部中设置了不分片比特。

这意味着solaris2.2一般把不分片比特置1

　　，

　　作为实现路径mtu发现机制的一部分。

　　第1行显示的是回显请求通过路由器netb到达sun主机，没有进行分片，并设置了dF比特，因此我们知道还没有达到netb的slipmtu。

　　接下来，在第2行注意到dF标志被复制到回显应答报文中。

这就带来了问题。

回显应答与回显请求报文长度相同（超过600字节），但是sun外出的slip接口mtu为552。

因此回显应答需要进行分片，但是dF标志比特又被设置了。

这样，sun就产生一个icmp不可达差错报文返回给bsdi（报文在bsdi处被丢弃）。

这就是我们在主机solaris上没有看到任何回显应答的原因。

这些应答永远不能通过sun。

分组的路径如图11-12所示。

　　icmp回显请求

　　icmp回显应答icmp回显请求icmp回显请求

　　icmp不可达：

需要分片，

　　dF但又设置了位

　　图11-12例子中的分组交换

　　最后，在图11-11中的第3行和第6行中，mtu=0表示主机sun没有在icmp不可达报文中返回出口mtu值，如图11-9所示（在25.9节中，将重新回到这个问题，用snmp判断netb上的

　　slip接口mtu值为1500）。