MPLS-filia vojigo: kion la CE lernas kaj de kiu

Gastiganto en unu filio malfermas konekton al servilo en alia, kaj ambaŭ ejoj staras malantaŭ la sama administrata MPLS VPN de tavolo 3. La gastiganto konas nur sian propran implicitan enirejon kaj nenion alian, kio estas ĝuste. Gravas, ke la loka klienta rando transdonas la pakaĵon al sia provizanta rando, kaj ke la VPN-vojiga stato de la provizanto liveras ĝin al la filio, kiu posedas la celan prefikson.

Sekvi unu pakaĵon laŭ la vojo estas la plej rapida maniero vidi, kiu parto estas respondeco de la kliento kaj kiu parto apartenas al la servo.

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

Kie finiĝas la tasko de ĉiu salto

CE-A bezonas itineron por la malproksima LAN, kiu montras al sia loka provizanta konekto, ne al la WAN-adreso de la malproksima filio. Poste la provizanto portas la pakaĵon tra sia propra kerno per la VPN-vojiga stato, kaj CE-B liveras ĝin al la cela LAN. Neniam gastiganto devas kompreni etikedojn, VRF-ojn aŭ la interretan cirkviton de la alia flanko.

La eraro, kiu ripete aperas en biletoj, estas agordi la WAN-adreson de filio B kiel la sekvan salton en filio A. Ambaŭ filioj aĉetis la saman servon, do ŝajnas, kvazaŭ ili devus esti najbaroj. Ili ne estas: sekva salto devas esti atingebla per la vojiga dizajno, kiun vi vere havas, kaj la malproksima CE kutime troviĝas multajn saltojn for malantaŭ aparataro, kiun vi ne administras. Statika itinero konstruita sur tiu supozo montriĝas kiel aktiva kaj solviĝas al nenio, kio estas pli malbona ol mankanta itinero, ĉar ĝi aspektas ĝusta en la tabelo.

RFC 4364 apartigas la interŝanĝon inter klienta kaj provizanta rando disde la disdonado de VPN-itineroj fare de la provizanto, kaj tio estas ĝuste la limo, pri kiu temas ĉi tiu gvidilo. La tasko de la kliento estas diri al sia rando, kion ĝi povas liveri, kaj akcepti la atingeblon, kiun la servo proponas reciproke.

Pri kio devas interkonsenti la transdono

Elektu la mekanismon kun la provizanto, ne ĉirkaŭ ĝi. Statikaj itineroj, BGP aŭ vojiga protokola interkonsento inter CE kaj PE estas ĉiuj legitimaj, kaj OSPF havas difinitan MPLS VPN-modelon por tia transdono. Neniu el ili estas kaŭzo konstrui OSPF-najbarecon inter du malproksimaj klientaj randoj tra neprecizigita provizanta kerno, ĉar tio estas dizajno, al kiu la provizanto ne konsentis kaj kiun ĝi ne povas subteni.

Antaŭ ol nova LAN ekfunkcios, skribu kvar aferojn: la prefikson, la lokan pluan itineron ĉe la CE, la anoncon, kiun la provizanto akceptos, kaj la itinerojn, kiujn la provizanto resendos. Aldonu ajnan filtradon, prefiksajn limojn aŭ limigojn inter ejoj, kiujn trudas la kontrakto. Sana najbareco estas kanalo por interŝanĝi informojn, kaj ĝi ne estas pruvo, ke aparta prefikso estis akceptita; la sesio povas esti aktiva dum via nova subreto sidas en filtrilo.

Poste sekvu la respondon. Filio B bezonas itineron reen al la fonta LAN, kaj la gastiganto ĉe la riceva flanko bezonas sian propran enirejon kaj siajn proprajn servajn permesojn. Itinero, kiu aperas ĉe CE-A, starigas duonon da rondiro, kaj duono da rondiro estas la kialo, ke unu direkto de ping-testo aspektas sana dum la aplikaĵo ankoraŭ malsukcesas.

Kontrolu ambaŭ transdonojn antaŭ la aprobo

Kolektu la vojigan staton ĉe ambaŭ klientaj randoj, konfirmu kun la provizanto, ke la celataj LAN-prefiksoj estis akceptitaj en la VPN, kaj poste testu unu permesitan aplikaĵon en ĉiu direkto. Itinertabeloj solaj ne pruvas, ke la aplikaĵo funkcias, kaj aplikaĵa testo sola ne diras al vi, kiu rega ebeno malsukcesis, kiam ĝi ne funkcias.

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

Legu la tri eligojn kune. La unua diras, kion la rando kredas, la dua diras, kion ĝi lernis kaj de kiu samtavolano, kaj la tria diras, kion ĝi efektive plusendos. Malkonsento inter ili estas kutime politika aŭ rekursia problemo prefere ol mankanta anonco, kaj indas solvi ĝin antaŭ ol peti la provizanton esplori. Portu tiujn tri eligojn al la interparolo kun la operatoro, ĉar ili respondas la plejmulton de la demandoj, kiujn subtena inĝeniero alie demandus al vi.

Sciu, kion la servo ne provizas

Ĉi tio estas vojigita aliro de tavolo 3. Ĝi ne estas cirkvito de tavolo 2, kiu etendas dissendojn inter oficejoj, do malkovraj protokoloj, dissendo-dependaj aplikaĵoj kaj supozoj pri komuna segmento ne vojaĝas kun ĝi. Presado, nomfoliumado kaj io ajn, kio dependas de loka segmento, bezonas sian propran dizajnon.

VPN-apartigo ankaŭ ne estas ĉifrado. Etikeda ŝaltado tenas klientojn aparte ene de la reto de la provizanto, kaj ĝi ne faras la ŝarĝon konfidenca, se la kontrakto postulas konfidencecon. Kie tio gravas, la aplikaĵo aŭ tavolo super ĝi devas provizi ĝin.

Fine, tenu la servomodelon skribita apud la vojiga agordo de la ejo. La sekva inĝeniero, kiu aldonos subreton, devus povi legi, kiuj prefiksoj estas anoncitaj, kiu akceptas ilin, kaj kio estas la atendata revena vojo: la specifikaĵo BGP/MPLS IP VPN estas la referenco por la modelo malantaŭ ĉio ĉi.