Construye el borde EVPN alrededor de la política de exportación, no de las conexiones

La suposición habitual es que el modelo de conexión Layer 2 en el borde determina todo lo que hay encima, así que el diseño empieza con un par vPC y sube. Normalmente acaba con decisiones de encaminamiento tomadas por accidente. Un borde EVPN es primero un límite de encaminamiento: un contexto de encaminamiento de inquilino se encuentra con un dominio de encaminamiento externo, y lo que cruza esa línea es una declaración de política. Elige las rutas, la relación ASN y los caminos de fallo antes de que nadie discuta sobre port-channels. El modelo de conexión pasa después a derivarse de un requisito en lugar de dictarlo.

Empieza por lo que cruza el borde

Escribe las rutas que deben ser visibles en cada lado, la dirección en la que viajan y quién aprueba un cambio en esa lista. Un borde que acepta todo y anuncia todo no tiene política, solo un cable.

Después nombra el fallo que pretendes operar: un uplink caído, un border leaf caído o todo el dominio externo inalcanzable. Cada respuesta cambia si necesitas dos vecinos independientes, una conexión Layer 2 compartida o ambas.

Solo cuando existen esas dos listas la pregunta de la conexión se vuelve respondible. Antes de eso, todos los mecanismos parecen igual de válidos. Después, la mayoría se descartan solos. Ese es todo el argumento para hacer primero el trabajo de encaminamiento.

Fija el límite de ASN y peering

Una fábrica con AS privadas suele hacer peering con el dominio de borde público mediante eBGP, y la parte interesante es la política en ambos lados. Decide qué prefijos se aceptan, cuáles se anuncian y qué AS path debe recibir el upstream.

RFC 6996 reserva un rango de ASN de uso privado, y esos ASN no deberían aparecer en anuncios globales. Aplica la política de eliminación o filtrado que admite la plataforma y verifica el anuncio resultante en lugar de suponer que el dispositivo lo hizo. Ese paso tampoco te da autoridad para anunciar un prefijo público arbitrario, eso es una conversación aparte con el propietario de la dirección.

Una confederación o una función local-AS es una decisión de diseño para una topología concreta. Ninguna es obligatoria solo porque la fábrica y el upstream usen roles ASN distintos, y adoptar una sin el requisito añade piezas móviles a cada cambio futuro.

Los uplinks Layer 3 no necesitan multichassis LAG

Las interfaces enrutadas independientes con sus propios vecinos BGP dan dos caminos claros y dos dominios de fallo claros. vPC u otro multichassis LAG sirve a un requisito de conexión Layer 2, y es la herramienta correcta cuando ese requisito existe.

Una regla general de que cada par de borde debe usar vPC, o debe evitarlo, oculta las condiciones que realmente deciden el caso. Pregunta qué tiene que transportar la conexión y luego elige el mecanismo que lo transporta con menos modos de fallo compartidos.

La política de encaminamiento que escribiste primero no cambia cuando cambia el mecanismo de conexión, lo que es buena señal de que el orden era correcto.

Exporta solo lo que el inquilino necesita

Un inquilino puede necesitar una ruta por defecto, un conjunto de prefijos externos seleccionados o una tabla mucho mayor. Elige ese alcance según la capacidad real de reenvío y de plano de control, no según un recuento antiguo de rutas de internet que nadie ha vuelto a medir.

La ruta EVPN IP Prefix, llamada habitualmente Type 5 y definida en RFC 9136, transporta información de prefijo en el overlay. La implementación sigue necesitando política de exportación e importación coincidente más resolución de next-hop, así que recibir una ruta BGP externa en el borde no significa que cada VRF de inquilino la importe.

No todos los leaf necesitan la tabla completa solo porque el borde la tenga. Distribuye lo que exige el tráfico del inquilino y deja que el borde posea el resto.

Verifica un prefijo de extremo a extremo

Elige un prefijo externo representativo y síguelo por el VRF previsto del borde, la política de exportación, el contexto de reenvío del leaf receptor y el camino de vuelta a un origen del inquilino. Un prefijo que aparece en un lugar y no en el siguiente localiza el error de inmediato.

Confirma cómo se resuelve el next hop a través del overlay, porque una ruta presente con un next hop sin resolver no reenvía nada. Luego repite la comprobación después de un cambio de uplink, ya que es cuando la política y la resolución de next-hop divergen más a menudo.

Orden de trabajo: enumera las rutas que cruzan, acuerda la política ASN, elige la conexión para su trabajo real, delimita la exportación por inquilino y luego verifica un prefijo y su camino de vuelta.