Generating ICMP packets when TTL=2?

Ricky Robinson asked:

By inspecting the payload of ICMP time-exceeded packets, I noticed that sometimes it is the last but one router (when ttl=2 in the returned packet) or even a previous one(up to 5 hops before, ttl=5) that drops the packet and generates an ICMP message.

How so? Any reason behind this?

How do you set this in a CISCO router?

Edit:

please note that ALL these packets are ICMP type 11 code 0, which means:

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

Edit2: Here are two examples of such ICMP packets.

###[ 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      = 'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00 x00x9dxebx00x08x01x01x00nAx01'





    ###[ 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      = 'x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00x00 x00Xxf6x00x08x01x01x04x01x81xff'

My answer:


Routers are supposed to decrement the time to live field by 1 for each second spent processing the packet, but in no case should it decrement by less than 1.

So if a router spends more than a second processing a packet, it should decrement the TTL by more than one. However, it’s exceedingly rare that a router would spend more than a second processing a packet, unless it was terribly bogged down.

Barring router implementation bugs, that’s about the only thing I can think of that would explain this.


View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.