MPLS filiāļu maršrutēšana: ko CE iemācās un no kā

Vienas filiāles resursdators atver savienojumu ar otras filiāles serveri, un abas vietas atrodas aiz vienas pārvaldītas MPLS 3. slāņa VPN. Resursdators zina tikai savu noklusējuma vārteju un neko citu, un tas ir pareizi. Svarīgi ir tas, ka vietējā klienta mala nodod paketi savai pakalpojumu sniedzēja malai, un pakalpojumu sniedzēja VPN maršrutēšanas stāvoklis to nogādā filiālē, kurai pieder galamērķa prefikss.

Vienas paketes izsekošana visā ceļā ir ātrākais veids, kā redzēt, kura daļa ir klienta atbildība un kura daļa pieder pakalpojumam.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Kur beidzas katra lēciena darbs

CE-A ir nepieciešams maršruts uz attālo LAN, kas norāda uz tā vietējo pakalpojumu sniedzēja pieslēgumu, nevis uz attālās filiāles WAN adresi. Pēc tam pakalpojumu sniedzējs pārvadā paketi caur savu kodolu, izmantojot VPN maršrutēšanas stāvokli, un CE-B to nogādā mērķa LAN. Nevienā brīdī resursdatoram nav jāsaprot etiķetes, VRF vai otras puses interneta līnija.

Kļūda, kas atkārtojas biļetenos, ir B filiāles WAN adreses konfigurēšana kā nākamais lēciens A filiālē. Abas filiāles nopirka vienu un to pašu pakalpojumu, tāpēc šķiet, ka tām vajadzētu būt kaimiņiem. Bet tās nav: nākamajam lēcienam jābūt sasniedzamam caur to maršrutēšanas projektu, kas jums patiešām ir, un attālais CE parasti atrodas daudzu lēcienu attālumā aiz iekārtām, kuras jūs nepārvaldāt. Statiskais maršruts, kas veidots uz šo pieņēmumu, parādās kā aktīvs un nekur neizšķiras, un tas ir sliktāk nekā trūkstošs maršruts, jo tabulā tas izskatās pareizi.

RFC 4364 atdala klienta un pakalpojumu sniedzēja malu apmaiņu no pakalpojumu sniedzēja VPN maršrutu izplatīšanas, un tā ir tieši tā robeža, par kuru ir šī rokasgrāmata. Klienta uzdevums ir pateikt savai malai, ko tā var nogādāt, un pieņemt sasniedzamību, ko pakalpojums piedāvā pretī.

Par ko nodošanai jāvienojas

Izvēlieties mehānismu kopā ar pakalpojumu sniedzēju, nevis ap to. Statiskie maršruti, BGP vai maršrutēšanas protokola vienošanās starp CE un PE ir visas likumīgas, un OSPF ir definēts MPLS VPN modelis šādai nodošanai. Neviens no tiem nav iemesls veidot OSPF kaimiņattiecības starp divām attālām klienta malām pāri nenorādītam pakalpojumu sniedzēja kodolam, jo tas ir projekts, kam pakalpojumu sniedzējs nav piekritis un ko tas nevar atbalstīt.

Pirms jauna LAN nodošanas ekspluatācijā pierakstiet četras lietas: prefiksu, vietējo tālāko maršrutu CE, paziņojumu, ko pakalpojumu sniedzējs pieņems, un maršrutus, ko pakalpojumu sniedzējs atgriezīs. Pievienojiet jebkuru filtrēšanu, prefiksu ierobežojumus vai ierobežojumus starp vietām, ko uzliek līgums. Veselīgas kaimiņattiecības ir informācijas apmaiņas kanāls, un tas nav pierādījums, ka konkrēts prefikss ir pieņemts; sesija var būt aktīva, kamēr jūsu jaunais apakštīkls sēž filtrā.

Pēc tam izsekojiet atbildei. B filiālei ir nepieciešams maršruts atpakaļ uz avota LAN, un uztverošās puses resursdatoram ir nepieciešama sava vārteja un savas pakalpojuma atļaujas. Maršruts, kas parādās CE-A, nosaka pusi no ceļa turp un atpakaļ, un tieši puse ceļa ir iemesls, kāpēc viena ping testa virziena puse izskatās veselīga, kamēr lietotne joprojām neizdodas.

Pārbaudiet abas nodošanas pirms pieņemšanas

Savāciet maršrutēšanas stāvokli abās klienta malās, apstipriniet ar pakalpojumu sniedzēju, ka paredzētie LAN prefiksi ir pieņemti VPN, un pēc tam pārbaudiet vienu atļautu lietotni katrā virzienā. Tikai maršrutu tabulas nepierāda, ka lietotne darbojas, un tikai lietotnes tests nepasaka, kura vadības plakne neizdevās, kad tā nedarbojas.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Lasiet trīs izvades kopā. Pirmā saka, kam mala tic, otrā saka, ko tā iemācījās un no kura partnera, un trešā saka, ko tā faktiski pārsūtīs. Neatbilstība starp tām parasti ir politikas vai rekursijas problēma, nevis trūkstošs paziņojums, un to ir vērts atrisināt pirms pakalpojumu sniedzēja lūgšanas veikt izmeklēšanu. Ņemiet šīs trīs izvades līdzi sarunā ar operatoru, jo tās atbild uz lielāko daļu jautājumu, ko atbalsta inženieris citādi jums uzdotu.

Ziniet, ko pakalpojums nenodrošina

Šī ir 3. slāņa maršrutēta piekļuve. Šī nav 2. slāņa līnija, kas paplašina apraides starp birojiem, tāpēc atklāšanas protokoli, no apraides atkarīgas lietotnes un koplietota segmenta pieņēmumi ar to neceļo. Drukāšana, vārdu pārlūkošana un viss, kas atkarīgs no vietējā segmenta, prasa savu projektu.

VPN atdalīšana arī nav šifrēšana. Etiķešu komutācija tur klientus atsevišķi pakalpojumu sniedzēja tīklā, un tā nepadara saturu konfidenciālu, ja līgums prasa konfidencialitāti. Tur, kur tas ir svarīgi, to nodrošina lietotne vai pārklājuma slānis.

Visbeidzot, turiet pakalpojuma modeli pierakstītu blakus vietas maršrutēšanas konfigurācijai. Nākamajam inženierim, kas pievienos apakštīklu, vajadzētu būt iespējai izlasīt, kuri prefiksi tiek paziņoti, kas tos pieņem un kāds ir gaidītais atgriešanās ceļš: BGP/MPLS IP VPN specifikācija ir atsauce modelim, kas ir aiz visa šī.