Saturday, June 28, 2014
BGP/MPLS IP VPN
Un service provider se poate folosi de propria retea backbone pentru a furniza servicii IP VPN pentru clientii sai.
Routerele clientilor (CE) transmit toate rutele catre provider pe routere PE. BGP este apoi folosit de catre Service Provider (SP) pentru a tine actualizate rutele cu alte routere PE care apartin unui VPN.
Actiunea este realizata in asa fel incat rutele de la VPN-uri differite raman distincte si separate, chiar daca doua VPN-uri au un spatiu de adresare identic.Routerele PE distribuie catre routere CE dintr-un anumit VPN, rutele de la alte routere CE ce apartin aceluiasi VPN.
Routerele CE nu fac peering unul cu celalalt si prin urmare nu exista un "overlay" care sa fie vazut de alogritmul de rutare al VPN-ului. Termenul "IP" din "IP VPN" este folosit pentru a indica faptul ca routerul PE receptioneaza pachete IP de la CE, examineaza headerele IP, si le ruteaza corespunzator.
Fiecare ruta dintr-un VPN ii este asignata o eticheta MPLS. Cand BGP distribuie o ruta VPN, distribuie si eticheta MPLS pentru acea ruta.
Inainte ca pachetele de date sa traverseze reteaua backbone a SP-ului, acestea sunt encapsulate intr-o eticheta MPLS ce corespunde cu reteaua VPN a clientului si rutata catre adresa de destinatie a pachetului.
2. Retele Virtuale Private (VPN)
Sa ne imaginam un grup de "site-uri" ce sunt legate la o retea de date comuna pe care o numim backbone. Plecand de la premiza anterioara, se aplica apoi niste politici pentru a crea mai multe sub-gurpuri ale gurpului principal unde se impune urmatoare regula: doua site-uri pot avea conectivitate IP prin backbone daca unul din cele doua stie de ambele sub-grupe.
Aceste sub-gurpuri sunt VPN-urile. Doua site-uri care nu au un VPN in comun nu au conexiune prin reteaua backbone.
Daca toate site-urile ale unui VPN se afla in administrarea aceleasi enterprsie, VPN-ul poate fi interpretat ca si un "intranet" al unei companii. Daca site-urile VPN apartin mai multor entitati atunci VPN-ul este considerat un extranet. Un site poate face parte din mai multe retele VPN (ex. intr-un intranet si in cateva extranet-uri). Aici insa, cand folosim termenul de VPN nu se face distinctia intre extranet si intranet.
Administratorii site-urilor sunt denumiti clienti , iar operatorii/administratorii backbone-ului, Service Provider. Clientii obtin servicii VPN de la SP.
Un client poate fi un ISP, un Application Service Provider, un SP care ofera acelasi tipuri de serviciu VPN, o companie sau un grup de comapanii.
Politicile care determina daca o colectie de site-uri este un VPN apartin clientilor. Unii clienti vor dori ca implementarea politicilor sa fie responsabilitatea SP-ului. Alti clienti ar dori sa imparta responsabilitatea cu SP-ul.
3. Customer Edge si Provider Edge
Routerele pot fi conectate la alte router sau la sisteme si in diverse feluri: conexiuni PPP, circuite virutale ATM sau Frame Relay, interfete ethernet, VLAN-uri, tunele GRE, tunele L2TP, tunele IPSEC.Ce conteaza este ca e posibil ca doua device-uri sa aibe peering indiferent de ce "data link" se afla.
Fiecare site VPN trebuie sa aibe unul sau mai multe device-uri care au rol de CE. Fiecare din ele este conectat, indiferent de metoda, la router-ul PE al SP-ului.
Nota: Routere care se afla in reteaua provider-ului si nu sunt direct conectate la device-uri CE sunt denumite si "P routers"
Device-urile CE pot fi host-uri sau routere. De regula, un site contine unul sau mai multe routere, unele dintre ele avand legatura catre routere PE. Acele echipamente ar avea rolul de routere CE, desi nu exista motiv pentru care un host sa nu se poata lega direct la un router PE. Acel host va deveni un device CE
Uneori, legatura fizica catre rotuterul PE este de la un switch L2. In situatia asta nu se spune ca switch-ul de L2 este un device CE. In schimb, device-ul CE sunt host-uri sau routere care comunica cu routerul PE cu ajutorul switch-ului L2. Infrastructura L2 este transparenta. Acesta in schimb poate furniza mai multe device-uri CE de la acelasi circuit.
Nota: Device-urile CE reprezinta partea logica a retelei VPN a clientului. Routerele PE si P sunt partea logica a retelei SP.
Cand un device CE este un router, acesta este si un peer cu PE-urile la care este conectat dar nu este si peer cu alte site-uri. Routere de la alte site-uri nu fac schimb direct de tabele de rutare; de fapt nici nu trebuie sa stie ca exista. Drept urmare, clientul nu are un backbone, nici macar virtual, pe care acesta trebuie sa il administreze si nu trebuie sa se ingrijoreze cu probleme de rutare intre site-uri. In alte cuvinte, un VPN nu este un adaos in reteaua SP-ului.
In ce priveste administrarea echipamentelor, delimitari clare sunt mentinute intre SP si clientii sai. Clientii nu sunt nevoiti sa acceseze routere PE sau P si nici SP-ul nu este nevoit sa acceseze device-urile CE.
4. VPN-uri cu spatii suprapuse de adresare.
Daca doua VPN-uri nu au site-uri in comun, atunci este posibil sa aibe spatiul de adrese suprapus. Anume, o adresa ar putea fi folosita (S1) de la site-ul VPN V1 dar poate fi si adresa S2 de la site-ul VPN V2. Este o situatie des intalnita cand fiecare VPN foloseste adresele specificate in RFC 1918.
Chiar si doua VPN-uri care au site-uri in comun pot avea spatii de adresare care se suprapun, cat timp nu este nevoie de comunicarea intre sisteme care au acele adrese.
5. VPN-uri cu rute diferite cu destinatii catre acelasi sistem.
Desi un site poate fi conectat la mai multe VPN-uri nu este necesar ca ruta catre un sistem anume din acel site sa fie similar in toate VPN-urile.
Sa presupunem ca avem un intranet ce consta din site-urile A, B si C si un extranet ce consta din A, B, C si unul "extern" D. La site-ul A se afla un server, si vrem ca cei din B, C, sau D sa folosescea serverul respectiv. La site-ul B este un firewall. Vrem ca traficul de la site-ul D catre server sa treaca prin el, astfel incat traficul de la extranet sa poata fi controlat. Dar nu vrem ca traficul de la C sa treaca prin firewall pentru ca el este trafic de intranet.
In situatia de mai sus este posibl sa configuram doua rute catre server. O ruta, este folosita de site-urile B si C, preia traficul direct catre serverul de la site-ul A. A doua ruta folosita de site-ul D, duce traficul la firewall-uld e al site-ul B. Daca firewall-ul permite ca traficul sa mearga mai departe, va fi ca si cum traficul vine de la site-ul B, care poi sa duce la site-ul A
5. Routere Backbone ale SP-ului
Backbone-ul SP-ului consta in routere PE, precum si alte routere P care nu se ataseaza la deivce-urile CE
Daca fiecare router din backbone-ul SP-ului ar trebuie sa mentina informatiile de rutare pentru toate VPN-urile pe care le are, ar fi fost probleme de scalabilitate severe; numarul de site-uri care ar trebui suportate ar fi limitate de marimea tabelei de rutare pe care un router poate sa o aiba. Din acest motiv, informatia legata de tablea de rutare trebuie sa fie prezenta pe routerele PE care sunt conectate la acel VPN.
Routerele P nu au nevoie de nicio informatie legate de rutare. (Conditie care ar putea fi relaxata atunci cand este vorba de rutare multicast - VPN MCast)
Asa cum nici clientii nu au o retea backbone ca sa o administreze, nici SP-urile nu au un backbone separat sau unul virutal pe care sa il administreze pentru fiecare VPN. Rutarea site-to-site in backbone este optima si nu este constransa in niciun fel de "topologia virutala" de tunele
6. Securitate.
Configuratia corecta nu face posibila ca sistemele dintr-un VPN sa aibe access la systemele din alt VPN. Daca este nevoie de criptarea datelor, din motive de privacy se poate folosie MPLS/BGP-IPSec.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment