Linux环境下,traceroute返回一系列*原因分析

Traceroute transmits packets with small TTL (Time To Live) values. The TTL is an IP header field that is used to prevent packets from running into endless loops. When a router that handles the packet subtracts one from the packet‘s TTL. The packet expires and it‘s discarded when the TTL reaches zero.

Traceroute sends ICMP Time Exceeded messages, (RFC 792 ), back to the sender when this occurs. By using small TTL values, the packets will quickly expire, so traceroute causes all routers along a packet‘s path to generate the ICMP messages that identify the router.

For example, TTL = 1 should produce the message from the first router, TTL = 2 generates a message from the second router in the path , and so on...

问题和解决办法

If you’re using a *nix or BSD-based operating system and trying to use traceroute at home behind a NAT router, you probably have problems with intermediate routers timing out, i.e.:

3  * * *
4  * * *
5  * * *
6  * * *

Furthermore, you may have also noticed that Windows’ tracert program doesn’t have this problem. The Unixtraceroute program uses a bunch of UDP packets on a bunch of client ports to do its magic , whereas tracert uses ICMP packets, which I guess would have to be port forwarded on your router normally . Regardless, the solution is to use:

traceroute -I targethost.com

This forces traceroute to use ICMP packets the way the Windows program does. Amazing! I’m sure there’s a downside to this approach, but so far it works like a charm.

traceroute 有

 

使用两种:使用ICMP的和使用UDP的。

Microsoft使用ICMP,所以win95上发出的traceRT应使用的是ICMP,但我没有用 sniffer查过;其它包括unix和cisco router都使用UDP.

 ICMP traceroute :
      ===========
      使用ICMP Echo Request , Echo Reply and TTL-expired .

源发出 ICMP
      Equest,第一个request的TTL为1,第二个request的TTL为2,以后依此递增直至第30个;中间的router送回ICMP TTL-expired ( ICMP type 11)通知source,(packet同时因TTL超时而被drop),由此source知晓一路上经过的每一个router;最后的 destination送回ICMP Echo Reply 。

所以中间任何一个router上如果封了ICMP Echo Request , traceroute就不能工作 ;如果封了type 11 (TTL-expired), 中间的router全看不到 ,但能看到packet 到达了最后的destination;如果封了ICMP Echo Reply,中间的全能看到,最后的destination看不到 。

UDP traceroute: 
      ==========
      使用ICMP TTL-expired (type 11), ICMP port unreachable (type 3, code 3), UDP
      port >32768 .

source发出UDP packet, source port使用随机的任何大于32768的高段port, destination port从33434开始每送个probe依此递增,直至33434+29,(cisco router上使用extended-traceroute命令可以修改这个起始的33434 port #),
      同时TTL从1开始依此递增,直至1+29=30(最多送30个probe)。中间的router送回 ICMP TTL-expired,使得source得知了中间的每一个router,最后的destination送回TTL-expired 和ICMP port unreachable (因为任何主机上都没有应用使用UDP port# >32768这样的高段port )。

所以中间某处封掉UDP port>32768回导致traceroute不工作 ;封掉TTL超时会使source看不到中间的router(有的router根本不支持回送TTL超时);封掉type3 code3可能看不到destination .

另外需要知道的是,由于回送TTL-expired的信息需要CPU生成一个packet,必须打断 CPU,为保证其它工作的正常进行,cisco router每隔一秒才处理traceroute ,所以在source 上你可能看到中间一路 * * *,但却看得到最后的destination. 这时你应知道这是中间的router CPU太忙或者中间路由器不回送TTL-expired包的原因 ,不必大惊小怪的。:-)

下面是我自己的问题终于得到了解答:

在虚拟机的red hat上使用nat方式上网:

到百度2跳就到了。

然而使用windows公网来:

要9跳才完成。。。

分析如下:

windows中的tracert和linux中的traceroute -I,都是使用icmp协议,但是linux是在虚拟机的nat路由器后面,个人估计在收到linux上的ip包时候,nat路由器在替换ip头的时候没有考虑tracert这个功能,直接换了,然后直接传递到目的地址,目的地址有一个icmp echo Reply.从而我2跳就到了。。。

如果在linux上使用traceroute,默认使用udp协议,除了第一跳,剩下的都是* * *。八成是因为虚拟机nat 路由器,默认丢弃port>32767的包。 所以一切都解释了。圆满了。

来自:http://blog.csdn.net/lhq9220/article/details/6436984

时间: 2024-10-03 23:46:02

Linux环境下,traceroute返回一系列*原因分析的相关文章

Linux环境下安装部署AWStats日志分析系统实例

AWStats是使用Perl语言开发的一款开放性日志分析系统,可分析Apache网站服务器的访问日志,还可以用来分析Samba.Vsftpd.IIS等日志信息.       此文章主要讲解如何在linux系统下安装部署关于对Apache网站服务站日志分析的AWStats. 实验步骤一,安装部署AWStats分析软件. 一,安装AWStats软件包. 直接将其解压到/usr/local/awstats目录下即可完成安装. 使用命令:mkdir -p /usr/local/awstats tar z

深度分析LINUX环境下如何配置multi-path

首先介绍一下什么是多路径(multi-path)?先说说多路径功能产生的背景,在多路径功能出现之前,主机上的硬盘是直接挂接到一个总线(PCI)上,路径是一对一的关系,也就是一条路径指向一个硬盘或是存储设备,这样的一对一关系对于操作系统而言,处理相对简单,但是缺少了可靠性.当出现了光纤通道网络(Fibre Channle)也就是通常所说的SAN网络时,或者由iSCSI组成的IPSAN环境时,由于主机和存储之间通过光纤通道交换机或者多块网卡及IP来连接时,构成了多对多关系的IO通道,也就是说一台主机

【转载】linux环境下tcpdump源代码分析

linux环境下tcpdump源代码分析 原文时间 2013-10-11 13:13:02   原文链接   主题 Tcpdump 作者:韩大卫 @ 吉林师范大学 tcpdump.c 是tcpdump 工具的main.c, 本文旨对tcpdump的框架有简单了解,只展示linux平台使用的一部分核心代码. Tcpdump 的使用目的就是打印出指定条件的报文,即使有再多的正则表达式作为过滤条件.所以只要懂得tcpdump -nXXi eth0 的实现原理即可. 进入main之前,先看一些头文件 n

Linux环境下段错误的产生原因及调试方法小结(转)

最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且 项目工程庞大复杂,出现了不少问题,其中遇到最多.花费时间最长的问题就是著名的“段错误”(Segmentation Fault).借此机会系统学习了一下,这里对Linux环境下的段错误做个小结,方便以后同类问题的排查与解决. 1. 段错误是什么 一句话来说,段错误是指访问的内存超出了系统给这个程序所设定的内存空间,例如访问了不存在的内存地址.访问了系统保护的内存地址.访问了只读的内存地址等等情况.这里贴一个对于“段

Linux环境下段错误的产生原因及调试方法小结

最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多.花费时间最长的问题就是著名的“段错误”(Segmentation Fault).借此机会系统学习了一下,这里对Linux环境下的段错误做个小结,方便以后同类问题的排查与解决. 1. 段错误是什么 一句话来说,段错误是指访问的内存超出了系统给这个程序所设定的内存空间,例如访问了不存在的内存地址.访问了系统保护的内存地址.访问了只读的内存地址等等情况.这里贴一个对于“段错

【转】【调试技巧】Linux环境下段错误的产生原因及调试方法小结

本文转自:http://www.cnblogs.com/panfeng412/archive/2011/11/06/segmentation-fault-in-linux.html 最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多.花费时间最长的问题就是著名的“段错误”(Segmentation Fault).借此机会系统学习了一下,这里对Linux环境下的段错误做个小结,方便以后同类问题的排查与解决. 1. 段错误

Linux环境下段错误的产生原因及调试方法小结(转载)

转载自http://www.cnblogs.com/panfeng412/archive/2011/11/06/2237857.html 最近在Linux环境下做C语言项目,由于是在一个原有项目基础之上进行二次开发,而且项目工程庞大复杂,出现了不少问题,其中遇到最多.花费时间 最长的问题就是著名的“段错误”(Segmentation Fault).借此机会系统学习了一下,这里对Linux环境下的段错误做个小结,方便以后同类问题的排查与解决. 1. 段错误是什么 一句话来说,段错误是指访问的内存超

mosquitto在Linux环境下的部署/安装/使用/测试

mosquitto在Linux环境下的部署 看了有三四天的的源码,(当然没怎么好好看了),突然发现对mosquitto的源码有了一点点感觉,于是在第五天决定在Linux环境下部署mosquitto. 使用传统源码安装步骤: 步骤1:http://mosquitto.org/files/source/官网下载源码,放到Linux环境中.解压后,找到主要配置文件config.mk,其中包含mosquitto的安装选项,需要注意的是,默认情况下mosquitto的安装需要OpenSSL(一个强大的安全

【原创】Linux环境的图形系统和AMD显卡驱动编程(1)——Linux环境下的图形系统简介

Linux/Unix环境下最早的图形系统是Xorg图形系统,Xorg图形系统通过扩展的方式以适应显卡和桌面图形发展的需要,然而随着软硬件的发展,特别是嵌入式系统的发展,Xorg显得庞大而落后.开源社区开发开发了一些新的图形系统,比如Wayland图形系统. 由于图形系统.3D图形本身的复杂以及历史原因,Linux下的图形系统相关的源码庞大而且复杂,而且缺少学习的资料(所有源代码分析或者驱动编程的书籍都很少介绍显卡驱动).在后续一系列文章中,笔者将从对AMD硬件编程的角度出发对部分问题做一个简单的