Resumen

  • El RFD afrontó una limitación real: el volumen de actualizaciones BGP podía agotar la capacidad de procesamiento de routers tempranos y provocar más fallos.
  • El algoritmo registraba retiradas y cambios, no sus causas. La exploración de rutas alternativas tras una sola retirada podía sumar penalizaciones suficientes para ocultar durante una hora un prefijo ya recuperado en las topologías estudiadas.
  • La autoridad efectiva estaba repartida entre autores de estándares, fabricantes y operadores. El dueño del recurso numérico podía anunciar correctamente, pero no ordenar a un router remoto que reutilizara la ruta.
  • La respuesta documentada pasó de coordinar parámetros a desactivar el mecanismo y, más tarde, a elevar los umbrales. La modificación de menor coste de coordinación sobrevivió mejor que el rediseño selectivo propuesto en 2002.

La corrección de 2006 empezó con un “no lo use”

En mayo de 2006, RIPE-378 dio por obsoletas tres generaciones de recomendaciones sobre damping y aconsejó no aplicar las implementaciones disponibles en redes de proveedores. El documento no negó el problema original. Lo que afirmó fue que la cura había adquirido efectos sobre la alcanzabilidad que podían ser peores que operar sin ella.

Ese giro resulta más instructivo si se reconstruye desde atrás. Ocho años antes, RFC 2439 había presentado el RFD como un mecanismo ya incorporado a productos comerciales. Cinco años antes, RIPE-229 había pedido que los ISP y los fabricantes adoptaran un conjunto coordinado de parámetros. En 2006, el mismo espacio operativo reconocía que una ruta estable podía resultar penalizada por la dinámica de BGP.

No hubo una autoridad central que apagara la función. RIPE-378 era una recomendación. Cada operador tenía que modificar su propia configuración; cada fabricante decidía qué posibilidades ofrecía el software. El cambio histórico fue una retirada de confianza, no una orden ejecutada desde un único punto.

Por qué la idea había vencido primero

A comienzos de los años noventa, la tabla crecía, las conexiones entre proveedores se multiplicaban y las retiradas debían procesarse en todos los routers que transportaban la tabla completa. La decisión BGP y las altas y bajas en la tabla de reenvío consumían procesador. Un equipo sobrecargado podía perder sesiones; su caída generaba nuevas retiradas y desplazaba más trabajo a los vecinos.

Los documentos operativos sitúan el desarrollo del RFD en 1993 y su integración en software de Cisco, ISI/RSd y GateD desde 1995. RFC 2439 llegó en noviembre de 1998. Sus objetivos eran reducir carga, frenar oscilaciones sostenidas y no sacrificar la convergencia de las rutas normalmente bien comportadas.

El método asignaba una puntuación a cada ruta recibida de un vecino eBGP. Una retirada aumentaba la penalización. Según la implementación, también podían contar la reaparición o los cambios de atributos. La puntuación disminuía exponencialmente. Al superar el umbral de supresión, la ruta dejaba de usarse; al bajar del umbral de reutilización, podía regresar.

Era barato de calcular y podía contener el daño cerca del origen. También era un pronóstico hecho con datos incompletos. RFC 2439 reconocía que no era posible conocer la estabilidad futura y usaba la historia reciente como aproximación. El mecanismo sabía cuánto había cambiado una ruta; no sabía por qué.

Tres flaps producidos por una reparación

RIPE-229 documentó un mantenimiento planificado de software. La recarga posterior a la actualización contó como un flap. El nuevo software se bloqueó, generando otro. La recarga con la versión anterior añadió el tercero. Todo ocurrió en diez minutos.

La secuencia muestra una decisión operativa verificable: probar una versión y revertirla cuando falla. En algunos límites de tránsito y peering, parámetros progresivos demasiado agresivos mantuvieron los /24 del operador y sus clientes suprimidos durante más de tres horas. El contador trató el proceso de recuperación como evidencia acumulada de que la ruta no merecía volver.

RIPE 27 escogió no comenzar la supresión antes del cuarto flap seguido y fijó una hora como máximo desde el último. Fue una corrección basada en experiencia. También formalizó una distribución de demora: los /24 y prefijos más largos podían recibir una hora, mientras que agregados más cortos recibían intervalos menores.

La longitud del prefijo funcionaba como aproximación al número de usuarios y como incentivo a la agregación. Para una red pequeña multihomed, sin embargo, anunciar un prefijo más específico podía ser precisamente el instrumento de redundancia. La política castigaba con mayor dureza a quienes dependían de esa especificidad.

RIPE-229 necesitó excepciones para redes “Golden”, entre ellas servidores raíz y de dominios de nivel superior situados en prefijos largos. La excepción reconocía que aplicar la misma regla a una infraestructura crítica podía prolongar una interrupción inaceptable. No demostraba que la longitud midiera mejor la inestabilidad; hacía visible quién quedaba protegido de la medida.

La coordinación sin mandato

El problema de los parámetros locales era real. Los fabricantes entregaban valores distintos y los operadores podían ajustar semivida, supresión, reutilización y tiempo máximo. El mismo prefijo podía circular por una parte de Internet y seguir retenido por otra. El proveedor de acceso podía limpiar su propio router tras reparar la avería, pero no una penalización desconocida en otro AS.

Una pregunta en RIPE 26 llevó a un BOF; RIPE 27 formó un grupo de tarea; RIPE-178 apareció en 1998. Tony Barber, de UUNET, diseñó parámetros probados durante varios meses en su entorno. RIPE-229 los maduró en 2001 y pidió una adopción común para facilitar comportamiento y diagnóstico consistentes.

Es importante no llamar a esto soberanía de una “comunidad”. Los participantes podían persuadir y documentar. No podían configurar todos los routers. Los autores de RFC podían definir un mecanismo. Los fabricantes podían convertirlo en código y elegir los valores iniciales. Los operadores podían activar la conducta en equipos propios. La alcanzabilidad global surgía de la composición de esas decisiones locales.

Cuando BGP fabricó flaps secundarios

Una retirada no conduce siempre de forma directa a “sin ruta”. Los routers exploran caminos AS alternativos. Cada cambio de mejor ruta altera atributos y se propaga. Un sistema de damping puede sumar esos cambios como si el origen hubiera fallado repetidamente, aunque la avería física haya ocurrido una sola vez.

El trabajo de Zhuoqing Morley Mao, Ramesh Govindan, George Varghese y Randy Katz, presentado en SIGCOMM 2002, analizó el fenómeno con modelos, simulaciones, trazas y un banco de routers comerciales. En las topologías estudiadas, una retirada seguida de una reaparición podía superar el umbral a través de flaps secundarios y mantener la ruta recuperada suprimida hasta una hora. RIPE-378 citó además una medición donde una retirada produjo 41 eventos BGP varios saltos de AS más lejos.

La investigación no midió qué porcentaje de Internet tenía RFD ni sostuvo que cada topología se comportara igual. Su fuerza fue falsar una relación causal demasiado sencilla. Una penalización alta no probaba una línea crónicamente mala; podía medir el trabajo que BGP hacía para converger.

Los autores propusieron damping selectivo: no contar como nuevos flaps los cambios monotónicos característicos de la exploración tras una retirada. En sus pruebas eliminó la supresión desencadenada por retirada y aún contuvo una ruta que realmente alternaba cada cuarenta segundos. Faltaban, sin embargo, adopción y evidencia a escala de producción.

Por qué vencieron los umbrales

RIPE-378 afirmó en 2006 que no se había expresado demanda de la industria de ISP ni actividad de implementadores para adoptar la modificación de 2002. Los routers más potentes también habían reducido la urgencia del consumo de CPU original. Apagar la función era más fácil que reemplazar su lógica.

Una encuesta de 2012, publicada como Internet-Draft, obtuvo 63 respuestas voluntarias mediante listas de operadores. Trece declararon utilizar RFD y 49 no; quince eligieron RIPE-378 como razón de no uso. No es una muestra representativa del mundo, pero muestra que la recomendación se había convertido en una razón operativa y que el impacto sobre clientes preocupaba a los participantes.

RIPE-580 y RFC 7196 reabrieron la posibilidad con medidas menos agresivas. Los datos mostraban que pocos prefijos producían una parte desproporcionada del ruido. En la semana citada por RFC 7196, un umbral de 6.000 redujo en 19 % la tasa de actualizaciones frente a no usar RFD y suprimió 90 % menos prefijos que el umbral de 2.000. Con 12.000, se suprimió 0,22 % de los prefijos y la reducción media horaria de actualizaciones rondó el 11 %.

RFC 7196 recomendó no menos de 6.000 para una configuración todavía agresiva y no menos de 12.000 para una conservadora. También contempló calcular sin suprimir. Pero no aconsejó cambiar en silencio los valores predeterminados, porque podía alterar configuraciones existentes. El erratum verificado 4011 aclara que la tabla de valores Cisco y Juniper era informativa, no una aprobación.

El rediseño selectivo pedía nuevo código. Elevar un número utilizaba la interfaz instalada. La compatibilidad hizo que incluso valores cuestionados fueran difíciles de modificar automáticamente. Así se produjo el bloqueo institucional: no por un decreto, sino por millones de decisiones baratas alrededor de un software ya desplegado.

El titular pagaba una decisión ajena

El operador que aplicaba damping ganaba menos actualizaciones y menos trabajo de control. En los primeros equipos, evitar una caída podía beneficiar a muchos otros. Cuando la detección era falsa, el coste recaía en el titular del prefijo recuperado, en sus clientes y en quienes intentaban usar el servicio. La investigación podía cruzar varios AS sin revelar quién retenía todavía la ruta.

El operador tenía autoridad local sobre su router. Esa autoridad no equivalía al consentimiento de todos los afectados ni a un mandato global concedido por una RFC o una recomendación RIPE. Tampoco hay pruebas en este expediente para acusar incumplimiento contractual o ilegalidad. La pregunta legítima es si el afectado podía observar la decisión, atribuirla y pedir una corrección.

Un contrafactual serio no elimina las limitaciones de 1995. Sin RFD, los routers tempranos habrían procesado más ruido. Las alternativas plausibles son el algoritmo selectivo, umbrales altos desde el principio, un modo de observación y telemetría que revele la penalización y el AS que la aplica. Cada una intercambia carga, coste de software o riesgo de abuso por menos falsos positivos.

Para los titulares de recursos numéricos, la consecuencia es duradera. Un registro puede documentar de quién es un prefijo y una ROA puede ayudar a validar un origen; ninguna de esas pruebas posee la política de cada router remoto. Tener el recurso no es tener todos los caminos que conducen a él.

Fuentes