MPLS-i harude marsruutimine: mida CE õpib ja kellelt

Ühe haru host avab ühenduse teise haru serveriga ning mõlemad saidid asuvad sama hallatava MPLS VPN-i taga 3. kihil. Host teab ainult oma oletusyhdyskäytävää ja mitte midagi muud, mis on õige. Oluline on see, et kohalik kliendi serv annab paketi edasi oma teenusepakkuja servale ning teenusepakkuja VPN-i marsruutimise olek toimetab selle harule, millele sihteesliide kuulub.

Ühe paketi jälgimine mööda teed on kiireim viis näha, milline osa on kliendi vastutus ja milline osa kuulub teenusele.

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

Kus iga hüppe töö lõpeb

CE-A vajab kaugema LAN-i jaoks marsruuti, mis osutab tema kohalikule teenusepakkuja ühendusele, mitte kaugema haru WAN-aadressile. Seejärel kannab teenusepakkuja paketti oma tuumas, kasutades VPN-i marsruutimise olekut, ja CE-B toimetab selle siht-LAN-i. Ühelgi hetkel ei pea host mõistma silte, VRF-e ega teise poole internetiühendust.

Viga, mis piletites ikka ja jälle esineb, on haru B WAN-aadressi seadistamine haru A järgmiseks hüppeks. Mõlemad harud ostsid sama teenuse, seega tundub, nagu peaksid nad olema naabrid. Nad ei ole: järgmine hüpe peab olema kättesaadav selle marsruutimiskavandi kaudu, mis teil tegelikult on, ja kaugem CE asub tavaliselt paljude hüpete kaugusel seadmete taga, mida te ei halda. Sellele eeldusele ehitatud staatiline marsruut kuvatakse aktiivsena ja ei lahene millekski, mis on hullem kui puuduv marsruut, sest tabelis näeb see õige välja.

RFC 4364 eraldab kliendi ja teenusepakkuja serva vahelise vahetuse teenusepakkuja VPN-marsruutide levitamisest ning see on täpselt see piir, millest see käsiraamat räägib. Kliendi ülesanne on öelda oma servale, mida see suudab kohale toimetada, ja võtta vastu kättesaadavus, mida teenus vastu pakub.

Milles peab üleandmine kokku leppima

Valige mehhanism koos teenusepakkujaga, mitte sellest mööda. Staatilised marsruudid, BGP või marsruutimisprotokolli kokkulepe CE ja PE vahel on kõik legitiimsed ning OSPF-il on sellise üleandmise jaoks määratletud MPLS VPN-i mudel. Ükski neist ei ole põhjus ehitada OSPF-i naabersuhet kahe kaugema kliendi serva vahel üle täpsustamata teenusepakkuja tuuma, sest see on kavand, millega teenusepakkuja ei ole nõustunud ja mida ta ei suuda toetada.

Enne kui uus LAN tööle hakkab, kirjutage üles neli asja: eesliide, kohalik edasine marsruut CE-l, teadaanne, mille teenusepakkuja vastu võtab, ja marsruudid, mille teenusepakkuja tagastab. Lisage kõik filtreerimine, eesliidete piirangud või saidiüleste piirangud, mida leping seab. Terve naabersuhe on info vahetamise kanal ja see ei ole tõend, et konkreetne eesliide vastu võeti; sessioon võib olla üleval, samal ajal kui teie uus alamvõrk istub filtris.

Seejärel jälgige vastust. Haru B vajab marsruuti tagasi lähtevõrku ja vastuvõtva poole host vajab oma väravat ning oma teenuselube. CE-A-l ilmuv marsruut loob poole edasi-tagasi teekonnast ja pool teekonda on põhjus, miks ping-testi üks suund näeb terve välja, samal ajal kui rakendus ikka veel ebaõnnestub.

Kontrollige mõlemat üleandmist enne heakskiitmist

Koguge marsruutimise olek mõlemas kliendi servas, kinnitage teenusepakkujaga, et kavandatud LAN-i eesliited võeti VPN-i vastu, ja seejärel testige igas suunas ühte lubatud rakendust. Ainuüksi marsruutimistabelid ei tõesta, et rakendus töötab, ja ainult rakenduse test ei ütle teile, milline juhtimistasand ebaõnnestus, kui see ei tööta.

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

Lugege kolme väljundit koos. Esimene ütleb, mida serv usub, teine ütleb, mida ta õppis ja milliselt peerilt, ja kolmas ütleb, mida ta tegelikult edasi saadab. Nendevaheline lahknevus on tavaliselt poliitika või rekursiooni probleem, mitte puuduv teadaanne, ja seda tasub lahendada enne, kui teenusepakkujalt uurimist palutakse. Võtke need kolm väljundit operaatoriga peetavale kõnele kaasa, sest need vastavad enamikule küsimustele, mida tugiinsener muidu teilt küsiks.

Teadke, mida teenus ei paku

See on marsruuditud 3. kihi juurdepääs. See ei ole 2. kihi ring, mis laiendab leviedastust kontorite vahel, seega avastamisprotokollid, leviedastusest sõltuvad rakendused ja jagatud segmendi eeldused ei sõida sellega kaasa. Printimine, nimede sirvimine ja kõik, mis sõltub kohalikust segmendist, vajavad oma kavandit.

VPN-i eraldamine ei ole samuti krüpteerimine. Siltide kommuteerimine hoiab kliendid teenusepakkuja võrgu sees lahus ega muuda kandevõimet konfidentsiaalseks, kui leping nõuab konfidentsiaalsust. Kus see loeb, peab selle tagama rakendus või pealiskihi lahendus.

Lõpuks hoidke teenusemudel kirjas saidi marsruutimiskonfiguratsiooni kõrval. Järgmine insener, kes alamvõrgu lisab, peaks saama lugeda, millised eesliited on teada antud, kes need vastu võtab ja milline on oodatav tagasitee: BGP/MPLS IP VPN-i spetsifikatsioon on viide mudelile, mis selle kõige taga on.