In host yn ien filiaal iepenet in ferbining mei in server yn in oar, en beide plakken steane achter deselde beheard MPLS VPN fan laach 3. De host ken allinnich syn eigen standertgateway en neat oars, wat korrekt is. Wat fan belang is, is dat de lokale klantkant it pakket oerdraacht oan syn providerkant, en dat de VPN-routingsteat fan de provider it by it filiaal bringt dat it bestemmingsprefiks besit.

Ien pakket troch it paad folgje is de fluchste manier om te sjen hokker diel ferantwurdlikheid fan de klant is en hokker diel by de tsjinst heart.

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

Wêr't it wurk fan elke hop einiget

CE-A hat in rûte nedich foar it fiere LAN dy't nei syn lokale provideroansluting wiist, net nei it WAN-adres fan it fiere filiaal. Dêrnei draacht de provider it pakket troch syn eigen kearn mei de VPN-routingsteat, en CE-B leveret it op it bestemmings-LAN. Op gjin inkeld stuit hoecht in host labels, VRF's of it ynternetkring fan de oare kant te begripen.

De flater dy't hieltyd wer yn tickets opkomt is it WAN-adres fan filiaal B as folgjende hop yn filiaal A konfigurearje. Beide filialen hawwe deselde tsjinst kocht, dat it fielt as soene se buorlju wêze moatte. Dat binne se net: in folgjende hop moat berikber wêze fia it routingûntwerp dat jo echt hawwe, en de fiere CE stiet meastentiids in protte hops fierder efter apparatuer dy't jo net beheare. In statyske rûte boud op dy oanname ferskynt as aktyf en lost op yn neat, wat slimmer is as in ûntbrekkende rûte, want yn 'e tabel liket er korrekt.

RFC 4364 skiedt de útwikseling tusken klant- en providerkant fan 'e distribúsje fan VPN-rûtes troch de provider, en dat is krekt de grins dêr't dizze hânlieding oer giet. De taak fan 'e klant is syn kant fertelle wat er leverje kin en de berikberens akseptearje dy't de tsjinst werom biedt.

Wêr't de oerdracht it oer iens wurde moat

Kies it meganisme mei de provider, net om har hinne. Statyske rûtes, BGP of in routingprotokol-oerienkomst tusken CE en PE binne allegear legit, en OSPF hat in definiearre MPLS VPN-model foar dy oerdracht. Gjin fan dizze is in reden om in OSPF-buorskip te bouwen tusken twa fiere klantkanten oer in net oantsjutte providerkearn, want dat is in ûntwerp dat de provider net akseptearre hat en net stypje kin.

Foardat in nij LAN yn bedriuw giet, skriuw fjouwer dingen op: it prefiks, de lokale folgjende rûte op 'e CE, de oankundiging dy't de provider akseptearret, en de rûtes dy't de provider weromstjoert. Foegje alle filterjen, prefikslimit of beheiningen tusken plakken ta dy't it kontrakt oplizze. In sûne buorskip is in kanaal foar it útwikseljen fan ynformaasje, en it is gjin bewiis dat in bepaald prefiks akseptearre is; de sesje kin oan wêze wylst jo nije subnet yn in filter sit.

Folgje dan it antwurd. Filiaal B hat in rûte werom nei it boarne-LAN nedich, en de host oan 'e ûntfangende kant hat syn eigen gateway en syn eigen tsjinstrjochten nedich. In rûte dy't op CE-A ferskynt, festiget de helte fan in hinne-en-werom, en de helte fan in hinne-en-werom is wêrom't ien rjochting fan in ping-test sûn liket wylst de applikaasje noch altyd mislearret.

Kontrolearje beide oerdrachten foar it goedkarren

Sammele de routingsteat oan beide klantkanten, befêstigje mei de provider dat de bedoelde LAN-prefiksen yn 'e VPN akseptearre binne, en test dan ien tastiene applikaasje yn elke rjochting. Allinnich routingtabellen bewiist net dat de applikaasje wurket, en in applikaasjetest allinnich fertelt jo net hokker kontrôleflak mislearre doe't it net wurke.

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

Lês de trije útfieringen tegearre. De earste seit wat de kant leaut, de twadde seit wat er leard hat en fan hokker peer, en de tredde seit wat er eins trochstjoere sil. Unienigens tusken har is meastentiids in belieds- of rekursjeprobleem ynstee fan in ûntbrekkende oankundiging, en it is de muoite wurdich om it op te lossen foar't de provider frege wurdt om te ûndersykjen. Nim dy trije útfieringen mei nei it petear mei de ferfierder, want se beantwurdzje de measte fragen dy't in stipe-yngenieur oars stelle soe.

Wit wat de tsjinst net biedt

Dit is rûtearre tagong fan laach 3. Dit is gjin kring fan laach 2 dy't útstjoerings tusken kantoaren útwreidet, dat ûntdekkingsprotokollen, applikaasjes dy't fan útstjoering ôfhingje en oannames oer dielde segminten reizgje net mei. Printsjen, nammeblêdzjen en alles wat fan in lokaal segmint ôfhinget, hat syn eigen ûntwerp nedich.

VPN-skieding is ek gjin fersifering. Labelskeakeling hâldt klanten apart binnen it netwurk fan de provider, en it makket de lading net fertroulik as it kontrakt fertroulikheid easket. Wêr't dat fan belang is, moat de applikaasje of in oerlizze laach it leverje.

Hâld úteinlik it tsjinstmodel opskreaun njonken de routingkonfiguraasje fan it plak. De folgjende yngenieur dy't in subnet taheakket, moat lêze kinne hokker prefiksen oankundige wurde, wa't se akseptearret en wat it ferwachte werompaad is: de BGP/MPLS IP VPN-spesifikaasje is de referinsje foar it model efter dit alles.

Relatearre artikelen