Kai kurie L2VPN maršrutai dingsta pridėjus maršrutų atšvaitus

Sesijos lieka aktyvios, IGP yra stabilus, ir vis dėlto keli L2VPN maršrutai niekada nepasirodo dviejuose iš keturių teikėjo kraštų. Šis modelis priklauso atspindžio, o ne transporto problemai, nes sugedusi sesija sugenda visiškai, o pakartotinai naudojama atspindžio riba sugenda selektyviai. Fizinis žiedas neturi tam įtakos; loginis paskirstymo grafas yra vieta, kur tie maršrutai sustojo. To taško radimas nereikalauja perstatyti valdymo plokštumos.

Praradimas yra selektyvus, o tai susiaurina paiešką

Keturi teikėjo kraštai fiziniame žiede pilnam tinklui reikalauja šešių loginių sesijų, nes kiekvienas maršrutizatorius poruojasi su kitais trimis. Tos sesijos eina per maršrutizuotą transportą, todėl kabeliai nieko nesako apie tai, kiek gretimybių yra ar kuri iš jų atspindi. Kai du kraštai praleidžia tam tikrą prefiksų rinkinį, o visa kita konverguoja, kabelis nėra įtariamasis.

Selektyvus praradimas rodo į kilpų prevenciją, politiką arba ryšio kryptį, kai vieni maršrutai kerta ribą, o kiti pakeliui išmetami. Visiškas praradimas rodo į sesiją arba adresų šeimą. Nuspręsti, kurią iš šių dviejų matote, yra pirmas naudingas žingsnis, ir tam reikia vienos komandos.

Ką atspindys iš tikrųjų keičia

Maršrutų atspindys sušvelnina taisyklę, kad iBGP kalbėtojas negali iš naujo skelbti maršruto, išmokto iš kito iBGP kalbėtojo. RFC 4456 išreiškia išimtį per santykį tarp kalbėtojo ir maršruto šaltinio, ir to santykio kryptis svarbesnė, nei sufleruoja dauguma santraukų. Maršrutas, išmoktas iš kliento, gali būti atspindimas kitiems klientams ir ne klientams, o maršrutas, išmoktas iš ne kliento, gali būti atspindimas tik klientams. Perskaitykite asimetriją du kartus, nes ji paaiškina, kaip kliento ryšio pridėjimas gali paslėpti projektavimo klaidą: jis atveria kelią, kurio topologija niekada neketino.

Atributas CLUSTER_LIST registruoja atspindžio istoriją, o atšvaitas, kuris tame sąraše randa savo paties klasterio ID, turi nepaisyti skelbimo. Tai kilpų prevencija, ir tai taip pat mechanizmas, kuris ištrina maršrutus, kai identifikatoriai netyčia pakartotinai panaudojami. ORIGINATOR_ID atlieka giminingą vaidmenį įvardydamas maršrutizatorių, kuris pirmasis paskelbė maršrutą.

Pakartotinai naudojami klasterių ID yra būdas, kuriuo maršrutai dingsta

Mažas tinklas kviečia trumpinti: duokite kiekvienam maršrutizatoriui klasterio ID, lygų jo loopback, vėliau pridėkite dar vieną atšvaitą ir pakartotinai panaudokite esamą loopback, nes jis patogiai po ranka. Jei šis identifikatorius dabar pasirodo dviejuose nepriklausomuose atspindžio etapuose, antrasis etapas mato savo ID CLUSTER_LIST ir atmeta maršrutą. Niekas neįrašo klaidos, nes atmetimas yra teisingas atsakas į kilpą.

Pertekliniai atšvaitai, aptarnaujantys vieną klasterį, yra teisėta išimtis: jie sąmoningai dalijasi ID, kad bet kuris iš jų galėtų aptarnauti tuos pačius klientus. Identifikatorius turi atitikti atspindžio projektą, o ne skirti korpusų pavadinimus.

Nubrėžkite numatytą grafą prieš liesdami bet kokią konfigūraciją: kas sukuria prefiksą, kuris kliento ryšys leidžia pirmąjį atspindį, kuris atšvaitas nuneša jį į kitą etapą ir kur yra paskutinis klientas. Kiekvienas to grafo šuolis yra vieta, kur pakartotinai naudojamas identifikatorius, trūkstamas kliento ryšys ar politikos filtras gali sustabdyti maršrutą. Kai grafas nubrėžtas, trūkstamas maršrutas turi vietą, o ne mįslę.

Atsispirkite pagundai kiekvieną kaimyną padaryti klientu

Greitas trūkstamo maršruto taisymas yra padaryti kiekvieną kaimyną kiekvieno atšvaito klientu. Sklaida grįžta, ir projektas nustoja jums ką nors sakyti: jis padaugina maršrutus, kuriuos neša kiekvienas kalbėtojas, ir kartu paslepia, kuris ryšys turėjo atlikti darbą.

Mažam tinklui paprastai reikia vienos iš dviejų formų. Visas iBGP tinklas yra šešios sesijos keturiems maršrutizatoriams visiškai be atspindžio, o paskirtų atšvaitų pora, aptarnaujanti likusius kraštus, yra kita. Abi lengviau apgalvoti nei dalinį tinklą, kuriame kiekvienas maršrutizatorius šiek tiek atspindi. Rinkitės formą pagal mastą ir gedimo elgseną, o ne pagal kabelių schemą.

Patikrinkite adresų šeimą prieš kaltindami atspindį

TCP sesija prievade 179 įrodo, kad du kalbėtojai gali kalbėtis, ir nieko apie tai, ar VPN adresų šeima apsikeitė bent vienu maršrutu. Nustatykite sesijos būseną, tada šeimą, tada atskirą prefiksą.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Trys išvedimai atskiria gretimybės problemą nuo apsikeitimo problemos ir nuo trūkstamo prefikso problemos. Jei šeima visai nerodo prefiksų, patikrinkite kaimyno aktyvavimo būseną ir eksporto politiką prieš žiūrėdami į atspindį. Jei prefiksai pasirodo viename krašte, bet ne kitame, palyginkite klasterių sąrašą ir šaltinį priimančioje pusėje, tada pereikite ankstesnio skyriaus grafą.

Laikykite kito šuolio pasiekiamumą ir perdavimo būseną už šio patikrinimo ribų. Atspindėtas maršrutas su nepasiekiamu kitu šuoliu egzistuoja ir yra nenaudingas, o tai atrodo kaip atspindžio gedimas, kol nepažvelgsite į kito šuolio stulpelį. Išspręskite kitą šuolį, patvirtinkite perdavimo įrašą ir tik tada nuspręskite, ar paskirstymo grafui reikia dar vieno atšvaito.