Resumen

  • La vigencia predeterminada de un anuncio en la RFC 1256 es de 1.800 segundos: sin una actualización, el host puede tardar ese máximo en olvidar un router aprendido dinámicamente; no es una promesa de conmutación en media hora.
  • La RFC advierte que el ritmo predeterminado —un anuncio cada 7,5 a 10 minutos— no basta para detectar un agujero negro en el primer salto antes de que venza una sesión de transporte. La detección de pasarelas caídas pertenece a otra función del host, descrita en la RFC 1122.

Lo inquietante de una pasarela caída no siempre es el instante en que deja de funcionar. También importa cuánto tarda el host en dejar de creer que esa dirección sigue siendo una salida válida.

En septiembre de 1991, la RFC 1256 ofreció a los hosts una alternativa a las listas de direcciones mantenidas a mano y a depender de un protocolo de enrutamiento concreto para descubrir routers vecinos. Los routers enviaban anuncios ICMP; al iniciar una interfaz, un host podía emitir unas pocas solicitudes. El mecanismo hacía visible quién se anunciaba como vecino. La elección más reveladora fue cuánto debía durar esa creencia.

Los valores iniciales son discretos a propósito. El intervalo máximo de anuncio es de 600 segundos y el mínimo predeterminado equivale al 75 %: 450 segundos. El siguiente intervalo se escoge al azar dentro del rango, de modo que los anuncios suelen llegar cada 7 minutos y medio a 10 minutos, sin sincronizarse. La vigencia predeterminada es tres veces el máximo: 1.800 segundos, media hora.

Ese plazo funciona como un alquiler de estado local. Cuando recibe un anuncio válido de un router vecino, el host agrega su dirección a la lista de routers predeterminados e inicia un temporizador con la vigencia anunciada. Los anuncios posteriores lo renuevan. Si vence, el host elimina la entrada aprendida dinámicamente. Una dirección configurada de forma estática no recibe ese temporizador por el mero hecho de estar configurada.

Sería fácil interpretar los «treinta minutos» como un ajuste de conmutación. La RFC lo descarta expresamente. Explica que el ritmo y la vigencia predeterminados mantienen baja la carga del enlace y de los hosts, incluso con muchos routers, pero que no detectan un agujero negro del primer salto a tiempo para evitar que venza una sesión de transporte. El operador puede reducir esos valores; el texto no afirma que esa sea la práctica general.

Descubrir presencia no equivale a comprobar funcionamiento. Un anuncio dice que una dirección se ofrece como router vecino y seguirá siendo válida hasta cierto límite si no llega otro. No prueba que el siguiente paquete hacia un destino concreto vaya a cruzar por allí. La RFC 1256 no es un protocolo de enrutamiento y no elige la mejor ruta para cada destino. ICMP Redirect responde a otra situación: ya se envió tráfico por un router y este informa de un primer salto mejor.

La RFC 1122 establece la otra mitad: la capa IP debe detectar la falla de la pasarela del siguiente salto y escoger una alternativa. En 1989, el documento reconocía que no existía un algoritmo general plenamente satisfactorio. Prohibía hacer ping continuo, por costoso y poco escalable, y favorecía las señales de capas superiores e inferiores. Un acuse TCP aporta evidencia positiva; retransmisiones reiteradas o una indicación del enlace pueden aportar evidencia negativa. El temporizador de la RFC 1256 no sustituye ese juicio.

La solicitud de inicio ayuda a descubrir pronto, pero no es un pulso de vida permanente. El host puede enviar hasta tres solicitudes, separadas por tres segundos; al recibir un anuncio válido debe detenerse. Después, los anuncios periódicos mantienen actualizada la lista. El silencio acaba borrando una entrada, pero no determina por sí solo cuándo dejó de servir el camino.

La historia, por tanto, no trata de una caída de media hora, sino de dos clases de evidencia. Router Discovery reduce el trabajo de configuración y guarda una memoria acotada de los routers que se han anunciado. La detección de una pasarela caída debe evaluar el reenvío presente, el tráfico y las señales de otras capas. Convertir la caducidad en un compromiso de recuperación mezcla ambas tareas y atribuye a la RFC una garantía que niega explícitamente.

Las fuentes son la RFC 1256 y la sección 3.3.1.4 de la RFC 1122. Fijan valores y límites de diseño, no la velocidad a la que un sistema, una red o una persona concreta se recuperó de una falla real.