MPLS filialų maršrutizavimas: ko išmoksta CE ir iš ko
Filialo kraštas keičiasi maršrutais su teikėjo kraštu, o ne su tolimu filialu. Sekite vieną paketą ir patikrinkite abu perdavimus prieš priimdami objektą.
Vieno filialo hostas atidaro ryšį su kito filialo serveriu, o abi aikštelės yra už to paties valdomo MPLS 3. sluoksnio VPN. Hostas žino tik savo numatytąją šliuzą ir nieko daugiau, ir tai yra teisingai. Svarbu tai, kad vietinis kliento kraštas perduoda paketą savo teikėjo kraštui, o teikėjo VPN maršrutizavimo būsena jį pristato į filialą, kuriam priklauso paskirties priešdėlis.
Vieno paketo sekimas visu keliu yra greičiausias būdas pamatyti, kuri dalis yra kliento atsakomybė, o kuri priklauso paslaugai.
10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24
Kur baigiasi kiekvieno šuolio darbas
CE-A reikia maršruto į tolimą LAN, kuris nukreiptas į jo vietinį teikėjo prijungimą, o ne į tolimo filialo WAN adresą. Tada teikėjas neša paketą per savo branduolį naudodamas VPN maršrutizavimo būseną, o CE-B pristato jį į paskirties LAN. Nė vienu momentu hostui nereikia suprasti žymų, VRF ar kitos pusės interneto linijos.
Klaida, kuri nuolat pasitaiko bilietuose, yra B filialo WAN adreso konfigūravimas kaip kito šuolio A filiale. Abu filialai nusipirko tą pačią paslaugą, todėl atrodo, kad jie turėtų būti kaimynai. Bet jie nėra: kitas šuolis turi būti pasiekiamas per tą maršrutizavimo projektą, kurį iš tikrųjų turite, o tolimas CE paprastai yra daug šuolių atstumu už įrangos, kurios neadministruojate. Statinis maršrutas, pastatytas šia prielaida, rodomas kaip aktyvus ir nieko neišsprendžia, o tai yra blogiau nei trūkstamas maršrutas, nes lentelėje jis atrodo teisingai.
RFC 4364 atskiria kliento ir teikėjo kraštų mainus nuo teikėjo VPN maršrutų platinimo, ir tai yra būtent ta riba, apie kurią šis vadovas. Kliento užduotis yra pasakyti savo kraštui, ką jis gali pristatyti, ir priimti pasiekiamumą, kurį paslauga siūlo atgal.
Dėl ko turi susitarti perdavimas
Pasirinkite mechanizmą kartu su teikėju, o ne aplink jį. Statiniai maršrutai, BGP arba maršrutizavimo protokolo susitarimas tarp CE ir PE yra visi teisėti, o OSPF turi apibrėžtą MPLS VPN modelį tokiam perdavimui. Nė vienas iš jų nėra priežastis kurti OSPF kaimynystę tarp dviejų tolimų kliento kraštų per neapibrėžtą teikėjo branduolį, nes tai projektas, su kuriuo teikėjas nesutiko ir negali jo palaikyti.
Prieš pradedant eksploatuoti naują LAN, užsirašykite keturis dalykus: priešdėlį, vietinį tolesnį maršrutą CE, skelbimą, kurį teikėjas priims, ir maršrutus, kuriuos teikėjas grąžins. Pridėkite bet kokį filtravimą, priešdėlių limitus ar apribojimus tarp aikštelių, kuriuos nustato sutartis. Sveika kaimynystė yra informacijos mainų kanalas, ir tai nėra įrodymas, kad konkretus priešdėlis buvo priimtas; sesija gali būti aktyvi, kol jūsų naujasis potinklis sėdi filtre.
Tada sekite atsakymą. B filialui reikia maršruto atgal į šaltinio LAN, o priimančios pusės hostui reikia savo šliuzo ir savo paslaugos leidimų. Maršrutas, kuris atsiranda CE-A, nustato pusę kelionės pirmyn ir atgal, ir būtent pusė kelionės yra priežastis, kodėl viena ping testo kryptis atrodo sveika, o programa vis tiek nepavyksta.
Patikrinkite abu perdavimus prieš priėmimą
Surinkite maršrutizavimo būseną abiejuose kliento kraštuose, patvirtinkite su teikėju, kad numatyti LAN priešdėliai buvo priimti į VPN, ir tada išbandykite vieną leidžiamą programą kiekviena kryptimi. Vien maršrutų lentelės neįrodo, kad programa veikia, o vien programos testas nepasako, kuri valdymo plokštuma nepavyko, kai ji neveikia.
show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10
Skaitykite tris išvestis kartu. Pirmoji sako, kuo kraštas tiki, antroji sako, ko išmoko ir iš kurio partnerio, o trečioji sako, ką jis iš tikrųjų persiųs. Nesutarimas tarp jų paprastai yra politikos ar rekursijos problema, o ne trūkstamas skelbimas, ir verta ją išspręsti prieš prašant teikėjo atlikti tyrimą. Atneškite šias tris išvestis į pokalbį su operatoriumi, nes jos atsako į daugumą klausimų, kuriuos palaikymo inžinierius kitaip jums užduotų.
Žinokite, ko paslauga neteikia
Tai yra 3. sluoksnio maršrutizuota prieiga. Tai ne 2. sluoksnio linija, kuri išplečia transliacijas tarp biurų, todėl atradimo protokolai, nuo transliacijos priklausančios programos ir bendro segmento prielaidos su ja nekeliauja. Spausdinimas, vardų naršymas ir viskas, kas priklauso nuo vietinio segmento, turi savo projektą.
VPN atskyrimas taip pat nėra šifravimas. Žymų perjungimas laiko klientus atskirai teikėjo tinkle, ir tai nepadaro turinio konfidencialiu, jei sutartis reikalauja konfidencialumo. Ten, kur tai svarbu, tai turi užtikrinti programa arba perdangos sluoksnis.
Galiausiai laikykite paslaugos modelį užrašytą prie aikštelės maršrutizavimo konfigūracijos. Kitas inžinierius, kuris pridės potinklį, turėtų galėti perskaityti, kurie priešdėliai skelbiami, kas juos priima ir koks yra laukiamas grįžimo kelias: BGP/MPLS IP VPN specifikacija yra nuoroda modeliui, kuris slypi už viso to.