Resumo

  • A validade padrão de um anúncio da RFC 1256 é de 1.800 segundos: sem uma nova atualização, esse é o prazo máximo para o host esquecer um roteador aprendido dinamicamente — não uma promessa de comutação em meia hora.
  • A RFC afirma que o ritmo padrão, de um anúncio a cada 7,5 a 10 minutos, não basta para detectar um buraco negro no primeiro salto antes do fim de uma sessão de transporte. A detecção de gateway inativo é uma função separada do host, descrita na RFC 1122.

O incômodo de uma falha de gateway nem sempre está no instante da falha. Também está no intervalo em que o host ainda acredita que aquele endereço continua sendo uma saída válida.

Em setembro de 1991, a RFC 1256 propôs uma forma de os hosts descobrirem roteadores vizinhos sem manter listas de endereços manualmente ou depender de um protocolo de roteamento específico. Os roteadores enviavam anúncios ICMP; quando uma interface era iniciada, o host também podia enviar algumas solicitações. A ideia tornava visível quem se apresentava como vizinho. A decisão mais reveladora era por quanto tempo essa declaração deveria valer.

Os valores padrão foram feitos para gerar pouco ruído. O intervalo máximo de anúncio é de 600 segundos; o mínimo padrão corresponde a 75% disso, ou 450 segundos. O próximo intervalo é sorteado dentro da faixa, espalhando os anúncios por cerca de 7 minutos e 30 segundos a 10 minutos. A validade anunciada, por padrão, equivale a três vezes o máximo: 1.800 segundos, meia hora.

Esse prazo funciona como um aluguel de estado local. Ao receber um anúncio válido de um roteador vizinho, o host inclui o endereço na lista de roteadores padrão e inicia um temporizador com a validade informada. Novos anúncios renovam o temporizador. Quando ele vence, a entrada aprendida dinamicamente é removida. Uma entrada configurada estaticamente é diferente: a configuração não lhe dá automaticamente esse temporizador.

É fácil tomar os “trinta minutos” por um parâmetro de comutação. A RFC diz que não são. A baixa frequência e a validade longa limitam a carga no enlace e nos hosts, mesmo quando há muitos roteadores; mas os valores padrão não detectam um buraco negro no primeiro salto antes que uma sessão de transporte expire. Um administrador pode escolher prazos menores. O texto não afirma que essa seja a prática comum.

Descobrir a presença de um roteador e verificar se ele encaminha tráfego agora são perguntas diferentes. O anúncio informa que um endereço se oferece como roteador vizinho e pode permanecer válido até certo limite sem atualização. Não prova que o próximo pacote para determinado destino atravesse por ali. A RFC 1256 não é um protocolo de roteamento e não seleciona a melhor rota para cada destino. O ICMP Redirect cuida de outra situação: avisar que existe um primeiro salto melhor para um destino já encaminhado.

A RFC 1122 descreve a outra metade: a camada IP deve detectar a falha do gateway do próximo salto e escolher uma alternativa. Em 1989, o documento reconhecia que não havia um algoritmo geral plenamente satisfatório. Pingar o gateway continuamente foi descartado por ser caro e pouco escalável. Em vez disso, camadas superiores e inferiores poderiam aconselhar a camada IP: um ACK TCP é evidência positiva; retransmissões repetidas ou um sinal do enlace podem indicar problema. O temporizador da RFC 1256 nunca foi pensado para substituir esse julgamento.

A solicitação no início ajuda na descoberta inicial, mas não é um pulso de vida permanente. O host pode enviar até três solicitações, com intervalos de três segundos; quando recebe um anúncio válido, deve parar. Depois, anúncios periódicos renovam a lista. O silêncio acaba removendo uma entrada, mas não informa sozinho quando o caminho deixou de funcionar.

Assim, a história não é sobre uma queda de meia hora, mas sobre a separação entre dois tipos de evidência. Router Discovery reduz o trabalho de configuração e mantém uma memória limitada de quem se anunciou. A detecção de gateway inativo precisa avaliar o encaminhamento atual, o tráfego e os sinais de outras camadas. Tratar o prazo de expiração como compromisso de recuperação mistura essas tarefas e atribui à RFC uma garantia que ela rejeita explicitamente.

As fontes são a RFC 1256 e a seção 3.3.1.4 da RFC 1122. Elas registram valores e limites de projeto, não o tempo de recuperação de um sistema operacional, rede ou usuário específico.