Resumen

  • Para quien depende de una conexión remota, una ruta puede existir físicamente y, sin embargo, quedar fuera del alcance representable por RIP si requiere más de 15 saltos.
  • Tras un fallo, las rutas antiguas pueden seguir enviando tráfico por el camino equivocado. La RFC 1058 usó 16 para acotar ese conteo, no para prometer una reparación inmediata.

Una ruta puede ser demasiado larga para existir

Pensemos en un servicio de una oficina remota: los enlaces pueden estar activos, pero la ruta aún debe caber en el mapa del protocolo. Un fallo distinto aparece cuando una pasarela retira un destino y una vecina sigue apuntando de vuelta hacia ella. Es un ejemplo explicativo, no un incidente histórico concreto; la RFC 1058 describe el mecanismo, no una avería identificada.

La especificación de 1988 fijó un punto de parada deliberadamente bajo. En la RFC 1058, una métrica entre 1 y 15 era utilizable; 16 significaba inalcanzable. No era una distancia literalmente infinita, sino la frontera del protocolo entre una ruta que podía anunciar y otra que debía retirar.

La consecuencia era clara: RIP no podía expresar un trayecto válido cuya métrica superara 15. El memorando de Hedrick describe un protocolo para redes de tamaño moderado y recoge que sus diseñadores dudaban de su utilidad en redes con un diámetro superior a 15. A la vez, el valor reducido dejaba menos incrementos para que una ruta obsoleta siguiera circulando durante el conteo hasta el infinito.

El límite acota el fallo, no lo elimina

La RFC 1058 no presenta el número como una solución completa. Explica el conteo hasta el infinito como un problema de convergencia y analiza otras defensas: split horizon, reverse poisoning y actualizaciones activadas. Ninguna convertía el proceso en infalible. Una actualización podía llegar tarde y dejar que información dañada siguiera propagándose; el propio documento reconoce que el conteo aún podía ocurrir.

Que el fallo tenga un final definido no lo vuelve inocuo. Mientras las pasarelas elevan la métrica, pueden enviar paquetes por una ruta falsa. El 16 indica cuándo el plano de control deja de anunciarla como válida; no certifica que antes todos los paquetes encontraran un camino operativo.

La RFC 2453, sobre RIP versión 2, mantuvo el 16 como infinito y volvió a describir las limitaciones y los bucles. La RFC 1812 incluye RIP entre los protocolos históricos. Especificar bien un mecanismo no lo convierte en la opción apropiada para cualquier topología.

El tamaño era parte de la arquitectura

El 16 podría parecer una constante heredada. La lógica expuesta en la RFC es más útil: conviene que el infinito sea pequeño para que la cuenta tras una avería no se prolongue innecesariamente, pero no tanto que excluya las rutas normales. La decisión intercambia diámetro de red por velocidad de recuperación cuando persiste información equivocada.

Por eso el valor es también una hipótesis operativa. Quien desplegaba RIP aceptaba un perímetro topológico. Si la red lo superaba, cambiar temporizadores no volvía válida una ruta con métrica 16. El protocolo había agotado su capacidad de representar ese trayecto.

Todo límite puede contener la expansión de un fallo al declarar ciertos estados fuera de alcance. La cuestión es quién asume el coste: el mecanismo, el operador que debe rediseñar, o las personas cuyo tráfico no encuentra una ruta representable. En 1988, RIP hacía visible el intercambio. Dieciséis señalaba el borde de su mapa.

Documentos primarios: RFC 1058; RFC 2453; RFC 1812.