Premessa
Benchè esistano valide alternative come EoIP e - finalmente nella 7.0 - VXLAN, VPLS è il protocollo di elezione in tutti quei casi in cui sia richiesto un trasporto di Livello 2 (come ad esempio per centralizzare le soluzioni hotspot, oppure per veicolare il traffico PPPoE dagli apparati di accesso verso i BNG/BRAS).
Il problema
Una delle limitazioni di MPLS in RouterOS è la mancanza di supporto per ECMP; non vi è infatti possibilità di far si che un singolo LSP segua, laddove disponibili, due o più percorsi: l'etichetta MPLS viene "attaccata" ad una sola delle rotte presenti in tabella. Ad ogni modo, questo distribuirebbe il carico in maniera più o meno simmetrica, non consentirebbe - ad esempio - di gestire in maniera efficace tutte quelle situazioni che dovessero presentare path asimmetrici.
L'ideale sarebbe avere la possibilità di creare più interfacce VPLS tra due peer - una per ogni path che vogliamo impegnare - così da poter gestire il traffico in maniera flessibile (ad es. utilizzando un bond, oppure facendo bridging selettivo).
MPLS-TE ci viene in aiuto, consentendoci di stabilire LSP distinte tra due endpoint, al "costo" di qualche loopback aggiuntiva (ricordiamo infatti che l'interfaccia TE vuole una tupla from-address, to-address).
Purtroppo, utilizzando le classiche interfacce VPLS segnalate in LDP, la cosa non funzionerebbe, in quanto il processo LDP sui router si aspetta di ricevere le connessioni dei vari peer provenienti da IP specifici: in RouterOS tale configurazione è globale (si tratta del parametro "transport-address" di ldp), rendendo di fatto vano l'utilizzo delle loopback multiple.
Nota bene: in questo contesto non stiamo parlando di LDP in quanto protocollo per stabilire l'LSP necessaria alla consegna dei frame MPLS, ma di quello utilizzato per scambiare le etichette relative alle interfacce stesse (ovvero le "inner label"); utilizzeremo RSVP allo scopo (sotto forma di interfacce traffic-eng), pertanto non utilizzeremo LDP.
La soluzione
Fortunatamente per noi, RouterOS ci consente di utilizzare un altro sistema per la distribuzione delle inner label, ovvero il protocollo BGP.
Questa feature è stata originariamente pensata per tutte le situazioni in cui vi sia la necessità di stabilire un mesh di tunnel VPLS tra più endpoint: la sua principale caratteristica è infatti quella di creare in modo automatico le interfacce VPLS, sulla base degli annunci ricevuti via BGP. Tra le sue caratteristiche vi è anche una certa flessibilità nella configurazione dei peer, motivo per cui andremo ad abusarla per i nostri scopi.
Questo è il diagramma dell'infrastruttura di test che andremo a realizzare:
La topologia è il classico anello a 4 router. Stabiliremo due tunnel VPLS tra West e East: uno via North, in rosso, l'altro via South, in verde.
Abbiamo allocato la 192.0.2.0/28 per le point-to-point, la 192.0.2.240/29 per le loopback "normali" ed, infine, la 192.0.2.248/29 per le loopback "VPLS"; dato che North e South non hanno endpoint VPLS, a loro abbiamo assegnato un solo indirizzo loopback.
Nel prossimi post vedremo come configurare l'esempio sopra, partendo da zero. Stay tuned!