Gerando pacotes ICMP quando TTL = 2?

Question

Ao inspecionar a carga útil dos pacotes ICMP time-exceeded , percebi que às vezes é o último mas um roteador (quando ttl=2 no pacote retornado) ou mesmo um anterior (até 5 saltos antes, ttl=5 ) que derruba o pacote e gera uma mensagem ICMP.

Como assim? Alguma razão por trás disso?

Como você define isso em um roteador CISCO ?

Editar:

por favor note que TODOS estes pacotes são código ICMP tipo 11 0, o que significa:

type = time-exceeded, código = ttl-zero-during-transit

Edit2: Aqui estão dois exemplos de tais pacotes 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'

    

Answer 1

link

link

Seus pacotes são encapsulados em MPLS quando o TTL do rótulo externo é decrementado para 0, mas o pacote TTL interno não é atualizado, portanto o pacote rotulado com TTL expirado é encaminhado e o pacote IP interno (com um TTL aparentemente válido) é devolvido a você como expirado pelo último roteador MPLS.

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

Quando um pacote rotulado TTL expira, o pacote é realmente encaminhado até o final do 'túnel', pois o roteador que diminuiu o campo TTL para 0 pode não ter uma rota válida de volta ao remetente original. Assim, o rótulo MPLS é editado para indicar a expiração do TTL e, eventualmente, o roteador de túnel final decapsula o pacote 'válido, mas expirado pelo rótulo' e o envia de volta com uma mensagem de falha do TTL.

Disclaimer: Eu li através de seções relevantes do TTL de vários RFCs, mas nada foi definido neste tratamento, então eu diria que esse comportamento pode variar de fornecedor para fornecedor.

Evidências de um pacote capturado:

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 

    

Answer 2

Os roteadores devem diminuir o tempo de vida do campo em 1 por cada segundo gasto no processamento do pacote, mas em nenhum caso ele deve diminuir em menos de 1.

Portanto, se um roteador gastar mais de um segundo processando um pacote, ele deverá decrementar o TTL em mais de um. No entanto, é extremamente raro que um roteador gaste mais de um segundo processando um pacote, a menos que esteja terrivelmente atolado.

Bloqueio de erros de implementação do roteador, isso é a única coisa em que consigo pensar que explicaria isso.

    

Answer 3

Embora eu não possa dizer exatamente o que está acontecendo aqui, o pacote Time Exceeded é enviado em uma das duas condições: o TTL é excedido ou o tempo de remontagem de fragmento é excedido. Qual é o código enviado de volta (segunda mordida da carga útil). Se for 1 , o motivo para enviar o pacote é o tempo de remontagem excedido. Normalmente, isso deve ser definido em 60 a 120 segundos, não em 0,01s. São sempre os mesmos roteadores que enviam esses pacotes de volta? Você pode postar o pacote completo que você está recebendo de volta e? Você pode postar alguma informação sobre os roteadores em questões? Faço? Modelo?

    

Answer 4

Embora seja possível, um erro nesse nível rudimentar é improvável; além de considerar o tempo (rápido) necessário para processar pacotes, prefiro direcionar a semelhança de um problema para algum tipo de loop ou saltando. No caso trivial / usual, o roteador decrementa o TTL e direciona o pacote para a interface correta com base em sua tabela de roteamento.

Existem alguns casos mais complexos em que o TTL pode depender da implementação do roteador. Do topo da minha cabeça, vem NAT mascarando onde o pacote pode "reentrar" no roteador após a tradução do endereço ter sido realizada - este é tipicamente o caso quando alguém quer testar um IP da WAN do roteador dentro (e isso não funciona em todos os roteadores)

Por exemplo,

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

o endereço 198.252.206.16 sendo o próprio endereço visto da Internet (o lado WAN do roteador) que é internamente ligado a 10.1.2.3 ie é na verdade o mesmo host que o remetente

O roteador recebe o pacote e percebe que o endereço da WAN é seu próprio endereço, o pacote "reentra" na interface da WAN (dependente da implementação) e é direcionado para o endereço da LAN 10.1.2.3 .

Como o TTL é tratado nesse caso (o que não está funcionando em todos os roteadores) depende da implementação.

    

Answer 5

A resposta para " Por que você está recebendo time-exceeded pacotes " (sua pergunta original de " Como? Qualquer razão por trás disso? ") é fácil de responder :

Veja o pacote de tempo excedido que você caputou, qual é o valor do código dentro dele. Se for 0, era um problema de TTL no roteador de geração, se fosse 1, era um problema de fragmentação no roteador de geração.

A pergunta " Como você define isso em um roteador CISCO? " não faz sentido, defina o quê? Nenhum comportamento fora do comum foi exibido de acordo com o que você disse.

" Por que o roteador está tendo problemas de TTL ou de fragmentação? " é uma boa pergunta aqui, acredito. Se o roteador (assumindo que é sempre o mesmo) está fora de seu controle, então não podemos dizer com certeza. Mas podemos especular um pouco. Poderia ser uma incompatibilidade de MTU entre interfaces, poderia ser um problema de buffering, suponho também. Isto está assumindo que é um problema de fragmentação. Se for um problema de TTL, pode ser uma configuração incorreta de um MPLS LSP ou um MPLS LSR que está dando uma leitura conflitante de ICMP devido a PHP / UHP, etc. (embora improvável).

Quando você está recebendo essas mensagens de tempo excedido, os fluxos atuais de UDP / TCP estão com problemas, algum deles cai? A mensagem de tempo excedido deve conter parte do pacote de dados que causou a geração do pacote ICMP, a unidade de dados original é um quadro jumbo ou um pacote TCP grande, ele tem o bit DF definido?

Você não deu muito para continuar em termos do contexto no qual os pacotes ICMP estão sendo gerados, em primeiro lugar.