AFI i SAFI: pročitajte par prije naziva usluge

Možete gledati kako sesija ustaje, vidjeti rutu kako se pojavljuje, i ipak čitati pogrešnu uslugu. Par brojeva na početku svake objave, identifikator adresne porodice i identifikator naredne adresne porodice, odlučuje koji parser čita teret i koja tabela drži rezultat. Pogriješite li par i politika uvoza, podudaranje ruta-targeta i traženje sljedećeg hopa svi se izvode prema strukturi koju niko nije objavio. Šetnja ispod počinje tim parom i završava rezultatom prosljeđivanja.

Dva broja odlučuju u koju tabelu ruta pripada

Par se pojavljuje dvaput: unutar multiprotokolarne sposobnosti, gdje govornik objavljuje porodicu, i ispred svakog NLRI koji ta porodica nosi. Time je svojstvo rute, a ne postavka na izvornoj kutiji. Proizvođači ga ispisuju kao naziv poput Address family VPNv4 Unicast, a formulacija se mijenja između izdanja dok brojevi ostaju na mjestu.

Četiri kodiranja pokrivaju skoro svaki poslovni slučaj: 1 sa 128 za MPLS-označeni VPN-IPv4, 2 sa 128 za IPv6 ekvivalent, 25 sa 65 za VPLS signaliziran BGP-om, i 25 sa 70 za EVPN. Prva greška je pretpostaviti da svaka usluga Layer 2 stoji iza 25 sa 65, što skriva EVPN. Druga je tretirati dvije IP porodice kao jednu porodicu sa dužom adresom, dok se one pregovaraju odvojeno i mogu biti prihvaćene na različitim peer-ovima. Treća se pojavljuje kad se šablon kopira iz izdanja koje zna samo jednu od njih. Pogled u registar rješava sve tri brže od nagađanja zasnovanog na nazivu usluge.

Tretirajte četiri reda kao primjere iz IANA registra, ne kao sam registar. Kad broj ne odgovara ničemu što prepoznajete, pogledajte ga prije nego što oko njega izgradite politiku.

AFI 25 nosi dva nepovezana NLRI formata

Obje porodice Layer 2 stoje pod AFI 25 i sličnost tu prestaje. VPLS NLRI u RFC 4761 section 3.2.2 nosi dužinu, razlikovnik rute, VE ID, pomak VE bloka, veličinu VE bloka i bazu oznaka, što zajedno imenuje krajnju tačku pseudowire-a i njenu oznaku. EVPN zadržava AFI 25 i prelazi na SAFI 70, gdje je teret tip rute: Ethernet automatsko otkrivanje, MAC/IP objava, inkluzivni multicast, Ethernet segment, IP prefiks. Zato isti pomak u bajtovima znači različite stvari u dvije porodice. Parser napisan za jednu čita drugu bez pritužbe i proizvodi besmislicu. Par je jedino upozorenje da je tumačenje pogrešno.

Polje koje u jednoj porodici znači pomak VE bloka nema pandan u drugoj, a ruta MAC/IP objave postoji samo u EVPN-u. Citirati atribut kao da važi za obje jeste način na koji pregled snimka pođe po zlu.

Kad vam neko preda snimak ili tabelu proizvođača, pitajte kojoj porodici atribut pripada. Zatim potvrdite da prijemna implementacija podržava tu porodicu, a ne naziv usluge sa podatkovnog lista. Dvije platforme mogu obje tvrditi podršku za VPLS dok implementiraju različite signalne porodice. Par ih razdvaja; oznaka proizvoda ne.

Vlastita adresna porodica sesije je odvojeno pitanje

VPN-IPv6 se rutinski objavljuje kroz sesiju čija TCP veza ide preko IPv4, i to je podržan dizajn, ne kvar. Zato čitanje samo sažetka sesije ne govori ništa o tome koje VPN porodice peer-ovi razmjenjuju.

NLRI porodica, transportna porodica i porodica prosljeđivanja tri su nezavisne odluke. Ruter može govoriti IPv4 sa svojim peer-om, prihvatiti dostupnost VPN-IPv6 i instalirati rutu čiji je sljedeći hop adresa IPv6 dostupna putem puta koji niste namjeravali. Svaki sloj traži vlastitu potvrdu. Lokacije koje prijavljuju nedostupne destinacije IPv6 dok objave izgledaju ispravno obično su izgubile razrješenje sljedećeg hopa, a ne pregovaranje porodica.

Testirajte adresnu porodicu sesije zasebno, pa porodice koje nosi, pa ono što jezgro može proslijediti. Držanje tri stvari odvojenim sprječava čestu pogrešnu dijagnozu gdje se ispravna objava čita kao dokaz da IPv6 radi od kraja do kraja. To dokazuje samo da je jedan peer rekao drugom za prefiks.

Pregovoreno, primljeno, uvezeno, instalirano

Za jednu očekivanu rutu četiri stanja moraju važiti po redu i svako je vidljivo. Porodica mora biti pregovarana s tim peer-om, ruta mora stići, ruta-target ju mora uvesti u predviđeni kontekst i sljedeći hop mora se razriješiti da bi se ruta instalirala. Preskakanje prvog stanja čini druga tri neodgovorivim, jer nepregovarana porodica ne proizvodi rute za pregled. Na platformama u stilu Cisco sažeci porodica i sposobnosti po peer-u odvojene su komande.

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

Pregovaranje se vidi u razmjeni sposobnosti ispisanoj po peer-u, a uspostavljena sesija bez navedene porodice ne nosi ništa od onoga što ste tražili. Uvoz određuju ruta-targeti nošeni kao proširene zajednice, pa ispravan par sa pogrešno otkucanim targetom ostavlja tabelu praznom. Instalacija zatim zavisi od razrješenja sljedećeg hopa u prijemnom kontekstu, što može pasti dok svaka objava izgleda savršeno.

Potvrdite ravan podataka posljednju, jer ruta u tabeli je tvrdnja, a ne isporuka. Ista četiri stanja važe za svaku porodicu; mijenjaju se samo komande i nazivi tabela.

Šta par porodica nikada ne dokazuje

Ispravno čitanje para govori vam kako tumačiti rutinške informacije koje slijede i to je cijela tvrdnja. Ono ne govori ništa o dostupnosti, ništa o politici, ništa o zdravlju ravni podataka. Miješanje dvoje proizvodi sigurne izjave o mreži koju niko nije provjerio. Nesklad ruta-targeta i pokvaren sljedeći hop izgledaju identično iz samog para. Par je uputa za čitanje, nikada presuda.

Kad eskalirate, stavite par, ruta-target i razriješeni sljedeći hop u istu bilješku. Sljedeći inženjer tada ima tri nezavisne stvari za testiranje umjesto naziva usluge koji treba ponovo tumačiti. Ako pregovaranja nema, vide to odmah, pogrešan target ostavlja uvoz vidno odsutnim, a nerazriješen sljedeći hop ostavlja rutu prisutnom ali neupotrebljivom.