Encaminament de sucursals MPLS: què aprèn la CE i de qui

Un equip d’una sucursal obre una connexió amb un servidor d’una altra, i totes dues seus estan darrere de la mateixa VPN MPLS de nivell 3 gestionada. L’equip només coneix la seva pròpia passarel·la per defecte i res més, cosa que és correcta. L’important és que la vora de client local lliuri el paquet a la seva vora de proveïdor, i que l’estat d’encaminament VPN del proveïdor el lliuri a la sucursal que té el prefix de destinació.

Recórrer un paquet pel camí és la manera més ràpida de veure quina part és responsabilitat del client i quina part pertany al servei.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

On acaba la feina de cada salt

La CE-A necessita una ruta per a la LAN remota que apunti al seu enllaç local del proveïdor, no a l’adreça WAN de la sucursal remota. Després el proveïdor transporta el paquet per la seva pròpia xarxa troncal fent servir l’estat d’encaminament VPN, i la CE-B el lliura a la LAN de destinació. En cap moment un equip ha d’entendre etiquetes, VRF ni el circuit d’internet de l’altre costat.

L’error que apareix una vegada i una altra als tiquets és configurar l’adreça WAN de la sucursal B com a salt següent a la sucursal A. Totes dues sucursals han comprat el mateix servei, així que sembla que hagin de ser veïnes. No ho són: un salt següent ha de ser abastable pel disseny d’encaminament que realment tens, i la CE remota normalment és a molts salts de distància, darrere d’equipament que no administres. Una ruta estàtica construïda sobre aquesta suposició apareix com a activa i no resol enlloc, cosa que és pitjor que una ruta absent perquè a la taula sembla correcta.

La RFC 4364 separa l’intercanvi entre la vora de client i la vora de proveïdor de la distribució de rutes VPN que fa el proveïdor, i aquest és exactament el límit del qual tracta aquest manual. La feina del client és dir a la seva vora què pot lliurar i acceptar l’abastabilitat que el servei ofereix a canvi.

Què ha d’acordar l’entrega

Tria el mecanisme amb el proveïdor, no al seu voltant. Les rutes estàtiques, BGP o un acord de protocol d’encaminament entre la CE i la PE són tots legítims, i OSPF té un model MPLS VPN definit per a aquesta entrega. Cap d’aquests no és motiu per construir una adjacència OSPF entre dues vores de client remotes a través d’una xarxa troncal de proveïdor no especificada, que és un disseny que el proveïdor no ha acceptat i no pot suportar.

Abans que una LAN nova entri en servei, anota quatre coses: el prefix, la ruta local següent a la CE, l’anunci que el proveïdor acceptarà i les rutes que el proveïdor retornarà. Afegeix-hi qualsevol filtratge, límit de prefixos o restricció entre seus que imposi el contracte. Una adjacència sana és un canal per intercanviar informació, i no és prova que un prefix concret hagi estat acceptat; la sessió pot estar activa mentre la teva subxarxa nova és dins d’un filtre.

Després segueix la resposta. La sucursal B necessita una ruta de tornada a la LAN d’origen, i l’equip del costat receptor necessita la seva pròpia passarel·la i els seus propis permisos de servei. Una ruta que apareix a la CE-A estableix mitja anada i tornada, i mitja anada i tornada és la raó per la qual una direcció d’una prova de ping sembla sana mentre l’aplicació encara falla.

Verifica les dues entregues abans de signar

Recull l’estat d’encaminament a les dues vores de client, confirma amb el proveïdor que els prefixos de LAN previstos s’han acceptat a la VPN, i després prova una aplicació permesa en cada direcció. Les taules de rutes soles no proven que l’aplicació funcioni, i una prova d’aplicació sola no et diu quin pla de control ha fallat quan no funciona.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Llegeix les tres sortides juntes. La primera diu què creu la vora, la segona diu què ha après i de quin veí, i la tercera diu què reenviarà realment. La discrepància entre elles sol ser un problema de política o de recursió més que un anunci absent, i val la pena resoldre’l abans de demanar al proveïdor que investigui. Porta aquestes tres sortides a la trucada amb l’operador, perquè responen la majoria de preguntes que un enginyer de suport et faria d’altra manera.

Sap què no ofereix el servei

Això és accés encaminat de nivell 3. No és un circuit de nivell 2 que estengui difusions entre oficines, així que els protocols de descoberta, les aplicacions dependents de difusió i les suposicions de segment compartit no hi viatgen. La impressió, l’examen de noms i qualsevol cosa que depengui d’un segment local necessiten el seu propi disseny.

La separació de VPN tampoc no és xifratge. La commutació d’etiquetes manté els clients separats dins de la xarxa del proveïdor, i no fa confidencial la càrrega útil si el contracte exigeix confidencialitat. On això importa, l’aplicació o una capa superposada ha de proporcionar-la.

Finalment, tingues el model de servei escrit al costat de la configuració d’encaminament de la seu. El proper enginyer que afegeixi una subxarxa hauria de poder llegir quins prefixos s’anuncien, qui els accepta i quin és el camí de tornada esperat: l’especificació BGP/MPLS IP VPN és la referència del model que hi ha darrere de tot això.