Disa rrugë L2VPN zhduken pasi shtoni reflektues rrugësh

Sesionet mbeten aktive, IGP është i qëndrueshëm, dhe megjithatë disa rrugë L2VPN nuk shfaqen kurrë në dy nga katër skajet e ofruesit. Ky model i përket një problemi reflektimi dhe jo transporti, sepse një sesion i thyer dështon plotësisht, ndërsa një kufi reflektimi i ripërdorur dështon në mënyrë selektive. Unaza fizike nuk ka të bëjë fare; grafiku logjik i shpërndarjes është vendi ku ato rrugë u ndalën. Gjetja e atij pike nuk kërkon rindërtimin e planit të kontrollit.

Humbja është selektive, çka e ngushton kërkimin

Katër skaje ofruesi në një unazë fizike kërkojnë gjashtë sesione logjike për një rrjetë të plotë, sepse çdo router çiftohet me tre të tjerët. Ato sesione udhëtojnë mbi transportin e rrugëzuar, ndaj instalimet nuk thonë asgjë për sa afërsi ekzistojnë ose cila prej tyre reflekton. Kur dy skaje humbin një grup të caktuar prefiksesh ndërsa gjithçka tjetër konvergon, kablloja nuk është i dyshuari.

Humbja selektive të çon te parandalimi i sytheve, politika ose drejtimi i marrëdhënies, ku disa rrugë kalojnë një kufi dhe të tjerat hidhen rrugës. Humbja totale të çon te sesioni ose te familja e adresave. Të vendosësh se cilën nga të dyja po shikon është hapi i parë i dobishëm, dhe kërkon një komandë të vetme.

Çfarë ndryshon në të vërtetë reflektimi

Reflektimi i rrugëve zbut rregullin që një folës iBGP nuk mund të ri-shpallë një rrugë të mësuar nga një folës tjetër iBGP. RFC 4456 e shpreh përjashtimin përmes marrëdhënies midis folësit dhe burimit të rrugës, dhe drejtimi i asaj marrëdhënieje ka më shumë rëndësi sesa sugjerojnë shumica e përmbledhjeve. Një rrugë e mësuar nga një klient mund të reflektohet te klientë të tjerë dhe te joklientë, ndërsa një rrugë e mësuar nga një joklient mund të reflektohet vetëm te klientët. Lexojeni asimetrinë dy herë, sepse shpjegon se si shtimi i një marrëdhënieje klienti mund të fshehë një gabim projektimi: hap një shteg që topologjia nuk e kishte menduar kurrë.

Atributi CLUSTER_LIST regjistron historikun e reflektimit, dhe një reflektor që gjen ID-në e klasterit të vet në atë listë duhet të injorojë shpalljen. Ky është parandalimi i sytheve, dhe është gjithashtu mekanizmi që fshin rrugët kur identifikuesit ripërdoren aksidentalisht. ORIGINATOR_ID luan një rol të ngjashëm duke emërtuar routerin që shpalli rrugën i pari.

ID-të e klasterit të ripërdorura janë mënyra se si rrugët zhduken

Një rrjet i vogël fton një shkurtore: jepini çdo routeri një ID klasteri të barabartë me loopback-un e tij, shtoni më vonë edhe një reflektor dhe ripërdorni një loopback ekzistues sepse është pranë dorës. Nëse ky identifikues tani shfaqet në dy faza reflektimi të pavarura, faza e dytë sheh ID-në e vet në CLUSTER_LIST dhe e hedh rrugën. Asgjë nuk regjistron gabim, sepse hedhja është përgjigja e saktë ndaj një sythi.

Reflektorët e tepërt që shërbejnë një klaster të vetëm janë përjashtimi i ligjshëm: ata ndajnë qëllimisht një ID që secili prej tyre të mund të shërbejë të njëjtët klientë. Identifikuesi duhet të përputhet me projektimin e reflektimit dhe jo të dallojë emrat e kutive.

Vizatoni grafikun e synuar përpara se të prekni çdo konfigurim: kush e krijon prefiksin, cila marrëdhënie klienti lejon reflektimin e parë, cili reflektor e çon në fazën tjetër dhe ku qëndron klienti i fundit. Çdo kërcim në atë grafik është një vend ku një identifikues i ripërdorur, një marrëdhënie klienti që mungon ose një filtër politike mund ta ndalin rrugën. Me grafikun e vizatuar, një rrugë që mungon ka një vendndodhje në vend të një misteri.

Rezistojini tundimit për ta bërë çdo fqinj klient

Rregullimi i shpejtë për një rrugë që mungon është ta bësh çdo fqinj klient të çdo reflektori. Përhapja kthehet, dhe projektimi ndalon së të thënëse asgjë: shumëfishon rrugët që mban çdo folës dhe njëkohësisht fsheh cilës marrëdhënie i takonte ta bënte punën.

Një rrjet i vogël zakonisht ka nevojë për një nga dy forma. Një rrjetë e plotë iBGP është gjashtë sesione për katër routera pa asnjë reflektim, dhe një çift reflektuesish i caktuar që shërben skajet e mbetura është forma tjetër. Të dyja janë më të lehta për t'u menduar sesa një rrjetë e pjesshme në të cilën çdo router reflekton pak. Zgjidhni formën sipas shkallës dhe sjelljes në dështim, jo sipas diagramit të instalimeve.

Kontrolloni familjen e adresave përpara se të fajësoni reflektimin

Një sesion TCP në portën 179 provon se dy folësit mund të flasin, dhe asgjë për atë nëse familja e adresave VPN ka shkëmbyer edhe një rrugë të vetme. Përcaktoni gjendjen e sesionit, pastaj familjen, pastaj prefiksin individual.

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

Këto tre dalje i ndajnë një problem afërsie nga një problem shkëmbimi dhe nga një problem prefiksi që mungon. Nëse familja nuk shfaq fare prefikse, kontrolloni gjendjen e aktivizimit dhe politikën e eksportit të fqinjit përpara se të shikoni reflektimin. Nëse prefikset shfaqen në një skaj por jo në një tjetër, krahasoni listën e klasterëve dhe origjinuesin në anën marrëse, pastaj ndiqni grafikun e seksionit të mëparshëm.

Mbajeni arritshmërinë e kërcimit të ardhshëm dhe gjendjen e përcjelljes jashtë atij kontrolli. Një rrugë e reflektuar me një kërcim të ardhshëm të paarritshëm është e pranishme dhe e papërdorshme, çka duket si dështim reflektimi derisa të shikoni kolonën e kërcimit të ardhshëm. Zgjidhni kërcimin e ardhshëm, konfirmoni hyrjen e përcjelljes, dhe vetëm atëherë vendosni nëse grafiku i shpërndarjes ka nevojë për një reflektor tjetër.