RD kontraŭ RT en MPLS VPN: unikeco kontraŭ importa politiko

Du klientaj ejoj povas anonci 10.20.0.0/24 kaj ambaŭ restas validaj ene de unu provizanta reto. La itin-distingisto tenas tiujn anoncojn apartaj; la itin-celo decidas kiun klientan VRF rajtas preni kopion. Ili staras unu apud la alia en la agordo kaj faras tute malsamajn taskojn. Konfuzi la du kondukas al ŝanĝoj, kiuj aspektas raciaj kaj riparas nenion.

Sekvu unu itinon de la klienta rando ĝis fora VRF kaj la divido fariĝas konkreta: identeco estas alkroĉita antaŭ ol la itino eniras BGP, kaj la distribua politiko estas taksata kiam la itino atingas la ricevan provizantan randon.

Itino VPN-IPv4 estas RD plus IPv4-prefikso

RFC 4364 difinas la adresan familion VPN-IPv4 kiel okbajtan itin-distingiston sekvatan de kvarbajta IPv4-adreso. La RD estas antaŭmetata al la klienta prefikso, do du identaj prefiksoj el malsamaj ejoj fariĝas du malsamaj BGP-itinoj.

Tiu konstruo estas la tuta unikeca mekanismo. La provizanto ne bezonas, ke la klientoj interkonsentu pri nekoincida adresspaco, kaj itino el unu ejo ne povas silente anstataŭigi identan prefikson el alia ejo.

La RD-formato mem estas valoro elektita de la administranto, kutime aŭtonoma sistema numero kaj loka numero. Ĝia numera formo estas konvencio, ne signo, ke la du kampoj kunhavas signifon kun itin-celo, kiu hazarde uzas la samajn ciferojn.

La RD faras koincidajn prefiksojn distingeblaj

Konsideru du anoncojn por la sama prefikso. Ejo A portas RD 65000:101 kaj ejo B portas RD 65000:202, ambaŭ por 10.20.0.0/24. BGP nun tenas du itinojn VPN-IPv4, kiujn oni povas sendepende kompari, filtri kaj elekti.

La RD ne diras, kiun VRF devas ricevi ĉiun el la itinoj, kaj ĝi identigas nek klienton nek servon. Ĝi estas identeca kampo de la itino, ne membrolisto. La propra RD de VRF ne devas kongrui kun la RD de itino, kiun ĝi importas.

Jen kial ŝanĝi RD por kongrui kun la numero de alia ejo riparas nenion. Se itino mankas ĉe la alia flanko, kongruaj ciferoj kreas alian identecan problemon anstataŭ ripari la importan decidon.

La RT estas BGP-atributo, ne paketa etikedo

Eksporta politiko alkroĉas unu aŭ plurajn itin-celojn al la itino kiel etenditaj komunumaj atributoj de BGP. La ricevanta provizanta rando komparas tiujn atributojn kun la importa politiko de ĉiu VRF. La RT vojaĝas kun la itino tra la regada ebeno. La komparo okazas tute en la itina politiko, antaŭ ol iu ajn klienta pakaĵo estas plusendata.

Klientaj datumpakaĵoj ne portas la RT. Post kiam itino estas instalita en VRF, la plusendado uzas la tabelon de tiu VRF kaj la MPLS-etikedan stakon, kiun la arkitekturo asignas. La provizanta rando ne legas itin-celon el ĉiu klienta pakaĵo.

Itino povas porti plurajn RT-ojn, kaj VRF povas importi plurajn. La agordo ofte aspektas kiel mallonga bloko:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Legu tiun blokon kiel du apartajn deklarojn. La eksporta linio regas, kio estas alkroĉata al itinoj forlasantaj ĉi tiun VRF; la importa linio regas, kion ĉi tiu VRF pretas konsideri. Kongruaj numeroj estas oportunaj, ne devigaj.

Importa rajteco ne estas instalado

Itino povas esti elektebla por VRF kaj tamen ne aperi en ĝia plusenda tabelo. Elektebleco estas filtrilo; poste la normala BGP-decida procezo komparas elekteblajn itinojn kaj elektas unu. Pli malnova aŭ malpli preferata itino povas malvenki al alia elektebla vojo.

Kontrolu la elektitan itinon, ne nur la importan politikon. VRF, kiu importas RT 65000:500 kaj montras neniun itinon por 10.20.0.0/24, eble ricevis la itinon kaj malakceptis ĝin dum elekto, aŭ eble neniam ricevis ĝin.

Ĉi tiu distingo gravas ankaŭ kiam aperas neatendita prefikso. Tro larĝa importa politiko povas altiri itinojn, kiujn la ejo ne intencis uzi, kaj la unikeco de la RD tute ne malhelpas tion. La distribua amplekso estas demando de RT-politiko.

Spuru mankan itinon laŭ la ordo de la regada ebeno

Komencu per la anonco: ĉu la fonta VRF eksportas la celatan RT, kaj ĉu la itino ekzistas kiel itino VPN-IPv4 ĉe la itin-reflektilo aŭ ĉe la ricevanta PE? Poste kontrolu la atributon tiel, kiel ĝi estis ricevita, ne tiel, kiel ĝi estas agordita ĉe la sendanto.

Poste komparu la importan liston de la ricevanta VRF kun la realaj RT-valoroj de la itino. Fine ekzamenu la elektitan itinon en tiu VRF kaj la etikedan ligon. Ĉiu paŝo respondas al alia demando, kaj salti al la RD kutime preterlasas ĝuste tiun, kiu estas malĝusta.

Notu la RD, la eksportitan RT, la importitan RT kaj la elektitan sekvan salteton por la funkcianta kaj la malsukcesa ejo. Kvar valoroj unu apud la alia transformas varman “la VPN ne pasigas itinojn” en la precizan paŝon de la regada ebeno, kiu diferencas.