1.先看现象
#今天工作亲身经历,现有一台windows和一台linux,都在一个网络里,同一个网段,跟踪同一个目标地址。 #windows结果如下; C:\Users\Administrator>tracert 10.206.157.56 通过最多 30 个跃点跟踪到 10.206.157.56 的路由 1 6 ms 10 ms 10 ms 10.136.153.12 2 * * * 3 5 ms 4 ms 6 ms 10.136.158.22 4 * 5 ms 4 ms 10.132.36.156 5 * * * #linux结果如下 [root@localhost ~]# traceroute 10.206.157.56 traceroute to 10.206.157.56 (10.206.157.56), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * *
2.再说原因
windows的tracert是使用icmp来探路,linux的traceroute是使用udp探测,给traceroute加上-I参数就会使用icmp。
3.原理分析
window下的tracert是常用的网络故障排查命令,首先PC会发送一个icmp request且TTL为1的数据包,数据包到达节点A,节点A回应ICMP差错消息(TTL超时),PC根据发出与接收到数据包的时间差来算出时延,接着发送TTL为2的数据包,以此类推,直到收到目的节点回复的ICMP replay消息。
linux中的traceroute原理与tracert类似,只不过默认把发送的ICMP request数据包更换成了UDP数据包(30000 以上端口),直到目的主机回应端口不可达(ICMP port unreachable)为止。
4.举一反三
traceroute的问题解决了,再仔细看windows中结果:
1 6 ms 10 ms 10 ms 10.136.153.12 2 * * * 3 5 ms 4 ms 6 ms 10.136.158.22 4 * 5 ms 4 ms 10.132.36.156
4.1.有的中间节点没有回复?是网络异常吗?
网络设备上设置了针对ttl为1的报文进行直接丢弃不回复来节约设备资源。
中间有防火墙之类的安全设备,不会发送icmp的ttl超时报文。
该设备上没有任何可以和互联网进行通信的公网ip地址。
4.2.有的中间节点出现两个*或一个*,是在丢包?
不是,因为网络设备对icmp报文的速率进行了一定的限制。
4.3.结论
tracert和traceroute最大的用处是探测源目节点间的路由走向,而不是探测目的节点网络连通性。
tracepath 使用 UDP 端口或一些随机端口。它类似于 traceroute,没有参数能让tracepath使用ICMP探测。
5.常用参数
tracert -d 不解析成域名 -h hops指定到达目标的最大跃点数(最大TTL) -w wait等待每个回复的超时时间(毫秒) -4 强制使用IPv4 -6 强制使用IPv6 traceroute -n 不解析成域名 -m 指定探测的最大跃点数(最大TTL),默认30 -w 等待超时的时间(秒),默认为5秒 -4 使用IPv4地址 -6 使用IPv6地址 -I 使用ICMP来追踪路由 -T 指定TCP格式,默认为UDP -p 指定目的地址的端口号 -s 指定源地址 -i 指定发送数据包的网卡接口。默认根据路由表选择接口 -q 每个跃点的探测数(发包个数),默认为3 tracepath -4 仅使用IPv4。 -6 仅使用IPv6。 -n 以数字形式只显示 IP 地址。 -b 同时显示 IP 地址和主机名。 -l 设置初始化的数据包长度,IPv4 默认为 65535,IPv6 默认为 128000。 -m 设置最大 TTL 值,默认为 30。 -p 设置要使用的初始目标端口。 -V 打印版本并退出。
转载请注明:零五宝典 » 同一网络环境,用tracert正常但是用traceroute不正常?tracert/traceroute/tracepath区别