当TTL = 2时产生ICMP数据包?

通过检查ICMP time-exceeded数据包的有效负载,我注意到有时它是最后一个路由器(当返回的数据包中ttl=2时),或者甚至是前一个(最多5跳之前, ttl=5 )数据包并生成一个ICMP消息。

怎么会这样? 这背后有什么理由?

你如何在CISCO路由器中设置?

编辑:

请注意, 所有这些数据包都是ICMPtypes11代码0,这意味着:

type = time-exceeded,code = ttl-zero-transit-transit

编辑2:这是这样的ICMP数据包的两个例子。

 ###[ IP ]### version = 4L ihl = 5L tos = 0x0 len = 168 id = 9969 flags = frag = 0L ttl = 243 proto = icmp chksum = 0x19ea src = 193.51.189.25 dst = 134.59.129.241 \options \ ###[ ICMP ]### type = time-exceeded code = ttl-zero-during-transit chksum = 0xbf6e unused = 0 ###[ IP in ICMP ]### version = 4L ihl = 5L tos = 0x0 len = 52 id = 57161 flags = DF frag = 0L ttl = 2 proto = tcp chksum = 0xcf32 src = 134.59.129.241 dst = 173.194.20.89 \options \ ###[ TCP in ICMP ]### sport = 43843 dport = http seq = 3927922380L ack = 3188073609L dataofs = 8L reserved = 0L flags = A window = 14165 chksum = 0x51f9 urgptr = 0 options = [('NOP', None), ('NOP', None), ('Timestamp', (5088093, 1579045454))] ###[ Padding ]### load = '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x9d\xeb\x00\x08\x01\x01\x00\nA\x01' ###[ IP ]### version = 4L ihl = 5L tos = 0x0 len = 168 id = 37758 flags = frag = 0L ttl = 246 proto = icmp chksum = 0xaa73 src = 193.51.189.2 dst = 134.59.129.241 \options \ ###[ ICMP ]### type = time-exceeded code = ttl-zero-during-transit chksum = 0x2e1c unused = 4 ###[ IP in ICMP ]### version = 4L ihl = 5L tos = 0x0 len = 60 id = 53079 flags = DF frag = 0L ttl = 5 proto = tcp chksum = 0x6d73 src = 134.59.129.241 dst = 74.125.230.71 \options \ ###[ TCP in ICMP ]### sport = 45799 dport = http seq = 2382327024L ack = 0 dataofs = 10L reserved = 0L flags = S window = 14600 chksum = 0x83ed urgptr = 0 options = [('MSS', 1460), ('SAckOK', ''), ('Timestamp', (5088167, 0)), ('NOP', None), ('WScale', 4)] ###[ Padding ]### load = '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00X\xf6\x00\x08\x01\x01\x04\x01\x81\xff' 

  • 为特定目的推荐一个内容分发networking(CDN)
  • 在更新之前,azure cdn存在多久?
  • 我把TTL从24小时改成了5分钟。 在更改logging之前是否需要等待24小时?
  • Windows 2008 R2 DNS可以设置每条logging的TTL吗?
  • Windows Server 2008 R2 DNS - 将更改同步到TTL
  • 清漆caching - 默认的TTL?
  • 5 Solutions collect form web for “当TTL = 2时产生ICMP数据包?”

    http://packetlife.net/blog/2008/dec/22/disabling-mpls-ttl-propagation/

    http://www.ciscopress.com/articles/article.asp?p=680824&seqNum=4

    当外层标签的TTL递减到0时,你的数据包被MPLS封装,但是内层数据包TTL没有被更新,所以TTL过期的标签数据包被转发并且内部IP数据包(具有明显有效的TTL)被返回给你作为最后的MPLS路由器过期了。

    ============================

    当带标签的数据包TTL过期时,数据包实际上被转发直到它的“通道”结束,因为将TTL字段递减为0的路由器可能没有有效的路由回到原始发送者。 因此,MPLS标签被编辑以指示TTL过期,并且最终隧道最终路由器解封装“有效但标签过期”的分组并且将其发回TTL失败消息。

    免责声明:我通过几个RFC的TTL相关部分阅读,但没有明确的处理,所以我会说,这种行为可能会有所不同,从供应商。

    来自捕获的数据包的证据:

     Internet Control Message Protocol Type: 11 (Time-to-live exceeded) Code: 0 (Time to live exceeded in transit) Checksum: 0xf4df [correct] Internet Protocol, Src: 192.168.1.x (192.168.1.x), Dst: 8.8.8.8 (8.8.8.8) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x80 (DSCP 0x20: Class Selector 4; ECN: 0x00) Total Length: 92 Identification: 0x6b56 (27478) Flags: 0x00 Fragment offset: 0 Time to live: 2 <===== payload of packet entering MPLS tunnel Protocol: ICMP (1) Header checksum: 0x7abb [correct] Source: 192.168.1.x (192.168.1.x) Destination: 8.8.8.8 (8.8.8.8) Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 Checksum: 0xf78f [correct] Identifier: 0x0001 Sequence number: 111 (0x006f) Sequence number (LE): 28416 (0x6f00) Data (64 bytes) MPLS Extensions Version: 2 Reserved: 0x000 Checksum: 0x5581 [correct] MPLS Stack Entry Length: 0x0008 Class: 1 C-Type: 1 Label: 1864, Exp: 4, S: 1, TTL: 1 0000 0000 0111 0100 1000 .... = Label: 1864 .... .... .... .... .... 100. = Experimental: 4 .... .... .... .... .... ...1 = Stack bit: Set Time to live: 1 <========== MPLS TTL 

    路由器应该在处理数据包的每一秒钟内将生存时间减1,但绝不应该减less到小于1。

    所以,如果一个路由器花费多于一秒的时间处理一个数据包,它应该把TTL减less一个以上。 然而,路由器花费超过一秒的时间处理一个数据包,这是非常罕见的,除非它非常困难。

    除了路由器的执行错误,这是我能想到的唯一的事情将解释这一点。

    虽然我不能确切地说明在这里发生了什么,但超时时间数据包是以两种情况之一发送的:超出TTL,或者超过了片段重新组装时间。 什么是代码发回(有效载荷的第二口)。 如果是1 ,则发送数据包的原因是重新组装时间超出。 通常应该设置在60到120秒,而不是0.01秒。 它是否总是相同的路由器发送这些数据包? 你可以发布你回来的完整数据包吗? 你可以在路由器上发布任何信息吗? 使? 模型?

    虽然可能的话,这个初级阶段的错误是不太可能的。 加上考虑处理数据包所需的(快)时间,我宁愿将问题的forms指向某种循环或弹跳。 在平凡/平常的情况下,路由器递减TTL并根据其路由表将数据包定向到正确的接口。

    还有一些更复杂的情况,TTL可能取决于路由器的实现。 从我的头顶来看,地址转换完成后, NAT会伪装数据包可能“重新进入”路由器 – 这是典型的情况,当你想从内部testing一个路由器WAN IP时在所有路由器上工作)

    例如,

     source: local 10.1.2.3/24 destination: public: 198.252.206.16/32 (an example..) 

    地址198.252.206.16是自己的地址,如从内部绑定到10.1.2.3的因特网(路由器的WAN侧)看到的,ie实际上是与发送方相同的主机

    路由器接收数据包并实现WAN地址是自己的地址,数据包“重新进入”WAN接口(取决于实施)并被驱动到LAN地址10.1.2.3

    在这种情况下TTL是如何处理的(这在所有路由器上都不起作用)是依赖于实现的。

    答案是“ 为什么你会收到time-exceeded数据包 ”(你最初的问题是“ 怎么会这样?这背后的任何原因? ”)很容易回答:

    看看你超时包裹的时间,里面的代码值是多less。 如果是0,则在生成路由器时是TTL问题,如果是1,则在生成路由器时是碎片问题。

    你如何在CISCO路由器中设置这个问题 ”这个问题没有意义,设置什么? 根据你所说的,没有显示出不寻常的行为。

    为什么路由器有TTL或碎片问题? ”在这里我相信是一个很好的问题。 如果路由器(假设它总是一样的)超出了你的控制范围,那么我们不能肯定地说。 但我们可以推测一下。 这可能是接口之间的MTU不匹配,也可能是缓冲问题。 这是假设它是一个分裂问题。 如果是TTL问题,可能是由于PHP / UHP等(尽pipe不太可能)而导致的MPLS LSP或MPLS LSR的configuration错误。

    当你收到这些超时的消息时,当前的UDP / TCPstream是否有问题,做任何一个丢弃? 超时消息应该包含导致产生ICMP数据包的部分数据包,原始数据单元是巨帧还是大TCP包,是否有DF位置1?

    从一开始就生成ICMP数据包的上下文来看,您还没有做太多的工作。

    服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器.