AFI ir SAFI: perskaitykite porą prieš paslaugos pavadinimą
AFI 25 su SAFI 65 nėra ta pati paslauga kaip AFI 25 su SAFI 70. Perskaitykite porą, tada patikrinkite šeimų mainus, maršrutą ir perdavimo rezultatą.
Galite matyti, kaip sesija kyla, maršrutas atsiranda, ir vis tiek skaityti netinkamą paslaugą. Skaičių pora kiekvieno pranešimo pradžioje, adresų šeimos identifikatorius ir tolesnės adresų šeimos identifikatorius, nustato, kuris analizatorius skaito naudingąją apkrovą ir kuri lentelė laiko rezultatą. Suklyskite poroje ir importo politika, maršruto tikslo atitikimas bei kito šuolio paieška visos veikia prieš struktūrą, kurios niekas nepaskelbė. Toliau pateiktas kelias prasideda nuo tos poros ir baigiasi perdavimo rezultatu.
Kuriai lentelei priklauso maršrutas, nusprendžia du skaičiai
Pora pasirodo du kartus: daugiaprotokolio gebėjimo viduje, kur kalbėtojas skelbia šeimą, ir prieš kiekvieną NLRI, kurį ta šeima neša. Tai daro ją maršruto savybe, o ne nustatymu pradiniame įrenginyje. Gamintojai ją spausdina kaip pavadinimą, pavyzdžiui, Address family VPNv4 Unicast, o formuluotė keičiasi tarp leidimų, kol skaičiai lieka vietoje.
| Where you meet it | Family pair | Boundary of what it proves |
|---|---|---|
| VPNv4 unicast capability on a neighbour | 1 / 128 | the peer will signal labelled VPN-IPv4, nothing about import |
| VPNv6 unicast capability on a neighbour | 2 / 128 | the peer will signal VPN-IPv6, silent about the transport below |
| VPLS NLRI with a VE ID and a label base | 25 / 65 | a pseudowire is signalled, not that a bridge learned a MAC |
| EVPN MAC/IP advertisement route | 25 / 70 | a binding is advertised, not that the host answers |
Keturi kodavimai apima beveik visus įmonių atvejus: 1 su 128 MPLS pažymėtam VPN-IPv4, 2 su 128 IPv6 atitikmeniui, 25 su 65 BGP signalizuojamam VPLS ir 25 su 70 EVPN. Pirmoji klaida yra manyti, kad kiekviena Layer 2 paslauga yra už 25 su 65, o tai paslepia EVPN. Antroji — traktuoti dvi IP šeimas kaip vieną šeimą su ilgesniu adresu, nors dėl jų deramasi atskirai ir jos gali būti priimtos skirtinguose partneriuose. Trečioji pasirodo, kai šablonas kopijuojamas iš leidimo, kuris pažįsta tik vieną iš jų. Paieška registre išsprendžia visas tris greičiau nei spėjimas, paremtas paslaugos pavadinimu.
Laikykite keturias eilutes IANA registro pavyzdžiais, o ne pačiu registru. Kai skaičius neatitinka nieko žinomo, pažiūrėkite jį prieš statydami aplink jį politiką.
AFI 25 neša du nesusijusius NLRI formatus
Abi Layer 2 šeimos yra po AFI 25, ir panašumas ten baigiasi. VPLS NLRI RFC 4761 section 3.2.2 neša ilgį, maršruto skirtuką, VE ID, VE bloko poslinkį, VE bloko dydį ir etikečių bazę, kurie kartu įvardija pseudowire galinį tašką ir jo etiketę. EVPN išlaiko AFI 25 ir pereina prie SAFI 70, kur naudingoji apkrova yra maršruto tipas: automatinis Ethernet aptikimas, MAC/IP skelbimas, imlusis multicast, Ethernet segmentas, IP priešdėlis. Todėl tas pats baitų poslinkis dviejose šeimose reiškia skirtingus dalykus. Vienai parašytas analizatorius skaito kitą be priekaištų ir gamina nesąmones. Pora yra vienintelis įspėjimas, kad interpretacija neteisinga.
Laukas, kuris vienoje šeimoje reiškia VE bloko poslinkį, kitoje neturi atitikmens, o MAC/IP skelbimo maršrutas egzistuoja tik EVPN. Cituoti atributą taip, lyg jis galiotų abiem, yra būdas, kuriuo užfiksuotos medžiagos peržiūra nueina ne taip.
Kai kas nors duoda jums užfiksuotą medžiagą ar gamintojo lentelę, paklauskite, kuriai šeimai priklauso atributas. Tada patvirtinkite, kad priimanti realizacija palaiko tą šeimą, o ne paslaugos pavadinimą duomenų lape. Dvi platformos gali abi teigti palaikančios VPLS, tačiau įgyvendinti skirtingas signalizacijos šeimas. Pora jas atskiria; produkto etiketė ne.
Sesijos pačios adresų šeima yra atskiras klausimas
VPN-IPv6 įprastai skelbiamas per sesiją, kurios TCP ryšys eina per IPv4, ir tai yra palaikomas dizainas, o ne gedimas. Todėl skaitant vien sesijos santrauką nieko nesakoma apie tai, kurias VPN šeimas partneriai keičiasi.
NLRI šeima, transporto šeima ir perdavimo šeima yra trys nepriklausomi sprendimai. Maršrutizatorius gali kalbėti IPv4 su savo partneriu, priimti VPN-IPv6 pasiekiamumą ir įdiegti maršrutą, kurio kitas šuolis yra IPv6 adresas, pasiekiamas keliu, kurio nenumatėte. Kiekvienam sluoksniui reikia savo patvirtinimo. Svetainės, kurios praneša apie nepasiekiamus IPv6 tikslus, kol skelbimai atrodo teisingi, paprastai prarado kito šuolio sprendimą, o ne šeimų derybas.
Išbandykite sesijos adresų šeimą atskirai, tada šeimas, kurias ji neša, tada tai, ką branduolys gali persiųsti. Trijų atskyrimas apsaugo nuo dažnos klaidingos diagnozės, kai teisingas skelbimas skaitomas kaip įrodymas, jog IPv6 veikia nuo galo iki galo. Tai įrodo tik tai, kad vienas partneris kitam papasakojo apie priešdėlį.
Suderėta, gauta, importuota, įdiegta
Vienam laukiamam maršrutui turi galioti keturios būsenos iš eilės, ir kiekviena yra stebima. Šeima turi būti suderėta su tuo partneriu, maršrutas turi atvykti, maršruto tikslas turi jį importuoti į numatytą kontekstą, o kitas šuolis turi išsispręsti, kad maršrutas būtų įdiegtas. Praleidus pirmą būseną, kitos trys tampa neatsakomos, nes nesuderėta šeima negamina maršrutų, kuriuos būtų galima apžiūrėti. Cisco stiliaus platformose šeimų santraukos ir kiekvieno partnerio galimybės yra atskiros komandos.
show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family
Derybos matomos kiekvienam partneriui spausdinamame galimybių apsikeitime, o užmegzta sesija be nurodytos šeimos neša nieko, ko prašėte. Importą nusprendžia maršruto tikslai, nešami kaip išplėstinės bendruomenės, todėl teisinga pora su neteisingai įvestu tikslu palieka lentelę tuščią. Tada įdiegimas priklauso nuo kito šuolio išsisprendimo priimančiame kontekste, o tai gali nepavykti, kol kiekvienas skelbimas atrodo tobulas.
Duomenų plokštumą patvirtinkite paskutinę, nes maršrutas lentelėje yra teiginys, o ne pristatymas. Tos pačios keturios būsenos galioja kiekvienai šeimai; keičiasi tik komandos ir lentelių pavadinimai.
Ko šeimų pora niekada neįrodo
Teisingas poros perskaitymas pasako, kaip interpretuoti tolesnę maršrutizavimo informaciją, ir tai yra visas teiginys. Jis nieko nesako apie pasiekiamumą, politiką ar duomenų plokštumos būklę. Sumaišius abu, atsiranda užtikrinti teiginiai apie tinklą, kurio niekas nepatikrino. Maršruto tikslo neatitikimas ir sugadintas kitas šuolis atrodo identiškai vien iš poros. Pora yra skaitymo instrukcija, niekada ne nuosprendis.
Kai eskaluojate, įdėkite porą, maršruto tikslą ir išspręstą kitą šuolį į tą pačią pastabą. Tada kitas inžinierius turi tris nepriklausomus dalykus išbandyti, o ne paslaugos pavadinimą, kurį reikia interpretuoti iš naujo. Jei derybų nėra, jie tai mato iš karto, neteisingas tikslas palieka importą akivaizdžiai nesančiu, o neišspręstas kitas šuolis palieka maršrutą esantį, bet netinkamą naudoti.