Yhden sivukonttorin isäntä avaa yhteyden toisen sivukonttorin palvelimeen, ja molemmat kohteet ovat saman hallitun MPLS VPN:n takana 3. kerroksessa. Isäntä tuntee vain oman oletusyhdyskäytävänsä eikä mitään muuta, mikä on oikein. Ratkaisevaa on, että paikallinen asiakasreuna luovuttaa paketin omalle palveluntarjoajan reunalleen ja että palveluntarjoajan VPN-reititystila toimittaa sen sivukonttorille, joka omistaa kohde-etuliitteen.

Yhden paketin seuraaminen polulla on nopein tapa nähdä, mikä osa on asiakkaan vastuulla ja mikä osa kuuluu palveluun.

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

Mihin kunkin hypyn työ päättyy

CE-A tarvitsee reitin kauko-LANiin, joka osoittaa sen paikalliseen palveluntarjoajaliitäntään, ei kaukokonttorin WAN-osoitteeseen. Sen jälkeen palveluntarjoaja kuljettaa paketin oman runkonsa läpi VPN-reititystilan avulla, ja CE-B toimittaa sen kohde-LANiin. Missään vaiheessa isännän ei tarvitse ymmärtää tarroja, VRF:iä tai vastapuolen internet-piiriä.

Virhe, joka toistuu tiketeissä jatkuvasti, on sivukonttorin B WAN-osoitteen määrittäminen seuraavaksi hypyksi sivukonttorissa A. Molemmat sivukonttorit ostivat saman palvelun, joten tuntuu kuin niiden pitäisi olla naapureita. Ne eivät ole: seuraavan hypyn on oltava tavoitettavissa sen reitityssuunnittelun kautta, joka sinulla todella on, ja kaukainen CE on yleensä monen hypyn päässä laitteiden takana, joita et hallinnoi. Tähän olettamaan rakennettu staattinen reitti näkyy aktiivisena eikä ratkea mihinkään, mikä on pahempaa kuin puuttuva reitti, koska se näyttää taulukossa oikealta.

RFC 4364 erottaa asiakas- ja palveluntarjoajareunan välisen vaihdon palveluntarjoajan VPN-reittien jakelusta, ja juuri se on se raja, jota tämä käsikirja käsittelee. Asiakkaan tehtävä on kertoa reunalleen, mitä se voi toimittaa, ja hyväksyä tavoitettavuus, jota palvelu tarjoaa takaisin.

Mistä luovutuksen on sovittava

Valitse mekanismi yhdessä palveluntarjoajan kanssa, älä sen ohi. Staattiset reitit, BGP tai reititysprotokollasopimus CE:n ja PE:n välillä ovat kaikki hyväksyttäviä, ja OSPF:llä on määritelty MPLS VPN -malli tällaiseen luovutukseen. Mikään niistä ei ole syy rakentaa OSPF-naapuruutta kahden kaukaisen asiakasreunan välille määrittelemättömän palveluntarjoajarungon yli, sillä se on suunnittelu, johon palveluntarjoaja ei ole suostunut eikä voi tukea.

Ennen kuin uusi LAN otetaan käyttöön, kirjoita neljä asiaa: etuliite, paikallinen jatkoreitti CE:llä, ilmoitus, jonka palveluntarjoaja hyväksyy, ja reitit, jotka palveluntarjoaja palauttaa. Lisää kaikki suodatus, etuliiterajat tai toimipaikkojen väliset rajoitukset, joita sopimus edellyttää. Terve naapuruus on kanava tiedon vaihtamiseen, eikä se ole todiste siitä, että tietty etuliite on hyväksytty; istunto voi olla ylhäällä, kun uusi aliverkkosi istuu suodattimessa.

Seuraa sitten vastausta. Sivukonttori B tarvitsee reitin takaisin lähde-LANiin, ja vastaanottavan puolen isäntä tarvitsee oman yhdyskäytävänsä ja omat palveluoikeutensa. CE-A:lle ilmestyvä reitti muodostaa puoli edestakaista matkaa, ja puoli matkaa on syy siihen, miksi ping-testin toinen suunta näyttää terveeltä, vaikka sovellus edelleen epäonnistuu.

Tarkista molemmat luovutukset ennen hyväksyntää

Kerää reititystila molemmilta asiakasreunoilta, vahvista palveluntarjoajalta, että aiotut LAN-etuliitteet hyväksyttiin VPN:ään, ja testaa sitten yhtä sallittua sovellusta kumpaankin suuntaan. Pelkät reititystaulukot eivät todista, että sovellus toimii, eikä pelkkä sovellustesti kerro, mikä ohjaustaso epäonnistui, kun se ei toimi.

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

Lue kolme tulostetta yhdessä. Ensimmäinen kertoo, mihin reuna uskoo, toinen kertoo, mitä se oppi ja miltä vertaiselta, ja kolmas kertoo, mitä se todella välittää. Niiden välinen ristiriita on yleensä käytäntö- tai rekursio-ongelma eikä puuttuva ilmoitus, ja se kannattaa ratkaista ennen kuin palveluntarjoajaa pyydetään tutkimaan. Ota nämä kolme tulostetta operaattorin puheluun, sillä ne vastaavat useimpiin kysymyksiin, joita tukikeskuksen insinööri muuten kysyisi sinulta.

Tiedä, mitä palvelu ei tarjoa

Tämä on reititetty 3. kerroksen pääsy. Tämä ei ole 2. kerroksen piiri, joka laajentaa lähetykset toimistojen välille, joten löytöprotokollat, lähetyksistä riippuvat sovellukset ja jaetun segmentin oletukset eivät kulje sen mukana. Tulostus, nimien selaus ja kaikki paikallisesta segmentistä riippuva tarvitsevat oman suunnittelunsa.

VPN:n erottelu ei ole salaustakaan. Tarrakytkentä pitää asiakkaat erillään palveluntarjoajan verkossa, eikä se tee hyötykuormasta luottamuksellista, jos sopimus vaatii luottamuksellisuutta. Missä sillä on merkitystä, sovelluksen tai päällekkäisverkon on tarjottava se.

Pidä lopuksi palvelumalli kirjattuna kohteen reitityskonfiguraation viereen. Seuraavan insinöörin, joka lisää aliverkon, pitäisi pystyä lukemaan, mitkä etuliitteet ilmoitetaan, kuka ne hyväksyy ja mikä on odotettu paluupolku: BGP/MPLS IP VPN -määritelmä on viite mallille, joka on kaiken tämän takana.

Aiheeseen liittyvät artikkelit