Protocolul Mpls Notiuni de Baza Si Implementare

Protocolul MPLS noțiuni de bază și implementare

Cuprins

1. Introducere

1.1 Factorii principali în implementarea rețelei MPLS

1.2 Tendințe curente

2. Fundamentele rețelei MPLS

2.1 Arhitectura MPLS

2.2 Control plane

2.3 Forwading plane

2.4 LDP

2.5 RSVP-TE

3. Tipuri de implementări MPLS

3.1 Introducere

3.2 Layer 3 MPLS VPN

3.4 Virtual Private LAN Services (VPLS)

3.5 Concluzii

4. MPLS Traffic Engineering

4.1 Obiective ale TE

4.2 Setarea unei rute predefinite pentru TE

5. Funcționalitatea siguranței în MPLS

5.1 Protecția traseului

5.2 Protecția locală

5.3 Protecția nodului

6. Configurarea unei rețele MPLS bazata pe echipamente CISCO

Abrevieri folosite:

AD – Administrative Distance

APS – Automatic Protection Switching

AS – Autonomous system

ASA – Adaptive Security Appliance

ASIC – Application Specific Integrated Circuit

ATM – Asynchronous Transfer Mode

BFD – Bidirectional Forwarding Detection

BGP – Border Gateway Protocol

CAM – Content Addressable Memory

CE – Customer Edge

CEF – Cisco Express Forwarding Cisco

IOS – Cisco Internetwork Operating System Cisco

PIX – Cisco Private Internet eXchange

CLR – Conservative Label Retention mode CoS – Class of Service

CPU – Central Processing Unit

CRC – Cyclic Redundancy Check

CSPF – Constrained SPF

CW – Control Word

DiffServ – Differentiated Services

DLCI – Data Link Connection Identifier

DSCP – DiffServ Code Point

eBGP – External Border Gateway Protocol

EC – Extended Community

EGP – Exterior Gateway Protocol

EIGRP – Enhanced Interior Gateway Routing Protocol

E-LDP – EXP based LSP

ERO – Explicit Route Object

EXP – Experimental

FEC – Forwarding Equivalency Class

FIB – Forwarding Information Base

FRO – FRR Object

FRR – Fast Reroute

GNS3 – Graphical Network Simulator 3

GRE – Generic Routing Encapsulation

GUI – Graphical User Interface

iBGP – Internal Border Gateway Protocol

ICMP – Internet Control Message Protocol id – Identifier

IETF – Internet Engineering Task Force

IGP – Internal Gateway Protocol IntServ – Integrated Services

IP – Internet Protocol

IPS – Intrusion Prevention System

IPsec – IP Security

IPv4 – Internet Protocol version 4

IPv6 – Internet Protocol version 6

IS-IS – Intermediate System to Intermediate System

ISP – Internet Service Provider

JunOS – Juniper Operating System

L2VPN – Layer 2 VPN

L3VPN – Layer 3 VPN

LAB – Laboratory

LAN – Local Area Network

LDP – Label Distribution Protocol

LFIB – Label Forwarding Information Base

LLR – Liberal Label Retention mode

L-LSP – Label-inferred based

LSP LSP – Label Switch Path

LSR – Label Switch Router

MAC – Media Access Control

MP – Merge Point

MP-BGP – Multiprotocol BGP

MPLS – Multiprotocol Label Switching

NAT – Network Address Translate

NLRI – Network Layer Reachability Information

OSPF – Open Shortest Path First

P – Provider

PA – Path Attribute

Path – Path message

PathErr – Path Error message

PathTear – Path Teardown message

PE – Provider Edge

PHB – Per Hop Behavior

PHP – Penultimate Hop Popping

PLR – Point of Local Repair

PPP – Point-to-point protocol

PSTN – Public Switched Telephone Network

QoS – Quality of Service

RAW – Reading And Writing

RD – Route Distinguisher

Resv – Reservation message

ResvErr – Reservation Error message

ResvTear – Reservation Teardown message

RFC – Request For Comments

RIB – Routing Information Base

RR – Route Reflector

RRO – Record Route Object

RSVP-TE – Resource Reservation Protocol – Traffic Engineering

RT – Route Target

SAO – Session Attribute Object

SDH – Synchronous Digital Hierarchy

SONET – Synchronous Optical Networking

SPF – Shortest Path First

SRLG – Shared Risk Link Group

TCP – Transmission Control Protocol

TDM – Time Division Multiplex

TED – Traffic Engineering Database

ToS – Type of Service TTL – Time To Live

VC – Virtual Circuit

VCID – VC identifier

VLAN – Virtual Local Area Network

VPI/VCI – Virtual Path Identifier / Virtual Channel Identifier

VPLS – Virtual Private LAN Services

VPN – Virtual Private Network

VRF – Virtual Routing and Forwarding

WAN – Wide Area Network

Introducere

Prima parte a lucrării își propune să descrie modul de funcționarea a unei rețele MPLS, necesitatea acestui tip de rețea, contribuția adusă ramurii rețelistice cât și modul în care suportă interconectarea diferiților clienți. În continuare ne focalizăm pe serviciile oferite de rețeaua MPLS în timp ce păstrăm izolarea clienților, modul ușor de administrare și siguranța datelor care circulă prin rețea. În următoarea parte a lucrării ne îndreptăm atenția spre detaliile implementării unei rețele MPLS cât și Traffic Engineering (TE) cu redundanță la avarii. Partea practică a acestei lucrări constă în implementarea unei rețele MLPS pe platforma CISCO. Pentru a putea emula o rețea de date MLPS cât mai aproape de realitate am ales să folosesc aplicația GNS3.

Multiprotocol Label Switching (MPLS) în prezent este cea mai utilizată rețea de către providerii de internet (ISP). Acest lucru se datorează în principal faptului că acest protocol înglobează caracteristici care până acum nu erau disponibile niciunui alt protocol. Înaintea implementării acestui protocol erau folosite tehnologi ca Asynchronous Transfer Mode (ATM), Frame Relay sau linii închiriate, toate aceste soluții au avantajele lor dar au făcut ca implementarea rețelelor între diferite locații să devină anevoioasă din punct de vedere al interoperabilității. Din nevoia de a elimina acest neajuns s-a născut idea de Tag Switching care a fost preluată, dezvoltată și apoi standardiză de către CISCO în Multiprotocol Label Switching (MPLS). Idea din spatele protocolului MPLS este să se marcheze cu o etichetă fiecare pachet care intră în rețea și care este plasat în tabela de rutare Label Forwarding Instance Based (LFIB).

Factorii principali în implementarea rețelei MPLS

De mai bine de 10 ani, protocolul MLPS a început să fie suport pentru transportul atât a altor protocoale de rutare cât și a altor tipuri de servicii de transport de date. Din acest motiv acest protocol a avut foarte mare succes în rețelele providerilor de servicii.

Multi-service network

Motivul pentru care rețeaua MPLS a devenit un real succes este se datorează abilitații de a implementa multi-service network. Acest lucru permite să avem o infrastructura a rețelei foarte variata din punct de vedere al tehnologiei și în același timp să menținem același standard unic care ne permite să avem tot ce ne trebuie pentru controlul traficului în rețea.

Virtual Private Networks

Al doilea factor important pentru implementarea unei rețele MPLS este abilitatea de a pune la dispoziție diferiților clienți o rețea privată (VPN) interconectată cu conexiuni securizate peste aceeași topologie de rețea. Acest lucru reprezintă un avantaj superior față de alte soluții de transport (ATM, Frame Relay, linii închiriate, etc).

Funcții de Traffic Engineering

Un alt factor important în implementarea unei rețele MPLS este implementarea funcțiilor de Traffic Engineering. Abilitatea de a avea controlul traficului unde și cum să fie direcționat oferă un avantaj foarte mare în utilizarea inteligenta a capacitaților de rețea disponibile evitând astfel congestionarea rețelei prin prioritizarea mai eficientă a traficului.

Fiabilitatea și siguranța rețelei

Fiabilitatea și siguranța rețelei a devenit un factor foarte popular și important când vine vorba de caracteristica rețelei MPLS. Rețeaua unui provider de servicii este absolut necesar să fie fiabilă și sigură împotriva oricărui tip de avarie sau întrerupere. Calitatea unei asemenea rețele este de a pune la dispoziție și garanta continuitatea serviciului fără încălcarea contractuală între providerul de servicii și client. În capitolul 5 vom discuta mai detaliat aceste caracteristici alea rețelei MPLS.

Scalabilitate

Înainte să apară rețelele MPLS multe rețele aveau la bază switchuri ATM înconjurate de routere care erau toate interconectate între ele pentru a putea oferi fiabilitatea necesară. Trecând la o rețea structurată MPLS aceste probleme au fost rezolvate, astfel încât nu mai este necesar ca toate routerele din rețea să fie interconectate între ele. În rețelele de tip MPLS conexiunile virtuale sunt construite și ținute în echipamentele care înconjoară practic nucleul rețelei, acest lucru reduce semnificativ numărul de destinații virtuale, la acest nivel conexiunile nucleului de rețea sunt securizate. Urmărind o abordare structurală a rețelei face ca administrarea, mentenanța și depânărea rețelei să fie mult mai ușoară pentru inginerii de rețea.

Tendințe curente

Rețelele de MPLS de astăzi pot fi implementate în diferite forme. Cele mai ușoare implementări sunt cele care se pot adapta la topologia actuală a rețelei fără a face modificări în topologie. Acesta este unul din cel mai mare beneficiu în implementarea unei rețele MPLS. În zilele noastre corporațiile au sedii un toate colțurile lumii, iar aceste sedii trebuie conectate într-o singura rețea. Pentru ca acest lucru să se realizeze ar putea să-și conecteze toate sediile cu un cablu terestru dar probabil ca acest lucru a fi extrem de costisitor și ireal de implementat. Desigur ce ar trebui să facă în acest caz este să ceară providerului de servicii să le furnizeze un VPN MPLS cu același efect dorit dar cu un cost mult mai redus, probabil că cea mai răspândită soluție este Layer 3 MPLS VPN. Un Layer 3 VPN oferă clientului o linie virtuală privată securizată și fără limitări. Folosind Layer 3 VPN toată partea de rutare se mută în administrarea providerului de servicii astfel încât clientul nu este nevoit să aloce resurse suplimentare pentru administrarea conexiunilor între sedii. O alta opțiune pentru care ar putea opta clientul este o conexiune Layer 2 configurată între cele două sedii. Aceasta este o simplă counexiune punct-la-punct între cele două sedii fără controlul procesului de rutare de către providerul de servicii, prin urmare clientul este obligat să-și administreze procesul de rutare între cele două puncte. De asemenea acest tip de conexiune permite transportul oricărui trafic de tip Layer 2 (Ethernet, ATM sau Frame Relay). Și în final ultima opțiune ar fi ca clientul să ceară o conexiune completă LAN, acest tip de servcicu face se pară ca și cum toate sediile clientului se află conectate în același switch.

În ultimul deceniu s-a dovedit că MPLS este protocolul viitorului, dat fiind faptul că putem muta servicii non-IP în rețele IP și putem folosi MPLS ca tehnologie de transport indiferent de aplicația care trebuie să o transporte. Mulți provideri de servicii folosesc MPLS pentru a transporta diferite rețele cum sunt cele de telefonie publică (PSTN), TDM sau transportul canalelor TV.

Fundamentele rețelei MPLS

Pachetele rutate traversează rețeaua în urma unei decizii de rutare luate de fiecare router în parte de la sursa la destinație. Fiecare router trebuie să proceseze informația din headerul pachetului să analize și să ia o decizie de rutare bazată pe analiza efectuată asupra pachetului și adresa de destinație. Acest lucru înseamnă că fiecare echipament spre destinația pachetului trebuie să repete prelucrarea pachetului și să ia o decizie în ce direcție trebuie să trimită pachetul. De exemplu un pachet IP conține mult mai multă informație decât doar o simplă acțiune de redirectarea spre interfața corecta. Nu doar atât dar headerul IP conține informație despre CRC care din cauza modificării valorii TTL-ului trebuie recalculat pentru a furniza detecția erorii. Acțiunea de transmitere a unui pachet către următorul router este alcătuită din două funcții. Prima dată trebuie analizat un întreg set de pachete posibile care traversează rețeaua și asocierea lor cu FEC. Toate pachetele care aparțin unui FEC sunt manipulate la fel și tot timpul vor avea aceeași cale pentru a ajunge la destinație. A două funcție este de a asocia fiecare FEC cu un anume router. Cele două funcții enumerate mai sus sunt necesare să ruleze pe fiecare echipament de-a lungul traseului.

La începutul anilor 2001 IETF a fondat protocolul MPLS care rezolva problema consumului de timp cu transmiterea pachetelor prin luarea deciziilor de transmitere bazate pe etichete care în final formează un Label Switched Path (LSP) în rețeaua MPLS. Să nu uităm că bazate pe eticheta de intrare este logica inversă în mediul rutat. Având în vedere că echipamentul nu mai trebuie să îi pese de headerul altor niveluri acesta poate transmite pachetul doar pe baza acestei etichete. Clasificarea și transmiterea se face doar o singură dată la echipamentul de intrare de unde restul rețelei MPLS nu mai inspectează conținutul headerelor și face căutarea explicita în baza etichetei de intrare la cel de ieșire asociat, schimbând cele două etichete și trimițând pachetul către interfața corectă.

Arhitectura MPLS

Pentru a înțelege mai ușor capitolele care urmează, în acest capitol voi furniza un anumit nivel de detaliu al protocolului MPLS.

Headerul MPLS

Headerul MPLS are lungimea de 32 bit, este situat logic între layer 2 și layer 3 al modelului de referință OSI și este împărțit în 4 câmpuri distribuite astfel; 20 de bit sunt folosiți pentru eticheta, următorii 3 bit erau rezervați experimental dar acum sunt folosiți pentru QoS, 1 bit marchează sfârșitul headerului iar 8 bit sunt folosiți pentru stocarea valorii TTL. (Figura 2 – 1)

Figura 2 – 1

După cum se poate observa în Figura 2 – 1 headerul de MPLS se află între layerul 2 și layerul 2, din acest motiv îl mai putem caracteriza ca și layer 2.5.

Eticheta MPLS

Eticheta este un identificator local de mărime fixă folosit pentru a identifica FEC. Este un număr alocat arbitrar care are doar semnificație locală. Această asociere între label și FEC face ca echipamentul de transmitere să genereze o valoare pentru eticheta care este transmisă echipamentului de recepție acesta va ști ca eticheta respectivă este asociată unei valori FEC. Cu alte cuvinte echipamentele adiacente de transmitere și recepție agreează să folosească această legătură între etichetă și FEC pentru a transmite traficul între ele. Pentru eticheta există un spațiu alocat de 20 bit în headerul MPLS care oferă un total de 1048575 de combinații. Etichetele de la 0 la 15 sunt rezervate pentru cazuri speciale și niciodată nu vor fi folosite în producție. Tabelul 2 – 1 arată scopul fiecărei etichete rezervate, restul etichetelor de la 16 la 1048575 pot fi folosite în scopul propus. În Tabelul 2-1 sunt prezentate tipurile de etichetele și RFC aferent unde sunt documentate.

Tabel 2-1

LER și LSR

Echipamentele care operează la marginea rețelei MPLS și care sunt punctul de contact direct cu echipamentul clientului se numesc Provider Edge (PE) sau Label Edge Router (LER). Mai departe echipamentele care se află în nucleul rețelei și fac doar label swapping din punct de vedere MPLS se numesc Label Switch Routers sau mai simplu Provider (P). Și în final echipamentele care se află la client și sunt conectate direct în PE se numesc Customer Edge (CE). În Figura 2 – 2 se poate observa un exemplu de rețea MPLS.

Figura 2 – 2

Pentru a ne putea orienta de asupra direcției LSP s-au introdus termenii precum upstream și downstream, acest lucru se aplică și pentru routerle P adiacente unu-i LSP particular pentru a se face diferența de direcție între cele două routere P. Pentru a face sens discuției vom defini un LSP. Presupunem că dorim să construim un LSP în rețea cu direcția de la PE1 la PE2. Traficul spre PE2 are o direcție de downstream iar în sensul opus se numește direcția de upstream. Cel mai aproape nod P adiacent de sursa pe parcursul LSP se numește nod upstream (P2 Figura 2 – 3) iar vecinul lui cel mai apropiat de destinație se numește nod downstream (P3 Figura 2 – 3)

Figura 2 – 3

FEC

FEC este un flux de pachete cărora li se aplică același tratament de transmitere de-a lungul drumului spre destinație. Toate pachetele care aparțin aceluiași FEC au aceeași etichetă. Deși nu toate pachetele care au aceeași etichetă aparțin aceluiași FEC deoarece valoarea bitului EXP diferă. Din acest motiv tratarea pachetului nu este neapărată la fel și ele pot aparține unui FEC diferit.[2] Clasificarea pachetelor pe un anumit FEC este făcută de routerul de intrare P. Acest lucru demonstrează toată logica în jurul comportamentului MPLS în contradicție cu transmiterea pachetelor convențională. Același FEC poate fi la fel la următoarele pachete care:

Sunt adresate aceleiași destinații

Se afla în același grup multicast

Sunt tratate la fel conform cu prioritatea sau IP DiffServ

Aparțin aceluiași VC sau sub interfață în punctul de intrare LSP

Principalul rezultat al clasificării FEC este că pachetele aparținând aceluiași FEC sunt tratate în același mod ca și cum ar primi același label la fiecare punct de ieșire.

LSP

LSP este un traseu unidirecțional format în interiorul rețelei MPLS între două noduri, nu este necesar ca nodurile să fie la marginea rețelei. Cu alte cuvinte LSP este o înșiruire de LSR care trimit pachete etichetate cu un același FEC. Nodul care inițiază un LSP se numește head end of LSP sau ingress LSP. Asemănător nodul unde se termină LSP se numește tail end of LSP sau egress LSP. Identificarea corectă a etichetei pentru nodul downstream este o problemă ce ține de control plane unde sunt ținute legăturile dintre etichete și noduri și sunt distribuite cu ajutorul protocolului de distribuție al etichetelor, Label Distribution Protocol (LDP).

Figura 2 – 4

Un exemplu de LSP se poate observa în Figura 2 – 3, secvența traseului fiind PE1-P2-P3-PE2. Spre deosebire de transmiterea convențională a pachetelor în MPLS avem 3 funcții diferite care sunt efectuate de-a lungul LSP.

În Figura 2 – 4 avem un exemplu de distribuție a etichetele și modul în care sunt transmise pachetele ale funcțiilor de mai jos.

Label Pushing

Label pushing este procesul prin care se creează un header cu o anumită valoare label reprezentând un anume FEC. Pachetele care sunt transferate prin rețeaua MPLS sunt marcate cu un nou label la ingress LSR. Figura 2 – 1 arată unde este aplicată eticheta în interiorul headerului MPLS.

Label Swapping

Label swapping este procesul prin care LSR schimbă valoare etichetei care este aplicată pachetului primit, pentru vecinii de downstream ai săi. Scopul este să trimită pachetele spre destinație cât mai repede, iar pentru acest lucru următoarele acțiuni au loc:

LSR extrage valoarea din label a unui pachet primit

Determină eticheta și interfațata de ieșire pentru o anumită etichetă

LSR schimbă eticheta de intrare cu cea de ieșire și trimite pachetul spre interfața de ieșire determinată anterior.

Label Popping

Label popping este procesul prin care o etichetă a unui pachet este înlăturată din headerul MPLS. Există două metode diferite prin care eticheta poate fi înlăturată din header.

Explicit null – egress LSR anunță eticheta cu valoarea 0, care reprezintă IPv4 explicit null sau 2 pentru IPv6 explicit null, către vecinii de upstream. Acest lucru spune penultimului LSR că este lângă ultimul nod din LSP și va înlocui eticheta primită cu valoarea 0. Dacă pachetul este marcat de către egress LSR împiedică routerul să păstreze informații care nu sunt necesare despre pop label. Un explicit null menține LSP Class of Service (CoS) pe tot parcursul LSP prin păstrarea headerului MPLS până ajunge la egress LSR.

Implicit null – egress LSR anunță label cu valoarea 3 către vecinii de upstream. Acest lucru indică penultimului router să facă pop în loc de swap iar rezultatul fiind de a avea același pachet original primit de ingress LSR. Acest lucru salvează timpul necesar de egress LSR să proceseze încapsularea încărcăturii. Aceasta abordare se mai numește și penultimate hop popping. Deoarece headerul MPLS nu există la nivelul nodului egress LSR, acesta este obligat să manevreze pachetul conform setărilor CoS specifice din payload.

Penultimate hop popping

Folosind penultimate hop popping evităm scenarii în care egress LSR este nevoit să verifice de două ori eticheta. Din punctul de vedere logic nu este nevoie să facem verificarea la egress LSR, deoarece pachetele de o anumită mărimea a labelului au ajuns la destinație. Cu alte cuvinte pachetul MPLS va elimina un header MPLS când ajunge la penultimul nod. Acuma dacă egress LSR primește un pachet etichetat va face o verificare și va trimite pachetul mai departe cu o noua etichetă.

LSP next hop

LSP next hop este totdeauna determinat din tabela de forwarding în funcție de valoare etichetei de intrare. Acest next hop poate fi diferit de next hop care este determinat pentru alte protocoale.

Label stack

Label stack este o succesiune de etichete fiecare încorporate în propriul header MPLS (Figura 2 – 5). Ultimul header MPLS din stiva are setat bitul, care indica sfârșitul stivei, pe 1.

Figura 2 -5

Moduri de operare MPLS

Asignarea și distribuirea unei etichete

Asignarea etichetelor începe la ingress LSR prin aplicarea headerului MPLS unui pachet care poate fi chiar alt pachet MPLS deja etichetat sau alte protocoale care sunt transportate prin rețeaua MPLS. Nodul de downstream va schimba eticheta aplicată unui pachet primit cu o altă etichetă de trimitere care va conta doar pentru nodul următor de downstream. În momentul în care pachetul ajunge la egress LSR, eticheta este scoasa din headerul MPLS, și LSP se termină. Toate acestea nu s-ar putea întâmpla dacă valorile etichetelor nu ar fi distribuite în rețeaua MPLS. Etichetele au înțeles local doar pentru echipament în sine. Pentru ca să se poate realiza comunicația trebuie să există un algoritm care va spune echipamentului ce eticheta va fi folosita pentru a putea trimite un pachet către nodul de downstream. Acest algoritm poate fi implementat în două moduri diferite:

Poate fi instalat la baza unu protocol de rutare IP deja existent – așa numita etichetare suprapusă (piggybacking labels)

Poate fi asigurat folosind un protocol separat – label distribution protocol (LDP)

Distribuția etichetelor suprapuse peste un protocol de rutare IP deja existent. Această metoda se bazează pe un protocol IGP pentru distribuirea etichetelor. Pentru acest scop protocoalele IGP trebuie să aibă extensia necesară acestui proces. Avantajul acestui mod este ca tot timpul există o etichetă pentru FEC deoarece aceasta funcție este incorporată.

Având în vedere că protocolul BGP nu este un protocol de rutare IGP poate facilita distribuția etichetelor iar de obicei este folosit în rețelele MPLS VPN.

Distribuția etichetelor cu un protocol separat și specializat în acest sens. În multe situații este mai convenabil să introducem un nou protocol pentru distribuirea etichetelor. Există câteva motive pentru care ar trebui să folosim protocoale independente pentru distribuția etichetelor decât să folosim IGP pentru acest scop.

Nu toate platformele oferă extensii pentru distribuirea etichetelor

MPLS poate fi distribuit peste mai multe Autonomous Systems (AS) în timp ce IGP este legat de un singur AS

Ar fi o provocare pentru anumite protocoale link-state să implementeze distribuția etichetelor

Un protocol independent de distribuit etichete furnizează un mediu la care pot fi adăugate alte funcții noi

Bazarea pe protocoale IGP nu este o idee prea bună

În prezent cele mai răspândite protocoale de distribuție a etichetelor sunt:

Label Distribution Protocol (LDP)

Resource Reservation Protocol – Traffic Engineering (RSVP-TE)[4]

Moduri de distribuire a unui etichete

În MPLS există două abordări în distribuirea etichetelor. În Figura 2 – 6 expunem ambele moduri de distribuție.

Unsolicited downstream, este modul în care LSR anunță legăturile etichetelor către downstream LSR adiacent fără ca acele LSR să facă cerere pentru o eticheta specifică.

Downstream on demand, este modul prin care LSR trebuie să facă cerere la upstream LSR adiacent pentru o eticheta specifică. Upstream LSR răspunde cu o eticheta specifică unui FEC.

Figura 2 – 6

Moduri de păstrare a unei etichete

Diferitele moduri de retenție se referă la cum un echipament folosește legăturile etichetelor care nu sunt utilizate.

Liberal label retention (LLR), folosind acest mod de retenție echipamentul retine toate legăturile etichetelor în FIB. Doar legăturile etichetelor anunțate de downstream LSR și folosite pentru transmiterea unui FEC sunt puse în LFIB. Restul legăturilor de etichete primite de la un alt LSR sunt asociate cu un FEC și păstrate în FIB. Acest lucru permite LSR să actualizeze imediat LFIB cu noile legături ale etichetelor și să înceapă să trimită trafic după schimbarea topologiei rețelei datorita unui eveniment.

Conservative label retention (CLR), în acest mod LSR păstrează doar conexiunile etichetelor primite la un downstream LSR pentru un anumit FEC.

Concluzii

Principala diferența între LLR și CLR este ca LLR se adaptează repede la schimbări de topologie în timp ce CLR păstrează mai puține legături ale etichetelor în memorie. O practica bună este să se folosească CLR pentru distribuirea etichetelor downstream on demand și LLR pentru modul de distribuție unsolicited downstream.

Moduri de control LSP

Un echipament poate să creeze o legătura a etichetelor local folosind două moduri de abordare.

Independent LSP control mode. Când este folosit acest mod echipamentul va crea legăturile etichetelor locale independent de orice alt LSR, iar lucru acesta se va întâmpla imediat ce un FEC este recunoscut.

Ordered LSP control mode. Când este folosit acest mod formațiunile LSP sunt inițiate la ingress LSR și succesiv propagate în întreaga rețea până se ajunge la punctul egress. În acest mod LSR creează legăturile etichetelor doar dacă recunoaște ca este egress LSR pentru FEC sau data LSR a primit legătura unei etichete pentru next hop.[2]

Concluzii

Dacă folosim modul de control independent LSP s-ar putea ca echipamentul să înceapă să trimită pachete înainte ca tot LSP să se stabilească, ceea ce ar putea rezulta în inconsistența transmiterii de pachete sau chiar pierderi de pachete.

Control plane

Control plane al unui router este locul unde se întâmplă toate computațiile și deciziile legate de transmiterea finala a unui pachet. Entitatea cea mai mare este protocolul de rutare sau rute statice care sunt responsabile pentru alcătuirea tabelei de rutare. Mai mult un router poate fi configurat cu echipamente adiționale pentru a creste puterea de control.

Componentele control plane:

Protocoale de rutare – sunt responsabile pentru alcătuirea tabelei de rutare

Routing Information Base (RIB) (de ex. tabela de rutare IP) – este locul un în care routerul caută destinația cu cel mai lung prefix pentru a putea trimite pachetul spre destinație. Dacă există mai mulți candidați către aceeași destinație, în RIB se va instala prefixul cu cel mai mic Administrative Distance (AD).

Label Distribution Protocol – protocolul responsabil cu crearea de LSP prin rețeaua MPLS prin schimbul de etichete.

Forwading plane

Este partea dintr-un router care se ocupă cu transmiterea pachetelor. Are o tabela care definește deciziile finale pentru a trimite pachetele primite. De obicei informația pentru transmitere este ținuta logic într-o tabela care de obicei este controlata de control plane. Forwarding plane diferă de la producător la producător dar ideea este aceeași, să grăbim procesul prin care se iau deciziile de rutare.

LDP

Label Distribution Protocol este cel mai răspândit protocol de distribuție a etichetelor în rețeaua MLPS. În timp ce găsește LSP de la ingress la egress întotdeauna folosește la baza o cale IGP. Este foarte util dacă dorim să implementăm foarte repede MPLS într-o rețea. Prin simpla activare LDP pe o interfață o rețea full-mesh de tunele va fi automatic creata în toată rețeaua bazându-se pe informația disponibila în protocolul IGP. Din acest motiv il face foarte ușor de implementat dar nu poate fi folosit pentru TE în rețeaua MPLS.

RSVP-TE

Resource Reservation Protocol este protocolul IntServ pentru alocarea de resurse pe parcursul unui traseu pentru un anumit flux de date. Scopul inițial a fost de a permite utilizatorilor să ceară rețelei o anumită setare QoS și apoi să ajute nodurile pe traseu să stabilească și să mențină o asemenea conexiune. RSVP a fost dezvoltat cu mult timp în urma protocolului MPLS, dar grupul care s-a ocupăt de MPLS a adoptat această implementare și au definit-o ca standard RSVP-TE. Acest protocol oferă funcționalitatea pentru semnalizarea traseului cu toate extensiile necesare pentru a adaugă capabilitatea de traffic engineering în rețeaua MPLS.

RSVP-TE oferă următoarele caracteristici:

Semnalizarea traseului și menținerea acestuia

Calcul Constrained Shortest Path First (CSPF)

Definirea traseului explicit

Rezervarea de resurse de-alungul traseului

Capabilități fast rerouting

Colorarea conexiunilor

LSP preferăt

Routerul ingress inițiază o sesiune RSVP unidirecțională trimițând un mesaj Path către punctul egress din rețea. Mesajul Path conține atributele necesare semnalizării resurselor de rețea din drumul spre destinație. După aceea un mesaj Resv este trimis către ingress LSR conținând informații dacă atributele au fost nu onorate și desigur securizarea etichetei asignate acestui LSP.

Mesaje RSVP-TE pentru a semnaliza o sesiune:

Path – este folosit pentru a crea LSP sau pentru împrospătare periodica

Resv – folosit pentru a semnaliza resursele rezervate și se ocupă de asignarea etichetelor, mesajul este originat de egress LSR și procesat de toate echipamentele care fac parte din RSVP până ajunge la ingress LSR

PathTear – în totdeauna merge spre downstream și este folosit pentru a șterge LSP și eliberarea de resurse ocupate. Poate fi generat de oricare ingress LSR sau orice nod căruia i-au expirat conexiunile

ResvTear – folosit doar pentru a dealoca resurse pentru un anumit LSP

PathErr – folosit pentru a raporta erorile în timp ce se procesează mesajele Path care circula în direcția upstream

ResvErr – folosit la raportarea erorilor de rezervarea resurselor și traversează fiecare hop până la egress LSR

Protocolul RSVP-TE este potrivit pentru a acomoda necesitățile TE într-o rețea MPLS. Acest protocol permite inginerilor de rețea să configureze cate un LSP individual pentru a avea o cale potrivită. Acesta va semnaliza fiecare stare a rețelei chiar dacă evenimentul s-a încheiat cu succes sau a avut loc eroare.

Tipuri de implementări MPLS

Introducere

Rețeaua MPLS permite crearea de diferite tipuri de VPN pentru a transporta traficul clienților peste aceeași infrastructură de rețea. MPLS pune la dispoziție tunelare transparentă între punctele clienților. În acest capitol voi face o descriere a celor mai întâlnite tipuri de implementări de VPN disponibile în rețelele providerilor de servicii, care sunt următoarele:

Layer 3 MPLS VPN

Layer 2 MPLS VPN

Virtual Private LAN Service

În continuare vom trece face o descriere a implementărilor enumerate mai sus.

Layer 3 MPLS VPN

Modelul BGP/MPLS VPN

Acest model de implementare mai este și cunoscut sub simplul nume de L3VPN, acest model este cel mai de succes model deoarece combina cel mai bine două tipuri de VPN, VPN prin linii virtuale și VPN punct-la-punct.

Următoarele caracteristici pot descrie modelul L3VPN:

Provizionarea statică nu este necesară

Implementarea unui site nou nu necesită modificarea altor siteuri

Instanțe separate de rutare per client

Filtrarea traficului nu mai este necesară. Cu instanțe separate de rutare pachetele unui client nu mai pot ajunge în rețeaua altui client.

Nu există restricții în folosirea rutei implicite

Pentru a face funcțional acest model două noi componente au fost introduse în rețeaua MLPS:

1 – Virtual Routing and Forwarding (VRF), componenta de separarea a instanțelor de rutare ale clienților.

2 – Componenta de schimb a informație între instanțele clienților, Multi-Protocol BGP (MP-BGP), care permite ca adrese IP multiple de calași fel să fie folosite în paralel peste rețea.

Modelul cu instante VRF

Conceptul de VRF nu are neapărat legătură cu MPLS sau cu MP-BGP. VRF simplu adaugă mai multe instanțe pe echipament. VRFurile nu au nimic în comun între ele sau instanțele globale de rutare, dacă nu se specifică explicit acest lucru printr-o politică de rutare. Putem să considerăm un router virtual separat de cel fizic (Figura 3-1). VRFul este asignat unei interfețe dar acest lucru nu înseamnă ca interfața este alocată doar acestui VRF.

Figura 3-1

O instanță de VRF pune la dispoziție separarea informație de rutare dar nu garantează izolarea traficului între instanțe. Desigur există un mecanism care controlează informația instalată în fiecare instanță VRF.

Un exemplu care demonstrează cum funcționează VRFul se poate observa în Figura 3-2. În care Clientul 1 și Clientul 2 au scheme de adresare la fel în rețeaua lor dar nu se suprapun deoarece prin implementarea cu VRF fiecare client are instanța lui de rutare și interfețe dedicate în fiecare VRF.

Implementarea VRF

Implementarea de instanțe VRF distribuite în întreaga rețea poate fi redusa la implementarea unui protocol de tunelare cum este de exemplu MPLS care va putea încapsula și transporta traficul direct pe PE corect. Cu ajutorul tunelării echipamentele din rețea nu sunt nevoite să știe despre toate instanțele VRF ale clienților deoarece traficul a fost încapsulat și clasificat pentru a fi transmis către PEul care trebuie. În acest mod echipamentele din nucleul rețelei sunt nevoite doar să care traficul încapsulat către marginea rețelei de MPLS, ele oferă doar fundația pentru implementarea tunelurilor. Însuși MPLS este o tehnica de tunelare mult mai ușor de implementat decât o topologie de interconectare totală a tunelurilor.

Figura 3-2

Ca MPLS să funcționeze este necesar ca rețeaua să ruleze unul din protocoalele de rutare IGP, pe urmă este doar o chestiune de câteva comenzi care activează protocolul MPLS. În Figura 3-3 putem observa tehnica de tunelare care ajuta la distribuirea traficul clienților.

Figura 3-2

Distribuirea informațiilor de routare

Până acum se cunoaște faptul ca informația de rutare este deținută de către routere dar nu s-a discutat despre distribuirea și constrângerea ei per VPN. Există două moduri securizate de a distribui informația per VPN. Primul mod ar fi că fiecare informație de rutare a unui VPN să se păstreze în instanțe separate a protocolului de rutare, dar este clar că lucrul acesta este greu de administrat și nu este scalabil, pentru ca ar însemnă ca pentru fiecare VPN să configurăm o instanță de rutare a protocolului de rutare iar acest lucru doar ar complica lucrurile mai mult. A două soluție mult mai elegantă este să folosim MP-BGP.

MP-BGP

Urmând această abordare putem distribui și administra toată informația despre rutare a VPNurilor într-o singura instanță. MP-BGP este o extensie a protocolului BGP furnizează modalitatea de distribuire și constrângerea multiplelor familii de adresare. În alta ordine de idei BGP este singurului protocol care are capabilitatea și suportul necesar furnizării modelului L3VPN.

Route Reflector (RR)

Arhitectura BGP necesită ca pentru vecinii interni să avem o rețea total interconectata între toate PEurile. RR poate fi folosit pentru a reduce numărul de conexiuni iBGP. În acesta abordare RRurile sunt toate interconectate între ele și restul sesiunilor BGP din același AS se vor conecta doar cu RRurile., de obicei există mai mult de un RR în rețea pentru a avea redundanta, prin urmare vecinii care sunt desemnați RR sunt esențiali pentru a pune la dispoziție conexiuni iBGP din același AS.

Route Distinguisher (RD)

În mediile unde coexista mai multe domenii de rutare avem nevoie să diferențiem fiecare instanță de rutare, aici intervine RD. RD este o valoare de 8 bytes prefixată prefixelor din fiecare VRF. Acest lucru ne dă unicitatea tuturor prefixelor dintre instanțele de rutare. Nu contează cum este structurat RDul atât timp cât se alocă un RD unic pentru fiecare instanță de VRF. Acesta este și motivul pentru care BGP poate doar să distribuie rute IP exclusive.

În Figura 3-4 avem 3 tipuri de structuri folosite ca valori RD. Poate să fie o combinație între un număr arbitrar și numărul AS sau adresa IP. De obicei se folosește adresa AS a providerului sau adresa IP a routerului PE. Ambele sunt urmate de un număr local semnificativ.

2 bytes 2 bytes 4 bytes

2 bytes 4 bytes 2 bytes

2 bytes 4 bytes 2 bytes

Figura 3-4

Adițional RDului mai există 4 bytes alocați adresei IP, se poate vedea în Figura 3-5, această adresă este unică înăuntru unui VRF/VPN. Un exemplu de RD cu adresa IPv4 este 8708:100:10.03.0/24

8 bytes 4 bytes

Figura 3-5

Route Target (RT)

RT este folosit pentru a constrânge informațiile de rutare, RT mai este cunoscut și ca o extensie a comunităților BGP. Are o lungime de 64 bit care se împarte în două astfel, 32 bit sunt folosiți pentru numărul AS al providerului iar restul de 32 bit sunt pentru o valoare arbitrară. Combinația dintre RD, adresa IPv4 și RT produce o informație de rutare unica pentru BGP și se poate scrie ca o succesiune de valori separate prin două puncte (:), de exemplu 36500:400:10.0.3.0/24:36500:999. Din punct de vedere al tabelei VRF există două declarații:

Export RT – ce rute vor fi exportate din VRF în BGP

Import RT – ce rute vor fi importate din BGP în VRF

Pentru a putea urmări cum sunt aplicate în practica aceste tehnici urmărim exemplul din Figura 3-9 unde sunt configurate două VRFuri. MPLS este nucleul care pune la dispoziție logica de tunelare între PE. Fiecare prefix din ambele VRFuri este configurat cu un RD și RT. În abastru este valoare RD compusa din interfața de loopback și un număr arbitrar al fiecărui PE, iar în verde este RT format din AS și un număr arbitrar, în modul acesta putem idenfica care PE furnizează conectivitate pentru prefixele respective. În final este la îndemâna VRFului ce va fi importat într-o instanță particulară bazată pe RT.

Figura 3-9

Tunel VPN

Până acum știm cum MP-BGP poate să schimbe informația de rutare din VRF și cum este folosit MPLS pentru a crea tunele între PE. Pentru a afla legătură între pachetele primite și instanțele de VRF de pe un PE se aplică VRF pe o interfață care se afla în într-un anumit VPN. Din păcate această soluție nu poate fi implementată și pe egress PE dar spre norocul nostru alternativa este foarte simplă. Se folosește un alt layer MPLS care formează tunelul VPN. În mesajul de actualizare BGP PE este informat despre o eticheta spre VPN asociat unei prefix din VPN. Această etichetă nu se modifică niciodată pe parcursul traseului și are ca scop transportul de informație pentru egress PE pentru care instanță de VRF primește pachete.

Layer 2 MPLS VPN

Alt tip de VPN disponibil în MPLS este Layer 2 MPLS VPN sau pe scurt L2VPN. Idea generala a L2VPN este ca din moment ce deja avem o infrastructura MPLS L2VPN ar putea fi folosita pentru transportul pachetelor Layer 2 care sunt direct tunelate peste rețeaua IP MPLS. Rezultatul acestei implementări este ca din punct de vedere al CE pare să fie direct conectate între ele. Nu contează ce fel de conexiune Layer 2 este folsoita de către client, poate fi ATM, PPP, Frame Relay sau Ethernet sau toate împreună deoarece în final sunt tunelate peste rețeaua MPLS. Conexiune dintre PE și CE se referă la un Attachment Circuit (AC). Dezavantajul acestei conexiune este ca sunt necesare interfețe fizice multiple între PE și CE. Desigur pentru a suporta tipuri de conexiuni diferite din partea CE pe PE trebuie implementate anumite tehnologi Layer 2. Un mare beneficiu adus interconectării layer 2 este ca clienții pot folosi tot felul de tehnology layer 2.

Principii de transport Layer 2 peste MPLS

O conexiune între CEuri peste rețeaua MPLS se referă la pseudowire datorita faptului ca o singura conexiune între două puncte poate fi considera ca un sigur fir format de către MPLS. În Figura 3-12 putem vedea o interconectare a multiplelor CEuri folosind pseudowire. Traficul este trimis între CEuri printr-un anumit circuit, în funcție de te tehnologie circuitul poate fi VLAN, PVC sau DLCI. Este nevoie de circuite diferite pentru fiecare destinație. De exemplu CE1 trimite pachete către CE3 prin circuitul 200, PE3 trebuie să schimba valoare în 500 pentru a-i lui CE3 ca este un pachet de comunicare între CE1 și CE3. Nu contează ce tehnologie este folosita pentru a trimite pachetele între CE și PE. În cazul nostru Ethenert VLAN este translatat în ATM PVC și vice-versa.

Virtual Private LAN Services (VPLS)

Soluțiile L2VPN discutate anterior sunt doar punct-la-punct ceea ce înseamnă ca fiecare pseudowire reprezintă un singur domeniu de broadcast. Acest lucru simplifica tot conceptul L2VPN și-l face mai ușor de implementat. Cu VPLS tot conceptul devine mult mai complicat. Principala trăsătura a VPLS este că conexiunile între PE sunt multipunct, rezultatul fiind că ele se atașează la rețeaua providerului ca și cum ar fi în același switch. Figura 3-14 reprezintă o implementare de VPLS între 3 siteuri diferite.

Figura 3-12

Deoarece rețeaua VPLS se comporta ca un switch pentru fiecare CE în parte, tabela CAM trebuie menținută pentru fiecare nod, acest lucru nu era necesar înpunct-la-punct L2VPN. Acest lucru înseamnă ca fiecare PE trebuie să aibă propria schema de învățare a adreselor MAC și asocierea acestora cu un egress PE. Acest lucru se întâmplă inspectând adresa MAC sursa a fiecărui frame primit asociindu-l cu portul de unde a venit frameul. Cu alte cuvinte un PE se comporta ca un switch separat pentru fiecare VPLS.

Concluzii

Acest capitol a reprezentat o descrie sumara a diferitelor implementări MPLS. MLPS este leader în tehnologia de transport folosita în rețelele providerilor de servicii, acest lucru se datorează în principal arhitecturii și interconectarea cu BGP.

MPLS Traffic Engineering

Deținerea controlului asupra traficului din rețeaua MPLS este un concept ce tine de Traffic Engineering (TE) și există multe motive pentru care am dori să influențăm direcția în care circula traficul în rețeaua MPLS, dar principalul motiv este ca să folosim rețeaua într-un mod cât mai înțelept pentru a evita supraîncărcarea sau sub încărcarea rețelei.

Figura 3-14

TE nu este o necesitate pentru rețeaua MPLS, există provider de servicii care preferă să investească bani în creșterea capacității de transport, dar acest lucru merge până la un punct. TE ajuta providerii de servicii să economisească banii cheltuiți pe resurse în plus pentru a creste capacitățile de transport. Implementat TE la nivel de MPLS permite providerilor de servicii să controleze fiecare pachet în rețea.

Obiective ale TE

Obiectivele TE se pot clasifica în 3 secțiuni:

Necesitatea de a trimite un anumit trafic pe o ruta predefinita

Îmbunătățirea resurselor utilizate în rețea

Controlul resurselor din rețea în caz de necesitate

Setarea unei rute predefinite pentru TE

Procesul de setarea unei rute prestabilite este împărțit în două părți; prima parte este calculare în funcție de constrângeri și atribute RSVP-TE și a doua parte este trimitere efectiva a traficului peste ruta LSP computata.

Prioritățile LSP

Pentru a diferenția LSP cu o garantare mai stricta, a fost introdus conceptul de prioritate LSP. Fiecare LSP poate fi configurat cu o prioritate între 0 și 7, unde 0 este considerata ce mai bună prioritate iar 7 cea mai proasta. Prioritățile LSP ne permit să prioritizăm LSP în două scenarii diferite, primul când setam o cale predefinita iar al doilea când se întâmplă să avem o avarie în rețea, în ambele cazuri LSP mai important permite accesul la sericii și altor LSP mai puțin importante.

Distribuția informației TE

Distribuția informației legate de TE trebuie distribuita cumva în rețea tuturor nodurilor participante. Pentru acest motiv s-au creat extensii ale protocolului IGP pentru a cară informația despre MPLS-TE de-a lungul rețelei. Ambele protocoale IS-IS și OSPF dispun de aceste extensii.

Informația MPLS-TE:

Lățimea de banda

Atribute administrative – colorarea legăturilor

Metrica TE

Numărul maxim de hopuri

Configurarea priorităților LSP

În acest mod toată informația necesară despre MPLS-TE este ținută local în TE Database (TED).[5]

Colorarea legăturilor

Procesul de a găsi cea mai scurta cale prin CSPF poate fi constrânsă de folosirea legăturilor care aparțin unui grup sau grupuri administrative specific. Grupurile administrative sunt configurate prin RSVP și scopul lor este de a diferenția legăturile între ele. Aceeași culoare aparține aceluiași grup administrativ. Odată ce au fost create grupurile administrative ele se aplica interfețelor RSVP. Una sau mai multe culori se pot atribui interfețe RSVP. MPLS-TE permite includerea, excluderea sau ignorarea legăturilor cu o anumită culoare. Se pot folosi până la 32 de grupe de culori în topologia de rețea.

Figura 4-2 este un exemplu care arata modul în care legăturile sunt colorate, constrângerile pentru calcularea CSPF sunt după cum urmează:

Pentru legăturile primare folosim legăturile implicite (fără culoare)

Pentru protecție locală în rețea folosim legăturile implicite:

Legăturile în combinație cu ALBASTRU dacă PE este la 3 hopuri distanta

Legăturile în combinație cu ROSU dacă PE este la 4 hopuri distanta

Pentru protecție punct-la-punct folosim combinația de legături VERDE, ROSU și ALBASTRU.

Figura 4-2

CSPF

Link-state IGP folosește algoritmul Shortest Path First (SPF) pentru a determina cel mai scurt traseu în rețea. RSVP folosește un algoritm modificat care se numește Constrained SPF care permite ca determinarea să fie influențată și de alte atribute. Toate atributele sunt menținute în TED care pune la dispoziție topologia curenta MPLS-TE.

Pentru a determina ce cale să aleagă, CSPF folosește următoarele reguli:

LSP sunt calculate o singura data, începând de la prioritatea cea mai mare urmând LSP cu lățimea de banda dea mai mare

Taie toate legăturile care:

Nu au suficienta banda rezervabila

Nu partajează vreo culoare

Conține culori excluse. Legăturile fără culori sunt alocate ca fiind acceptate.

Găsește cea mai scurta cale către routerul egress LSP luând în considerare orice ERO.

Dacă mai multe cai au același cost:

Alege pe cea ultimul-hop la fel ca destinația LSP

Alege calea cu cele mai puține hopuri

Aplica regula de balansarea încărcării CSPF configurată în LSP

Reoptimizarea traseului

În momentul calculării traseului s-ar putea ca acesta să nu fie cel mai optim. Calcularea CSPF se bazează pe informația din IGP. În funcție de informația despre topologia rețelei, care poate să fie cea curenta sau nu, pot există LSP sub nivelul optim, sau un alt caz poate fi când se întâmplă o avarie iar traficul este transferat pe trasee alternative. Da avaria s-a încheiat, este necesar ca traficul să fie mutat înapoi pe legătură primara. Pentru a evita situațiile în care traficul sare între legătură primara și cea alternativa reoptimizarea traseului este efectuată într-un anumit interval de timp. Temporizatorul reoptimizării traseului este la fel pentru toate LSP de pe un echipament, deoarece ar fi ineficient să se mențină un temporizator pentru fiecare LSP.

Selectarea traseului TE

Ultima parte a implementării traseului MPLS este să facem echipamentul să selecteze aceste trasee. Din punct de vedere al LSP transmiterea se face ca și cum ar fi interfața de ieșire. Desigur metrica este asociata acestuia. Poate să fie metrica IGP sau poate să fie metrica MPLS-TE, depinde de configurație. Un mod simplu de implementare este să folosim rute statice pentru a folosi LSP ca și interfața de ieșire pentru un anumit prefix. Acesta abordare nu este foarte comod de administrat datorita faptului ca este necesară interacțiunea manuala cu traseele. O alta opțiune ar fi folosirea protocolului BGP pentru a instala în tabela de rutare prefixele care au ca next-hop adresa ruterului de egress LSR. Dacă este permis prin configurație traseele LSP pot fi folosite împreună cu rutarea IGP pentru a determina ce-a mai scurta cale către destinație.

Funcționalitatea siguranței în MPLS

Protejarea și restaurarea traseului sunt elementele cheie în rețeaua MPLS. Pentru a furniza un serviciu providerii de servicii semnează un contract cu un client în care este specificat un SLA pentru un serviciu MPLS. Iar pentru a putea susține acest SLA providerii de servicii trebuie să fie sigur ca rețeaua lor este imuna oricărei avarii sau instabilitatea. În acest capitol voi discuta despre tehnicile care furnizează acesta siguranța a rețelei MPLS. Știm ca MLPS poate să lucreze cu multe tehnologi de nivel 2 al rețelei care pot să vina cu propriul lor mod de protecție. Acest lucru ne face să ne gândim dacă putem să ne bazam în siguranța pe ce oferă aceste tehnologi. De exemplu SONET sau SDH pun la dispoziție o protecție al nivelului fizic folosind Automatic Protection Switching (APS) unde legătura secundara este pregătita să își asume rolul de principal imediat ce este detectata o problema pe linia principala, dar acest lucru are un cost ridicat datorita faptului ca trebuie să avem două linii una primara și un secundara iar lățimea de banda trebuie rezervata din timp cu costuri și echipamente adiționale.[5] În MPLS aceste tehnici similare le-au numit Fast Reroute (FRR), doar ca în loc legături fizice avem tuneluri MLPS. În spatele acestei ide se afla este decizia locală și calea precalculata care intra în acțiune imediat ce în calea primara a intervenit o avarie. În final scopul FRR este de a pune la dispoziție un LSP temporar până un alt LSP nou primar este gata să preia controlul folosind legături fizice diferite de prima. Folosind FRR nu mai este nevoie să folosim legături secundare LSP deoarece este timp pentru a calcula și crea o noua cale LSP. Un alt concept care trebuie luat în considerare este cât de rapid avem nevoie de restaurarea caii. În multe cazuri nu este nevoie să restauram conexiunea în sub 50ms. Diversitatea aplicațiilor pentru care se oferă servicii MPLS se reflecta în necesități diferite de trasee. Prin urmare traficul trebuie clasificat de exemplu dacă traficul poate tolera pierderi sau cât de multe pot fi aceste pierderi, timpul maxim de răspuns, sau dacă lățimea de banda trebuie garantata etc. De exemplu pentru traficul de voce o pierdere de 300ms va influenta calitatea serviciului semnificativ, iar pierderi de pachete de 1-2 secunde poate duce la închiderea convorbirii sau dacă avem pierderi peste 3 secunde putem aveam probleme cu convergenta IGP în rețea. Protecția și restaurarea este un proces foarte scump dar providerii de servicii vor suporta consecințele dacă nu implementează aceste tehnici.

Protecția traseului

Protecția traseului sau end-to-end protection este una din protecțiile esențiale care o pot oferi providerii de servicii. LSP primar este protejat de un alt traseu LSP care are aceeași sursa și destinație dar folosind traseu fizic diferit, aceasta este cea mai uzuală practică pentru a furniza convergenta necesară. În condiții normale doar LSP primar este folosit pentru a transmite trafic. Atât timp cât LSP primar nu are vreo avarie LSP secundar nu transmite nici un fel de trafic. În funcție de cum este configurat LSP secundar poate fi pre-semnalizat și menținut pe echipamentul local fapt care face ca timpul de restaurare să se reducă simțitor în detrimentul rezervării resurselor nefolosite. A două opțiune este ca traseul să fie semnalizat în timp real odată ce head end este informat că există o avarie pe legătura principală LSP. În Figura 5-1 avem o avarie pe legătura primară între P3 și D. Notificarea este efectuată de către PLR, routerul P3, prin simpla propagare a RSVP PathErr înapoi spre sursă.

Figura 5-1

Pentru a pune la dispoziție protecția end-to-end providerii de servicii trebuie să ia în considerare diferite aspecte și necesități:

Utilizarea resurselor – Dacă traseul este pre-semnalizat, același număr de resurse pentru LSP primar sunt prealocate și pentru LSP secundar. Când resursele încep să devina limitate se poate face ca semnalizarea să efectueze în momentul avariei, dar aceasta soluție are dezavantajele ei, timpul total de restaurare poate creste de câteva ori. Un alt lucru care trebuie luat în calcul atunci când se face semnalizarea în momentul avariei este ca există posibilitatea ca resursele disponibile să nu fie suficiente din pricina faptului ca alte resurse trebuie alocate pentru LSP secundar. Pentru a rezolva aceasta problema s-a introdus prioritatea, pur și simplu se aloca o prioritate pentru fiecare LSP în caz de necesitate, LSP cu prioritate mai mica este obligat să renunțe la resurse pentru un LSP mai prioritar.

Controlul fluxului de date – având calea presemnalizata oferă un avantaj foarte mare atunci când stil exact ce flux de date avem. Cu aceste date putem garanta ca există destula capacitate și legătura principala poate să întrunească toate necesitățile legăturii principale. Acest lucru se poate realiza cu trasee prestabilite pentru legătura secundara.

Diversitatea legăturilor disponibile – este esențial ca traseul primar și cel secundar să nu partajeze aceeași legătura fizica sau echipamente de-a lungul traseului. Dacă acest lucru nu se poate obține providerul de servicii risca să nu poată oferi o soluție redundanta.

Timp de întârziere nedeterminat – eroarea RSVP trebuie propagata de la PLR spre head end al traseului, fiecare echipament înapoi pe traseu este implicat în aceasta propagare. Acest lucru tine de control plane nu este garantat în nici un fel ca fiecare echipament poate servi aceasta cerere imediat.

Protecție inutila – toată calea de la sursa până la destinație este protejata, dacă undeva pe traseu există alte mecanisme de recuperare, aplicarea protecție de la cap la cap este imposibila de aplicat.

Când vrem să protejam o anumită cale, nu revine în totalitate treaba rețelei, vom observa ca există și alți factori care pot influenta acest lucru. Această protecție o putem compara cu situația în care vrem să ajungem la o destinație dar ne dam seama ca traseul principal este blocat undeva la mijloc, dar încă nu am intrat pe drumul principal așa ca o luat pe drumul secundar pentru a evita o întârziere. Următorul subcapitol descrie cazul celor care folosesc calea blocată deja. [5]

Protecția locală

Există multe aplicații sensibile care nu se pot baza doar pe protecția traseului. Timpul de schimbare este inacceptabil chiar dacă am face pre-semnalizare și am păstra informația în hardware. În acest scop a fost introdusa protecția locală și se bazează pe o idee simpla; pune la dispozitie un traseu de ocolire cât mai aproape de punctul de avarie. Cum am menționat în exemplul real dat mai sus, ce se întâmplă cu cei care nu au fost anunțați și se afla pe traseu ? Soluția este evidenta, vor folosi cel mai scurt traseu din jurul punctului unde traseul este blocat, locul unde traseul principal este părăsit se numește Point of Local Repair (PLR) iar locul unde se reintră pe traseul principal se numește Merge Point (MP). Cu alte cuvinte PLR reprezintă echipamentul din care traficul este rutata local către echipamentul MP unde totul se continua pe traseul principal. (Figura 5-2). De aici tragem concluzia ca aceasta este doar o soluție de moment pentru traficul care deja care încă se afla pe legătura principală LSP și nu va fi afectat de pierderea de pachete sau blocarea pentru o anumită perioadă de timp. FRR a fost conceput să furnizeze restaurarea traseului temporar dar foarte rapid. Temporar până când head endul traseului primește informația despre avaria traseului LSP principal și va schimba pe traseul secundar LSP.

Următoarele avantaje caracterizează protecția FRR:

Este legata de resurse. Protejează o singură resursă în rețea fie ca este o legătură sau un echipament. Acest lucru îl face să fie ușor de înțeles și implementat

Poate furniza cel mai scurt traseu pentru a evita punctul de avarie. Acest lucru face ca restaurarea traseului să fie foarte rapid cu un minim de echipamente implicate.

Traseul de evitarea este precalculata și ținut în hardwareul echipamentului, gata să fie folosit în caz ca este detectata o avarie

Când FRR este prezent nu este necesară să menținem un LSP secundar. Există suficient timp pentru semnalizarea și crearea unul LSP secundar.

Figura 5-2

Protecția FRR poate lucra în două moduri diferite. Poate proteja cate un singur LSP separat sau poate proteja un grup LSP. Protecția unui singur LSP se numește protecție 1:1 și un grup de LSP se numește protecție N:1. Procesul de implementare a protecție locale este format din 4 secțiuni Figura 5-3.

Figura 5-3

Configurația pre-avarie

Avantajul protecție locale este libertatea de a alege pentru ce LSP se va furniza protecție împotriva anumitor resurse care nu vor fi disponibile. Providerii de servicii vor putea alege care din servicii va primi aceasta protecție și care nu. Cu aceasta abordare traficul care este mai vulnerabil, cum este cel de voce, poate primi o prioritate mai are când se întâmplă avaria fata de un trafic mai puțin important, care poate fi cel de web. Un alt beneficiu poate fi capătul ca resursele deja protejate pot fi excluse din aceasta protecție. Pentru a furniza FRR, head endul LSP protejat trebuie mai întâi să ceară o protecție locală, aceasta informație se va propaga de-a lungul LSP folosind mesajul RSVP Path cu eșantionul local protection desired configurat în Session Attribute Object (SAO). În acest mod PLR ii se comunica ce LSP trebuie protejat, mai mult decât atât PLR este configurat pentru ce resurse va furniza FRR.

Calcularea rutei de rezerva

Odată ce totul este configurat PLR va calcula tunelul de rezerva rulând calcularea CSPF cu hopul următor, al resursei protejate, ca destinație. Head endul poate limita calea de rezerva cu anumite criterii folosint FRR Object (FRO) în mesajul RSVP, anumite limitări se pot aplica cum ar fi numărul maxim de hopuri, lățimile de banda necesară, priorități, etc. Aceste limitări asigura ca tunelul de rezerva are suficiente resurse pentru a putea înlocui tunelul principal, și oricum este necesar ca anumite necesități să fie garantate pentru tunelul de protecție. În cazul protecției 1:1 nu este necesar să se specifice ce legături colorate sau lățime de banda să se folosească. Aceste atribute sunt moștenite de la LSP care este protejat.

Instalarea stării de transmitere

Instalarea stării de transmitere pentru tunelele de protejare se face la fel ca LSP principal. MP este informat că este end pointul tunelului și la rândul lui va înștiința echipamentele de upstream ce eticheta va avea acesta cale a tunelului. Există două tehnici diferite pentru acest lucru. MP va primi un pachet MPLS cu aceeași eticheta primita de la PLR unde echipamentul precedent va face pop sau swap etichetei.

Detecția avariei

Primii pași în furnizarea recuperării este detecția avariei. Timpul în care putem să detectam o avarie este esențial și este dat de doi factori. Unul din ei este distanta între punctul unde a avut loc avaria și cui trebuie să raportam acest lucru. În cazul protecție locale avaria are loc la cel mai apropiat echipament și este vorba doar de milisecunde pentru a fi detectată. Dacă avarie necesita a fi raportata undeva mai departe în rețea, detecția avariei poate dura foarte mult, de ordinul sutelor de milisecunde. Al doilea factor dacă detectarea avariei se face în hardware sau în software. În mule din scenariile de azi detecția este implementata la nivel hardware unde transmisia la nivelul fizic se face în câteva milisecunde, detecția în hardware oferă multe avantaje dar totul vine cu un preț care nu este mic. Când hardwareul nu vine cu detecția avariei, procesul ar trebui să aibă loc în software. Sunt șanse să apară obstacole în prelucrarea informației cum ar fi procesorul care ar putea să nu fie pregătit să servească cererile fiind ocupat cu prelucrarea altor informații. Când hardwareul nu vine cu detecția avariei există posibilitatea ca acest lucru să fie preluat de nivelele superioare. Un exemplu clasic este convergenta protocoalelor IGP.

Protocolul BFD

Bidirectional Forwarding Protocol (BFD) este un protocol de rețea folosit în detecția avariilor între două motoare de transmitere conectate între ele. Acest protocol pune la dispoziție detecția avariei chiar și la nivelul fizic de rețea, cum ar fi Ethernet, VC, tuneluri și MPLS LSP[9]. Este un proces simplu care rulează pe echipament, singurul lui rol fiind de a controla pachetele hello de la baza protocoalelor. BFD nu vine cu nici un mecanism de descoperire, este făcut în așa fel încât să fie simplu și ușor de implementat, din acest motiv este necesar ca el să fie configurat în ambele direcții ale legăturii. Una din cele mai simple soluții pentru a furniza recuperarea rapida este să rulam protocolul LDP la baza rețelei de MPLS, și din moment ce LDP urmează protocolul IGP asigura restaurarea nivelului. Atât timp BFD administrează mesajele hello putem regla timpii de detecția a avariei să fie reduși considerabili, dar totuși mai mari decât timpii de detecție ai rețelelor SONET/SDH.

Restaurarea conectivității

Odată ce PLR afla de avarie unui circuit protejat LSP poate începe imediat trimiterea traficului peste tunelul de rezerva. Acest lucru se întâmplă foarte repede deoarece tunelul de rezerva este ținut în hardware și pregătit să servească trafic. Există 4 moduri diferite cum un tunel de rezervă poate fi conceput pentru a proteja resursele.

Semnalizarea post-avarie

Suprimare și notificare head endului LSP

O sarcina foarte importantă este suprimarea LSP care se întâmplă atunci când avaria este detectată prin avertismentele IGP. Acest lucru se întâmplă prin suprimarea mesajelor de eroare generate le ambele capete ale tunelului LSP. Altfel mesajele de eroare generate ar face ca traseul LSP să fie distrus iar protecția locală fără sens. Head endul LSP trebuie să fi notificat despre avarie prin RSVP chiar dacă ar afla și din IGP, de exemplu. Nucleul rețelei la nivel de IGP poate fi structurata în multe arii diferite sau sisteme autonome care ar face ca head endul să nu afle despre avarie produsa pe traseul LSP. Comportamentul implicit al RSVP-TE când apare o eroare este să anunțe head endul fiecărui LSP protejat prin propagarea mesajului PathErr folosind codul „routing problem” (24) wi eticheta „no route available” (5) în jos spre destinație. Având în vedere acest lucru tot conceptul de protectie locală nu mai are nici un sens. Desigur trebuie să folosim alte tehnici de notificare al head end LSP. Suprimarea LSP este o abordare în care PLR notifica head endul LSP pentru fiecare LSP protejat folosind codurile de eroare „notify error” (25) în mesajul RSVP-TE ParhErr și etichetând „path locally repaired” (3) setat pe PRO. Acesta are ca rezultat de a nu bloca traficul perioada de timp în care noul traseu este calculat. În cazul în care cel puțin un head end nu a putut forma o cale noua, protecția locală rămâne prezenta evitând terminarea unei traseu LSP. Oricum LSP poate fi terminat de tail endul LSP în cazul în care LSP a fost compromis. Acest lucru se poate întâmplă în 3 moduri diferite. Ar fi putut primi o actualizare IGP, nu ar primi un mesaj PathTear sau RSVP Path refresh pentru o anumită perioada de timp. Este clar ca și PathTear trebuie să fie suprimat. Acest lucru se poate face prin trimiterea de mesaje path refresh care aparțin sesiunii RSVP cu avari prin legătura de rezervă către device care va crede ca va deveni MP. Echipamentul nu va verifica pe care interfața va primi path refresh pentru un anumită sesiune RSVP în acest fel nu va fi necesar să genereze un mesaj PathTear[5]. Unde se afla procesul pentru notificarea avariei ? Depinde dacă FRR a fost configurat pentru anume LSP sau nu. Dacă este știm deja ca RSVP-TE ignoră notificările IGP iar LSP protejate pot fi oprite dor folosind mesaje RSVP-TE PathErr. Când FRR nu este implementat și head endul primește notificări IGP despre o eroare în rețea despre unu anumit LSP acesta va șterge LSP pentru care a primit mesajul și va forma un nou traseu.

Stabilirea unui nou traseu

Stabilirea traseului LSP de rezerva se poate face și offline, înainte de avaria traseului sau imediat ce head end LSP este informat despre avarie. În oricare din situații traseul este calculat în aceeasi maniera folosind abordarea make-before-break. În funcție de restricțiile TE aflate în rețea traseul de rezerva este calculat. Dacă nu există restricții și traseul LSP primar este protejat local, LSP de rezerva poate partaja resurse cu LSP primar. Aceasta tehnica se mai numește și shared explicit descriptor în mesajul RSVP. Dacă topologia rețelei arată ca în Figura 5-4 atunci este posibil ca LSP de rezerva să partajeze resursele de calculare cu LSP primar. Pentru o perioada scurtă de timp traficul se va dubla. După ce toate LSP sunt configurate cu protecție locală si au fost mutate pe legătura de rezervă, legătura LSP principală poate fi ștearsă și eliberate resursele.

Data plane

Echipamentul sursă primește un pachet care trebuie trimis mai departe, se va uita în tabela de rutare și va verifica dacă există o etichetă asociată cu un FEC, și în caz ca există pachetului îi este alocat un header MPLS înglobând eticheta și este procesat de către LFIB ca pachet etichetat. Figura 5-4 descrie o topologie de rețea cu 3 conexiuni LSP între o sursă și 3 destinații. Pentru o înțelegere mai ușoară să ne gândim că metrica este numărul de hopuri. În condiții normale toate LSP urmăresc cea mai scurtă cale spre destinația lor iar traseul S-P3-P4 este partajat de toate LSP

Figura 5-4

Control plane

Control plane este mult mai complicat ca data plane, sunt mult mai multe lucruri care trebuie să se întâmple pentru a crea o cale stabilă de a trimite pachetele. Traseul de rezerva trebuie calculat și pre-semnalizat înainte ca avarie să se întâmple ceea ce înseamnă ca starea de transmitere a pachetelor trebuie să fie instalată în toate nodurile inclusiv în MP și PLR. Figura 5-5 arată un proces de stabilire LSP între sursă și destinație cu protecție FRR. Echipamentul P4 este PLR deoarece el schimbă traseul tunelului protejat, iar P5 este MP pentru că aici traficul intră în traseul LSP protejat.

Figura 5-5

Protecția legăturii

Avariile legăturilor într-o rețea sunt lucruri foarte comune și tind să se întâmple mult mai des ca avaria nodurilor lucru care face ca protecția legăturilor să fie cea mai favorizată soluție pentru recuperarea rapidă. Oricum există o soluție să conturăm conexiunile între noduri prin legături multiple care sunt agregate într-o singura legătură logică numită port-channel. Acest lucru este de obicei practicat între nodurile care au trafic foarte mare. Având port-channel între noduri putem mitiga impactul avariei unei singure legături între două noduri. Protecția legăturilor se bazează pe echipamentul next hop și va încerca să stabilească tunelurile de rezervă folosind calculul CSFP. Dacă în cazul legăturilor protejate tot nodul devine indisponibil atunci ambele trasee LSP primar și secundar se vor opri din trimis trafic.

Protecția legăturii folosind modelul N:1

Facilitatea protecției este de a pune la dispoziție un tunel de deviere al traficului pentru toate tunelele LSP care trec prin PLR și partajează același hop. Acest tunel este creat de PLR și variază în funcție de avarie și capătul echipamentului MP car are next hop. Presupunând că avem o avarie de legătură între P3 și P4, P3 primește rolul de PLR creând un tunel de ocolire a avariei. Ca urmare un singur tunel de ocolire va fi creat care va avea metrica cea mai mica de 2 hopuri până la echipamentul MP. Observăm faptul că tunelul de ocolire pentru LSP1 nu este optimal folosind un total de 5 hopuri către destinație în loc de 4, prin P1 – P2. Nodul PLR are un tunelul deja construit deasupra tuturor LSP. Acest tunel este folosit peste LSP care sunt configurate pentru protecție, adăugând încă o etichetă. Tunelul este semnalizat ca oricare LSP. Specific în exemplul nostru din Figura 5-7, pentru traseul tunelului, MP anunță către upstream eticheta 3, sau implicit null label. Tunelul este terminat în PLR unde primul nod downstream semnalizează PLR cu eticheta 101 pentru protecția tunelului. Din punct de vedere al scalabilității PLR păstrează doar o instanță de trimitere pentru a fi folosită în protecția tunelului, indiferent câte LSP avem, N:1 protecții locale vor fi puse la dispoziție. Nodul MP nu are nevoie de o alte stări de trimitere procesate în LFIB. Când pachetul MLPS ajunge pe PLR, este necesar ca pachetul MLPS să facă un push și un swap al etichetelor cu cele care sunt prevăzute pentru tunelul LSR de ocolire. Nodul din fata MP face penultimate hop pop ceea ce face ca MP să primească același pachet ca și cum ar fi de la direct de la un PLR, diferind doar portul (Figura 5-7).

Protecția legăturii folosind modelul 1:1

Pentru protecția 1:1 PLR pune la dispoziție pentru fiecare tunel LSP un alt tunel individual. Este evident că folosind acest model vom avea mai multe MP pentru un singur PLR. Fiecare tunel individual se referă la un tunel de ocolire.

Figura 5-7

În Figura 5-8 se observă o avarie a unei legături între P3 și P4. În acest model LSP1 poate folosi traseul cel mai scurt spre destinație calculat din perspectiva PLR. Acest îmbunătățire vine cu costul semnalizării separate a traseului de ocolire pentru fiecare LSP și menținând mai multe stări de trimitere, comparativ cu modelul N:1.

Protecția nodului

Câteodată este vital să protejam nodul, decât doar legăturile. Topologia providerilor de servicii au nevoie și de protecția nodului mai ales în rețele unde redundanța este crucială. De asemenea și protecția nodului vine în două variante folosind modelul 1:1 sau N:1 la fel ca protecția legăturilor.

Protecția nodului folosind modelul N:1

Focalizarea protecției împotriva avariei unui nod se face punând la dispoziție cate un tunel creat de PLR pentru fiecare grup LSP protejat care au același downstream next hop imediat după nodul care-l protejează. Având în vedere faptul ca nu este vorba doar de o legătură locală care are același capăt pentru toate LSP protejate, next hop poate varia în funcție de traseul care-l urmează LSP.

Figura 5-8

În Figura 5-10 avem un exemplu de topologie unde next hop este diferit pentru fiecare LSP în cazul unei avarii la nodul P4. Nodul P3 are rol de PLR și traficul este împărțit între două MP diferite. Pentru LSP1 este P2, pentru LSP2 și LSP3 este P5. După ce traficul a fost împărțit el va traversa ca și înainte spre destinații. După cum se știe noile trasee nu garantează ca LSP va urma cea mai scurta cale spre destinație. LSP3 ajunge la P5 pentru ca tunelul se termina acolo și trebuie să se întoarcă la P8 ca să ajungă la D3. Similar cu control plane al protecției legăturii PLR construiește un tunel de rezerva pentru fiecare grup LSP protejat care are același MP cu alte LSP din rețea. Acelor tunele li se dă un nivel în plus de etichete pentru evitarea segmentului afectat. În exemplu din Figura 5-10 este necesar ca PLR să știe despre tabela de etichete folosita de P4 pentru fiecare LSP protejat. După ce PLR știe aceste date poate să folosească operațiunea swap folosind acele etichete obținute de la P4 și pe urma făcând push pentru eticheta unui tunel.

Figura 5-10

Protecția nodeului folosind modelul 1:1

S-a menționat deja faptul că pentru modelul 1:1 a fost creat un traseu separat pentru fiecare LSP protejat. Ocolirile create de PLR diferite se pot uni în același LSP. Acesta aspect face ca numărul total de ocoliri per LSP să nu fie așa de mare precum credeam. Figura 5-12 arata un exemplu de topologie de rețea unde PLR furnizează protecție 1:1 pentru fiecare LSP. În cazul în care nodul P4 suferă o avarie, sunt puse la dispoziție 3 trasee către 3 MP diferite, unul pentru fiecare traseu. Nu este necesar ca ocolirile să se întâlnească cu LSP principal. Presupunând ca LSP2 ii protejat împotriva unei avarii a legături între nodurile P3-P4 și P4-P5, în loc să avem două ocoliri separate P3-P1-P4 și P3-P6-P7-P8-P5 putem păstra doar pe a doua pentru a proteja ambele legături. Pentru protejarea nodului 1:1 logica control plane rămâne la fel ca protecția legăturii. PLR pune la dispoziție tunele de ocolire prin distrugerea LSP existent și conectându-l la o ocolire care nu este necesar să se întâlnească cu LSP principal.

Configurarea unei rețele MPLS bazata pe echipamente CISCO

Mediul de testare a fost implementat cu ajutorul aplicatie GNS3. Este o aplicatie cunoscuta pentru acest tip de scenarii fara echipamentie fizice disponibile. Partea pactica a acestei lucrari consta în implementarea serviciilor L3VPN și L2VPN într-o rețea MPLS.

Figura 5-12

Din pacate apliactia GNS3 nu suporta VPLS și prin urmare nu am putut implementa aceata topologie. Configuratia echipamentelor virtuale de rețea se va rezuma stric la ce și-a propus să demonstreze aceast proiect să evidentieze deoarece orice alta configuratie nu face subiectul acestei lucrari.

Lista protocoalelor folosite în rețea:

OSPF – pentru accesibilitate MPLS

LDP – pentru interconectare full-mesh în toată rețeaua MPLS

MLPS-TE – tunele TE pentru a pune la dispozitie functionalitatea TE în rețea

RSVP – pentru a semnaliza LSP care au nevoie de protectie

VRF – pentru a izola diferiti clienti în și implemnta serviciul L3VPN

MP-BGP – pentru a rula intreg conceptul de L3VPN

iBGP – pentru seiunile PE-PE

eBGP – pentru sesiunile CE-PE (Client2)

EIGRP – protocol folosit pentru comunicare cu CE (Client1)

LDP L2VPN – pentru a pune la dispozitie comunicatia punct la punct între două locatii.

Figura 6-1

Configurație PE1

!

! configurăm hostname

!

hostname PE1

service timestamps debug datetime localtime

service timestamps log datetime localtime

service password-encryption

!

! Loopback0 este interfața folosită pentru identificarea locală a routerului în topologia de rețea.

!

! Este folosită pentru OSPF, BGP, LDP. LSP sunt configurate este configurat cu Loopback1.

! Loopback1 va simula o rețea care o anunțăm în BGP.

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

ip ospf network point-to-point

ip ospf 1 area 0

!

interface Loopback1

ip address 50.0.0.1 255.0.0.0

!

! Interfețele fizice care sunt spre rețeaua MPLS

!

! Configurația este aproape la fel pentru fiecare interfață, dar poate varia

! în funcție de necesități

!

interface GigabitEthernet1/0

ip address 10.0.7.1 255.255.255.0

!

interface GigabitEthernet2/0

ip address 10.0.1.1 255.255.255.0

!

interface GigabitEthernet3/0

ip address 10.0.10.1 255.255.255.0

!

! Interfața fizică spre clientul cu L3VPN

! În configurație trebuie să alocam și să

! specificăm un VRF pentru client

!

interface GigabitEthernet5/0

vrf forwarding CUSTOMER2

ip address 20.0.3.1 255.255.255.0

!

interface GigabitEthernet6/0

vrf forwarding CUSTOMER1

ip address 20.0.1.1 255.255.255.0

!

! Configurația IGP pentru accesibilitatea rețelei

!

! OSPF este folosit pentru accesibilitatea rețelei și pentru a suporta extensiile MPLS-TE

!

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

router-id 1.1.1.1

log-adjacency-changes

auto-cost reference-bandwidth 100000

network 10.0.0.0 0.255.255.255 area 0

!

! Configurația VRF

!

! Configurația VRF pentru fiecare client, se specifică RD și RT pentru export și import

!

vrf definition CUSTOMER1

rd 1.1.1.1:100

route-target export 36500:100

route-target import 36500:100

!

address-family ipv4

exit-address-family

!

vrf definition CUSTOMER2

rd 1.1.1.1:200

route-target export 36500:200

route-target import 36500:200

!

address-family ipv4

exit-address-family

!

! Activarea și configurarea globala a protocolului MPLS

!

! Conține configurația globală pentru MPLS și configurația pentru

! ce interfețe să activeze MPLS, mai este activa și protocolul RSVP hello pentru

! interfețe cu detecția rapidă a avariei

!

ip cef

mpls traffic-eng tunnels

mpls traffic-eng reoptimize timers frequency 30

mpls label protocol ldp

mpls ldp router-id Loopback0

ip rsvp signalling hello

!

interface GigabitEthernet1/0

mpls traffic-eng tunnels

mpls ip

ip rsvp signalling hello

!

interface GigabitEthernet2/0

mpls traffic-eng tunnels

mpls ip

ip rsvp signalling hello

!

interface GigabitEthernet3/0

mpls traffic-eng tunnels

mpls ip

ip rsvp signalling hello

!

! Configurația BGP

!

! Configurația MP-BGP pentru împerecherea între PE. Având în vedere ca rețeaua este una

! mica, nu vom folosi RR. Împerecherea vecinilor BGP se va face direct unul cu celălalt.

! Configurație MP-BGP logic este împărțită în 3 sectiuni. Prima este pentru conectivitatea

! IPv4 între PE și backbone. A două este pentru suportul de VPN. Face posibila conectivitatea

! între PE prin punerea la dispoziție unui VPN configurat să trimită comunitățile extinse

! unui anume vecin. Ultima secțiune este folosita pentru distribuirea rutelor de la clienti

! în BGP pentru a ajunge la egress PE care le va redistribui în instanța de VPN care rulează

! pentru un client.

!

router bgp 36500

no synchronization

bgp log-neighbor-changes

network 50.0.0.0

neighbor 2.2.2.2 remote-as 36500

neighbor 2.2.2.2 update-source Loopback0

no auto-summary

!

address-family vpnv4

neighbor 2.2.2.2 activate

neighbor 2.2.2.2 send-community both

exit-address-family

!

address-family ipv4 vrf CUSTOMER1

redistribute eigrp 100

no synchronization

exit-address-family

!

address-family ipv4 vrf CUSTOMER2

neighbor 20.0.3.103 remote-as 65100

neighbor 20.0.3.103 activate

no synchronization

exit-address-family

!

! Configurația protocolului IGP

! între PE și client

!

! Acest protocol este folosit pentru a vorbi cu CE din partea

! clientului facând accesibile prefixele

!

router eigrp 1

auto-summary

!

address-family ipv4 vrf CUSTOMER1

redistribute bgp 36500 metric 1500 4000 200 10 1500

network 20.0.0.0

no auto-summary

autonomous-system 100

exit-address-family

!

! Configurația LSP

!

! Aceasta este configurația pentru tuneleul LSP, pe Cisco LSP se creează

! prin interfața de tip tunel

!

interface Tunnel1

ip unnumbered Loopback0

ip ospf interface-retry 0

tunnel destination 2.2.2.2

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng path-option 10 explicit name TUNNEL1_PRI

tunnel mpls traffic-eng path-option 15 explicit name TUNNEL1_BCK

tunnel mpls traffic-eng path-option 20 dynamic

tunnel mpls traffic-eng record-route

tunnel mpls traffic-eng path-selection metric igp

tunnel mpls traffic-eng fast-reroute

no routing dynamic

!

! Configurația explicită a traseului

!

! Configurația explicita a traseului primar și de rezerva

!

ip explicit-path name TUNNEL1_PRI enable

next-address 3.3.3.3

next-address 5.5.5.5

next-address 6.6.6.6

next-address 2.2.2.2

!

ip explicit-path name TUNNEL1_BCK enable

next-address 7.7.7.7

next-address 2.2.2.2

!

! Configurația L2VPN

!

! Conține configurația individuală a pseudowires și interfețele logice unde este

! configurată maparea bidirecțională pentru clienții dintre cele două PE

!

pseudowire-class SITE1-TO-SITE2

encapsulation mpls

!

pseudowire-class SITE1-TO-SITE3

encapsulation mpls

interworking ethernet

!

interface GigabitEthernet5/0.12

encapsulation dot1Q 12

xconnect 2.2.2.2 12 pw-class SITE1-TO-SITE2

!

interface GigabitEthernet5/0.13

encapsulation dot1Q 13

xconnect 2.2.2.2 13 pw-class SITE1-TO-SITE3

Configurația PE2 este aproape la fel din acest motiv voi trece in lucrare doar configurația care diferă intre PE1 si PE2

PE2

interface Tunnel0

ip unnumbered Loopback0

ip ospf interface-retry 0

tunnel destination 1.1.1.1

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng path-option 3 explicit name EXCEPT-P4-P5

tunnel mpls traffic-eng path-option 5 dynamic

no routing dynamic

!

ip explicit-path name EXCEPT-P4-P6 enable

exclude-address 4.4.4.4

exclude-address 6.6.6.6

!

Configurația Peurilor este aproape la fel pentru toate, din acest motiv voi trece in lucrare doar configurația completa a lui P4 iar pentru restul doar părțile esențiale care diferă.

P4

hostname P4

!

ip cef

mpls traffic-eng tunnels

mpls traffic-eng reoptimize timers frequency 30

mpls label protocol ldp

mpls ldp router-id Loopback0

ip rsvp signalling hello

!

interface Loopback0

ip address 4.4.4.4 255.255.255.255

ip ospf network point-to-point

ip ospf 1 area 0

!

interface GigabitEthernet1/0

ip address 10.0.2.4 255.255.255.0

mpls traffic-eng tunnels

mpls ip

ip rsvp signalling hello

!

interface GigabitEthernet2/0

ip address 10.0.3.4 255.255.255.0

mpls traffic-eng tunnels

mpls ip

ip rsvp signalling hello

!

interface GigabitEthernet3/0

ip address 10.0.6.4 255.255.255.0

mpls traffic-eng tunnels

mpls ip

ip rsvp signalling hello

!

router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0

router-id 4.4.4.4

log-adjacency-changes

auto-cost reference-bandwidth 100000

network 10.0.0.0 0.255.255.255 area 0

!

P3(PLR)

interface Tunnel52

ip unnumbered Loopback0

tunnel destination 6.6.6.6

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng path-option 10 explicit name TUNNEL1_BCK(Node5)

tunnel mpls traffic-eng path-selection metric igp

no routing dynamic

!

ip explicit-path name TUNNEL1_BCK(Node5) enable

next-address 4.4.4.4

next-address 6.6.6.6

!

interface GigabitEthernet3/0

ip address 10.0.4.3 255.255.255.0

mpls traffic-eng tunnels

mpls traffic-eng backup-path Tunnel52

mpls ip

ip rsvp signalling hello

!

P5(PLR)

interface Tunnel51

ip unnumbered Loopback0

tunnel destination 6.6.6.6

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng path-option 10 explicit name TUNNEL1_BCK(Link5)

tunnel mpls traffic-eng path-selection metric igp

no routing dynamic

!

ip explicit-path name TUNNEL1_BCK(Link5) enable

next-address 3.3.3.3

next-address 4.4.4.4

next-address 6.6.6.6

!

interface GigabitEthernet1/0

ip address 10.0.5.5 255.255.255.0 l

negotiation auto

mpls traffic-eng tunnels

mpls traffic-eng backup-path Tunnel51

mpls ip

ip rsvp signalling hello

!

Configurația HQ care este foarte simplă. Este configurata o sesiune de EIGRP intre fiecare router și PE pentru anunțarea și învățarea prefixelor prin ea. Este de datoria providerului de servicii să se ocupe de rutarea pachetelor in L3VPN. Configurația Office este asemănătoare cu cea a HQ din acest motiv nu o voi trece.

HQ

hostname HQ

!

interface Loopback0

ip address 101.101.101.101 255.255.255.255

ip ospf network point-to-point

!

interface Loopback1

ip address 151.0.0.1 255.0.0.0

!

interface FastEthernet0/0

ip address 172.21.0.1 255.255.255.0

duplex auto

speed auto

!

interface GigabitEthernet1/0

ip address 20.0.1.101 255.255.255.0

negotiation auto

!

router eigrp 100

network 20.0.0.0

network 101.0.0.0

network 151.0.0.0 0.255.255.255

network 172.21.0.0

no auto-summary

!

Pentru a anunța si învăța prefixe, pe CE1 s-a folosit protocolul BGP, de asemeni este trecută doar configurația CE1, CE2 fiind identică.

CE1

hostname CE1

!

interface Loopback0

ip address 103.103.103.103 255.255.255.255

!

interface Loopback1

ip address 153.0.0.1 255.0.0.0

!

interface GigabitEthernet1/0

ip address 20.0.3.103 255.255.255.0

negotiation auto

!

router bgp 65100

no synchronization

bgp log-neighbor-changes

network 20.0.3.0 mask 255.255.255.0

network 103.103.103.103 mask 255.255.255.255

network 153.0.0.0 mask 255.0.0.0

neighbor 20.0.3.1 remote-as 36500

neighbor 20.0.3.1 allowas-in

no auto-summary

!

LAN1, LAN2 și LAN3 folosesc o configurație foarte asemănătoare si foarte scurtă, in scopul testării configurația lor este foarte simplă

LAN1

hostname LAN1

!

interface GigabitEthernet1/0.12

encapsulation dot1Q 12

ip address 3.0.0.1 255.255.255.0

!

interface GigabitEthernet1/0.13

encapsulation dot1Q 13

ip address 4.0.0.1 255.255.255.0

!

LAN2

hostname LAN2

interface FastEthernet0/0.12

encapsulation dot1Q 12

ip address 3.0.0.2 255.255.255.0

!

LAN3

hostname LAN3

interface FastEthernet0/0

ip address 4.0.0.2 255.255.255.0

!

Bibliografie:

Continut DVD

Directorul LUCRARE – conține lucrarea efectiv redactată in Microsoft Word 2013

Directorul ROUTERS CONFIG – conține configurația routerelor așa cum este ea disponibila pe echipamente

Directorul GNS3 PRACTIC – conține configurația aplicației GNS3 pentru a putea rula proiectul în simulator

Directorul FIGURI – conține figurile in Microsoft Visio 2013 folosite in aceata lucrare