Resumen

  • Breizh-IX afirma que rehace cada noche listas estrictas de prefijos, comprueba autorizaciones RPKI y respeta el indicador de PeeringDB «Never via route servers». Sus ponentes en RIPE 93 separan además la coherencia del número de rutas y la voluntad de que un anuncio se reenvíe.
  • PeeringDB llama a su indicador una pista que debe ser recogida y aplicada por el punto de intercambio. El clic del cliente y la política efectiva del servidor requieren una conexión comprobable.

Una lista de invitados no es una orden de abrir la puerta

El filtro reconoce una ruta. Excelente. Ahora falta saber si el miembro quiere que el servidor la ofrezca a los demás. Esa segunda frase suele desaparecer detrás de la primera, porque ambas viven cerca de las mismas bases de datos. Pero describen actos distintos: qué prefijos pueden corresponder a un AS, cuántos entran en un anuncio razonable y a quién ha autorizado el miembro a repartirlo.

El resumen original de RS-API en RIPE 93, firmado por Evann Dreumont y Alarig Le Lay de Breizh-IX para el 28 de octubre, enumera esas tres comprobaciones. La búsqueda en IRR verifica si la ruta cae dentro del AS-SET del cliente. Un control de volumen debe detectar conjuntos que, por anidación, pueden arrastrar una porción enorme de la tabla global. Después viene la pregunta política y operativa: ¿quiere el cliente que el servidor de rutas lo vuelva a anunciar? La respuesta no está escondida en la sintaxis del AS-SET.

La diferencia tiene alcance. RFC 7947 describe el servidor de rutas de un intercambio como intermediario de información BGP entre tres o más participantes. Ahorra sesiones bilaterales y concentra la distribución en un mismo punto. Por eso una decisión equivocada no queda encerrada en el expediente de un cliente: puede propagarse por la lista de pares a los que el servidor exporta. El estándar contempla políticas por cliente. El operador debe convertir la preferencia del cliente en una de esas políticas.

El expediente de Breizh-IX tiene controles concretos

En su propio sitio, la asociación sin ánimo de lucro de Rennes dice que genera listas de prefijos cada noche con bgpq4 en modo estricto; un prefijo sin objeto route se rechaza. También declara comprobaciones de ROA con RPKI de los RIR, del atributo OTC y del registro ASPA en el segundo servidor. Añade que respeta el campo «Never via route servers» de PeeringDB. Son controles que la entidad atribuye a su operación actual. La ponencia propone RS-API para reunir y confrontar entradas que hoy exigen trabajo repetido.

La FAQ oficial de PeeringDB da una instrucción incómodamente precisa. Su campo info_never_via_route_servers es una pista. El intercambio debe comprobar con frecuencia ese dato y honrarlo. Un perfil puede registrar el rechazo del miembro a anunciar por servidores; la base de datos no cambia por sí misma la configuración BGP de Breizh-IX. Entre una pantalla y otra hay un operador, un calendario y un archivo de política.

Imaginemos una actualización de preferencia a mediodía. La regeneración nocturna de listas IRR no demuestra cuándo se descargó el nuevo valor de PeeringDB ni cuándo llegó a ambos servidores. No se ha documentado aquí un fallo real de Breizh-IX. El ejemplo revela qué comprobación falta en un sistema auditable: hora de modificación, hora de lectura, versión de configuración y anuncios emitidos después. Un cliente que marca una exclusión necesita conocer su momento efectivo, no solamente recibir un acuse de la base.

El control numérico tampoco se resuelve con un número bonito. Un AS-SET puede contener otro que multiplica los prefijos de forma inesperada; un límite demasiado alto deja pasar el exceso. El resumen de la charla afirma que RS-API busca contrastar la información declarada con la situación operativa mediante un proxy. No publica código ni resultados de producción. Sería inventar una mejora medida. Sí permite exigir que la futura automatización muestre qué expansión causó cada lista y qué umbral se eligió.

Una ruta necesita la historia de su decisión

El recibo útil reúne cuatro relojes: edición del AS-SET, actualización de la preferencia del miembro, generación del filtro y activación en el servidor. Junto a ellos deben aparecer el tamaño de la expansión, el límite empleado y los pares a los que se ofreció el anuncio. Así un rechazo no se confunde con un problema de origen y una aceptación puede responder a la pregunta fundamental: quién autorizó el reparto.

Los documentos revisados no fijan la regla de RS-API cuando el dato de permiso falta o llega tarde. Una regla pública para ese caso, seguida de una traza verificable, cambiaría el juicio. Hasta entonces, la lista de prefijos puede ser impecable y el mandato de distribución seguir siendo opaco.

Fuentes