Viens un tas pats /24 diviem klientiem? VPNv4 vajag RD un etiķeti
Divi nomnieki var reklamēt vienu un to pašu /24 tikai tāpēc, ka RD katram maršrutam piešķir savu identitāti. Etiķete atbild uz citu jautājumu: kā pārsūtīt.
Divi nomnieki numurē savu filiāli ar to pašu 10.50.0.0/24, un pēc izmaiņām viena nomnieka maršruts pazūd no pakalpojumu sniedzēja malas, kamēr otrs turpina darboties. Šī pieteikuma pamatā parasti ir maršruta atšķirēja (RD) atmešana, jo „etiķete jau identificē klientu“. Tā neidentificē. RD un etiķete atbild uz diviem dažādiem jautājumiem, un atšķirība kļūst redzama tikai tad, kad pārklājošās adreses to piespiež.
Viens maršruts tur, kur vajadzētu būt diviem
Parastais IPv4 unicast salīdzina divus ceļus uz vienu un to pašu prefiksu un instalē labāko. 10.50.0.0/24 no nomnieka A un 10.50.0.0/24 no nomnieka B ir viena atslēga, tāpēc viens uzvar, bet otrs izdzīvo tikai kā rezerves ceļš. Protokols izdarīja to, kas tam tika teikts; kontroles plaknei tika lūgts glabāt divus dažādus maršrutus zem viena identifikatora.
Rezultāts izskatās pēc trūkstoša maršruta, nevis pēc kļūdas: PE, kas zaudēja sacensībā, joprojām lokāli pārsūta savu nomnieku, tāpēc pārbaude vietnes iekšienē izdodas, bet tests starp vietnēm neizdodas. Pirms jebkuras politikas aiztikšanas saskaitiet tā prefiksa ierakstus VPNv4 tabulā.
RD pārvērš vienu atslēgu divās
Astoņu baitu maršruta atšķirējs tiek pievienots IPv4 prefiksa priekšā, un objekts, ko nes BGP, kļūst par VPN-IPv4 adresi, nevis IPv4 prefiksu. Divi nomnieki var turēt vienus un tos pašus 32 bitus, jo priekšējie 64 biti atšķiras. Pastāv formāta tipi RD, kas balstīts uz AS, un RD, kas balstīts uz adresi, un izvēle pieder sākotnējam PE. RD, kas balstīts uz AS, ir ierasts, ja PE dala AS, bet uz adresi balstītais – ja nedala.
Nelasiet RD kā dalības etiķeti. Maršruta mērķi pārvalda importu un eksportu un izlemj, kuri VRF drīkst instalēt maršrutu; RD tikai garantē, ka maršrutam ir sava identitāte. Dot katram VRF savu RD ir ierasta prakse, jo tā saglabā šo kartējumu lasāmu maršrutu pārskatā.
Etiķete ir lokāla pārsūtīšanas instrukcija
Katrs paziņojums nes arī MPLS etiķeti, un tās nozīme ir ierobežota ar maršrutētāju, kas to piešķīra. Cits PE var izsniegt to pašu numuru nesaistītam galamērķim. Tieši tāpēc etiķete nevar aizstāt klienta identitāti: numurs ir pareizs tikai blakus nākamajam lēcienam un pārsūtīšanas stāvoklim, kas to instalēja.
Piešķiršanas granularitāte atšķiras atkarībā no ieviešanas un dizaina: dažas platformas piešķir vienu etiķeti uz VRF, citas uz prefiksu, un etiķete var apzīmēt pārsūtīšanas darbību, nevis klientu. Divas dažādas etiķetes, kas sasniedz vienu un to pašu galamērķi, nav pretruna, un tas pats etiķetes numurs divos PE arī nav.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
Kāpēc viens nevar aizstāt otru
Lasīt paziņojumu nozīmē skatīties uz četrām lietām kopā: RD kvalificēto prefiksu, maršruta mērķus, nākamo lēcienu un etiķeti. Lasīt lietotāja paketi nozīmē skatīties uz steku, kas instalēts no šīs informācijas. Veselīgs dizains parāda abas puses sakrītam, un bojātā parasti viena puse ir pareiza, bet otra novecojusi. Šis salīdzinājums atdala identitātes problēmu no pārsūtīšanas problēmas.
Kārtīgais kontrasts starp kontroles un datu plakni ir mācību līdzeklis, nevis kodējuma apraksts. RFC 8277 ievieto etiķeti marķētajā NLRI, tāpēc pats paziņojums nes saiti; izmantot to pārsūtīšanai ir vēlākais, atsevišķais solis.
Kad nomnieka maršruts pazūd, pārbaudiet šādā secībā: divi VPNv4 ieraksti prefiksam, pareizais maršruta mērķis katrā, atrisināms nākamais lēciens un etiķete, kurai saņēmējam PE ir stāvoklis. Identitātes labošana ar pārsūtīšanas vērtību, vai otrādi, izturēs vienu pārbaudi un izgāzīsies nākamajā.