Resumen

  • Un servidor de rutas de un punto de intercambio actúa sobre el plano de control, pero no debe convertirse en salto de datos. RFC 7947 recomienda que no inserte su AS en AS_PATH y exige conservar el NEXT_HOP del participante que originó el anuncio.
  • El cliente recibe por diseño una ruta cuyo vecino BGP no coincide con el primer AS ni con el siguiente salto. Desactivar la comprobación del primer AS solo es razonable para vecinos de route server verificados y nunca sustituye la política de importación del cliente.
  • La equivalencia se demuestra ruta por ruta: entrada del anunciante, validación, cálculo para cada cliente, Adj-RIB-Out, recepción, selección local, resolución de capa 2 y paquetes. Dos sesiones activas o dos contadores iguales no bastan.

La ruta que desapareció entre dos cifras idénticas

En un laboratorio se conectan tres participantes a dos servidores de rutas con direcciones y números reservados para ejemplos. El participante A anuncia dos caminos hacia un prefijo de prueba. El participante B permite recibir cualquiera de ellos, salvo el preferido por la tabla común del primer servidor. El participante C no aplica esa exclusión.

Ambos servidores mantienen el mismo total de prefijos. En el primero, el proceso elige el camino de A antes de aplicar la regla de B; la regla lo elimina y B no recibe alternativa. En el segundo, existe una vista calculada para B y el camino secundario sí llega. Los paneles de capacidad son iguales, pero el servicio que recibe B es distinto.

Cuando la ruta aparece, su AS_PATH comienza con el AS del participante que la anunció. El ASN del servidor de rutas no figura en el atributo. NEXT_HOP señala la dirección del anunciante en la LAN del intercambio. Los paquetes salen de B directamente hacia ese router. La máquina que entregó el UPDATE no está en el trayecto.

El caso es sintético, pero la contradicción es la esencia del diseño: el servidor puede decidir qué información ofrece sin convertirse en la entidad que transporta el tráfico.

Intermediación no significa tránsito

Un IXP reúne sistemas autónomos sobre una infraestructura de capa 2. Si cada participante establece sesiones bilaterales con todos los demás, el número de relaciones operativas crece con rapidez. El servidor de rutas reduce esa carga: recibe anuncios de muchos miembros y entrega a cada cliente una selección de rutas.

No es un simple colector. Un colector conserva feeds para observación y diagnóstico; el servidor de rutas interviene en la distribución viva. Tampoco es un router de tránsito. Tiene sesiones, tablas y políticas, pero el tráfico entre miembros debe cruzar directamente la infraestructura compartida.

La diferencia determina el significado de AS_PATH. Ese atributo ayuda a describir el recorrido por sistemas autónomos, aplicar políticas y detectar bucles. No pretende enumerar todo proceso que haya inspeccionado un UPDATE. Si el route server añadiera su ASN solo porque habló BGP con el receptor, introduciría un salto que no existe en el camino de datos y podría alterar la selección.

Por eso su autoridad es singular. Puede aceptar o rechazar una ruta, interpretar una instrucción de distribución y elegir un candidato para cada receptor. Es una autoridad sobre la mediación, no sobre el tránsito. Su ausencia en AS_PATH no equivale a ausencia de poder.

La transparencia es una obligación verificable

RFC 4271 describe el comportamiento ordinario de eBGP: al anunciar externamente, el locutor agrega su AS. RFC 7947 adapta esa regla al servidor de rutas y recomienda no anteponer el ASN del broker ni modificar AS_PATH por defecto. La razón es operativa: un AS adicional puede cambiar la preferencia o activar filtros del cliente.

Con NEXT_HOP la regla es aún más clara. Como el servidor no reenvía los paquetes, debe conservar el valor recibido. El cliente aprende así la dirección de otro participante y resuelve ese destino directamente sobre la LAN de peering.

Preservar atributos no convierte al servidor en un tubo inerte. Puede aplicar validaciones de prefijo y origen, políticas de cada cliente, comunidades con significado local o controles contra fugas. La transparencia limita la forma de esa intervención: el resultado no debe fingir que el broker fue un salto de reenvío.

La prueba debe separar dos historias. Los atributos transportan la historia que necesita el plano de encaminamiento. Los registros del servidor documentan quién envió el anuncio, qué regla se ejecutó, cuál fue la vista del receptor y qué UPDATE salió. Ninguna historia está completa sin la otra.

Una excepción que no debe escapar del vecino correcto

Muchos equipos verifican que el AS situado a la izquierda de AS_PATH coincide con el ASN del vecino eBGP. En una sesión bilateral esa comprobación detecta errores útiles. En una sesión transparente con un route server, el primer AS corresponde al participante anunciante y no al broker.

RFC 7947 exige que el cliente pueda desactivar esa verificación y recomienda hacerlo por vecino. La granularidad es el control de seguridad. Las direcciones de los servidores deben proceder de la fuente oficial del IXP y la excepción debe quedar asociada exclusivamente a ellas.

Aplicar enforce-first-as de forma rígida deja la sesión activa pero descarta las rutas. Desactivarlo en una plantilla global debilita relaciones de tránsito y peering que no necesitan la excepción. Ambos extremos convierten una adaptación local en un fallo sistémico.

La relajación tampoco elimina otros límites. B debe seguir comprobando la presencia de su propio AS, filtrar prefijos y orígenes según su política, mantener límites de volumen y decidir qué rutas entran en su Loc-RIB. El servidor construye una oferta; el cliente conserva la decisión final.

La política individual puede ocultar una alternativa válida

Un miembro puede pedir al servidor que anuncie un prefijo a todos menos a un AS, solo a una lista o a nadie. RFC 7948 menciona comunidades, registros de políticas y bases accesibles a clientes como formas de expresar esas decisiones. Los documentos actuales de IXP Manager, AMS-IX y LINX muestran contratos concretos basados en comunidades estándar y Large Communities.

Esos valores no tienen una autoridad universal por sí mismos. Una comunidad es una instrucción dentro del contrato publicado por el operador. La evidencia de ejecución es la ruta que aparece en el Adj-RIB-Out destinado a cada cliente.

El orden de selección crea el problema de path hiding. Si un servidor elige un solo mejor camino global y luego la política de B lo prohíbe, el resultado puede ser una retirada, aunque exista otro camino permitido. La política se respetó literalmente, pero la perspectiva elegida no era la de B.

RFC 7947 describe tablas o vistas de selección por cliente como la solución más portable. También contempla la distribución de varios caminos, incluso con ADD-PATH, con la cautela de que el servidor debería enviarlos sin aceptar de los clientes alternativas inactivas como nuevas fuentes. FRRouting documenta hoy un modelo de Loc-RIB específica para cada cliente; AMS-IX publica el uso de la opción secondary de BIRD para evitar el ocultamiento.

Las declaraciones de producto o configuración son indicios, no resultados. Una prueba válida crea dos caminos, impide el preferido para B y comprueba que el permitido llega con sus atributos exactos.

Conservar NEXT_HOP obliga a validar quién puede nombrarlo

El próximo salto directo evita que el broker reciba tráfico. También permite un abuso: A podría anunciar un prefijo usando como NEXT_HOP la dirección de C. Si el servidor lo distribuye, muchos clientes dirigirían paquetes hacia C.

RFC 7948 recomienda comparar el próximo salto con la interfaz del cliente que anunció la ruta y descartar discrepancias entre sistemas autónomos. Puede existir una excepción para varios routers del mismo AS. IXP Manager documenta un control semejante dentro de su algoritmo de filtrado.

La verificación debe ocurrir donde todavía se conoce con certeza al anunciante: el servidor. Después de agregar rutas de cientos de miembros en una sesión, el receptor no puede reconstruir fácilmente la autorización de cada dirección.

Sin embargo, que el NEXT_HOP sea autorizado no significa que sea alcanzable. Un fallo no transitivo del conmutador puede permitir que B llegue a ambos route servers mientras impide llegar a A. BGP continúa verde, ARP o NDP no resuelve y los paquetes se pierden. Probar únicamente las IP del broker mide el camino equivocado.

Redundancia: comparar decisiones, no cajas

RFC 7948 recomienda varios servidores de rutas. Pueden ejecutarse sobre sistemas operativos o implementaciones distintas para evitar una causa común. Esa independencia solo aporta valor si el resultado comprometido con cada cliente se puede comparar.

Los servidores pueden usar generaciones diferentes de configuración, instantáneas IRR, estados RPKI, tiempos de convergencia o algoritmos de vista por cliente. La misma cantidad de prefijos no detecta que una ruta tenga otro AS_PATH, NEXT_HOP, MED o conjunto de comunidades.

La comprobación correcta calcula una huella por prefijo y cliente sobre los atributos relevantes. Toda diferencia esperada debe tener una explicación y una versión de política asociada. Un cambio se despliega primero en rutas de prueba y no se amplía mientras haya divergencias sin clasificar.

Dos procesos idénticos y opacos pueden compartir el mismo error. Dos programas distintos sin contrato de equivalencia pueden producir servicios incompatibles. La redundancia útil combina independencia de implementación con igualdad observable de la función.

Ocho pasos de evidencia

Para reconstruir una decisión hacen falta registros encadenados:

  1. el Adj-RIB-Out o captura de A demuestra el anuncio original;
  2. el Adj-RIB-In del servidor demuestra lo recibido;
  3. el registro de validación explica aceptación o rechazo;
  4. la vista y versión de política de B explican la selección individual;
  5. el Adj-RIB-Out del servidor muestra lo enviado a B;
  6. el Adj-RIB-In de B muestra lo que atravesó la sesión;
  7. la ruta seleccionada, FIB y estado ARP/NDP muestran el próximo salto programado;
  8. contadores, sondas o capturas demuestran el recorrido de los paquetes.

Una tabla maestra no sustituye la vista de un cliente. Un looking glass rara vez conserva todos los candidatos rechazados. Una configuración deseada no prueba qué versión está en ejecución. Los tiempos y las identidades de generación son esenciales, en especial durante una convergencia.

La responsabilidad sigue la misma secuencia. A responde por lo que origina; el operador del servidor, por validar y ejecutar la distribución; B, por importar y seleccionar; el IXP, por la entrega de capa 2. Cada actor debe demostrar su función con su propio registro.

Migrar mediante pruebas que puedan fallar

La puesta en marcha comienza con el inventario oficial de ASN, direcciones, familias, capacidades y contrato de comunidades de cada servidor. La excepción del primer AS se limita a esos vecinos y se conserva el resto de la política.

Un prefijo de laboratorio se anuncia a ambos servidores. Se verifica en orden: entrada, validación, vista de B, salida, recepción, selección, resolución de MAC y paquetes directos. El resultado esperado incluye un AS_PATH que comienza con el anunciante y un NEXT_HOP que no es la dirección del servidor.

Después se ejercen los límites: anunciar a B y no a C; invertir la decisión; ofrecer dos caminos y excluir el preferido; presentar un NEXT_HOP de otro AS y exigir el rechazo; repetir en IPv4 e IPv6. Los dos servidores se comparan atributo por atributo.

El plan de reversión conserva la versión anterior de ambos lados. Reponer una línea no retira necesariamente rutas aprendidas; puede hacer falta una reevaluación, route refresh o acción controlada de sesión. La elección depende del coste de convergencia y debe evitar reinicios ajenos al cambio.

Fuentes y límites

La base normativa es RFC 7947, comparada con RFC 4271. RFC 7948 aporta recomendaciones operativas sobre redundancia, fugas, capa 2 y secuestro de NEXT_HOP. RFC 7911 y RFC 6774 describen alternativas de varios caminos.

La documentación de FRRouting, BIRD e IXP Manager aporta comportamiento de implementaciones y automatización. AMS-IX y LINX documentan prácticas propias actuales. Ninguna página demuestra por sí sola la configuración en ejecución de un intercambio no identificado; el caso inicial es de laboratorio.