OSPF-reittityyppi VPN:n yli: ei aina ulkoinen

Asiakkaan etuliite kulkee palveluntarjoajan pilven läpi BGP VPN -reittinä ja saapuu kaukaiseen toimipaikkaan näyttäen ulkoiselta OSPF-reitiltä, mitä monet insinöörit odottavat, eikä se ole ainoa mahdollinen lopputulos. Se, mitä kaukana oleva CE näkee, riippuu OSPF-verkkotunnuksesta, josta etuliite tuli, ja sen alkuperäisestä reittityypistä, ja molemmat kulkevat VPN-reitin mukana. Oletus, että jokainen uudelleenjaettu etuliite muuttuu tyypiksi 5, johtaa preferenssimuutoksiin, jotka eivät voi toimia. Vertaa ensin verkkotunnuksen tunnistetta, ei hallinnollista etäisyyttä.

PE-CE-malli kantaa riittävästi kontekstia, jotta vastaanottava PE voi rakentaa OSPF-ilmoituksen uudelleen sen sijaan, että keksisi sen.

Mikä kulkee reitin mukana

RFC 4577 määrittelee OSPF-attribuutit, jotka liittyvät VPN-reittiin: verkkotunnuksen tunniste, metriikka ja lähtötoimipaikan reittityyppi. Vastaanottava PE käyttää niitä päättääkseen, miltä kelvollisen etuliitteen pitäisi näyttää sen paikalliselle OSPF-prosessille. Ilman näitä attribuutteja kaukaisella PE:llä ei olisi perustaa millekään muulle kuin ulkoiselle uudelleenjaolle. Siksi reitti voi saapua alueiden välisenä LSA:na, vaikka BGP kuljetti sitä välissä.

Myös alueen tyyppi on tärkeä. Stub- tai NSSA-alue rajoittaa, mitkä LSA:t voivat tulla sisään, joten sama VPN-reitti voidaan esittää eri tavoin riippuen siitä, missä vastaanottava OSPF-instanssi sijaitsee. Määritetty vientikäytäntö voi myös ohittaa oletusesityksen, mikä on tarkoituksellinen valinta eikä sivutuote.

Sama verkkotunnus, erilainen esitys

Saman verkkotunnuksen alueen sisäinen tai alueiden välinen reitti saapuu yleensä kaukaiseen toimipaikkaan alueiden välisenä reittinä eli tyypin 3 LSA:na. Toisen verkkotunnuksen etuliite, lähde, joka ei koskaan puhunut OSPF:ää, tai alun perin ulkoinen OSPF-ilmoitus seuraa sen sijaan ulkoisia sääntöjä, ja siellä tyyppi 5 ja sen NSSA-vastine ilmestyvät. Molemmat käyttäytymiset ovat oikein; syöte eroaa. Vertaa verkkotunnusten tunnisteita ja ilmoitettuja attribuutteja ennen kuin kosket preferenssiarvoihin.

Hallinnollinen etäisyys valitsee lähteiden välillä yhdellä reitittimellä. Se ei kirjoita LSA-tyyppiä uudelleen eikä luo puuttuvaa verkkotunnussuhdetta.

Milloin sham link on oikea vastaus

Kuvittele kaksi toimipaikkaa samalla alueella, jotka yhdistää suora takaporttilinkki. OSPF pitää tämän alueen sisäisen polun sen sijaan, että käyttäisi palveluntarjoajan tarjoamaa alueiden välistä polkua, vaikka määritetyt kustannukset tekisivät palveluntarjoajan polusta houkuttelevan. Sham link edustaa alueen sisäistä suhdetta VPN:n yli, jotta kustannukset voivat osallistua päätökseen. Se on olemassa juuri tätä polunvalintaongelmaa varten, ei tehdäkseen jokaisesta saman verkkotunnuksen reitistä sisäistä.

Sham link tarvitsee saavutettavat päätepisteet ja molemminpuolisen määrityksen molemmille PE:ille. Sen määrittäminen vain toiselle puolelle tuottaa suhteen, joka ei koskaan muodostu, ja reititystaulu säilyttää vanhan preferenssinsä, mikä näyttää siltä kuin ominaisuus ei tekisi mitään.

Älä riko silmukkasuojausta

PE-CE-malli asettaa DN-bitin jakamilleen reiteille, jotta etuliite ei voi palata toisen CE:n kautta ja tulla uudelleenjaetuksi toista kertaa. Tämä suojaus estää etuliitettä kiertämästä silmukassa toimipaikkojen välillä, jotka jakavat OSPF-verkkotunnuksen. Sen poistaminen tai huomiotta jättäminen reitin saamiseksi näyttämään sisäiseltä voi luoda juuri sen silmukan, jonka estämiseksi se suunniteltiin. Kun etuliite näyttää väärältä, käsittele DN-bittiä tietona äläkä esteenä.

Sama varovaisuus koskee uudelleenjakosuodattimia ja reittikarttoja, jotka poistavat yhteisöjä. Jokainen poistaa kontekstia, jota kaukana oleva puoli tarvitsee, ja tuloksena oleva ilmoitus voi näyttää uskottavalta vaikka on väärä. Muuta yhtä attribuuttia kerrallaan ja tarkista, mitä kaukana oleva CE todella asentaa.

Tarkista sitten kaukaisesta toimipaikasta: LSA:n tyyppi, ilmoittava reititin ja valittu polku. Se näyttö vastaa kysymykseen, jonka tiketti esitti.