RD ja RT MPLS-VPN:ssä: yksilöllisyys ja tuontikäytäntö
Reitinerottaja tekee päällekkäisistä etuliitteistä yksilöllisiä, ja reittikohde päättää, mitkä reitit VRF saa tuoda. Seuraa yhtä MPLS-reittiä molemmissa rooleissa.
Kaksi asiakassivustoa voi mainostaa 10.20.0.0/24 ja molemmat pysyvät kelvollisina yhden operaattoriverkon sisällä. Reitinerottaja pitää nämä mainokset erillään; reittikohde päättää, mikä asiakkaan VRF saa ottaa kopion. Ne seisovat konfiguraatiossa vierekkäin ja tekevät täysin eri tehtäviä. Niiden sekoittaminen johtaa muutoksiin, jotka näyttävät järkeviltä eivätkä korjaa mitään.
Seuraa yhtä reittiä asiakkaan reunasta etäiseen VRF:ään ja jako muuttuu konkreettiseksi: identiteetti liitetään ennen kuin reitti tulee BGP:hen, ja jakelukäytäntö arvioidaan, kun reitti saavuttaa vastaanottavan operaattorin reunan.
VPN-IPv4-reitti on RD plus IPv4-etuliite
RFC 4364 määrittelee VPN-IPv4-osoiteperheen kahdeksan tavun reitinerottajaksi, jota seuraa neljän tavun IPv4-osoite. RD lisätään asiakkaan etuliitteen eteen, joten kaksi samanlaista etuliitettä eri sivustoilta muuttuu kahdeksi eri BGP-reitiksi.
Tämä rakenne on koko yksilöllisyysmekanismi. Operaattorin ei tarvitse saada asiakkaita sopimaan päällekkäisyydettömästä osoiteavaruudesta, eikä yhden sivuston reitti voi hiljaa korvata toisen sivuston samanlaista etuliitettä.
Itse RD-muoto on järjestelmänvalvojan valitsema arvo, tavallisesti autonomisen järjestelmän numero ja paikallinen numero. Sen numeerinen muoto on käytäntö, ei merkki siitä, että kaksi kenttää jakaisi merkityksen reittikohteen kanssa, joka sattuu käyttämään samoja numeroita.
RD tekee päällekkäisistä etuliitteistä erotettavia
Tarkastellaan kahta mainosta samasta etuliitteestä. Sivusto A kantaa RD:tä 65000:101 ja sivusto B kantaa RD:tä 65000:202, molemmat etuliitteelle 10.20.0.0/24. BGP:ssä on nyt kaksi VPN-IPv4-reittiä, joita voidaan verrata, suodattaa ja valita toisistaan riippumatta.
RD ei kerro, minkä VRF:n pitäisi vastaanottaa kumpikaan reiteistä, eikä se tunnista asiakasta tai palvelua. Se on reitin identiteettikenttä, ei jäsenluettelo. VRF:n oma RD ei vaadi vastaavuutta sen tuoman reitin RD:n kanssa.
Siksi RD:n muuttaminen toisen sivuston numeron mukaiseksi ei korjaa mitään. Jos reitti puuttuu vastapuolelta, numeroiden sovittaminen luo toisen identiteettiongelman sen sijaan, että se korjaisi tuontipäätöksen.
RT on BGP-attribuutti, ei paketin tunniste
Vientikäytäntö liittää reittiin yhden tai useamman reittikohteen BGP:n laajennettuina yhteisöattribuutteina. Vastaanottava operaattorin reuna vertaa näitä attribuutteja kunkin VRF:n tuontikäytäntöön. RT kulkee reitin mukana ohjaustason läpi. Vertailu tapahtuu kokonaan reitityskäytännössä ennen kuin yhtään asiakaspakettia välitetään.
Asiakkaan datapaketit eivät kanna RT:tä. Kun reitti on asennettu VRF:ään, välitys käyttää kyseisen VRF:n taulukkoa ja sitä MPLS-tunnistepinoa, jonka arkkitehtuuri määrittää. Operaattorin reuna ei lue reittikohdetta jokaisesta asiakaspaketista.
Reitti voi kantaa useita RT:itä ja VRF voi tuoda useita. Konfiguraatio näyttää usein lyhyeltä lohkolta:
vrf definition CUST-A
rd 65000:101
address-family ipv4
route-target export 65000:500
route-target import 65000:500
Lue tämä lohko kahtena erillisenä lausumana. Vientirivi määrittää, mitä liitetään tästä VRF:stä lähteviin reitteihin; tuontirivi määrittää, mitä tämä VRF on valmis harkitsemaan. Numeroiden täsmääminen on kätevää, ei pakollista.
Tuontikelpoisuus ei ole asennus
Reitti voi olla kelpoinen VRF:lle ja silti olla näkymättä sen välitystaulukossa. Kelpoisuus on suodatin; sen jälkeen tavallinen BGP:n päätösprosessi vertaa kelpoisia reittejä ja valitsee yhden. Vanhempi tai vähemmän suosittu reitti voi hävitä toiselle kelpoiselle polulle.
Tarkista valittu reitti, älä vain tuontikäytäntöä. VRF, joka tuo RT:n 65000:500 eikä näytä reittiä etuliitteelle 10.20.0.0/24, on ehkä vastaanottanut reitin ja hylännyt sen valinnassa, tai se ei ehkä ole saanut sitä lainkaan.
Tämä ero on merkityksellinen myös silloin, kun odottamaton etuliite ilmestyy. Liian laaja tuontikäytäntö voi vetää sisään reittejä, joita sivusto ei aikonut käyttää, eikä RD:n yksilöllisyys estä sitä lainkaan. Jakelun laajuus on RT-käytännön kysymys.
Jäljitä puuttuva reitti ohjaustason järjestyksessä
Aloita mainoksesta: viekö lähde-VRF aiotun RT:n, ja onko reitti olemassa VPN-IPv4-reittinä reittihypyssä tai vastaanottavassa PE:ssä? Tarkista sitten attribuutti sellaisena kuin se vastaanotettiin, ei sellaisena kuin se on määritetty lähettäjällä.
Vertaa seuraavaksi vastaanottavan VRF:n tuontiluetteloa reitin todellisiin RT-arvoihin. Tarkastele lopuksi valittua reittiä kyseisessä VRF:ssä ja tunnisteen sidontaa. Jokainen vaihe vastaa eri kysymykseen, ja hyppääminen RD:hen ohittaa yleensä juuri sen, joka on väärä.
Kirjaa RD, viety RT, tuotu RT ja valittu seuraava hyppy toimivalle ja vialliselle sivustolle. Neljä arvoa vierekkäin muuttaa epämääräisen “VPN ei välitä reittejä” täsmälliseksi ohjaustason vaiheeksi, joka eroaa.