L3VPN perdavimas: privatūs maršrutai, numatytasis maršrutas ar visa lentelė?

Jūsų linija įjungta, VRF sukonfigūruota, o tiekėjas užduoda trumpą klausimą, kuris nulemia likusį projektą: ką turi gauti kliento kraštas? Trys atsakymai paplitę, ir nė vienas jų nekyla iš to, kad egzistuoja žymių rinkinys. Tai paslaugos sprendimai apie tai, iš kur srautas palieka filialą.

Peržiūrėti perdavimą iš eilės yra pigiausias būdas tai padaryti teisingai. Pradedate nuo to, kas nutinka srautui, kuris nieko neatitinka, tada užrašote privačiuosius prefiksus ir jų elgseną gedimo metu ir tik tada kalbate apie tai, kokio dydžio srautą esate pasirengę perduoti.

Pradėkite nuo srauto, kurio niekas neplanavo

Užduokite vieną klausimą, kol dar nepasirodė joks prefiksų sąrašas: kai paketas neatitinka jokio privataus maršruto, kur jis turi eiti? Filialas su savo interneto linija paprastai laiko vietinį numatytąjį maršrutą, todėl įprastas interneto srautas išeina per vietinę užkardą ir tiekėjo visai neliečia. Tokiame projekte VPN perduoda tik nutolusias privačias svetaines, o atranką atlieka konkretesni prefiksai.

Filialas, kuris turi naudoti centrinį išėjimą, yra priešingas atvejis. Ten numatytasis maršrutas rodo į paslaugos vidų, o tiekėjas arba centrinė svetainė valdo persiuntimą, grįžtamąjį maršrutizavimą ir bet kokį vertimą. Pasakyti "numatytasis į VPN" be to šeimininko reiškia filialą, kuris išsprendžia vardus ir nieko nepasiekia.

Abu projektai skiriasi tuo, kaip atrodo maršrutizavimo gedimas, ir todėl spėlioti brangu. Su vietiniu numatytuoju maršrutu prarastas privatus maršrutas nusiunčia tą srautą į internetą, kur jį išmeta užkarda arba, dar blogiau, atsako kažkas, ko neketinote. Su centriniu numatytuoju maršrutu tas pats praradimas visiškai atima interneto prieigą, o bilietas atkeliauja kaip "visas filialas neveikia". Nė vienas gedimas savaime nėra neteisingas, bet tik vienas atitinka parduotą paslaugą, o vien BGP konfigūracija nepasakys, kurį pastatėte.

Užrašykite privačiuosius prefiksus kartu su jų gedimo atveju

Išvardykite prefiksus, kuriuos filialas turi pasiekti, ir pažymėkite, kurie jų yra apibendrinti. Agregatas, kuris vienu bitu per platus, įtraukia nežinomus adresatus į VPN, ir tai priimtina tik jei tolimoji pusė juos tikrai valdo ir persiunčia.

Tada aprašykite numatomą elgseną, kai privati paslauga sugenda. Išlaikytas atmetimo maršrutas laiko srautą toliau nuo neleistino kelio ir duoda švarų, laukiamą nutrūkimą. Plaukiojantis numatytasis maršrutas gali išsaugoti prieinamumą pereidamas į atsarginį kelią, bet tik jei tam atsarginiam keliui leidžiama perduoti tą srautą.

Prieinamumą ir leistiną atsarginį kelią laikykite dviem atskirais reikalavimais perdavimo dokumente. Komandos, kurios juos sujungia, galiausiai ginčijasi, ar filialas turėjo sugesti, o ne tikrina, ar sutarta politika buvo įgyvendinta.

Patikrinkite, ką CE iš tikrųjų įdiegė

Konfigūracijos ketinimas ir persiuntimo būsena pakankamai dažnai išsiskiria, kad patikra priklauso perdavimui, o ne incidento peržiūrai. IOS-XE kliento krašte trys žemiau esančios komandos atsako į tris skirtingus klausimus: kas buvo pasiūlyta, kas priimta ir kas iš tikrųjų naudojama.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Vykdykite visus tris perdavimo dieną, o ne po mėnesio, kol kas nors dar prisimena, kas buvo sutarta. Pirmoji išvestis priklauso nuo soft-reconfiguration inbound arba išsaugoto maršrutų atnaujinimo; be vieno ar kito CE negali parodyti, ko atmetė. Antroji rodo priimtus ir geriausius maršrutus po politikos. Trečioji pasako, kur numatytasis maršrutas iš tikrųjų eina, ir tai yra pati naudingiausia eilutė visame perdavime.

Vykdykite tuos pačius patikrinimus antrame CE, jei svetainė prijungta dviem linijomis. Asimetriškas priėmimas tarp dviejų kraštų yra dažna priežastis "veikia iš vieno serverio, o iš kito ne", ir ji nematoma konfigūracijos skirtume, kuris atrodo simetriškas.

Įvertinkite didesnį srautą, o ne darykite prielaidą

Kartais klientui tikrai reikia interneto maršrutų informacijos VRF viduje, politikos maršrutizavimui arba centriniam išėjimui, kuris valdo pagal prefiksą. Tai reikalavimas, kurį reikia deklaruoti, apriboti ir įkainoti, o ne paslėptas numatytasis maršrutas. Jis atneša atmintį RIB ir FIB, CPU atnaujinimams, filtrų priežiūrą ir gautos lentelės šeimininką.

Talpos argumentai klysta abiem kryptimis. Visa lentelė VRF viduje nėra draudžiama, ir ji nėra nemokama. Taip pat negalima išvesti šiandienos sąnaudų iš seno maršrutų skaičiaus, o mažesnis žymių paskirstymas nepanaikina maršrutų saugojimo sąnaudų.

BGP/MPLS IP VPN specifikacija aptaria keletą interneto prieigos sprendimų šalia pačios VPN paslaugos ir neskelbia visos lentelės ar numatytojo maršruto privalomais kiekvienam klientui, ir būtent ta sekcija verta nuorodos, kai pasirodo teiginys apie "standartinę praktiką": RFC 4364.

Užbaikite perdavimą įrašydami skelbtą rinkinį, gautą rinkinį ir pasirinktą rinkinį prie suderintos išėjimo politikos, ir išbandydami vieną privatų adresatą, vieną numatytą viešą adresatą ir vieną maršruto praradimo atvejį. Pasirašytas tų trijų bandymų įrašas išsprendžia daugiau ginčų nei bet koks teiginys apie tai, ką daro dauguma tinklų.