Resumen

  • AMS-IX opera dos servidores de rutas en Ámsterdam bajo AS6777, rs1.ams-ix.net y rs2.ams-ix.net; sumarse implica sesionar con ambos.
  • La norma impone un único comportamiento, entregar el NEXT_HOP sin modificar, y clasifica la preservación de AS_PATH y MED como recomendaciones con un motivo declarado.
  • El único reparto de responsabilidades explícito en la documentación publicada pone la coherencia de la lista de prefijos y el cumplimiento de la configuración en el participante.

Una red que se suma al servidor de rutas de la plaza de Ámsterdam deja de construir una sesión por cada par y construye una sola hacia una máquina que reanuncia lo que anuncian los demás. AMS-IX publica dos: rs1.ams-ix.net en 80.249.208.255 y 2001:7f8:1::a500:6777:1, y rs2.ams-ix.net en 80.249.209.0 y 2001:7f8:1::a500:6777:2, ambos hablando como AS6777. Las condiciones son concretas —conectarse a los dos, anunciar el mismo número y la misma longitud de prefijos en cada sesión, abrir el puerto TCP 179— y la documentación de AMS-IX sobre el servidor de rutas las enuncia sin rodeos.

Lo que esa documentación no hace es comprometer al operador con un conjunto simétrico de garantías. Describe un comportamiento. Las obligaciones que detalla son las del participante.

Lo único que la norma no negocia

RFC 7947 define el servidor de rutas de un punto de intercambio, y su exigencia más firme recae sobre una dirección: «the NEXT_HOP attribute MUST be passed unmodified» (sección 2.2.1, septiembre de 2016). Esa frase explica por qué un servidor de rutas no es un router en ningún sentido que le importe a un paquete. El siguiente salto que ve el cliente es la dirección del par que anuncia sobre la matriz de conmutación; el tráfico cruza la matriz de par a par y jamás pasa por la máquina que habló BGP en su nombre. RFC 7948, el documento de operación publicado el mismo mes, traza la misma frontera: distribuir información de alcanzabilidad no es reenviar tráfico.

Todo lo demás en la sección de atributos es más blando, y a propósito. El servidor de rutas «SHOULD NOT prepend its own AS number» a lo que retransmite (sección 2.2.2.1). Propaga el MULTI_EXIT_DISC y «SHOULD NOT modify its value» (sección 2.2.3). La sección 2.2 fija la transparencia de atributos como comportamiento por defecto y al mismo tiempo permite excepciones explícitas cuando la configuración local lo justifica; la sección 2.1 admite el filtrado por política sin más.

El RFC da su razón para detenerse en SHOULD y no en MUST con el AS_PATH: existe una base instalada de clientes antiguos que rechaza una sesión cuyo primer AS es inesperado, y una regla imperativa los habría dejado fuera. Por eso la norma exige a las implementaciones permitir desactivar la comprobación del primer AS, preferiblemente por par, en lugar de asumir la garantía más dura. Es un compromiso de ingeniería vestido de nivel de exigencia, y le importa a quien creía que la plaza había aceptado el deber absoluto de no tocar sus atributos de ruta.

Lo que el operador sí pone por escrito

AMS-IX publica su mitad del arreglo. No inserta AS6777 en los AS_PATH de las rutas que retransmite, y las comprobaciones del primer AS deben desactivarse donde correspondan. Los pares de exportación se eligen mediante entradas RPSL y comunidades: la comunidad 0:6777 bloquea toda exportación, 6777: habilita un par concreto, y las sesiones nuevas pasan por defecto a un filtrado combinado de IRRDB y RPKI. Las rutas aprendidas pueden servir al participante y a sus clientes aguas abajo, pero redistribuirlas a tránsitos, pares externos o al servidor de rutas de otro punto de intercambio está prohibido.

Dos frases de ese texto merecen una segunda lectura. La primera advierte que los datos de IRRDB y RPKI no llevan garantía de validez y no deben usarse en solitario: es la descripción del propio operador sobre el filtrado que aplica por defecto. La segunda es la cláusula de responsabilidad: «Participants are responsible for ensuring that their routing configuration complies with this policy.»

RFC 7948 ya había llegado al mismo reparto. Describe la responsabilidad del cliente de asegurar que su lista declarada de prefijos sea compatible con lo que anuncia (sección 4.3), recomienda mitigación de fugas del lado del operador y pide comparación automatizada entre las rutas recibidas y las listas configuradas allí donde exista filtrado entrante por cliente. El papel que dibujan los documentos es administrativo antes que tutelar: el servidor de rutas filtra, selecciona y reanuncia, el operador publica lo que hace, y nadie asume un deber de verificación enumerado hacia cada participante concreto.

Lo que esperaba encontrar y lo que dice el texto

Iba buscando un trato documentado: una sesión hacia cada miembro a cambio de una lista publicada de lo que la plaza te debe. Los documentos solo cubren la primera mitad. El trato es real —el número de sesiones se desploma de verdad— pero se paga en exposición y no en niveles de servicio. Un MUST categórico mantiene los paquetes fuera del hablante compartido. Dos SHOULD, un argumento de compatibilidad y una puerta abierta a la configuración local dejan libres las manos del operador sobre la ruta y el MED.

Así que la lectura útil no es que AMS-IX descuide su servidor de rutas. Es que el conjunto está diseñado como un administrador con mandato acotado: autorizado a tomar decisiones de plano de control, prohibido de reenviar un solo paquete, y responsable sobre todo mediante texto publicado. Ese encuadre es mío, no del IETF ni de la plaza, y ninguna posición formal lo enuncia.

Lo que un participante puede comprobar de verdad

La ficha de directorio de este servidor de rutas reúne los mismos hechos publicados en un solo lugar, y el problema de verificación está justo en lo que esos hechos dejan abierto. Un participante no puede auditar la conformidad interna del hablante compartido leyendo una página de política. Lo que sí puede es leer las rutas que recibe y confirmar que el siguiente salto que ve es el par y no el servidor de rutas. Puede observar si 0:6777 y 6777: producen la exportación prometida. Puede mantener ambas sesiones y comparar qué envía cada servidor, de modo que una divergencia aparezca como divergencia y no como un misterio.

La documentación no lleva fecha en su versión publicada, se consultó el 12 de noviembre de 2026 y su vigencia en la fecha de publicación no está confirmada. El comportamiento en producción no se probó aquí, y la página examinada no establece que los valores por defecto de filtrado y las comunidades de exportación se comporten igual en rs1 y rs2. Se localizó una sola cláusula de responsabilidad explícita, referida a la coherencia de la lista de prefijos; la ausencia de una garantía más amplia del operador en esa página es una observación sobre esa página, no la prueba de que tal texto no exista en otro lugar.

El resumen honesto del intercambio

Un servidor de rutas habla, no transporta, y el papeleo tiene esa misma forma: una promesa incondicional que mantiene el tráfico fuera de la caja, y dos promesas condicionales que dejan a la plaza las manos libres sobre los atributos que lo orientan. Una red que necesite más garantías no las encontrará en el texto de política. Las encontrará, o no, en sus propias rutas recibidas: exactamente donde los documentos ya sitúan la responsabilidad.