Resumen

  • Maximum-prefix limita una cantidad de estado de enrutamiento; no certifica que la ruta que cruza el umbral sea inválida. Si la acción es derribar la sesión, una ruta adicional puede retirar todas las aprendidas por ese vecino.
  • El control debe definirse por relación y familia de direcciones, distinguir prefijos recibidos de aceptados, calcular margen con crecimiento observado, escoger una respuesta proporcional y demostrar el resultado en la RIB, la FIB y el tráfico.

El cortacircuitos no conoce el valor de cada ruta

Un cortacircuitos eléctrico no decide qué aparato merece energía. Observa una condición agregada y abre el circuito para protegerlo. Maximum-prefix funciona de forma parecida cuando está asociado al cierre de una sesión BGP: observa un conteo y, al superar la frontera, interrumpe el canal completo.

La analogía ayuda a separar causa y legitimidad. La actualización que mueve el contador de N a N+1 puede ser una ruta perfectamente autorizada. Lo decisivo no es su contenido, sino que el receptor había convertido un presupuesto cuantitativo en permiso para terminar la relación. Al caer la sesión, las primeras N rutas pierden también su fuente; algunas encontrarán reemplazo, otras elegirán un camino peor y otras desaparecerán de la tabla de reenvío.

La protección sigue siendo necesaria. Una exportación accidental de tabla completa o una desagregación masiva puede consumir memoria, prolongar la convergencia y afectar la capacidad de respuesta del proceso. Pero el mecanismo solo es prudente si la organización entiende su radio de impacto. Un límite de recursos no debería presentarse como un veredicto sobre la última ruta.

Las opciones que deja el estándar

RFC 4271 permite que un hablante BGP configure un máximo local para los prefijos aceptados de un vecino. Al alcanzar la cota, puede descartar nuevos prefijos y mantener la conexión, o terminar la conexión BGP. Si termina porque se superó el máximo, debe enviar una notificación Cease.

RFC 4486 define el subcódigo 1 de Cease, Maximum Number of Prefixes Reached. La notificación puede incluir AFI, SAFI y el límite de cuatro octetos. Esa información separa una decisión de volumen de otras causas de cierre y permite reconstruir qué familia y frontera se ejecutaron.

El estándar no conoce la relación comercial ni la capacidad del receptor. Un cliente con un conjunto pequeño, un peer con una vista parcial y un tránsito que entrega rutas completas requieren presupuestos distintos. Tampoco conoce la diversidad de caminos ni el tráfico que quedará expuesto. El número y la acción son locales, por lo que la prueba y la responsabilidad también lo son.

Cantidad y validez son preguntas diferentes

Una tabla por debajo del límite puede contener una fuga, un origen inválido o una ruta incompatible con la relación. Una tabla por encima puede reflejar clientes nuevos, una migración, desagregación legítima durante una incidencia o una modificación de agregación aprobada.

Los filtros de prefijos, la política de AS_PATH, la validación de origen RPKI, las reglas de next hop y las comunidades evalúan características de cada ruta. Maximum-prefix mide volumen. Ambos tipos de control se necesitan porque las rutas válidas consumen recursos y una cantidad pequeña puede seguir siendo incorrecta. Lo que no pueden hacer es sustituirse.

Llamar seguridad al límite exige nombrar el recurso protegido. Puede defender memoria, tiempo de convergencia o capacidad de procesamiento frente a una carga inesperada. No autentica la intención del emisor, no demuestra que el anuncio final sea dañino y no garantiza que el conjunto restante sea correcto. Confundir el contador con un detector de abuso produce diagnósticos sin evidencia.

Antes o después de la política

Dos equipos con el mismo valor configurado pueden vigilar fronteras distintas.

La documentación BGP de FRRouting indica que maximum-prefix cuenta por defecto los prefijos aceptados. Con force incorpora también los recibidos que la política de entrada rechaza, y necesita conservar el estado de entrada correspondiente. FRRouting advierte además que destruir la sesión es mucho más perjudicial que rechazar rutas no deseadas.

Junos ofrece dos mandos separados. prefix-limit opera sobre prefijos recibidos; accepted-prefix-limit sobre los que pasan la política. Las acciones documentadas incluyen cerrar, descartar el exceso u ocultarlo, con estados residuales y mecanismos de recuperación diferentes.

El conteo previo a política muestra la carga que el vecino intentó entregar. Puede detectar una tabla completa aunque los filtros fueran a rechazarla, pero también puede cerrar una sesión por rutas que nunca habrían sido utilizables. El conteo posterior se acerca al estado realmente admitido, aunque un filtro fuerte puede ocultar la magnitud de la entrada procesada.

También importa si la implementación cuenta destinos únicos o caminos. ADD-PATH, familias VPN y estructuras internas pueden mantener varias rutas para un mismo prefijo. El operador debe consultar el comportamiento de la versión desplegada. Copiar un número entre plataformas sin copiar su definición crea una falsa equivalencia.

Elegir el fallo que se está dispuesto a soportar

Avisar mantiene sesión y rutas. Ofrece tiempo para investigar, pero no contiene el crecimiento. Si la alerta no llega, nadie la posee o el margen se consume antes de responder, el mecanismo solo registra el acercamiento al límite.

Descartar el exceso conserva la sesión y el estado anterior. Reduce el impacto total, aunque deja una vista parcial posiblemente dependiente del orden de llegada. Cuando baja el conteo, puede ser necesario solicitar un route refresh o reevaluar la política para recuperar lo que fue excluido.

Ocultar el exceso retiene información sin permitir selección normal. Puede simplificar la recuperación, pero mantener ese estado consume recursos. Si la finalidad era proteger memoria, hay que comprobar si la implementación cumple de verdad el objetivo.

Cerrar corta la fuente y limita su aportación futura. Al mismo tiempo retira todo camino cuyo único origen era esa sesión. El tráfico migra a alternativas que pueden tener menos capacidad, mayor latencia o ninguna cobertura para ciertos destinos.

Las etiquetas de fabricante no garantizan resultados idénticos. Cisco documenta porcentaje de aviso, cierre predeterminado, modo de solo aviso y reinicio temporizado. Arista EOS describe un máximo que puede deshabilitar el peering, mientras una opción de aviso puede mantenerlo y descartar rutas posteriores. La comparación correcta se hace sobre el estado que queda, no sobre el nombre del mando.

El contrato operativo produce el número

RFC 7454 recomienda límites específicos para cada peering. En una relación que solo debería anunciar un conjunto limitado, una cifra inferior a la tabla completa puede detectar la exportación accidental de toda ella. Para un upstream que sí debe entregar rutas completas, el techo debe superar el tamaño esperado sin rebasar la capacidad segura del receptor.

El cálculo parte del conjunto legítimo de la relación. Añade variación observada, crecimiento plausible, altas de clientes, desagregaciones previstas y migraciones. Después contrasta esa proyección con la plataforma y con el coste de la acción elegida. El resultado necesita dueño, fecha de revisión y vía de cambio urgente.

RFC 4778 recomienda coordinar la cantidad esperada y añadir margen para oscilaciones válidas. Una protección desconocida por la contraparte puede convertir un cambio autorizado en interrupción. RFC 7454 exige además revisar periódicamente los límites porque la población de rutas cambia.

El margen se entiende mejor como tiempo disponible y variación cubierta que como porcentaje copiado. La misma proporción puede equivaler a años en una relación estable o a días durante una expansión. Un margen mínimo provoca falsos incidentes; uno excesivo vuelve decorativa la frontera. La meta es conservar tiempo para decidir sin aceptar una carga que el equipo no soporte.

Un temporizador no corrige la causa

El reinicio automático puede recuperar rápido una sesión si el exceso fue transitorio y el emisor ya lo retiró. Si nada cambió, automatiza un ciclo: establecer, recibir el mismo conjunto, superar, cerrar y esperar.

El paso del tiempo no demuestra reparación. Para reabrir con fundamento debería existir una condición nueva: retirada del exceso, política corregida, incremento aprobado o capacidad ampliada. Un clear manual sin ese soporte no es más seguro; simplemente cambia quién pulsa el reintento.

RFC 8538 sugiere tratar el Cease por maximum-prefix como hard reset en el contexto de Graceful Restart. La retención silenciosa de rutas obsoletas no debería ocultar que el receptor ejecutó deliberadamente una política de volumen.

Del contador a los paquetes

La evidencia comienza con la configuración efectiva por vecino y AFI/SAFI, incluidas herencias, niveles de aviso y acción. Debe registrar la versión de software y la definición documentada de recibido frente a aceptado, además de prefijo frente a camino cuando corresponda.

Durante el evento se conservan la última actualización admitida, el cruce del contador, código y subcódigo Cease, datos AFI/SAFI/límite, estado de sesión, temporizadores y logs posiblemente limitados. Hay que distinguir rutas retiradas, descartadas, ocultas y retenidas.

Después se sigue la reachability. ¿Qué destinos cambiaron de mejor camino? ¿Las alternativas aparecieron en la RIB y se instalaron en la FIB? ¿Los enlaces que recibieron el tráfico tenían capacidad? ¿Las sondas de paquetes hacia clases críticas tuvieron éxito? Recuperar el mismo total no prueba que sean los mismos prefijos ni los mismos atributos.

El límite cumple su propósito solo cuando la capacidad protegida permanece dentro del objetivo y el servicio resultante coincide con el compromiso aprobado. El contador por sí solo no demuestra ninguna de las dos cosas.

Fuentes