tracert路由跟踪出现问题

tracetrt+IP命令只要你不手动关闭，会一直跟踪运行直至追踪到你所查IP。
如果在某一个路由一直请求超时，说明路由器关闭或者其他情况导致IP不能被追踪
arphbcnccn是指湖北网通ARP服务器。
望采纳，谢谢！

traceroute 主要利用 IP 数据包的 TTL 字段值 + ICMP 来实现，它发送的用于探测网络路径的数据包的 IP 之上的协议可以是 UDP、TCP或ICMP。

协议表示该数据报文所携带的数据所使用的协议类型，占 8 位。
该字段可以方便目的主机的 IP 层知道按照什么协议来处理数据部分。不同的协议有专门不同的协议号。
例如，TCP 的协议号为 6，UDP 的协议号为 17，ICMP 的协议号为 1。

不同模式下，探测过程中设计的数据包如下：

UDP 探测数据包（目标端口大于 30000） + 中间网关发回 ICMP TTL 超时数据包 + 目标主机发回 ICMP Destination Unreachable 数据包

TCP [SYN] 探测数据包（默认目标端口为 80） + 中间网关发回 ICMP TTL 超时数据包 + 目标主机发回 TCP [SYN ACK] 数据包

ICMP Echo (ping) Request 探测数据包 + 中间网关发回 ICMP TTL 超时数据包 + 目标主机发回 ICMP Echo (ping) reply 数据包

UDP 端口扫描比较麻烦，它同TCP不一样，因为它不需要建立连接。
我们向 目标主机 的固定端口发送UDP数据包，可以得到 两种结果：

在运营商的路由器上，UDP 与 ICMP 的待遇大不相同。
为了利于 troubleshooting，ICMP ECHO Request/Reply 是不会封的，而 UDP 则不同。
UDP 常被用来做网络攻击，因为 UDP 无需连接，因而没有任何状态约束它，比较方便攻击者伪造源 IP、伪造目的端口发送任意多的 UDP 包，长度自定义。
所以运营商为安全考虑，对于 UDP 端口常常采用白名单 ACL，就是只有 ACL 允许的端口才可以通过，没有明确允许的则统统丢弃。比如允许 DNS/DHCP/SNMP 等。

当网络工程师用Ping时，Ping在偷摸做啥事儿？
ping命令是依托于 ICMP协议的， ICMP协议的存在就是为了更高效的转发 IP数据报和提高交付成功的机会。
ping命令除了依托于 ICMP，在局域网下还要借助于 ARP协议， ARP协议能根据 IP地址反查出计算机的 MAC地址。
另外 ARP是有缓存的，为了保证 ARP的准确性，计算机会更新ARP缓存。

有时我们traceroute 一台主机时，会看到有一些行是以星号表示的。
出现这样的情况，可能是防火墙封掉了ICMP的返回信息，所以我们得不到什么相关的数据包返回数据。
有些路由器会隐藏的自己的位置，不让ICMP Timeout的消息通过，结果就是在那一跳上始终会显示星号。此外服务器也可以伪造traceroute路径的，不过一般应用服务器也没有理由这么做，所以Traceroute的结果还是能够为网络分析提供一些参考的。

Linux下traceroute程序默认发送的探测包为UDP协议，windows下tracert、mtr，以及Linux下mtr默认都发送的是icmp的数据包，并不是所有网关都会如实返回 ICMP 超时报文。处于安全性考虑，大多数防火墙以及启用了防火墙功能的路由器缺省配置为不返回各种 ICMP 报文，其余路由器或交换机也可能被管理员主动修改配置变为不返回 ICMP 报文。因此 Traceroute 程序不一定能拿到所有的沿途网关地址。所以，当某个 TTL 值的数据包得不到响应时，并不能停止这一追踪过程，程序仍然会把 TTL 递增而发出下一个数据包。这个过程将一直持续到数据包发送到目标主机，或者达到默认或用参数指定的追踪限制（maximum_hops 默认最大为30）才结束追踪

如果在局域网中的不同网段之间，我们可以通过traceroute 来排查问题所在，是主机的问题还是网关的问题。
如果我们通过远程来访问某台服务器遇到问题时，我们用到traceroute 追踪数据包所经过的网关，提交IDC服务商，也有助于解决问题；但目前看来在国内解决这样的问题是比较困难的，就是我们发现问题所在，IDC服务商也不可能帮助我们解决。

动态图解traceroute（路由追踪）的原理与实现
>