RD davant RT en una MPLS VPN: unicitat davant política d’importació
El distingidor de ruta fa únics els prefixos que se solapen, i l’objectiu de ruta decideix quines rutes pot importar un VRF. Seguiu una ruta MPLS pels dos papers.
Dos llocs de client poden anunciar 10.20.0.0/24 i tots dos continuen sent vàlids dins d’una sola xarxa de proveïdor. El distingidor de ruta manté aquests anuncis separats; l’objectiu de ruta decideix quin VRF de client pot prendre’n una còpia. Apareixen l’un al costat de l’altre a la configuració i fan feines completament diferents. Confondre’ls porta a canvis que semblen raonables i no arreglen res.
Seguiu una ruta des de la vora del client fins a un VRF remot i la divisió es torna concreta: la identitat s’adjunta abans que la ruta entri a BGP, i la política de distribució s’avalua quan la ruta arriba a la vora del proveïdor que la rep.
Una ruta VPN-IPv4 és un RD més un prefix IPv4
La RFC 4364 defineix la família d’adreces VPN-IPv4 com un distingidor de ruta de vuit bytes seguit d’una adreça IPv4 de quatre bytes. El RD s’anteposa al prefix del client, de manera que dos prefixos idèntics de llocs diferents es converteixen en dues rutes BGP diferents.
Aquesta construcció és tot el mecanisme d’unicitat. El proveïdor no necessita que els clients acordin un espai d’adreces sense solapament, i una ruta d’un lloc no pot substituir silenciosament un prefix idèntic d’un altre lloc.
El format del RD és un valor triat per l’administrador, normalment un número de sistema autònom i un número local. La seva forma numèrica és una convenció, no un senyal que els dos camps comparteixin significat amb un objectiu de ruta que casualment fa servir els mateixos dígits.
El RD fa distingibles els prefixos que se solapen
Considereu dos anuncis del mateix prefix. El lloc A porta el RD 65000:101 i el lloc B porta el RD 65000:202, tots dos per a 10.20.0.0/24. Ara BGP té dues rutes VPN-IPv4 que es poden comparar, filtrar i seleccionar de manera independent.
El RD no diu quin VRF ha de rebre cap de les dues rutes, ni identifica un client o un servei. És un camp d’identitat de la ruta, no una llista de pertinença. El RD propi d’un VRF no ha de coincidir amb el RD d’una ruta que importa.
Per això canviar un RD perquè coincideixi amb el número d’un altre lloc no arregla res. Si falta una ruta a l’altre costat, fer coincidir els dígits crea un problema d’identitat diferent en lloc de reparar la decisió d’importació.
L’RT és un atribut BGP, no una etiqueta al paquet
Una política d’exportació adjunta un o més objectius de ruta a la ruta com a atributs de comunitat estesa de BGP. La vora del proveïdor que rep compara aquests atributs amb la política d’importació de cada VRF. L’RT viatja amb la ruta pel pla de control. La comparació passa del tot en la política d’encaminament, abans que es reenviï cap paquet del client.
Els paquets de dades del client no porten l’RT. Un cop la ruta és instal·lada en un VRF, el reenviament fa servir la taula d’aquell VRF i la pila d’etiquetes MPLS que assigna l’arquitectura. La vora del proveïdor no llegeix cap objectiu de ruta de cada paquet del client.
Una ruta pot portar diversos RT, i un VRF pot importar-ne diversos. La configuració sovint sembla un bloc curt:
vrf definition CUST-A
rd 65000:101
address-family ipv4
route-target export 65000:500
route-target import 65000:500
Llegiu aquest bloc com dues afirmacions separades. La línia d’exportació controla què s’adjunta a les rutes que surten d’aquest VRF; la línia d’importació controla què està disposat a considerar aquest VRF. Que els números coincideixin és còmode, però no obligatori.
L’elegibilitat d’importació no és la instal·lació
Una ruta pot ser elegible per a un VRF i tot i així no aparèixer a la seva taula de reenviament. L’elegibilitat és un filtre; després el procés normal de decisió de BGP compara les rutes elegibles i en selecciona una. Una ruta més antiga o menys preferida pot perdre davant d’una altra ruta elegible.
Comproveu la ruta seleccionada, no només la política d’importació. Un VRF que importa l’RT 65000:500 i no mostra cap ruta per a 10.20.0.0/24 pot haver rebut la ruta i haver-la rebutjada durant la selecció, o potser no l’ha rebuda mai.
Aquesta distinció també importa quan apareix un prefix inesperat. Una política d’importació massa àmplia pot atreure rutes que el lloc no tenia intenció d’usar, i la unicitat del RD no ho impedeix gens. L’abast de distribució és una qüestió de política d’RT.
Depureu una ruta que falta en l’ordre del pla de control
Comenceu per l’anunci: exporta el VRF d’origen l’RT previst i existeix la ruta com a ruta VPN-IPv4 al reflector de rutes o al PE que rep? Després comproveu l’atribut tal com s’ha rebut, no tal com està configurat al remitent.
A continuació compareu la llista d’importació del VRF que rep amb els valors reals d’RT de la ruta. Finalment inspeccioneu la ruta seleccionada en aquell VRF i la vinculació de l’etiqueta. Cada pas respon una pregunta diferent, i saltar al RD normalment omet el pas que és incorrecte.
Anoteu el RD, l’RT exportat, l’RT importat i el següent salt seleccionat per al lloc que funciona i el que falla. Quatre valors costat a costat converteixen un vague “la VPN no passa rutes” en el pas exacte del pla de control que difereix.