Dos PE, un prefix: per què la RD decideix la visibilitat

Dos encaminadors de frontera que anuncien el mateix prefix de client descriuen una única destinació VPNv4 fins que alguna cosa els separa, i el separador és el route distinguisher. Qualifica el prefix; no decideix qui importa el resultat, que és la feina del route target. Assigneu les RD a partir del conjunt de rutes que han de romandre distingibles a cada domini on aquests anuncis es puguin trobar, no a partir de la disposició de fitxers d’una sola caixa. El número que trieu és una identitat de la qual dependran revisions posteriors, així que ha de ser a l’inventari abans d’entrar en una configuració.

Una RD més un prefix és una sola destinació

Una RD més un prefix IPv4 forma la destinació VPNv4 que compara el pla de control. Doneu a dos PE el mateix prefix per a clients diferents i, sense RD diferents, anuncien camins cap a una sola destinació. Res a la pantalla no us diu que aquesta agrupació és incorrecta, perquè la plataforma fa exactament el que diu la identitat. Canvieu la RD d’un d’ells i l’anunci antic es retira mentre sota una altra identitat n’apareix un de nou. Tot el que hi havia aigües avall lligat a la identitat antiga, des de la selecció de ruta fins a un filtre d’operador desat, ara es refereix a una cosa que ja no existeix.

Diversos camins per destinació és un comportament normal de BGP, no un símptoma. Un speaker pot mantenir diversos camins rebuts mentre selecciona un camí òptim per a l’enviament, i la diferència entre rebut i seleccionat és on viuen les preguntes de visibilitat. Quan un camí sembli haver desaparegut, confirmeu si la identitat a la qual pertanyia encara existeix abans de mirar la sessió.

Mateixa RD, mateixa destinació, camins diferents

Envieu una RD i un prefix des de dos encaminadors en nom del mateix servei i tots dos ofereixen camins cap a una sola destinació, normalment amb salts següents diferents. Quin d’ells un reflector de rutes propagarà és una decisió sobre el reflector: la seva selecció de camí, la seva capacitat d’anunciar i qualsevol política superposada. Cap dels dos encaminadors de frontera controla aquesta tria. Doneu RD diferents als dos anuncis i cada un esdevé la seva pròpia destinació, de manera que tots dos poden sobreviure a un pla de control que altrament només porta el camí seleccionat per a una identitat.

Visibilitat i multipath es troben a la VRF receptora, però no són la mateixa decisió, i un reflector que porta dues identitats no ha configurat un segon camí instal·lat. La VRF instal·la el que admet la seva política d’importació i el que permet la seva pròpia configuració de màxim de camins. Comproveu aquesta configuració per separat quan vulgueu que el segon camí s’utilitzi i no només que sigui visible.

Una regla local d’unicitat no és una política

Donar a cada PE i a cada instància d’encaminament la seva pròpia RD és una convenció sòlida: nomena l’origen, evita que serveis no relacionats xoquin en una identitat i dona a l’inventari una clau estable. Algunes plataformes només exigeixen unicitat dins de la caixa i permeten explícitament que els encaminadors comparteixin una RD per a la mateixa instància de VPN. Aquest permís és una restricció d’implementació, no una regla entre xarxes que pugueu delegar a un proveïdor. Si el domini abasta equips, escriviu vosaltres mateixos la política d’assignació.

La pertinença mai no ve dels dígits. Un patró com 65000:12 per a un PE i 65000:13 per a un altre és un hàbit, mentre que uns objectius d’exportació i importació coincidents com 65000:112 són el que posa una ruta en una VRF. Tracteu la RD com la identitat d’una ruta i el route target com el permís que la porta a una VRF.

Demostreu el canvi a la VRF, no a la pantalla

Abans de tocar una RD, anoteu quatre coses: què anuncia el PE avui, què reflecteix el reflector, què importa la VRF receptora i quin camí selecciona. Una RD nova retira un anunci i n’introdueix un altre, així que el canvi apareix als dos costats de la sessió i és fàcil de malinterpretar si només mireu el costat que anuncia. L’acceptació hauria de basar-se en la connectivitat que volíeu, no en una línia extra que aparegui en una llista de prefixos. La taula de sota evita que els tres identificadors es confonguin durant aquesta revisió.

Comenceu al PE que anuncia i compareu les dues identitats per al mateix prefix abans de treure res. Les ordres IOS de sota responen tres preguntes per ordre: hi és encara l’anunci antic, és visible la identitat nova per al reflector i selecciona la VRF el prefix.

show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24
show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24
show ip route vrf CUSTOMER-A 203.0.113.0/24

Altres plataformes imprimeixen la mateixa informació amb una sintaxi diferent, i les preguntes sobreviuen a aquest canvi. Si la identitat nova falta al reflector mentre el PE la llista com a anunciada, el primer sospitós és la política o la capacitat d’anunciar del reflector, no la numeració.

Registreu el PE, la instància, la RD, els objectius d’exportació i importació i la propietat del prefix en un sol lloc, perquè la propera assignació és una consulta i no una conjectura només quan aquest registre existeix. Manteniu la RD antiga fins que la identitat nova sigui visible a la VRF receptora, i retireu-la després en un segon pas perquè cada etapa segueixi sent reversible.