Construeix la frontera EVPN al voltant de la política d'exportació, no dels enllaços

L'assumpció habitual és que el model d'enllaç Layer 2 a la frontera determina tot el que hi ha a sobre, de manera que el disseny comença amb una parella vPC i puja. Normalment acaba amb decisions d'encaminament preses per accident. Una frontera EVPN és primer de tot una frontera d'encaminament: un context d'encaminament de client es troba amb un domini d'encaminament extern, i el que creua aquesta línia és una declaració de política. Trieu les rutes, la relació ASN i els camins de fallada abans que ningú discuteixi sobre port-channels. El model d'enllaç després ve d'un requisit en lloc de dictar-lo.

Comença pel que creua la frontera

Escriviu les rutes que han de ser visibles a cada costat, la direcció en què viatgen i qui aprova un canvi en aquesta llista. Una frontera que accepta tot i anuncia tot no té política, només un cable.

Després anomeneu la fallada que voleu operar: un uplink caigut, un border leaf caigut o tot el domini extern inabastable. Cada resposta canvia si necessiteu dos veïns independents, un enllaç Layer 2 compartit o tots dos.

Només quan existeixen aquestes dues llistes la pregunta de l'enllaç es pot respondre. Abans, tots els mecanismes semblen igual de vàlids. Després, la majoria s'eliminen sols. Aquest és tot l'argument per fer primer la feina d'encaminament.

Fixa la frontera d'ASN i peering

Una fàbrica amb AS privades normalment fa peering amb el domini de frontera públic per eBGP, i la part interessant és la política als dos costats. Decidiu quins prefixos s'accepten, quins s'anuncien i quin AS path ha de rebre l'upstream.

RFC 6996 reserva un rang d'ASN d'ús privat, i aquests ASN no haurien d'aparèixer en anuncis globals. Apliqueu la política de supressió o filtratge que admet la plataforma i verifiqueu l'anunci resultant en lloc de suposar que el dispositiu ho ha fet. Aquest pas tampoc no us dona autoritat per anunciar un prefix públic arbitrari, que és una conversa separada amb el propietari de l'adreça.

Una confederació o una funció local-AS és una decisió de disseny per a una topologia concreta. Cap de les dues no és obligatòria només perquè la fàbrica i l'upstream usin papers ASN diferents, i adoptar-ne una sense el requisit afegeix peces mòbils a cada canvi futur.

Els uplinks Layer 3 no necessiten multichassis LAG

Interfícies encaminades independents amb els seus propis veïns BGP donen dos camins clars i dos dominis de fallada clars. vPC o un altre multichassis LAG serveix un requisit d'enllaç Layer 2, i és l'eina correcta quan aquest requisit existeix.

Una regla general que cada parella de frontera ha d'usar vPC, o ha d'evitar-lo, amaga les condicions que realment decideixen el cas. Pregunteu què ha de portar l'enllaç i trieu després el mecanisme que ho porta amb el menor nombre de modes de fallada compartits.

La política d'encaminament que vau escriure primer no canvia quan canvia el mecanisme d'enllaç, cosa que és bon senyal que l'ordre era correcte.

Exporta només el que el client necessita

Un client pot necessitar una ruta per defecte, un conjunt de prefixos externs seleccionats o una taula molt més gran. Trieu aquest abast segons la capacitat real de reenviament i de pla de control, no segons un recompte antic de rutes d'internet que ningú no ha tornat a mesurar.

La ruta EVPN IP Prefix, anomenada habitualment Type 5 i definida a RFC 9136, porta informació de prefix a l'overlay. La implementació encara necessita política d'exportació i importació coincidents més resolució de next-hop, així que rebre una ruta BGP externa a la frontera no vol dir que tot VRF de client la importi.

No cal que cada leaf tingui la taula completa només perquè la frontera la té. Distribuïu el que el trànsit del client requereix i deixeu que la frontera posseeixi la resta.

Verifica un prefix d'extrem a extrem

Trieu un prefix extern representatiu i seguiu-lo pel VRF previst de la frontera, la política d'exportació, el context de reenviament del leaf receptor i el camí de tornada a un origen del client. Un prefix que apareix en un lloc i no en el següent localitza l'error immediatament.

Confirmeu com es resol el next hop a través de l'overlay, perquè una ruta present amb un next hop no resolt no reenvia res. Després repetiu la comprovació després d'un canvi d'uplink, ja que és quan la política i la resolució de next-hop divergeixen més sovint.

Ordre de treball: llisteu les rutes que creuen, acordeu la política ASN, trieu l'enllaç per a la seva feina real, abastiu l'exportació per client i verifiqueu després un prefix i el seu camí de tornada.