AFI un SAFI: izlasiet pāri pirms pakalpojuma nosaukuma

Jūs varat redzēt, kā sesija ceļas, maršruts parādās, un tomēr lasīt nepareizo pakalpojumu. Skaitļu pāris katra paziņojuma sākumā, adrešu saimes identifikators un nākamās adrešu saimes identifikators nosaka, kurš parsētājs lasa kravu un kura tabula glabā rezultātu. Kļūdīsities pārī, un importa politika, maršruta mērķa atbilstība un nākamā lēciena meklēšana visas darbojas pret struktūru, ko neviens nav paziņojis. Tālāk aprakstītais ceļš sākas ar šo pāri un beidzas ar pārsūtīšanas rezultātu.

Divi skaitļi nosaka, kurai tabulai maršruts pieder

Pāris parādās divreiz: daudzprotokolu iespējas iekšienē, kur runātājs paziņo saimi, un katras NLRI priekšā, ko šī saime nes. Tas to padara par maršruta īpašību, nevis iestatījumu uz izcelsmes kastes. Ražotāji to iespiež kā nosaukumu, piemēram, Address family VPNv4 Unicast, un formulējums mainās starp laidieniem, kamēr skaitļi paliek savā vietā.

Četri kodējumi aptver gandrīz visus uzņēmuma gadījumus: 1 ar 128 MPLS marķētam VPN-IPv4, 2 ar 128 IPv6 ekvivalentam, 25 ar 65 BGP signalizētam VPLS un 25 ar 70 EVPN. Pirmā kļūda ir pieņemt, ka katrs Layer 2 pakalpojums atrodas aiz 25 ar 65, kas slēpj EVPN. Otrā ir attiekties pret divām IP saimēm kā vienu saimi ar garāku adresi, lai gan par tām vienojas atsevišķi un tās var pieņemt dažādos partneros. Trešā parādās, kad veidne tiek kopēta no laidiena, kas pazīst tikai vienu no tām. Meklēšana reģistrā atrisina visas trīs ātrāk nekā minējums, kas balstīts uz pakalpojuma nosaukumu.

Uzskatiet četras rindas par IANA reģistra piemēriem, nevis pašu reģistru. Kad skaitlis neatbilst nekam zināmam, apskatiet to, pirms būvējat ap to politiku.

AFI 25 nes divus nesaistītus NLRI formātus

Abas Layer 2 saimes atrodas zem AFI 25, un līdzība tur beidzas. VPLS NLRI RFC 4761 section 3.2.2 nes garumu, maršruta atšķīrēju, VE ID, VE bloka nobīdi, VE bloka izmēru un etiķešu bāzi, kas kopā nosauc pseudowire galapunktu un tā etiķeti. EVPN saglabā AFI 25 un pāriet uz SAFI 70, kur krava ir maršruta tips: automātiska Ethernet atklāšana, MAC/IP paziņojums, iekļaujošais multicast, Ethernet segments, IP prefikss. Tāpēc viena un tā pati baitu nobīde divās saimēs nozīmē dažādas lietas. Vienai rakstīts parsētājs lasa otru bez iebildumiem un rada muļķības. Pāris ir vienīgais brīdinājums, ka interpretācija ir nepareiza.

Laukam, kas vienā saimē nozīmē VE bloka nobīdi, otrā nav ekvivalenta, un MAC/IP paziņojuma maršruts pastāv tikai EVPN. Citēt atribūtu tā, it kā tas attiektos uz abām, ir veids, kā ieraksta pārskatīšana aiziet greizi.

Kad kāds jums iedod ierakstu vai ražotāja tabulu, pajautājiet, kurai saimei atribūts pieder. Pēc tam apstipriniet, ka saņēmēja implementācija atbalsta šo saimi, nevis pakalpojuma nosaukumu datu lapā. Divas platformas var abas apgalvot VPLS atbalstu, vienlaikus ieviešot dažādas signalizācijas saimes. Pāris tās šķir; produkta etiķete ne.

Sesijas pašas adrešu saime ir atsevišķs jautājums

VPN-IPv6 parasti tiek paziņots sesijā, kuras TCP savienojums iet pāri IPv4, un tas ir atbalstīts dizains, nevis defekts. Tāpēc lasot tikai sesijas kopsavilkumu, nekas nav teikts par to, kuras VPN saimes partneri apmaina.

NLRI saime, transporta saime un pārsūtīšanas saime ir trīs neatkarīgi lēmumi. Maršrutētājs var runāt IPv4 ar savu partneri, pieņemt VPN-IPv6 sasniedzamību un instalēt maršrutu, kura nākamais lēciens ir IPv6 adrese, kas sasniedzama pa ceļu, kuru neplānojāt. Katram slānim vajag savu apstiprinājumu. Vietnes, kas ziņo par nesasniedzamiem IPv6 galamērķiem, kamēr paziņojumi izskatās pareizi, parasti ir zaudējušas nākamā lēciena atrisinājumu, nevis saimes sarunas.

Pārbaudiet sesijas adrešu saimi atsevišķi, pēc tam saimes, ko tā nes, pēc tam to, ko kodols var pārsūtīt. Trīs atdalīšana novērš biežo kļūdaino diagnozi, kad pareizu paziņojumu lasa kā pierādījumu, ka IPv6 darbojas no gala līdz galam. Tas pierāda tikai to, ka viens partneris otram pastāstīja par prefiksu.

Saskaņots, saņemts, importēts, instalēts

Vienam gaidītam maršrutam četriem stāvokļiem jāpastāv secībā, un katrs ir novērojams. Saimei jābūt saskaņotai ar to partneri, maršrutam jāatnāk, maršruta mērķim tas jāimportē paredzētajā kontekstā, un nākamajam lēcienam jāatrisinās, lai maršruts instalētos. Pirmā stāvokļa izlaišana padara pārējos trīs neatbildamus, jo nesaskaņota saime nerada maršrutus, ko apskatīt. Cisco stila platformās saimes kopsavilkumi un katram partnerim paredzētās iespējas ir atsevišķas komandas.

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

Sarunas redzamas katram partnerim iespiestajā iespēju apmaiņā, un izveidota sesija bez norādītas saimes nes neko no tā, ko lūdzāt. Importu nosaka maršruta mērķi, kas nesti kā paplašinātas kopienas, tāpēc pareizs pāris ar nepareizi ierakstītu mērķi atstāj tabulu tukšu. Pēc tam instalēšana atkarīga no nākamā lēciena atrisināšanas saņēmējā kontekstā, kas var neizdoties, kamēr katrs paziņojums izskatās perfekts.

Datu plakni apstipriniet pēdējo, jo maršruts tabulā ir apgalvojums, nevis piegāde. Tie paši četri stāvokļi attiecas uz katru saimi; mainās tikai komandas un tabulu nosaukumi.

Ko saimju pāris nekad nepierāda

Pareiza pāra lasīšana pasaka, kā interpretēt sekojošo maršrutēšanas informāciju, un tas ir viss apgalvojums. Tas neko nesaka par sasniedzamību, par politiku vai par datu plaknes veselību. Abus sajaucot, rodas pārliecināti apgalvojumi par tīklu, kuru neviens nav pārbaudījis. Maršruta mērķa neatbilstība un salauzts nākamais lēciens izskatās identiski tikai no pāra. Pāris ir lasīšanas instrukcija, nekad ne spriedums.

Kad eskalējat, ielieciet pāri, maršruta mērķi un atrisināto nākamo lēcienu tajā pašā piezīmē. Tad nākamajam inženierim ir trīs neatkarīgas lietas, ko pārbaudīt, nevis pakalpojuma nosaukums, kas jāinterpretē no jauna. Ja sarunu nav, viņi to redz uzreiz, nepareizs mērķis atstāj importu redzami neesošu, un neatrisināts nākamais lēciens atstāj maršrutu klātesošu, bet neizmantojamu.