Resumen

  • Una agregación crea un prefijo menos específico a partir de varias rutas más específicas. RFC 9774 retira AS_SET del funcionamiento normal; ATOMIC_AGGREGATE declara que el AS_PATH perdió datos y AGGREGATOR identifica al último speaker que produjo el resumen.
  • Que el agregado esté presente, el ROA sea válido y la sesión siga Established no demuestra que funcionen todos los destinos cubiertos. El descarte local puede ser la respuesta correcta para un componente desaparecido mientras el plano público no cambia.
  • La dirección debe permitir la compresión sólo con un origin AS elegido, filtros por contribuyente, evidencia anterior al resumen, comprobación RIB/FIB y de paquetes, y una reversión que recupere todo el contrato operativo.

El turno nocturno activa 203.0.112.0/22. Cuatro clientes aportan sendos /24; AS 64505 quiere anunciar una sola ruta a sus upstreams. La política suprime detalles innecesarios, un ROA autoriza el origen del /22 y el UPDATE contiene ATOMIC_AGGREGATE y AGGREGATOR.

Menos de una hora después desaparece 203.0.114.0/24. Los otros tres componentes siguen presentes y el software conserva el resumen. Los monitores externos no ven withdrawal, RPKI-ROV devuelve Valid, el BGP está Established y la FIB conserva el /22.

Una sonda hacia el bloque ausente llega a 64505, no encuentra un prefijo más largo y termina en el descarte del agregado. Esa ruta nula está haciendo su trabajo: evita que el tráfico salga por otra ruta menos específica y regrese formando un bucle. Pero también revela una indisponibilidad que el indicador “aggregate up” había borrado.

El episodio es sintético. La tensión es real. El protocolo permite publicar una afirmación mínima sobre un conjunto de direcciones aun cuando el camino anunciado ya no pueda enumerar todos los recorridos usados para formarla.

El resumen no es una abreviatura visual

BGP construye una ruta nueva. Combina destinos más específicos en una NLRI menos específica y le asigna atributos, reglas de activación y política de exportación propios. La estabilidad de esa nueva ruta puede ser deliberadamente distinta de la de sus componentes.

El procedimiento original de RFC 4271 conservaba la secuencia inicial más larga común a todos los AS_PATH. Los números restantes podían ir en AS_SET, una colección sin orden. El set preservaba parte de la participación y ayudaba a detectar bucles, pero no decía en qué orden se atravesaron los AS y podía dejar indeterminado el origin AS.

RFC 6472 recomendó abandonar AS_SET y AS_CONFED_SET. RFC 9774, de mayo de 2025, convirtió esa recomendación en regla de estándares: salvo una excepción configurada explícitamente durante una transición, no deben anunciarse esos segmentos y una ruta recibida que los incluya debe tratarse como retirada.

No se prohibió resumir. Se exigió una forma menos ambigua de hacerlo. La pérdida de detalle ya no se oculta dentro de un conjunto desordenado; se reconoce, se atribuye el acto de agregación y se estabiliza el origen mediante política.

ATOMIC_AGGREGATE marca un límite de conocimiento

ATOMIC_AGGREGATE es el atributo tipo 6. Es conocido, discrecional y tiene longitud cero. No contiene los AS omitidos, ni una copia de los contribuyentes, ni una firma. Sólo comunica una propiedad: el camino real hacia un destino puede incluir AS que no aparecen en el AS_PATH mostrado.

Cuando al formar el resumen se descarta el AS_SET y con él números presentes en las rutas fuente, el agregado debería llevar la marca. El receptor debería conservarla al propagar y no puede fabricar anuncios más específicos a partir de esa NLRI. Si un componente ya estaba marcado, la agregación posterior debe heredar el atributo.

Por eso no es un sello de aprobación. No dice que la ruta sea segura, completa, autorizada o alcanzable. Tampoco permite reconstruir lo perdido. Es una confesión protocolaria de que la representación pública no basta para auditar la realidad anterior.

La lectura institucional es importante. El resumen cumple una función coordinadora porque limita lo que otros necesitan procesar. Ese beneficio no convierte al resumen en dueño de los hechos descartados. Cuanto más fina sea la afirmación pública, más disciplinado debe ser el registro local.

AGGREGATOR identifica al último autor, no toda la historia

AGGREGATOR, tipo 7, es opcional y transitivo. El speaker que forma el resumen puede incluir su AS y una dirección IP, normalmente su BGP Identifier. RFC 9774 pide incluirlo junto con ATOMIC_AGGREGATE en la agregación consistent brief.

La pareja separa pérdida y autoría. Uno avisa que faltan datos de camino; el otro identifica quién formó el agregado representado. No conserva todos los pasos anteriores. De hecho, los valores AGGREGATOR de las rutas contribuyentes no se copian simplemente a la nueva ruta.

Tampoco autentica. Que un collector muestre 64505 y una dirección no demuestra control jurídico o técnico del prefijo, policy correcta ni conservación de fuentes. La compatibilidad de cuatro octetos —AGGREGATOR de ocho octetos entre speakers modernos o AS_TRANS con AS4_AGGREGATOR frente a equipos antiguos— preserva el número, no su credibilidad.

RFC 7606 usa attribute discard ante un ATOMIC_AGGREGATE o AGGREGATOR mal formado. Así se evita reiniciar toda la sesión, pero una ruta puede sobrevivir sin la advertencia o sin la atribución. El evento de error debe quedar en telemetría aunque el control plane siga verde.

Un origen no puede ser producto del azar

La agregación brief conserva la secuencia inicial común y elimina el resto. El resultado depende de qué rutas estén activas. Si dos componentes llegan por AS distintos, la secuencia común puede quedar vacía. Si uno desaparece, el único camino restante puede colocar otro AS en la posición de origen.

Eso convierte la disponibilidad de un peer en una decisión involuntaria sobre autoridad visible. Además complica RPKI-ROV: el titular tendría que autorizar todos los orígenes que el conjunto cambiante pudiera producir.

La agregación consistent brief resuelve el problema truncando AS_PATH después de la aparición más a la derecha de un origin AS elegido. Puede ser el propio AS agregador. Después, el ROA del prefijo debe autorizar ese AS. La responsabilidad deja de depender del orden en que aparecen los contribuyentes.

No confundamos esa identidad con el atributo ORIGIN. El primero es el AS derecho del camino usado por la validación de origen. El segundo expresa IGP, EGP o INCOMPLETE y, al agregarse, hereda la categoría menos favorable de las fuentes. Tampoco confundamos Valid con entregado: el ROA autoriza origen y prefijo, no AS_PATH completo, AGGREGATOR, NEXT_HOP, FIB ni tráfico.

Al quitar AS_SET, el control de bucles cambia de lugar

El AS_SET desordenado podía contener el número de un contribuyente. Si el agregado regresaba a ese AS, el control de bucles podía rechazarlo. Sin el set, esa memoria desaparece del camino.

RFC 9774 indica que el resumen no debería anunciarse a los AS contribuyentes. Cada uno recibe los otros específicos apropiados, excluyendo lo aprendido de sí mismo. La prevención depende ahora de una policy por vecino y por dirección. Hace falta saber quién aportó qué y actualizar el mapa cada vez que cambie la relación.

En forwarding existe otra obligación. RFC 4632 exige que el router generador descarte los paquetes cubiertos por el agregado que no coincidan con ninguna ruta más específica alcanzable. Una ruta null suele materializarla. Si falta, el paquete puede seguir un default, salir y volver bajo el resumen hasta formar un bucle.

El descarte demuestra contención, no servicio. Un paquete que cae allí confirma que el guardarraíl existe y que el destino carece de contribuyente activo. El centro de operaciones debe registrar ambas cosas sin convertir la primera en excusa para negar la segunda.

La prueba debe sobrevivir a la compresión

Un collector externo observa el resultado final. No ve las rutas rechazadas antes de la policy, los contribuyentes silenciosos ni los AS omitidos. ATOMIC_AGGREGATE precisamente declara que esa reconstrucción no es posible desde el UPDATE.

El ledger local debe incluir, para cada resumen, prefijos esperados, peer de origen, Adj-RIB-In antes de policy, rutas aceptadas, secuencia común calculada, origin AS decidido, estado ROA, versión de configuración y speaker agregador. Después debe registrar Loc-RIB, Adj-RIB-Out antes y después de policy, atributos, NEXT_HOP, ORIGIN y supresión de específicos.

La prueba continúa en RIB, FIB y paquetes. Compruebe el discard en software y hardware. Sondee un destino de cada contribuyente activo y otro de un componente deliberadamente ausente. Etiquete como estados distintos la entrega y el rechazo local esperado.

También separe cuatro alarmas: contribuyente presente; contribuyente ausente con resumen legítimo; resumen ausente; resumen presente sin descarte. La última es crítica: ofrece continuidad pública sin la propiedad que impide el bucle.

Canary y rollback son parte del diseño

Cambiar el agregado modifica NLRI, activación, origen, ROA, advertencia, autoría, filtros, supresión y descarte. Una prueba que mira sólo el anuncio no ha probado la operación.

El canary debe confirmar un caso positivo y uno negativo. Un /24 activo entrega tráfico. Al retirar un contribuyente de prueba, una dirección de ese componente termina dentro del AS agregador y no escapa hacia un peer. Al mismo tiempo se capturan AS_PATH, ATOMIC_AGGREGATE, AGGREGATOR, estado de origen y anuncios más específicos.

El rollback restaura como una unidad la importación de contribuyentes, la supresión, la generación del resumen, el origen, el ROA, los filtros de salida y la ruta null. Volver a escribir un comando sin devolver la reachability anterior no es rollback.