AFI i SAFI: llegiu la parella abans del nom del servei

Podeu veure com una sessió s'aixeca, com apareix una ruta, i tot i així estar llegint el servei equivocat. La parella de números al capdavant de cada anunci, l'identificador de família d'adreces i l'identificador de família d'adreces subsegüent, decideix quin analitzador llegeix la càrrega i quina taula guarda el resultat. Equivoqueu la parella i la política d'importació, la coincidència de l'objectiu de ruta i la cerca del següent salt s'executen tots contra una estructura que ningú va anunciar. El recorregut de sota comença en aquesta parella i acaba en el resultat de l'encaminament.

Dos números decideixen a quina taula pertany la ruta

La parella apareix dues vegades: dins de la capacitat multiprotocol, on un parlant anuncia una família, i davant de cada NLRI que aquesta família porta. Això la fa una propietat de la ruta i no un paràmetre de la caixa d'origen. Els fabricants la imprimeixen com un nom com Address family VPNv4 Unicast, i la redacció canvia entre versions mentre els números es queden al lloc.

Quatre codificacions cobreixen quasi tots els casos empresarials: 1 amb 128 per a VPN-IPv4 etiquetada amb MPLS, 2 amb 128 per a l'equivalent IPv6, 25 amb 65 per a VPLS senyalitzada amb BGP, i 25 amb 70 per a EVPN. El primer error és suposar que cada servei Layer 2 viu darrere de 25 amb 65, cosa que amaga EVPN. El segon és tractar les dues famílies IP com una família amb una adreça més llarga, quan es negocien per separat i es poden acceptar en parells diferents. El tercer apareix quan es copia una plantilla d'una versió que només en coneix una. Una consulta al registre resol els tres més de pressa que una conjectura basada en el nom del servei.

Tracteu les quatre files com a exemples del registre IANA, no com el registre mateix. Quan un número no coincideixi amb res que reconegueu, consulteu-lo abans de construir-hi una política al voltant.

AFI 25 porta dos formats NLRI no relacionats

Totes dues famílies Layer 2 seuen sota AFI 25, i la semblança s'acaba aquí. El NLRI de VPLS a RFC 4761 section 3.2.2 porta una longitud, un distingidor de ruta, un VE ID, un desplaçament de bloc VE, una mida de bloc VE i una base d'etiquetes, que junts nomenen un extrem de pseudowire i la seva etiqueta. EVPN conserva AFI 25 i passa a SAFI 70, on la càrrega és un tipus de ruta: descobriment automàtic Ethernet, anunci MAC/IP, multicast inclusiu, segment Ethernet, prefix IP. Per tant, el mateix desplaçament de byte significa coses diferents en les dues famílies. Un analitzador escrit per a una llegeix l'altra sense queixa i produeix bajanades. La parella és l'únic avís que la interpretació és incorrecta.

Un camp que en una família significa desplaçament de bloc VE no té equivalent en l'altra, i la ruta d'anunci MAC/IP només existeix en EVPN. Citar un atribut com si s'apliqués a totes dues és com va malament una revisió de captura.

Quan algú us doni una captura o una taula de proveïdor, pregunteu a quina família pertany l'atribut. Després confirmeu que la implementació receptora admet aquella família, no el nom del servei del full de dades. Dues plataformes poden reclamar suport VPLS mentre implementen famílies de senyalització diferents. La parella les separa; l'etiqueta del producte no.

La família d'adreces pròpia de la sessió és una pregunta a part

VPN-IPv6 s'anuncia habitualment per una sessió la connexió TCP de la qual va sobre IPv4, i això és un disseny admès, no un defecte. Per tant, llegir només el resum de la sessió no diu res sobre quines famílies VPN intercanvien els parells.

Família NLRI, família de transport i família d'encaminament són tres decisions independents. Un encaminador pot parlar IPv4 amb el seu parell, acceptar abast de VPN-IPv6 i instal·lar una ruta el següent salt de la qual és una adreça IPv6 abastable per un camí que no volíeu. Cada capa necessita la seva pròpia confirmació. Els llocs que informen de destinacions IPv6 inabastables mentre els anuncis semblen correctes solen haver perdut la resolució del següent salt, no la negociació de famílies.

Proveu la família d'adreces de la sessió per si sola, després les famílies que porta, després què pot encaminar el nucli. Mantenir les tres separades evita el diagnòstic erroni habitual on un anunci correcte es llegeix com a prova que IPv6 funciona d'extrem a extrem. Només prova que un parell va dir a un altre coses d'un prefix.

Negociat, rebut, importat, instal·lat

Per a una ruta esperada, quatre estats han de complir-se en ordre, i cadascun és observable. La família s'ha d'haver negociat amb aquell parell, la ruta ha d'arribar, un objectiu de ruta l'ha d'importar al context previst, i el següent salt s'ha de resoldre perquè la ruta s'instal·li. Saltar-se el primer estat fa els altres tres irresponables, perquè una família no negociada no produeix rutes per inspeccionar. A les plataformes d'estil Cisco els resums de família i les capacitats per parell són ordres separades.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

La negociació apareix a l'intercanvi de capacitats imprès per parell, i una sessió establerta sense cap família llistada no porta res del que heu demanat. La importació la decideixen els objectius de ruta portats com a comunitats esteses, així que una parella correcta amb un objectiu mal escrit deixa la taula buida. La instal·lació després depèn que el següent salt es resolgui en el context receptor, cosa que pot fallar mentre cada anunci sembla perfecte.

Confirmeu el pla de dades al final, perquè una ruta a la taula és una afirmació, no un lliurament. Els mateixos quatre estats s'apliquen a cada família; només canvien les ordres i els noms de taula.

Què no prova mai una parella de famílies

Llegir la parella correctament us diu com interpretar la informació d'encaminament que segueix, i aquesta és tota l'afirmació. No diu res sobre abast, res sobre política i res sobre la salut del pla de dades. Confondre les dues coses produeix afirmacions segures sobre una xarxa que ningú ha verificat. Un desajust d'objectiu de ruta i un següent salt trencat semblen idèntics només mirant la parella. La parella és una instrucció de lectura, mai un veredicte.

Quan escaleu, poseu la parella, l'objectiu de ruta i el següent salt resolt a la mateixa nota. L'enginyer següent té llavors tres coses independents per provar en lloc d'un nom de servei per reinterpretar. Si falta la negociació ho veuen de seguida, un objectiu equivocat deixa la importació visiblement absent, i un següent salt no resolt deixa la ruta present però inutilitzable.