Sama /24 kahele kliendile? VPNv4 vajab RD-d ja silti
Kaks üürnikku saavad sama /24 teavitada ainult sellepärast, et RD annab igale marsruudile oma identiteedi. Silt vastab teisele küsimusele: kuidas edasi suunata.
Kaks üürnikku nummerdavad oma haruüksuse sama 10.50.0.0/24-ga ja pärast muudatust kaob ühe üürniku marsruut teenusepakkuja servast, samal ajal kui teine jätkab töötamist. Selle pileti taga olev lihtsustus on tavaliselt marsruudieristaja (RD) ärajätmine, sest „silt identifitseerib kliendi juba“. Ei identifitseeri. RD ja silt vastavad kahele erinevale küsimusele ning vahe muutub nähtavaks alles siis, kui kattuvad aadressid selle peale suruvad.
Üks marsruut seal, kus peaks olema kaks
Tavaline IPv4 unicast võrdleb kahte teed sama prefiksi suunas ja paigaldab parema. 10.50.0.0/24 üürnikult A ja 10.50.0.0/24 üürnikult B on üks võti, seega võidab üks ja teine jääb püsima ainult varuteena. Protokoll tegi seda, mida talle öeldi; kontrolltasandilt paluti hoida kahte erinevat marsruuti ühe identifikaatori all.
Tulemus näeb välja nagu puuduv marsruut, mitte nagu viga: PE, mis võistluse kaotas, suunab oma üürnikku endiselt lokaalselt edasi, seega saidisisene ping õnnestub ja saidivaheline test ebaõnnestub. Enne mis tahes poliitika puudutamist loendage selle prefiksi kirjed VPNv4 tabelis.
RD muudab ühe võtme kaheks
Kaheksa baidi pikkune marsruudieristaja lisatakse IPv4 prefiksi ette ja objekt, mida BGP kannab, muutub IPv4 prefiksi asemel VPN-IPv4 aadressiks. Kaks üürnikku saavad hoida samu 32 bitti, sest ees olevad 64 bitti erinevad. Olemas on vormingutüübid AS-põhise RD ja aadressipõhise RD jaoks ning valik kuulub algsele PE-le. AS-põhine RD on tavaline, kui PE-d jagavad AS-i, ja aadressipõhine, kui nad ei jaga.
Ärge lugege RD-d liikmelisuse sildina. Marsruudisihtmärgid juhivad importi ja eksporti ning otsustavad, millised VRF-id tohivad marsruudi paigaldada; RD tagab ainult, et marsruudil on oma identiteet. Iga VRF-i jaoks oma RD andmine on tavaline praktika, sest see hoiab selle vastenduse marsruutide loendis loetavana.
Silt on lokaalne edasisuunamisjuhend
Iga teade kannab ka MPLS silti ja selle tähendus on piiratud ruuteriga, mis selle eraldas. Teine PE võib väljastada sama numbri mittediskreetse sihtkoha jaoks. Just seetõttu ei saa silt kliendi identiteeti asendada: number on õige ainult järgmise hüppe ja selle paigaldanud edasisuunamisoleku kõrval.
Eraldamise granulaarsus varieerub vastavalt teostusele ja disainile: mõned platvormid eraldavad ühe sildi VRF-i kohta, teised prefiksi kohta, ja silt võib tähistada edasisuunamistoimingut, mitte klienti. Kaks erinevat silti, mis jõuavad samasse sihtkohta, ei ole vastuolu, ja sama sildinumber kahes PE-s ei ole samuti.
| 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 |
Miks üks ei saa teist asendada
Teate lugemine tähendab nelja asja koos vaatamist: RD-ga kvalifitseeritud prefiks, marsruudisihtmärgid, järgmine hüpe ja silt. Kasutaja paketi lugemine tähendab sellest teabest paigaldatud pinu vaatamist. Terve disain näitab mõlemat poolt kokku sobivat ja katkine disain on tavaliselt ühe poolega õige ning teisega vananenud. See võrdlus eristab identiteediprobleemi edasisuunamisprobleemist.
Korrapärane vastandus kontroll- ja andmetasandi vahel on õppevahend, mitte kodeeringu kirjeldus. RFC 8277 paigutab sildi märgistatud NLRI sisse, seega kannab teade ise sidet; selle kasutamine edasisuunamiseks on hilisem, eraldi samm.
Kui üürniku marsruut kaob, kontrollige sellises järjekorras: kaks VPNv4 kirjet prefiksi kohta, igal õige marsruudisihtmärk, lahendatav järgmine hüpe ja silt, mille jaoks vastuvõtval PE-l on olek. Identiteedi parandamine edasisuunamisväärtusega või vastupidi läbib ühe kontrolli ja kukub järgmisel läbi.