AFI și SAFI: citiți perechea înainte de numele serviciului

Puteți vedea o sesiune ridicându-se, o rută apărând și totuși să citiți serviciul greșit. Perechea de numere de la începutul fiecărui anunț, identificatorul familiei de adrese și identificatorul următoarei familii de adrese, decide ce analizor citește încărcătura și ce tabelă păstrează rezultatul. Greșiți perechea și politica de import, potrivirea țintei rutei și căutarea următorului salt rulează toate împotriva unei structuri pe care nimeni nu a anunțat-o. Parcursul de mai jos începe la acea pereche și se termină la rezultatul transmiterii.

Care tabelă primește ruta decid două numere

Perechea apare de două ori: în interiorul capacității multiprotocol, unde un vorbitor anunță o familie, și în fața fiecărui NLRI pe care acea familie îl transportă. Asta o face o proprietate a rutei, nu o setare pe cutia de origine. Producătorii o tipăresc ca nume de forma Address family VPNv4 Unicast, iar formularea se schimbă între versiuni în timp ce numerele rămân pe loc.

Patru codificări acoperă aproape orice caz de întreprindere: 1 cu 128 pentru VPN-IPv4 etichetat MPLS, 2 cu 128 pentru echivalentul IPv6, 25 cu 65 pentru VPLS semnalizat prin BGP și 25 cu 70 pentru EVPN. Prima greșeală este să presupunem că fiecare serviciu Layer 2 stă în spatele lui 25 cu 65, ceea ce ascunde EVPN. A doua este să tratăm cele două familii IP ca o singură familie cu o adresă mai lungă, deși sunt negociate separat și pot fi acceptate pe parteneri diferiți. O a treia apare când un șablon este copiat dintr-o versiune care cunoaște doar una dintre ele. O căutare în registru rezolvă toate trei mai repede decât o presupunere construită pe numele serviciului.

Tratați cele patru rânduri ca exemple din registrul IANA, nu ca registrul însuși. Când un număr nu se potrivește cu nimic cunoscut, căutați-l înainte de a construi o politică în jurul lui.

AFI 25 transportă două formate NLRI fără legătură

Ambele familii Layer 2 stau sub AFI 25, iar asemănarea se oprește acolo. NLRI de VPLS din RFC 4761 section 3.2.2 transportă o lungime, un distingător de rută, un VE ID, un decalaj de bloc VE, o dimensiune de bloc VE și o bază de etichete, care împreună numesc un capăt de pseudowire și eticheta lui. EVPN păstrează AFI 25 și trece la SAFI 70, unde încărcătura este un tip de rută: descoperire automată Ethernet, anunț MAC/IP, multicast incluziv, segment Ethernet, prefix IP. De aceea același decalaj de octet înseamnă lucruri diferite în cele două familii. Un analizor scris pentru una o citește pe cealaltă fără plângere și produce absurdități. Perechea este singurul avertisment că interpretarea este greșită.

Un câmp care într-o familie înseamnă decalaj de bloc VE nu are corespondent în cealaltă, iar ruta de anunț MAC/IP există doar în EVPN. A cita un atribut ca și cum s-ar aplica ambelor este felul în care o revizuire de captură merge prost.

Când cineva vă dă o captură sau un tabel de la producător, întrebați cărei familii îi aparține atributul. Apoi confirmați că implementarea receptoare suportă acea familie, nu numele serviciului din fișa tehnică. Două platforme pot revendica amândouă suport VPLS implementând familii de semnalizare diferite. Perechea le separă; eticheta produsului nu.

Familia de adrese a sesiunii este o întrebare separată

VPN-IPv6 este anunțat în mod curent printr-o sesiune a cărei conexiune TCP rulează peste IPv4, iar asta este un proiect suportat, nu un defect. Citirea doar a rezumatului sesiunii nu spune deci nimic despre ce familii VPN schimbă partenerii.

Familia NLRI, familia de transport și familia de transmisie sunt trei decizii independente. Un router poate vorbi IPv4 cu partenerul său, accepta accesibilitatea VPN-IPv6 și instala o rută al cărei următor salt este o adresă IPv6 accesibilă printr-o cale pe care nu o intenționați. Fiecare strat are nevoie de propria confirmare. Siturile care raportează destinații IPv6 inaccesibile în timp ce anunțurile par corecte au pierdut de obicei rezolvarea următorului salt, nu negocierea familiilor.

Testați familia de adrese a sesiunii separat, apoi familiile pe care le transportă, apoi ce poate transmite nucleul. Ținerea celor trei separate împiedică diagnosticul greșit obișnuit în care un anunț corect este citit ca dovadă că IPv6 funcționează de la un capăt la altul. Dovedește doar că un partener i-a spus altuia despre un prefix.

Negociat, primit, importat, instalat

Pentru o rută așteptată, patru stări trebuie să fie valabile în ordine, iar fiecare este observabilă. Familia trebuie să fie negociată cu acel partener, ruta trebuie să sosească, o țintă de rută trebuie să o importe în contextul dorit, iar următorul salt trebuie să se rezolve ca ruta să se instaleze. Sărirea primei stări face celelalte trei fără răspuns, pentru că o familie nenegoțiată nu produce rute de inspectat. Pe platforme în stil Cisco, rezumatele de familie și capacitățile pe partener sunt comenzi separate.

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

Negocierea apare în schimbul de capacități tipărit pe partener, iar o sesiune stabilită fără nicio familie listată nu transportă nimic din ce ați cerut. Importul este decis de ținte de rută purtate ca comunități extinse, așa că o pereche corectă cu o țintă scrisă greșit lasă tabelul gol. Instalarea depinde apoi de rezolvarea următorului salt în contextul receptor, care poate eșua în timp ce fiecare anunț pare perfect.

Confirmați planul de date ultimul, pentru că o rută în tabel este o afirmație, nu o livrare. Aceleași patru stări se aplică fiecărei familii; se schimbă doar comenzile și numele tabelelor.

Ce nu dovedește niciodată o pereche de familii

Citirea corectă a perechii vă spune cum să interpretați informația de rutare care urmează, și aceasta este întreaga afirmație. Nu spune nimic despre accesibilitate, nimic despre politică și nimic despre sănătatea planului de date. Confundarea celor două produce afirmații încrezătoare despre o rețea pe care nimeni nu a verificat-o. O nepotrivire de țintă de rută și un următor salt rupt arată identic doar privind perechea. Perechea este o instrucțiune de citire, niciodată un verdict.

Când escaladați, puneți perechea, ținta de rută și următorul salt rezolvat în aceeași notă. Următorul inginer are atunci trei lucruri independente de testat în loc de un nume de serviciu de reinterpretat. Dacă lipsește negocierea o văd imediat, o țintă greșită lasă importul vizibil absent, iar un următor salt nerezolvat lasă ruta prezentă dar inutilizabilă.