Constrúe a fronteira EVPN arredor da política de exportación, non das conexións

A suposición habitual é que o modelo de conexión Layer 2 na fronteira determina todo o que está por riba, así que o deseño comeza cun par vPC e sobe. Normalmente acaba con decisións de encamiñamento tomadas por accidente. Unha fronteira EVPN é primeiro un límite de encamiñamento: un contexto de encamiñamento de inquilino atópase cun dominio de encamiñamento externo, e o que cruza esa liña é unha declaración de política. Escolle as rutas, a relación ASN e os camiños de fallo antes de que ninguén discuta sobre port-channels. O modelo de conexión pasa despois a derivarse dun requisito en lugar de ditelo.

Comeza polo que cruza a fronteira

Escribe as rutas que deben ser visibles en cada lado, a dirección na que viaxan e quen aproba un cambio nesa lista. Unha fronteira que acepta todo e anuncia todo non ten política, só un cable.

Despois nomea o fallo que pretendes operar: un uplink caído, un border leaf caído ou todo o dominio externo inalcanzable. Cada resposta cambia se necesitas dous veciños independentes, unha conexión Layer 2 compartida ou ambas.

Só cando existen esas dúas listas a pregunta da conexión se volve respondible. Antes diso, todos os mecanismos parecen igual de válidos. Despois, a maioría elimínanse sós. Ese é todo o argumento para facer primeiro o traballo de encamiñamento.

Fixa o límite de ASN e peering

Unha fabric con AS privadas adoita facer peering co dominio de fronteira público mediante eBGP, e a parte interesante é a política nos dous lados. Decide que prefixos se aceptan, cales se anuncian e que AS path debe recibir o upstream.

RFC 6996 reserva un rango de ASN de uso privado, e eses ASN non deberían aparecer en anuncios globais. Aplica a política de eliminación ou filtrado que admite a plataforma e verifica o anuncio resultante en lugar de supoñer que o dispositivo o fixo. Ese paso tampouco che dá autoridade para anunciar un prefixo público arbitrario, iso é unha conversación aparte co propietario do enderezo.

Unha confederación ou unha función local-AS é unha decisión de deseño para unha topoloxía concreta. Ningunha é obrigatoria só porque a fabric e o upstream usen roles ASN distintos, e adoptar unha sen o requisito engade pezas móbiles a cada cambio futuro.

Os uplinks Layer 3 non necesitan multichassis LAG

As interfaces encamiñadas independentes cos seus propios veciños BGP dan dous camiños claros e dous dominios de fallo claros. vPC ou outro multichassis LAG serve un requisito de conexión Layer 2, e é a ferramenta correcta cando ese requisito existe.

Unha regra xeral de que cada par de fronteira debe usar vPC, ou debe evitalo, oculta as condicións que realmente deciden o caso. Pregunta que ten que transportar a conexión e logo escolle o mecanismo que o transporta con menos modos de fallo compartidos.

A política de encamiñamento que escribiches primeiro non cambia cando cambia o mecanismo de conexión, o que é boa señal de que a orde era correcta.

Exporta só o que o inquilino necesita

Un inquilino pode necesitar unha ruta por defecto, un conxunto de prefixos externos seleccionados ou unha táboa moito maior. Escolle ese alcance segundo a capacidade real de reenvío e de plano de control, non segundo un reconto antigo de rutas de internet que ninguén volveu medir.

A ruta EVPN IP Prefix, chamada habitualmente Type 5 e definida en RFC 9136, transporta información de prefixo no overlay. A implementación segue necesitando política de exportación e importación coincidente máis resolución de next-hop, así que recibir unha ruta BGP externa na fronteira non significa que cada VRF de inquilino a importe.

Non todos os leaf necesitan a táboa completa só porque a fronteira a teña. Distribúe o que esixe o tráfico do inquilino e deixa que a fronteira posúa o resto.

Verifica un prefixo de extremo a extremo

Escolle un prefixo externo representativo e ségueno polo VRF previsto da fronteira, a política de exportación, o contexto de reenvío do leaf receptor e o camiño de volta a unha orixe do inquilino. Un prefixo que aparece nun lugar e non no seguinte localiza o erro de inmediato.

Confirma como se resolve o next hop a través do overlay, porque unha ruta presente cun next hop sen resolver non reenvía nada. Despois repite a comprobación tras un cambio de uplink, xa que é cando a política e a resolución de next-hop diverxen máis a miúdo.

Orde de traballo: enumera as rutas que cruzan, acorda a política ASN, escolle a conexión para o seu traballo real, limita a exportación por inquilino e despois verifica un prefixo e o seu camiño de volta.