Consiglio Nazionale delle Ricerche - iit.cnr.it B4-08-2016.pdf · le diﬀerenzia maggiormente è...

C

Consiglio Nazionale delle Ricerche

Design di una rete dati geograficamente distribuita: use case della rete dati regionale

toscana della Pubblica Amministrazione

P. Ussi, A. Gebrehiwot, M. C. Buzzi

IIT B4-08/2016

Nota Interna

Luglio 2016

Iit

Istituto di Informatica e Telematica

Design di una rete datigeograficamente distribuita: use casedella rete dati regionale toscana della

Pubblica Amministrazione

Paolo Ussi, Abraham Gebrehiwot, Maria Claudia BuzziIIT institute - National Research Council of Italy

via G. Moruzzi, 1 - 56124 Pisa, [email protected]

[email protected]@iit.cnr.it

Luglio 2016

mailto:[email protected]



Sommario

La Pubblica Amministrazione è composta da diversi enti quali i comuni,le università, le scuole e gli ospedali i cui uffici sono tipicamente sparsi sulterritorio. La necessità sempre maggiore di scambiare informazioni portaciascuna sede ad avvalersi dei servizi di un Service Provider che, oltre a fornireun accesso diretto ad Internet, può offrire un collegamento tra le varie sedidistaccate allo scopo di costituire la rete VPN della Pubblica Amministrazione.Una tecnologia legacy, robusta e scalabile, usata da molti Service Providers perla creazione di reti VPN è basata sulla struttura ATM/SDH che tuttavia nonè in grado di gestire efficacemente la banda. Molte altre soluzioni tradizionaliper la creazione di VPN quali le reti a circuito, GRE e IPSEC risultanodifficilmente scalabili,e non consentono la facile introduzione di nuovi servizi.Questo Technical Report illustra come alcune tecnologie innovative quali L3MPLS VPN, VPLS e VRF-Lite (Multi-VRF) con Tunneling IP possano essereadottate dai Service Providers allo scopo di creare delle reti VPN geografichemultipunto in maniera ottima e scalabile. Come esempio illustriamo l’usecase della rete dati regionale toscana della Pubblica Amministrazione.

Indice

1 Introduzione 4

2 Tecnologie per reti VPN multipunto di nuova generazione 62.1 L3 MPLS VPN . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 VRF Lite con Tunneling IP . . . . . . . . . . . . . . . . . . . 8

3 Use case: design dell’architettura della rete dati regionaletoscana della Pubblica Amministrazione 9

4 Laboratorio tecnologia MPLS VPN 144.1 Protocollo IGP - ISP core . . . . . . . . . . . . . . . . . . . . 144.2 MPLS - ISP core . . . . . . . . . . . . . . . . . . . . . . . . . 144.3 Protocollo MP-BGP - ISP core . . . . . . . . . . . . . . . . . 164.4 Configurazione delle VRF . . . . . . . . . . . . . . . . . . . . 174.5 Configurazione protocollo CE-PE . . . . . . . . . . . . . . . . 174.6 Redistribuzione delle rotte . . . . . . . . . . . . . . . . . . . . 184.7 Internet Access . . . . . . . . . . . . . . . . . . . . . . . . . . 184.8 Test di connettività . . . . . . . . . . . . . . . . . . . . . . . . 19

4.8.1 TEST 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 194.8.2 TEST 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 214.8.3 TEST 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 214.8.4 TEST 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 214.8.5 TEST 5 . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Laboratorio tecnologia VPLS 245.1 Protocollo IGP - ISP core . . . . . . . . . . . . . . . . . . . . 245.2 MPLS - ISP core . . . . . . . . . . . . . . . . . . . . . . . . . 265.3 Control Plane: MP-BGP Auto-Discovery . . . . . . . . . . . . 26

2

5.4 Configurazione delle istanze VPLS . . . . . . . . . . . . . . . 285.5 Internet Access . . . . . . . . . . . . . . . . . . . . . . . . . . 285.6 Test di connettività . . . . . . . . . . . . . . . . . . . . . . . . 29

5.6.1 TEST 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 305.6.2 TEST 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 305.6.3 TEST 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 305.6.4 TEST 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6 Laboratorio tecnologia VRF-LITE con Tunneling IP 366.1 Protocollo IGP - ISP core . . . . . . . . . . . . . . . . . . . . 366.2 Configurazione delle VRF . . . . . . . . . . . . . . . . . . . . 366.3 Configurazione protocollo CE-PE . . . . . . . . . . . . . . . . 386.4 Configurazione dei tunnels . . . . . . . . . . . . . . . . . . . . 386.5 Configurazione protocollo di routing tra le VRF . . . . . . . . 396.6 Test di connettività . . . . . . . . . . . . . . . . . . . . . . . . 40

6.6.1 TEST 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 406.6.2 TEST 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3

CAPITOLO 1

Introduzione

La Pubblica Amministrazione è composta da diversi enti quali i comuni, leuniversità, le scuole e gli ospedali i cui uffici sono tipicamente sparsi sulterritorio. La necessità sempre maggiore di scambiare informazioni portaciascuna sede ad avvalersi dei servizi di un Service Provider che, oltre afornire un accesso diretto ad Internet, può offrire un collegamento tra levarie sedi distaccate allo scopo di costituire la rete VPN della PubblicaAmministrazione.

Le reti VPN tradizionali vengono generalmente implementate seguendoun modello denominato Overlay VPN secondo il quale il Service Provider hail compito di costituire dei link punto-punto tra i vari siti dei customers senzatuttavia venire coinvolto nel loro processo di routing. Queste VPN possonoessere realizzate a Livello 3 grazie all’utilizzo dei protocolli di tunneling qualiGRE, IP-IP e IPSEC e a Livello 2 dove vengono utilizzate tecnologie a circuitovirtuale quali Frame Relay e ATM. I Service Providers possono inoltre offrirecircuiti dedicati che si affidano alle esistenti reti di trasporto SDH/SONET.

Le reti SDH/SONET, basate sulla multiplazione a divisione di tempo(TDM), sono resilienti, affidabili e sicure, ma sono costose e perdono i vantaggicaratteristici del multiplexing statistico che consente un utilizzo efficiente dellabanda, il facile dimensionamento delle connessioni ed una maggiore flessibilità.Le reti a circuito inoltre non si adattano molto bene alle nuove applicazioniche per la maggior parte risultano nativamente basate sul protocollo IP e chegeneralmente richiedono maggiore banda.

Al fine di creare reti convergenti di nuova generazione che beneficino deivantaggi delle reti a circuito e delle reti a pacchetto i Service Providers stannolentamente migrando da architetture di rete stratificate quali ad esempio

4

IP/ATM/SONET/DWDM ad architetture di rete più semplici basate suMPLS che includono ad esempio MPLS/DWDM.[1]

MPLS (Multi Protocol Label Switching) è una tecnologia a circuitovirtuale di livello 2.5 che consente il trasporto di circuiti PDH, SDH e SONETed il trasporto di protocolli L3 e L2 quali IPv4, IPv6, ATM ed Ethernetsopra un’unica infrastruttura di rete a pacchetto. Le topologie di rete soprale quali MPLS può lavorare sono molteplici ed includono quelle ad anello equelle mesh. MPLS offre svariati servizi tra i quali un sofisticato serviziodi QoS, la possibilità di fare Traffic Engineering, l’opportunità attraverso ilFast Re-Route (FRR) di ottenere un alto livello di resilienza comparabilea quello ottenuto con le tecniche di protezione dei link utilizzate dalle retiSDH/SONET e la possibilità di realizzare facilmente reti VPN multipuntoflessibili e scalabili sia a Livello 2 che a Livello 3 della pila protocollare.

Questo Technical Report illustra come alcune tecnologie innovative qualiL3 MPLS VPN e VPLS, basate su MPLS, e VRF-LITE con Tunneling IP,basata su IP, possano essere adotttate dai Service Providers allo scopo diprogettare reti VPN geografiche multipunto in maniera ottima e scalabile.Come esempio illustriamo l’use case della rete dati regionale toscana dellaPubblica Amministrazione.

5

CAPITOLO 2

Tecnologie per reti VPN multipunto di nuova generazione

Illustriamo in questo capitolo una breve panoramica sulle tecnologie innovativescelte per la creazione di reti VPN multipunto geografiche. Gli approfon-dimenti tecnici specifici per ciascuna tecnologia sono descritti nei capitolisuccessivi.

Figura 2.1: Tecnologie per reti VPN multipunto di nuova generazione

6

2.1 L3 MPLS VPN

L3 MPLS VPN, spesso denominata semplicemente MPLS VPN, è un’appli-cazione di MPLS che consente la creazione di reti VPN multipunto Layer 3che vengono indicate generalmente con il termine di Virtual Private RoutedNetworks (VPRN). (Figura 2.1 - Immagine 1)

MPLS VPN si basa su un modello chiamato Peer to Peer VPN secondoil quale i routers dei customers (CE routers) interagiscono con i routersdi confine dei Service Providers (PE routers) inviandogli le proprie rotte.Il protocollo Border Gateway Protocol (BGP) è poi utilizzato dal ServiceProvider per scambiare le rotte apprese appartenenti ad una particolare VPNcon tutti i routers PE che appartengono alla stessa VPN. Ciò è realizzatoin modo da assicurare che le rotte appartenenti a VPN differenti rimanganodistinte e separate anche nel caso in cui più VPN utilizzino lo stesso spazio diindirizzamento (overlapping address space). Prima di attraversare il backbonedel Service Provider il traffico dati del customer è incapsulato con un labelMPLS corrispondente alla specifica VPN e con un ulteriore label che consenteai dati di seguire uno specifico percorso verso il router PE di destinazione.[2]

MPLS VPN fornisce una grande scalabilità e facilità di gestione oltre cheun buon livello di sicurezza dovuto al fatto di mantenere separate le tabelle dirouting per ciascuna VPN (tabelle VRF). Con MPLS VPN i Service Providerspossono offrire servizi ad alto valore aggiunto come la Qualità del Servizio(QoS) e il Traffic Engineering (TE) ed inoltre possono interconnettere le lororeti MPLS VPN con le reti MPLS VPN di altri Service Providers allo scopodi incrementare ulteriormente la scalabilità (in questo caso entrano in giocotecnologie Inter-AS MPLS VPN e Carrier’s Carrier). MPLS VPN è adatto altrasporto di traffico dati IPv4, mentre la soluzione per il trasporto di datiIPv6, concettualmente identica, è denominata 6VPE.

Il Capitolo 4 illustra un’approdondimento tecnico riguardante la tecnologiaMPLS VPN e la simulazione di uno scenario di esempio.

2.2 VPLS

Virtual Private LAN Service (VPLS), anche nota con il nome di TrasparentLAN Service o Virtual Private Switched Network Service, è un’applicazionedi MPLS che consente la realizzazione di VPN multipunto L2 basate suEthernet/802.3 e VLAN 802.1Q. (Figura 2.1 - Immagine 2)

In sostanza VPLS consente di unire assieme varie reti LAN individuali chesi trovano sparse sul territorio e le fa apparire come se fossero appartenentiad una LAN singola. Ciò è realizzato introducendo i concetti di MAC addresslearning, flooding e forwarding nel contesto degli pseudowire che colleganoqueste LAN individuali al di sopra di una rete dati a pacchetto. [3]

7

VPLS fornisce una buona scalabilità e una facile gestione unita ad unbuon livello di sicurezza grazie al fatto di mantenere separate le tabelle diforwarding per ciascuna VPN. Inoltre poichè si creano delle VPN di livello 2,VPLS risulta essere una soluzione unica adatta sia al traffico dati IPv4 cheal traffico IPv6.

Il Capitolo 5 illustra un’approdondimento tecnico riguardante la tecnologiaVPLS con Tunneling IP e la simulazione di uno scenario di esempio.

2.3 VRF Lite con Tunneling IP

VRF Lite (Layer 3) con Tunneling IP (Figura 2.1 - Immagine 3) è unasoluzione flessibile basata su IP per la realizzazione di VPN multipuntoadatta a quei Service Providers che ancora non sono migrati o che nonintendono migrare verso un backbone MPLS.

VRF Lite è una tecnologia simile a MPLS VPN, entrambe infatti realiz-zano VPN di livello 3 ed entrambe si basano sul concetto di VRF, ciò chele differenzia maggiormente è il fatto che VRF Lite non necessita dell’im-plementazione di MPLS e MP-BGP all’interno della rete core del ServiceProvider. VRF Lite assicura un buon livello di sicurezza grazie al fatto dimantenere separate le tabelle di routing relative a ciascuna VPN (TabelleVRF). I tunnels IP hanno il compito di connettere assieme le varie istan-ze VRF appartenenti alla stessa VPN. In questo scenario le istanze VRF,presenti sui routers PE, che appartengono alla stessa VPN sono connessedai tunnel IP (ad esempio GRE Tunnels). Il numero di tunnel necessariodipende dal numero n di routers PE coinvoilti in misura di n · (n− 1)÷ 2 sedesideriamo una topologia FULL-MESH e in misura di (n−1) se desideriamouna topologia HUB and SPOKE.

Il Capitolo 6 illustra un’approdondimento tecnico riguardante la tecnologiaVRF LITE con Tunneling IP e la simulazione di uno scenario di esempio.

8

CAPITOLO 3

Use case: design dell’architettura della rete dati regionaletoscana della Pubblica Amministrazione

Illustriamo in questo capitolo come le tecnologie presentate nel capitoloprecedente unite ad altre considerazioni che descriveremo possano essereadottate per la realizzazione della rete dati regionale toscana della PubblicaAmministrazione di nuova generazione.

Una buona parte della rete dati regionale toscana della Pubblica Ammi-nistrazione è attualmente costituita da reti VPN implementate con tecnichetradizionali e si compone di quattro elementi principali che descriviamobrevemente:

1. La Pubblica Amministrazione (PA): la quale è composta dai co-muni, dalle università, dalle scuole e dagli ospedali che rappresentanogli utenti finali appartenenti alla rete dati regionale.

2. La Regione Toscana: che ricopre il ruolo di ente centrale di gestione,il cui compito è quello di redigere le regole operative generali per l’interarete dati regionale.

3. Il Tuscany Internet Exchange (TIX): che costituisce il luogo (meet-me-room) contenente i servizi condivisi e dove i Service Providers siscambiano le informazioni di routing.

4. I Service Providers: il cui compito è quello di connettere le PubblicheAmministrazioni al Tuscany Internet Exchange in modo che questepossano raggiungere i servizi condivisi. Collegamenti che vengonoattualmente realizzati con tecniche di VPN tradizionali.

L’architettura di rete innovativa che proponiamo per la creazione dellarete regionale toscana di nuova generazione è basata sui seguenti assunti:

9

• La Regione Toscana deve acquisire e gestire un pool di indirizzi pubbliciIPv4 e/o IPv6 (NB: in questo Capitolo si suppone invece che la RegioneToscana acquisisca il pool di indirizzi privato 172.16.0.0/16)

• La Regione Toscana deve delegare una porzione degli indirizzi acquisitiai Service Providers che ne fanno richiesta. I Service Providers a lorovolta assegnano gli indirizzi ottenuti alle Pubbliche Amministrazioniche ne fanno richiesta.

• La Regione Toscana dovrebbe addandonare l’architettura basata sulleVPN tradizionali e migrare verso un’architettura basata su VPN costi-tuite con tecnologie innovative quali MPLS VPN, VPLS o VRF LITEcon Tunneling IP

• Si deve creare una rete LAN all’interno del Tuscany Internet Exchangeper l’interconnessione dei Service Providers

• L’accesso ad Internet per la Pubblica Amministrazione deve esserefornito in maniera centralizzata presso il TIX.

Una volta che la Regione Toscana ha acquisito il pool di indirizzi pubbliciIPv4/IPv6, una porzione di questi deve essere assegnata alle PA che nefacciano richiesta. Quindi un adeguato numero di questi indirizzi dovrebbeessere disponibile quando i Service Providers ne facciano richiesta alla RegioneToscana.

Nel nostro caso, come mostrato in Figura 3.1, la Regione Toscana delega larete 172.16.1.0/24 al Service Provider 1 che a sua volta la porziona in reti piùpiccole che verranno assegnate alle Pubbliche Amministrazioni. Nell’esempiomostrato in Figura 3.1 il Comune 1 e l’Ospedale 1 riceveranno rispettivamentel’indirizzo di rete 172.16.1.10/26 e 172.16.1.198/26 mentre l’utente USER EXTche rappresenta un utente esterno alla Pubblica Amministrazione utilizzeràun indirizzo pubblico appartenente allo specifico Service Provider.

Si propone inoltre di creare una rete LAN all’interno del TIX dedicataall’interconnessione dei Service Providers. (Figura 3.2)

I Service Providers dovranno annunciare in eBGP, all’interno della reteLAN, le reti che hanno ricevuto in delega dalla Regione Toscana (ad esempio172.16.1.0/24, 172.16.2.0/24 e 172.16.3.0/24) e dovranno accettare una default-route proveniente dal Gateway Centrale del TIX.

Il Gateway Centrale dovrà annunciare le rotte aggregate 172.16.0.0/16verso Internet globale.

L’accesso ad Internet per la Pubblica Amministrazione dovrà essere fornitoin maniera centralizzata presso il TIX.(Figura 3.3)

Poichè il Gateway Centrale del TIX annuncia le rotte aggregate 172.16.0.0/16verso Internet e poichè i Service Providers hanno assegnato alle Pubbliche Am-ministrazioni un indirizzo appartentente a tale rete allora il traffico Internetrisulterà centralizzato e simmetrico.

10

Figura 3.1: Delegazione degli indirizzi di rete e Tunnel MPLS VPN (lineagialla)

La Figura 3.4 rappresenta uno schema generale della nuova architettu-ra della rete regionale toscana della Pubblica Amministrazione ottenutaimplementando i cambiamenti proposti.

11

Figura 3.2: LAN interna al TIX dedicata all’interconnessione dei ServiceProviders

Figura 3.3: accesso Internet centralizzato per la Pubblica Amministrazione

12

Figura 3.4: Visione di insieme della Rete dati regionale toscana della PubblicaAmministrazione di nuova generazione

13

CAPITOLO 4

Laboratorio tecnologia MPLS VPN

Questo capitolo descrive un possibile scenario per la rete dati regionale toscanadi nuova generazione quando all’interno della rete core del Service Provider sisia implementata la tecnologia MPLS VPN. La topologia in esame è riportatain Figura 4.1. Nei paragrafi successivi verranno descritti i principali blocchiche compongono la configurazione.

4.1 Protocollo IGP - ISP core

Per prima cosa è necessario che la rete core del Service Provider sia perfet-tamente funzionante, cioè dobbiamo garantire la reciproca raggiungibilitàdei router che la compongono. Per ottenere questo risultato abilitiamo ilprotocollo OSPF sulle interfacce di rete interne al service provider e sulleinterfacce di loopback dei router PE1, PE2, GW1, GW2. Il router GW1,inoltre, diffonde in OSPF una default-route per raggiungere Internet. Peruna questione di comodità annunciamo in OSPF anche la rete 6.6.6.0 chepermette di raggiungere l’utente USEREXT che non appartiene ad alcunaPubblica Amministrazione. I router inseriscono le rotte apprese in OSPFnella loro TABELLA DI ROUTING GLOBALE. (Figura 4.2)

4.2 MPLS - ISP core

Per poter usufruire del servizio MPLS VPN è necessario abilitare MPLS nellarete del Service Provider. Ogni router abilitato all’uso di MPLS crea unacorrispondenza tra ciascuna rotta presente nella propria tabella di routing eduna etichetta (label) e costituisce una tabella delle corrispondenze Ipv4-Label.La tabella delle corrispondenze viene scambiata con i router vicini attraverso

14

Figura4.1:

RTRT

EST

ESA

Lab

15

Figura 4.2: IGP - OSPF

il protocollo LDP. Succesivamente i routers analizzeranno le corrispondenzericevute e creeranno una tabella denominata LFIB che verrà utilizzata perinoltrare il traffico basandosi sulle etichette. (Figura 4.3)

Figura 4.3: LDP - MPLS TUNNEL

4.3 Protocollo MP-BGP - ISP core

MPLS VPN si basa sul concetto di mantenere separate sui router PE le tabelledi routing di ogni singolo customer (tabelle VRF). I routers dei customersinvieranno le proprie rotte ai router PE che provvederanno ad inserirle inuna specifica VRF. Poichè i customers potrebbero avvertire reti sovrapposte,che non potrebbero propagarsi correttamente all’interno della rete ISP, è

16

necessario trovare un meccanismo per rendere tali rotte uniche. L’idea è checiascuna rotta proveniente da ciascun customer riceverà un identificatoreunivoco RD (Route Distinguisher). Le rotte derivate dalla combinazionedi prefissi Ipv4+RD sono chiamate rotte VPNV4 (96bit). MP-BGP è ilprotocollo adibito a trasportare tali rotte tra i router PE. In ricezione le rotteannunciate possono essere importate o meno a seconda della configurazionedel parametro ROUTE-TARGET.(Figura 4.4)

Figura 4.4: MPBGP - vpnv4

4.4 Configurazione delle VRF

Il router PE deve avere un’istanza VRF per ciascuna VPN connessa. Attraver-so la configurazione è possibile assegnare l’interfaccia di PE sul collegamentoPE-CE, ad una specifica VRF. A ciascuna interfaccia è possibile assegnareuna sola VRF, ma la stessa VRF può essere utilizzata da più interfacce.Le tabelle VRF create vengono popolate attraverso i protocolli di routingdinamici o statici presenti tra il router CE ed il router PE. (Figura 4.5)

4.5 Configurazione protocollo CE-PE

E necessario configurare un protocollo di routing tra CE e PE al fine poterapprendere le rotte interne a CE. Tali rotte sono inserite nella tabella VRF.Si è scelto di utilizzare il protocollo OSPF per CE1-PE1 e CE2-PE2, mentreper GW2 si è configurato nella VRF INTERNET una defalt-route che puntaa RTIX. (Figura 4.6)

17

Figura 4.5: Tabelle VRF

Figura 4.6: Protocollo CE-PE

4.6 Redistribuzione delle rotte

Per poter creare una intranet tra PA1 e PA2 le rotte interne alle VRF dovrannoessere trasportate nella rete del Service Provider attraverso il protocollo MP-BGP. Viceversa le rotte ricevute in MP-BGP dovranno essere importate nelletabelle VRF specifiche. E necessario quindi configurare la redistribuzione dellerotte (OSPF in MPBGP e MPBGP in OSPF). Terminata la configurazionedella redistribuzione delle rotte i router PA1 e PA2 risulteranno appartenentialla stessa intranet e potranno colloquiare tra di loro attraverso i propriindirizzi privati (LAN to LAN). (Figura 4.7).

4.7 Internet Access

Gli utenti di PA1 e PA2 possono colloquiare tra loro poichè appartengonoalla stessa intranet, tuttavia nella loro tabella di routing VRF non è presentealcuna rotta per poter comunicare verso Internet. Per abilitare l’accesso adinternet per gli utenti di PA1 e PA2 è possibile procedere come segue: Sifaccia riferimento alla figura (Figura 4.8).:

18

Figura 4.7: Ridistribuzione rotte

• Importare in VRF CE e in VRF CE1 la default-route presente all’internodella tabella VRF INTERNET del router GW2 ed importare le rottepresenti in VRF CE e VRF CE1 all’interno di VRF INTERNET. Ladefault-route consentirà agli utenti di CE1 e CE2 di uscire verso internetattraverso RTIX;

• Far annunciare a GW2 all’interno della LAN del TIX, gli indirizzipubblici assegnati ai router CE (es. 159.213.2.1/24), oppure configuraresu RTIX le rotte statiche che puntino a tali indirizzi;

• Gli utenti di PA1 e PA2 devono essere presentati su Internet con unindirizzo ip pubblico del tipo 159.213.x.x/24, quindi dobbiamo abilitareil NAT sui router CE1 e CE2. É possibile fare in modo che gli utentivengano nattati solo quando accedano ad Internet, mentre continuinoad utilizzare gli indirizzi ip privati per le comunicazioni all’interno dellaintranet.

4.8 Test di connettività

In questo capitolo sono mostrati alcuni test di connettività relativi allatopologia presentata.

4.8.1 TEST 1

In questo test verifichiamo la connettività tra USEREXT ed Internet. Ri-cordiamo che USEREXT rappresenta un customer che non appartiene adalcuna Pubblica Amministrazione e che dovrà utilizzare l’internet-facingrouter del Service Provider GW1. La figura Figura 4.9 dimostra il correttoinstradamento.

19

Figura

4.8:Internet

access

20

Figura 4.9: USEREXT to Internet

4.8.2 TEST 2

Questo test dimostra che USEREXT non può connettersi direttamente allarete LAN di CE1 (Figura 4.10). USEREXT riuscirà a collegarsi con CE1solamente attraverso l’indirizzo pubblico di CE1. Si noti che il percorsomostrato in figura raggiunge internet perchè sui router dei Service Provider,per semplicità, non sono stati configurati i filtri per escludere gli indirizzi ipprivati.

Figura 4.10: USEREXT to CE1

4.8.3 TEST 3

Questo test dimostra che USEREXT può connettersi a CE1 e CE2 attraverso iloro indirizzi ip pubblici 159.213.1.2 e 159.213.2.2. (Figura 4.11 e Figura 4.12)

4.8.4 TEST 4

Questo test dimostra che la connessione ad Internet da parte di CE1 e CE2avviene attraverso il router RTIX. (Figura 4.13 e Figura 4.14)

4.8.5 TEST 5

Questo test dimostra la connettività LAN to LAN tra PA1 e PA2.(Figura 4.15)

21



Figura 4.13: CE1 to Internet

22


Figura 4.15: Intranet

23

CAPITOLO 5

Laboratorio tecnologia VPLS

Questo documento descrive una possibile configurazione per la rete datiregionale toscana di nuova generazione quando all’interno della rete core delService Provider si sia implementata la tecnologia MPLS VPLS (VirtualPrivate LAN Service).

MPLS VPLS offre un servizio di VPN Layer 2 multipoint basato suEthernet, in contrasto con le tradizionali VPN L2 che risultano essere point-to-point, e consente di collegare tra di loro reti LAN Ethernet geograficamenteseparate attraverso un backbone MPLS in modo da farle apparire e funzio-nare come se facessero parte di una singola rete LAN. Ciò risulta possibileincorporando sui Router PE tecniche di MAC address learning, flooding eforwarding. Il traffico dati generato in una particolare VPLS attraversa deipercorsi instaurati tra i router PE che vengono denominati PSEUDOWIRES.

La topologia in esame è riportata in Figura 5.1. Nei paragrafi successiviverranno descritti i principali blocchi che compongono la configurazione.


Per prima cosa è necessario che la rete core del Service Provider sia perfet-tamente funzionante, cioè dobbiamo garantire la reciproca raggiungibilitàdei routers che la compongono. Per ottenere questo risultato abilitiamo ilprotocollo OSPF sulle interfacce di rete interne al service provider e sulleinterfacce di loopback dei router PE (vMX-1, vMX-2, vMX-3) e dei router P(P2, P3, P4). Annunciamo in OSPF anche la rete 11.11.11.0 che permettedi raggiungere l’utente USEREXT che non appartiene ad alcuna PubblicaAmministrazione. Il router vMX-3 diffonde inoltre in OSPF una default-routeper raggiungere l’Internet Globale ed assume quindi il ruolo di default-gateway

24

Figura5.1:

RTRT

EST

ESA

Lab

25

dell’ISP. In Figura 5.2 sono evidenziate le interfacce coinvolte nel processoOSPF.


5.2 MPLS - ISP core

Per poter usufruire del servizio MPLS VPLS è necessario abilitare MPLSnella rete del Service Provider. Ogni router abilitato all’uso di MPLS crea unacorrispondenza tra ciascuna rotta presente nella propria tabella di routing eduna etichetta (label) e costituisce una tabella delle corrispondenze Ip-Label.La tabella delle corrispondenze viene scambiata con i router vicini attraversoil protocollo LDP. Succesivamente i routers analizzeranno le corrispondenzericevute e creeranno una tabella denominata LFIB che verrà utilizzata perinoltrare il traffico basandosi sulle etichette. (Figura 5.3)

Alla fine del processo di configurazione di VPLS un’ulteriore etichetta mplsdenominata LSI LABEL verrà utilizzata come inner label e verrà associata aduna particolare istanza VPLS configurata sul router PE. In sostanza questaetichetta servirà come demultiplexor per selezionere un particolare sito remotoservito dal router PE. La Figura 5.4, raffigurante una capture dati sul linkP2-P3, dimostra l’utilizzo dei due label mpls quando si sia effettuato un pingtra PC1 e PC3 che appartengono alla stessa VPLS. Figura 5.4.

5.3 Control Plane: MP-BGP Auto-Discovery

A questo punto è necessario configurare le due parti che compongono il controlplane di MPLS VPLS:

26

Figura 5.3: LDP - MPLS TUNNEL

Figura 5.4: Wireshark capture ping PC1-PC3, link P2-P3

1. Meccanismo di DISCOVERY: consente di scoprire quali router PEappartengano ad una determinata istanza VPLS. La configurazionepuò essere fatta in maniera manuale indicando per ciascuna istanzaVPLS quali sono gli indirizzi IP dei router PE membri, oppure èpossibile affidarsi al protocollo MP-BGP che, attraverso una minimaconfigurazione, consente la scoperta dei membri di una VPLS in manieraautomatica (AUTO-DISCOVERY);

2. Meccasinismo di SIGNALING: consente la segnalazione verso i routerPE dei circuiti pseudowires che connettono le instanze VPLS (es statodel circuito, inner label ecc..). In questo caso ci si può affidare alprotocollo LDP o al protocollo MP-BGP.

Nella topologia in esame si è scelto di utilizzare il protocollo MP-BGP comeunico protocollo che svolga le funzioni di DISCOVERY e SIGNALING. Per

27

quanto riguarda l’implementazione di MP-BGP è consigliabile configurare irouter PE in modalità full-mesh (scelta adottata in questo laboratorio) oppurequalora le dimensioni della rete risultino significative è possibile configurare iROUTE REFLECTOR al fine di ridurre il carico di lavoro del control plane.(Figura 5.5)

Figura 5.5: MPBGP - vpnv4

5.4 Configurazione delle istanze VPLS

Il passo successivo è la configurazione delle istanze VPLS desiderate su ciascunrouter PE. Ad ogni instanza configurata è associato uno switch virtuale chepotrà comunicare solamente con gli altri switch virtuali appartenenti allostesso dominio VPLS. (Figura 5.6)

La Figura 5.7 mostra le mac-address-table dei virtual switches configuratisul router v-MX1.

5.5 Internet Access

Per quanto riguarda l’accesso all’Internet Globale dobbiamo distinguere duecasi:

1. Accesso ad Internet da parte di utenti esterni alla PubblicaAmministrazione (router USEREXT). Il router v-MX3 è configuratoin modo da diffondere in OSPF una default-route verso gli altri routerdel Service Provider e assume quindi il ruolo di default-gateway dell’ISP.Il router USEREXT è configurato con una default-route che punta

28

Figura 5.6: Virtual Switches

all’indirizzo di v-MX1. In questo scenario il traffico Internet generatoda USEREXT uscirà attraverso v-MX3.

2. Accesso ad Internet da parte di utenti della Pubblica Am-ministrazione che si assume facciano parte di una VPLS. Gliapparati dei customers vengono configurati con un default-gateway chepunta al router GW che, a sua volta, ha una default-route che puntaal router R-TIX presente all’interno del TIX. Gli utenti che desidera-no comunicare verso Internet necessitano di un indirizzo pubblico ea questo scopo vengono adottate tecniche di NAT per presentare gliutenti con indirizzi pubblici del pool 159.213.0.0/16. Poichè il routerR-TIX avverte verso internet le rotte aggregate 159.213.0.0/16 il trafficointernet generato da un utente della PA fluisce in maniera simmetricaattraverso R-TIX.

La Figura 5.8 illustra il traffico internet nei due casi indicati



29

5.6.1 TEST 1

In questo test verifichiamo la connettività tra USEREXT ed Internet. Ri-cordiamo che USEREXT rappresenta un customer che non appartiene adalcuna Pubblica Amministrazione e che dovrà utilizzare l’internet-facingrouter del Service Provider v-MX3. La figura Figura 5.9 dimostra il correttoinstradamento.

5.6.2 TEST 2

Questo test dimostra che USEREXT può connettersi a CE1 e PC3 attraversoi loro indirizzi ip pubblici 159.213.1.3 e 159.213.2.2 (Figura 5.10 e Figura 5.11)

5.6.3 TEST 3

Questo test dimostra che la connessione ad Internet da parte di CE1 avvieneattraverso il router RTIX. (Figura 5.12)

5.6.4 TEST 4

Questo test dimostra la connettività LAN to LAN tra utenti della stessaVPLS sia nel caso IPv4 (PC1-PC3) che nel caso IPv6 (PC4-CE4).(Figura 5.13e Figura 5.14)

30

Figura 5.7: Virtual Switches - MAC Address Table

31

Figura

5.8:Internet

Access

32

Figura 5.9: USEREXT to Internet


33

Figura 5.11: USEREXT to PC3


Figura 5.13: Intranet PC1-PC3

34

Figura 5.14: Intranet PC4-CE4

35

CAPITOLO 6

Laboratorio tecnologia VRF-LITE con Tunneling IP

Questo documento descrive una possibile configurazione per la rete datiregionale toscana uando all’interno della rete core del Service Provider si siaimplementata la tecnologia VRF-LITE con Tunneling IP. La topologia inesame è riportata in Figura 6.1. Nei paragrafi successivi verranno descritti iprincipali blocchi che compongono la configurazione.


Per prima cosa è necessario che la rete core del Service Provider sia perfet-tamente funzionante, cioè dobbiamo garantire la reciproca raggiungibilitàdei router che la compongono. Per ottenere questo risultato abilitiamo ilprotocollo OSPF sulle interfacce di rete interne al service provider dei routerPE1, P1, P2, P3, P4, PE2, PE3. I router inseriscono le rotte apprese inOSPF nella loro TABELLA DI ROUTING GLOBALE. (Figura 6.2)

6.2 Configurazione delle VRF

Il router PE deve avere un’istanza VRF per ciascuna VPN connessa. Attraver-so la configurazione è possibile assegnare l’interfaccia di PE sul collegamentoPE-CE, ad una specifica VRF. A ciascuna interfaccia è possibile assegnareuna sola VRF, ma la stessa VRF può essere utilizzata da più interfacce.Le tabelle VRF create vengono popolate attraverso i protocolli di routingdinamici o statici presenti tra il router CE ed il router PE. (Figura 6.3)

36

Figura6.1:

RTRT

EST

ESA

Lab

37


Figura 6.3: Tabelle VRF

6.3 Configurazione protocollo CE-PE

E necessario configurare un protocollo di routing tra CE e PE al fine poterapprendere le rotte interne a CE. Tali rotte sono inserite nella tabella VRF.Al posto di utilizzare un protocollo di routing tra CE e PE in questo caso siè scelto di configurare sui router PE delle rotte statiche interne alla VRF chepuntano alle rotte interne dei router CE. (Figura 6.4)

6.4 Configurazione dei tunnels

Per far comunicare assieme le VRF appartenenti alla stessa VPN presenti suivari router PE si configurano dei tunnels IP tra i routers PE. Se si adottauna topologia FULL-MESH è necessario configurare, per ciascuna VPN, unnumero di tunnel dipendente dal numero di router PE coinvolti in misura din*(n-1)/2, mentre se si adotta una topologia HUB AND SPOKE è il numero

38

Figura 6.4: Configurazione statica CE-PE

di tunnel è (n-1). Anche l’interfaccia virtuale del tunnel dovrà appartenerealla specifica VRF. Nel nostro caso si è scelto di utilizzare tunnel GRE(punto-punto).(Figura 6.5)

Figura 6.5: Tunnel tra i router PE

6.5 Configurazione protocollo di routing tra le VRF

Affinchè le varie VRF possano scambiarsi le rotte che hanno appreso ènecessario configurare un protocollo di routing interno alla specifica vrf. Nelnostro caso si è scelto di utilizzare il protocollo RIPv2 (Figura 6.6).

39

Figura 6.6: Protocollo RIPv2 tra le varie VRF



6.6.1 TEST 1

In questo test verifichiamo la connettività tra i vari router CE Figura 6.7 eFigura 6.8 .

Figura 6.7: CE1 to CE2

Figura 6.8: CE1 to CE3

40

6.6.2 TEST 2

In questi screenshots sono mostrate la tabella di routing globale e la tabellavrf A del router PE1 Figura 6.9 e Figura 6.10.

Figura 6.9: Tabella di routing globale di PE1

Figura 6.10: Tabella di routing VRF A di PE1

41

Bibliografia

[1] Alcatel–Lucent Transformation of mission-critical communicationsnetworks. Migrating from SDH/SONET networks to IP/MPLS networks

[2] E. Rosen, Y. Rekhter RFC 4364: BGP/MPLS IP Virtual Private Networks(VPNs)

[3] K. Kompella, Y. Rekhter RFC 4761: Virtual Private LAN Service (VPLS)Using BGP for Auto-Discovery and Signaling

[4] M. Lasserre, V. Kompella RFC 4762: Virtual Private LAN Service (VPLS)Using Label Distribution Protocol (LDP) Signaling

[5] Luc De Ghein MPLS Fundamentals, Cisco Press 2006

[6] Ina Minei, Julian Lucek MPLS-Enabled Applications: EmergingDevelopments and New Technologies 3rd Edition, Wiley 2010

[7] Juniper Networks VPLS Configuration Guide

42

Consiglio Nazionale delle Ricerche - iit.cnr.it B4-08-2016.pdf · le diﬀerenzia maggiormente è...

Documents

Transcript of Consiglio Nazionale delle Ricerche - iit.cnr.it B4-08-2016.pdf · le diﬀerenzia maggiormente è...