Resumen

  • RFC 2439 hizo de la inestabilidad un estado local: los retiros elevaban la figura de mérito de una ruta, la decadencia exponencial la reducía y dos umbrales separados determinaban cuándo dejar de usarla y cuándo volver a aceptarla.
  • La experiencia posterior mostró que ese recuerdo podía penalizar un prefijo bien conectado durante una convergencia ordinaria. RFC 7196 no abolió el damping; recomendó umbrales más prudentes y un modo opcional de calcular sin suprimir.

Cuando el pasado de la ruta empezó a contar

En la década de 1990, los mensajes BGP no solo describían destinos alcanzables: su volumen consumía procesamiento en el router receptor y en los pares que recibían anuncios propagados. RFC 2439 propuso reducir los cambios repetidos sin alargar la convergencia de rutas relativamente estables. Era un documento Standards Track y señaló que ya había implementaciones comerciales en el momento de su publicación, en 1998. Esa afirmación habla de aquella época, no de la configuración actual. RFC 2439 Registro de RFC 2439

La innovación consistió en conservar algo más que el último UPDATE. Un router que recibía una ruta de un par externo podía mantener una figura de mérito asociada a su identidad. Cada transición de alcanzable a inalcanzable añadía penalización. Mientras la ruta permanecía estable, una función exponencial reducía el valor acumulado. La puntuación no diagnosticaba un cable roto ni una mala intención del par: representaba los cambios observados recientemente por un router e influía en si este usaría o anunciaría ese camino. RFC 2439

Así se abrió un intervalo entre recuperar alcance y recuperar elegibilidad. El umbral de supresión decidía cuándo retener la ruta; un umbral inferior de reutilización indicaba cuándo podía regresar al uso. Un tiempo máximo de retención limitaba la supresión. Alcanzabilidad, puntuación acumulada, estado de supresión y selección de mejor ruta estaban relacionados, pero no eran el mismo dato. Un par podía anunciar de nuevo una ruta que el receptor todavía mantenía suprimida. RFC 2439

Una memoria con umbrales, no un temporizador universal

RFC 2439 contrastó el damping sensible a la estabilidad con la limitación basada en temporizadores. El Minimum Route Advertisement Interval de BGP dosifica anuncios; el damping depende de la historia específica de cambios de una ruta. Mientras la puntuación no llega al umbral de corte, la ruta puede seguir utilizándose. Una vez suprimida, no vuelve hasta que su penalización decreciente cruza el umbral de reutilización. Por tanto, dos rutas recién cambiadas no reciben necesariamente la misma espera. RFC 2439 BGP-4

Los parámetros regulan efectos diferentes. La semivida determina cuánto tarda en caer la puntuación cuando la ruta está disponible; el comportamiento durante la indisponibilidad puede tener otra tasa o carecer de decadencia. Un umbral de supresión alto tolera más cambios. Un umbral de reutilización bajo exige más estabilidad antes del retorno. En el ejemplo de RFC 2439, dos o tres retiros podían bastar para suprimir una ruta, que luego necesitaba aproximadamente entre una vez y media y dos veces y media la semivida de estabilidad anunciada antes de reutilizarse. Es un resultado bajo supuestos concretos, no una promesa para todos los routers. RFC 2439

El documento también delimitó el punto de aplicación: damping de actualizaciones recibidas desde pares externos. Advirtió que aplicarlo a rutas aprendidas por iBGP o después de la selección podía provocar bucles. Propuso identificar una ruta al menos por NLRI y, por defecto, por AS_PATH. Penalizar solo el prefijo no equivale a penalizar un camino específico hacia él. RFC 2439

La implementación determinaba quién asumía el coste

La revisión operativa RFC 4277, publicada en 2006, dijo que las implementaciones entonces examinadas no conservaban el historial por NLRI o AS_PATH único, pese al requisito de RFC 2439. En una red densamente mallada, esa omisión podía suprimir un destino con excesiva agresividad, en el peor caso después de un solo fallo; la revisión indicó que se habían observado esos efectos. Es un hallazgo atribuido a ese informe, no una generalización sobre todos los routers. RFC 4277 también trató por separado el damping de sesiones de pares con errores persistentes, que no es el damping de rutas individuales. RFC 4277 RFC 2439

En 2014, RFC 7196 describió otro coste: una topología rica en caminos puede intercambiar más UPDATE durante una convergencia normal y penalizar justo a un prefijo bien conectado. En el estudio semanal citado, elevar el umbral a 6.000 redujo en 90 % los prefijos suprimidos frente a 2.000 y produjo una reducción estimada del 19 % en la tasa de UPDATE frente a no usar damping. Con 12.000, el estudio informó que se suprimió 0,22 % de los prefijos y que la tasa horaria media bajó 11 %. Son mediciones de ese estudio, no predicciones universales. RFC 7196

RFC 7196 recomendó al menos 6.000 para una política menos destructiva pero todavía algo agresiva, y 12.000 para una más conservadora. También pidió no cambiar los valores configurables existentes por defecto, para no romper operaciones. Permitió además un modo de prueba que calcula qué rutas resultarían suprimidas sin bloquearlas. La respuesta de 2014 fue calibrar y observar, no declarar que el damping siempre perjudica o que existe un valor adecuado para cualquier topología. RFC 7196

La historia no es un paso simple de «damping activado» a «damping desactivado». RFC 2439 quiso contener el churn haciendo que el pasado pesara sobre el uso inmediato; RFC 4277 mostró que la identidad de ruta guardada por la implementación podía ampliar esa penalización; RFC 7196 trató la convergencia normal y la buena conectividad como costes que debían medirse antes de suprimir. Una puntuación de damping no demuestra una avería física, un origen malicioso ni una interrupción general del servicio. RFC 2439 RFC 4277 RFC 7196 Principios de diseño de enrutamiento escalable Registro Datatracker de RFC 2439

Fuentes