Cursul MPLS 3.0 este un curs de 5 zile condus de un instructor special conceput pentru a oferi studenților cunoștințe aprofundate despre tehnologia MPLS, care este utilizată în rețelele ISP pentru a oferi rutarea traficului foarte eficientă, precum și Crearea VPN-rețele de nouă generație.

Cursul examinează problemele teoretice ale structurii și funcționării tehnologiei MPLS pe ​​routerele CISCO și, de asemenea, acoperă în detaliu problemele de depanare și depanare la configurarea și lucrul cu tehnologia MPLS. Cursul discută, de asemenea, în detaliu utilizarea MPLS pentru a crea VPN-uri MPLS și participarea protocolului MP-BGP la acestea. ÎN versiune actualizata Cursul a adăugat o secțiune care descrie capacitatea de a gestiona traficul în MPLS (tehnologia MPLS-TE).

Cea mai mare parte a cursului constă în sarcini practice care vă permit să aplicați cunoștințele și abilitățile dobândite într-o rețea de laboratoare de testare. Conținutul tehnic al cursului a fost actualizat și adaptat pentru Cisco IOS Software Release 15. Toate lucrări de laborator sunt produse la un stand virtual.

Cursul este destinat inginerilor de rețea, angajaților serviciului tehnic, precum și specialiștilor care sprijină și implementează tehnologia MPLS, profesioniștilor care doresc să-și îmbunătățească nivelul în domeniul tehnologiilor furnizorilor, exploatarea tehnologiei MPLS și utilizarea acesteia, arhitecții rețelelor de întreprindere. și rețelele furnizorilor de servicii.

• Profesioniști în rețea care trebuie să implementeze corect soluții bazate pe rutare în conformitate cu designul rețelei Cisco. Implementarea include planificarea, configurarea și testarea;
• Ingineri de rețea și personal de suport tehnic;
• Administratori care configurează și testează funcționarea protocoalelor de rutare în rețelele întreprinderii.

La finalizarea cursului vei putea

• Înțelegeți principiile de bază ale tehnologiei MPLS
• Înțelegeți cum sunt atribuite și distribuite etichetele
• Configurați și depanați MPLS în modul cadru pe echipamentele CISCO
• Înțelegeți principiile construirii unei arhitecturi distribuite a rețelelor MPLS și regulile de rutare și distribuire a pachetelor în astfel de rețele
• Configurați, depanați și monitorizați rețelele MPLS VPN
• Înțelegeți principiile utilizării MPLS pentru a crea sisteme de servicii gestionate
• Înțelegeți cum funcționează diferitele modele de acces la Internet, precum și avantajele și dezavantajele fiecărui model
• Implementați tehnologia MPLS TE

Pregătirea necesară

• Cisco Certified Network Associate (CCNA) sau un nivel echivalent de cunoștințe și experiență
• Se recomandă materiale de curs CCNA Basics și ICND sau un nivel echivalent de cunoștințe și experiență care poate fi dobândită din cursurile Cisco.
• Curs de Construire Scalabilă Rețele Cisco(BSCI) și Configurarea BGP pe routerele Cisco (BGP)
• Experiența practică în construirea și operarea rețelelor pe echipamente Cisco este foarte recomandată
• Cursul QoS este recomandat deoarece cunoașterea QoS este implicită în unele părți ale cursului

Programul cursului

Modulul 1: Caracteristici MPLS

• Tehnologia MPL
• Descrierea etichetelor MPLS și a stivelor de etichete
• Servicii MPLS

Modulul 2. Scopul și distribuția etichetelor

• Protocolul LDP
• Distribuție de etichete MPLS în mod cadru
• Descrierea convergenței în MPLS Frame-Mode

Modulul 3: Implementarea MPLS în mod cadru pe platforma Cisco IOS

• Utilizarea Cisco Express Forwarding Switching
• Configurarea MPLS în modul cadru pe platforma Cisco IOS
• Verificarea MPLS în modul cadru pe platforma Cisco IOS
• Depanarea MPLS în modul cadru pe platforma Cisco IOS

Modulul 4. Tehnologia MPLS VPN

• Introducere în VPN
• Introducere în arhitectura MPLS VPN
• Înțelegerea modelului de rutare MPLS VPN
• Redirecționarea pachetelor VPN MPLS
• Utilizarea mecanismelor VPN MPLS pe ​​platformele Cisco IOS
• Configurarea tabelelor VRF
• Configurarea sesiunilor MP-BGP între routerele de frontieră ale furnizorului
• Configurarea protocoalelor de rutare cu scalabilitate redusă între routerele furnizor și client
• Se verifică funcționarea MPLS VPN
• Configurarea OSPF ca protocol de rutare între routerele furnizor și client
• Configurarea BGP ca protocol de rutare între routerele furnizor și client
• Depanarea VPN MPLS

Modulul 5: VPN MPLS cuprinzătoare

• Vă prezentăm VPN suprapus
• Vă prezentăm Central Services VPN
• Folosind funcții avansate de import și export VRF
• Vă prezentăm serviciul de router gestionat de client

Modulul 6. Acces la Internet și VPN MPLS

• Combinând accesul la Internet și VPN MPLS
• Implementarea de servicii separate de acces la Internet și VPN
• Implementarea accesului la Internet ca VPN separat

Modulul 7: Prezentare generală a MPLS TE

• Introducere în conceptele de inginerie a traficului
• Prezentare generală a componentelor MPLS TE
• Configurarea MPLS TE pe platforma Cisco IOS
• Verificarea setărilor MPLS TE pe platforma Cisco IOS

Atestări și examene

Acest curs pregătește examenele incluse în programele de formare pentru specialiști internaționali atestați:

• Cisco Certified Internetwork Professional

VPN (Virtual Private Network) este o rețea privată virtuală sau o rețea logică care este creată pe deasupra rețelelor neprotejate (rețelele unui operator de telecomunicații sau ale furnizorului de servicii de internet). VPN este o tehnologie care protejează datele atunci când sunt transmise prin rețele nesecurizate. O rețea privată virtuală vă permite să creați un tunel în rețele nesecurizate (între două puncte de rețea), cum ar fi rețele ATM, FR sau IP.

Folosind un VPN, puteți realiza conexiuni: de la rețea la rețea, de la site la rețea sau de la site la site. Asemenea proprietăți tehnologii VPN oferă posibilitatea de a combina rețele locale de birouri ale companiei la distanță geografică într-o singură companie reteaua de informatii. Trebuie remarcat faptul că corporative retele de calculatoare(KVS) poate fi organizată și pe baza unor canale de comunicare dedicate (private sau închiriate). Astfel de instrumente organizatorice sunt folosite pentru întreprinderile mici (întreprinderi cu birouri amplasate compact) cu trafic care nu se modifică în timp.

Sunt cunoscute principalele tipuri de VPN și combinațiile lor:

• Intranet VPN (VPN intra-corporat);
• Extranet VPN (VPN inter-corporate);
• Remote Access VPN (VPN cu acces de la distanță);
• VPN client/server (VPN între două noduri ale rețelei corporative).

În prezent, următoarele tehnologii sunt utilizate pentru a construi rețele corporative, distribuite geografic, în infrastructura partajată a furnizorilor de servicii și a operatorilor de telecomunicații:

• tuneluri IP folosind tehnologii VPN GRE sau IPSec;
• SSL, care include OpenVPN și SSL VPN (SSL/TLS VPN) pentru organizarea canalelor de comunicații securizate;
• MPLS în rețeaua operatorului (L3 VPN) sau VPN în rețeaua BGP/MPLS;
• Metro Ethernet VPN în rețeaua operatorului (L2 VPN). Cea mai promițătoare tehnologie folosită în Metro Ethernet VPN este VPN bazată pe MPLS (MPLS L2 VPN) sau VPLS.

În ceea ce privește utilizarea liniilor închiriate și a tehnologiilor Frame Relay, ATM pentru organizarea rețelelor corporative distribuite geografic, acestea practic nu mai sunt folosite în aceste scopuri. Astăzi, de regulă, CBC-urile sunt construite pe baza rețelelor suprapuse (rețele client-server și peer-to-peer), care funcționează în infrastructura partajată a operatorilor și sunt „superstructuri” pe protocoalele de rețea clasice.

Pentru a organiza rețele corporative distribuite geografic, furnizorii oferă clienților următoarele modele VPN de bază pe Internet:

• Model IP VPN (GRE, IPSec VPN, OpenVPN) prin Rețea WAN, în care configurația VPN este furnizată de client;
• model L 3 VPN sau MPLS L3 VPN printr-o rețea WAN, în care configurația VPN este furnizată de furnizorul de servicii sau operatorul de telecomunicații;
• Model VPN L2 prin rețeaua MAN, în care configurația VPN este furnizată de furnizor sau operator de telecomunicații:
  • punct la punct (AToM, 802.1Q, L2TPv3);
  • multipunct (VPLS și H-VPLS).

Tehnologiile VPN pot fi clasificate în funcție de metodele de implementare a acestora folosind protocoale: autentificare, tunelare și criptare a pachetelor IP. De exemplu, VPN-urile (IPSec, OpenVPN, PPTP) se bazează pe criptarea datelor clienților, VPN-urile (L2TP și MPLS) se bazează pe separarea fluxurilor de date între clienții VPN, iar SSL VPN se bazează pe criptografie și autentificarea traficului. Dar, de regulă, VPN-urile folosesc opțiuni mixte atunci când tehnologiile sunt utilizate împreună: autentificare, tunel și criptare. Practic, organizarea rețelelor VPN se realizează pe baza protocoalelor legăturii de date și a straturilor de rețea ale modelului OSI.

Trebuie remarcat faptul că pentru utilizatorii de la distanță mobilă a fost dezvoltată tehnologia SSL VPN (Secure Socket Layer), care se bazează pe un alt principiu de transmitere a datelor private (date de utilizator) prin Internet. Protocolul SSL VPN este folosit pentru organizare nivelul de aplicare HTTPS. Pentru HTTPS se folosește portul 443, prin care se stabilește o conexiune folosind TLS (Transport Layer Security).

TLS și SSL (protocoale TLS și SSL ale stratului 6 al modelului OSI) sunt protocoale criptografice care oferă o protecție fiabilă a datelor la nivel de aplicație, deoarece folosesc criptografia asimetrică, criptare simetricăși coduri de autentificare a mesajelor. Dar din moment ce există 4 straturi definite în stiva TCP/IP, adică. Deoarece nu există straturi de sesiune și prezentare, aceste protocoale funcționează deasupra stratului de transport din stiva TCP/IP, asigurând securitatea transferului de date între nodurile de Internet.

Model IP VPN, în care configurația VPN este furnizată de client

Modelul IP VPN poate fi implementat pe baza standardului IPSec sau altul Protocoale VPN(PPTP, L2TP, OpenVPN). În acest model, interacțiunea între routerele clientului este stabilită prin intermediul rețelei WAN a furnizorului de servicii. În acest caz, furnizorul nu este implicat în configurarea VPN-ului, ci oferă doar rețelele sale neprotejate pentru transmiterea traficului clientului. Rețelele furnizorilor sunt destinate numai pentru conexiuni VPN încapsulate sau suprapuse (transparente) între birourile clienților.

Configurarea VPN este efectuată de mijloacele de telecomunicații ale clientului, adică clientul controlează el însuși direcționarea traficului. O conexiune VPN este o conexiune printr-o rețea punct-la-punct nesecurizată: „VPN gateway - VPN gateway” pentru conectarea rețelelor de birouri locale la distanță, „VPN user - VPN gateway” pentru conectarea angajaților la distanță la biroul central.

Pentru a organiza o rețea VPN, în fiecare sediu al companiei este instalat un router, care asigură interacțiunea între rețeaua de birou și rețeaua VPN. Software-ul pentru construirea de VPN-uri securizate este instalat pe routere, de exemplu, pachetul gratuit OpenVPN (în acest caz, pachetul OpenVPN trebuie configurat să funcționeze în modul de rutare). Tehnologia OpenVPN se bazează pe standardul SSL pentru comunicații securizate prin Internet.

OpenVPN oferă conexiuni sigure bazate pe OSI Layer 2 și Layer 3. Dacă OpenVPN este configurat să funcționeze în modul bridge, acesta oferă conexiuni securizate bazate pe 2 Nivelul OSI, dacă se află în modul de rutare - pe baza nivelului 3. OpenVPN, spre deosebire de SSL VPN, nu acceptă accesul la rețeaua VPN printr-un browser web. OpenVPN necesită o aplicație suplimentară (client VPN).

Routerul de la sediul central al companiei este configurat ca un server VPN, iar routerele de birou la distanță sunt configurate ca clienți VPN. Serverul VPN și routerele client VPN se conectează la Internet prin rețelele furnizorului. În plus, puteți conecta computerul unui utilizator de la distanță la biroul principal prin configurarea unui program client VPN pe computer. Ca rezultat, obținem un model IP VPN (captura de ecran este prezentată în Fig. 1).

Orez. 1. Model de rețea IP VPN (Intranet VPN + Remote Access VPN)

MPLS L3 VPN sau L3 VPN model, în care configurația VPN este furnizată de furnizorul de servicii sau operatorul de telecomunicații (furnizorul de servicii)

Să luăm în considerare procesul de organizare a unei rețele VPN pentru trei rețele locale la distanță de birouri ale clienților de servicii (de exemplu, SC-3 Corporation), situate în orașe diferite, folosind rețeaua principală MPLS VPN a furnizorului de servicii, construită pe baza MPLS L3 VPN tehnologie. În plus, la rețeaua corporației SC-3 sunt conectate un computer de la distanță și un laptop al unui utilizator mobil. În modelul MPLS L3 VPN, echipamentul furnizorului este implicat în rutarea traficului clientului prin WAN.

În acest caz, livrarea traficului clienților din rețelele locale ale birourilor clientului serviciului către rețeaua principală MPLS VPN a furnizorului de servicii se realizează folosind tehnologia IP. Pentru a organiza o rețea VPN, în fiecare birou al companiei este instalat un router CE periferic sau edge (Customer Edge router) care este conectat printr-un canal fizic la unul dintre routerele PE edge (routere Provider Edge) ale rețelei MPLS de furnizorul (operatorul). În acest caz, unul dintre protocoalele stratului de legătură (PPP, Ethernet, FDDI, FR, ATM etc.) poate funcționa pe canalul fizic care conectează routerele CE și PE.

Rețeaua unui furnizor de servicii (furnizor de servicii sau operator de telecomunicații) este alcătuită din routere PE periferice și o rețea de bază (nucleu de rețea) cu routere dorsale cu comutare de etichete P (router furnizor). Astfel, MPLS L3 VPN constă din rețelele IP locale ale biroului clientului și rețeaua principală MPLS a furnizorului (domeniul MPLS), care unește rețelele locale distribuite ale birourilor clientului într-o singură rețea.

Rețelele locale de la distanță ale birourilor clientului fac schimb de pachete IP prin rețeaua furnizorului MPLS, în care se formează tuneluri MPLS pentru a transmite traficul clientului prin rețeaua de bază a furnizorului. O captură de ecran a modelului de rețea MPLS L3 VPN (Intranet VPN + Remote Access VPN) este prezentată în Fig. 2. Pentru simplificarea diagramei de rețea, sunt acceptate următoarele condiții inițiale: toate LAN-urile de birou aparțin unui singur VPN, iar rețeaua backbone (backbone) este un domeniu MPLS, sub controlul unificat al unui furnizor național de servicii (operator de comunicații) .

Trebuie remarcat faptul că MPLS L3 VPN poate fi organizat folosind mai multe domenii MPLS de la diferiți furnizori de servicii. Figura 2 prezintă o topologie VPN cu plasă completă.

Orez. 2. Model de rețea MPLS L3 VPN (Intranet VPN + Remote Access VPN)

Funcționarea routerelor PE

Routerele periferice CE și PE (client și furnizor) schimbă informații de rutare între ele folosind unul dintre protocoalele interne de rutare IGP (RIP, OSPF sau IS-IS). Ca rezultat al schimbului de informații de rutare, fiecare router PE își creează propriul tabel de rutare VRF (extern) separat (VPN Routing and Forwarding) pentru rețeaua locală a biroului clientului conectat la acesta prin routerul CE. Astfel, informațiile de rutare primite de la CE sunt înregistrate în tabelul VRF al PE.

Tabelul VRF se numește tabel virtual de rutare și redirecționare. Doar routerele PE știu că rețeaua MPLS are un VPN pentru client. Din modelul de rețea MPLS L3 VPN rezultă că informațiile de rutare nu sunt schimbate între routerele CE ale clientului, prin urmare clientul nu participă la rutarea traficului prin coloana vertebrală MPLS furnizorul (operatorul).

Mai multe rețele VPN de la diferiți clienți pot fi conectate la routerul PE (Fig. 3). În acest caz, este instalat un protocol de rutare separat pentru fiecare interfață (int1, int2 etc.) a routerului PE la care este conectată rețeaua locală a biroului clientului. Pentru fiecare interfață de router PE, unul dintre IGP-uri creează o tabelă de rutare VRF, iar fiecare tabel de rutare VRF corespunde rutelor VPN pentru fiecare client.

De exemplu, pentru clientul SC-3 și rețeaua sa LAN0 (sediu central), conectat prin CE0 la PE0, tabelul VRF1 SC-3 va fi creat pe PE0, pentru LAN1 a clientului SC-3 pe PE1 va fi creat VRF2 SC-3 , pentru LAN2 pe PE2 - VRF3 SC-3 etc., dar aparțin aceluiași VPN SC3. Tabelul VRF1 SC-3 este comun pentru informațiile de rutare ale CE0 și CE4. Trebuie remarcat faptul că tabelele VRF sunt completate cu informații despre adresele rețelei locale ale tuturor celorlalte birouri ale unui anumit client folosind protocolul MP-BGP (multiprotocol BGP). Protocolul MP-BGP este utilizat pentru a schimba rute direct între routerele PE și poate transporta adrese VPN-IPv4 în informațiile de rutare.

Adresele VPN-IPv4 constau din adrese IPv4 sursă și un prefix RD (Route Distinguisher) sau un distinctor de rută care identifică VPN-ul specific. Ca rezultat, pe routerele PE vor fi create tabele VRF cu rute identice pentru o rețea VPN. Numai acele routere PE care participă la organizarea aceleiași rețele VPN client schimbă informații de rutare între ele folosind protocolul MP-BGP. Prefixul RD este configurat pentru fiecare tabel VRF.

Informații de rutare schimbate între routerele PE prin protocolul MP-BGP printr-o interfață globală sau internă:

• Adresa rețelei de destinație (VPN-IPv4);
• Adresa următorului router pentru protocol (next hop);
• Eticheta Lvpn – determinată de numărul de interfață (int) al routerului PE la care este conectat unul dintre rețelele LAN de birou ale clientului;
• Atributul mesajului RT (rută-țintă) este un atribut VPN care identifică toate rețelele LAN de birou care aparțin aceleiași rețele corporative client sau unui VPN.

Orez. 3. Router PE

În plus, fiecare router PE schimbă informații de rutare cu routerele P backbone folosind unul dintre protocoalele interne de rutare (OSPF sau IS-IS) și, de asemenea, creează o tabelă de rutare globală (GRT) separată (internă) pentru rețeaua principală MPLS. Tabelul extern (VRF) și tabelul global de rutare intern (GTM) în routerele PE sunt izolate unul de celălalt. Routerele P schimbă informații de rutare între ele și routerele PE folosind protocoalele IP tradiționale de rutare internă (IGP), cum ar fi OSPF sau IS-IS, și își creează tabelele de rutare.

Pe baza tabelelor de rutare care utilizează protocoale de distribuție a etichetelor LDP sau protocoale RSVP bazate pe tehnologia Traffic Engineering, tabelele de comutare a etichetelor sunt construite pe toate routerele P (FTN-urile sunt create pe PE) formând o rută LSP (Label Switched Paths) specifică. Rezultatul sunt rutele LSP cu etichete comutate, unde pachetele IP sunt transmise pe baza valorilor etichetelor antet MPLS și a tabelelor de comutare locale, mai degrabă decât a adreselor IP și a tabelelor de rutare.

Un antet MPLS este adăugat la fiecare pachet IP care intră în routerul PE de intrare și eliminat de ruterul PE de ieșire atunci când pachetele părăsesc rețeaua MPLS. Antetul MPLS nu folosește o etichetă, ci un teanc de două etichete, de ex. PE de intrare atribuie pachetului două etichete. Unul dintre ele este L extern, celălalt este Lvpn intern. Eticheta exterioară sau eticheta de nivel superior a stivei este utilizată direct pentru a comuta pachetul de-a lungul LSP de la intrare la PE de ieșire.

Trebuie remarcat faptul că PE direcționează traficul de intrare către un LSP specific bazat pe FEC (Forwarding Equivalence Class). FEC este un grup de pachete pentru condiții, al căror transport are aceleași cerințe. Pachetele aparținând aceluiași FEC călătoresc pe același LSP. Clasificarea FEC se poate face în diverse moduri, de exemplu: după adresa IP a rețelei de destinație (prefixul rețelei), tipul de trafic, cerințele de inginerie etc.

Dacă utilizați clasificarea după adresa IP a rețelei de destinație, atunci se creează o clasă separată pentru fiecare prefix al rețelei de destinație. În acest caz, protocolul LDP automatizează complet procesul de creare a claselor și de atribuire a valorilor etichetelor acestora (Tabelul 1). Fiecărui pachet de intrare care este rutat de routerul PE către o anumită adresă IP din rețeaua de birou i se atribuie o etichetă specifică pe baza tabelului FTN.

Tabelul 1. FTN (FEC To Next hop) pe routerul PE1

Din Tabelul 1 rezultă că valoarea etichetei externe este atribuită de către routerul de intrare PE1 pe baza adresei IP a rețelei locale de birou. Eticheta internă sau eticheta nivelului inferior al stivei nu participă la procesul de comutare a pachetului prin LSP de la intrare la PE de ieșire, dar definește VRF sau interfața pe PE de ieșire la care LAN-ul biroului clientului. este conectat.

Schimb de informații despre rută VPN prin protocolul MP-BGP

Informații de rutare (informații despre rută VPN) pe care routerul PE1 le transmite către routerul PE2 prin BGP (linii roșii):

• Adresă VPN-IPv4: 46.115.25.1:106:192.168.1.0;
• Următorul hop = 46.115.25.1;
• Lvpn=3;
• RT= SC-3.

Distingerul de rută RD=46.115.25.1:106 este adăugat la adresa IPv4 a LAN1 a Biroului Regional 1, unde 46.115.25.1 este adresa IP a interfeței globale a PE1 prin care PE1 comunică cu routerele P. Pentru această rută VPN SC-3, administratorul de rețea al furnizorului în routerul PE1 sau PE1 atribuie o etichetă (număr), de exemplu 106.

Când PE2 primește adresa de rețea de destinație VPN-IPv4 de la PE1, elimină delimitatorul de rută RD, plasează adresa 192.168.1.0 în tabelul SC-3 VRF3 și notează că intrarea a fost făcută de BGP. În plus, face publicitate acestei rute către routerul clientului CE2 conectat la acesta pentru acest VPN SC-3.

Tabelul VRF3 SC-3 este, de asemenea, actualizat cu protocolul MP-BGP - despre adresele de rețea ale altor birouri LAN ale acestui VPN SC-3. Routerul PE1 trimite, de asemenea, informații de rutare către alte routere prin protocolul MP-BGP: PE0 și PE3. Ca urmare, toate rutele din tabelele VRF ale routerelor (PE0, PE1, PE2 și PE3) conțin adresele tuturor rețelelor LAN ale birourilor unui anumit client în format IPv4.

Orez. 4. Tabelele VRF ale routerelor (PE0, PE1, PE2 și PE3)

Informații de rutare pe care routerul PE2 le transmite către routerul PE1 prin protocolul MP-BGP (linii roșii):

• Adresă VPN-IPv4: 46.115.25.2:116:192.168.2.0;
• Următorul hop = 46.115.25.2;
• Lvpn=5;
• RT=SC-3.

Transfer de date între PC-uri într-o rețea corporativă organizată pe baza tehnologiei MPLS L3 VPN

Să luăm în considerare modul în care are loc schimbul de date între PC-ul 2 (IP: 192.168.1.2) al rețelei LAN1 și PC-ul 1 (IP: 192.168.3.1) al rețelei LAN. Pentru a accesa fișierele aflate în directoare sau unități logice ale PC-ului 1 (LAN) cu acces partajat, trebuie să introduceți \\192.168.3.1 pe PC 2 (LAN1) în linia „Găsiți programe și fișiere” (pentru sistemul de operare Win 7) și apăsați tasta Enter. Ca urmare, ecranul PC-ului 2 va afișa directoarele partajate (directoare sau foldere („partajate”) care se află pe PC-ul 1. Cum se întâmplă acest lucru?

Când apăsați tasta Enter pe PC 2 (LAN1), la nivel de rețea este generat un pachet cu adresa IP de destinație 192.168.3.1. În primul rând, pachetul ajunge la routerul CE1 (Fig. 5), care îl redirecționează în conformitate cu tabelul de rutare către interfața int3 a routerului PE1, deoarece este următorul router care accesează rețeaua 192.168.3.0/24, în care sunt PC-urile 1 (LAN GO) cu adresa IP 192.168.3.1. Tabelul de rutare VRF2 SC-3 este asociat cu interfața int3, astfel încât transmiterea ulterioară a pachetului se bazează pe parametrii acestuia.

După cum se poate vedea din tabelul VRF2 SC-3, următorul router care redirecționează pachetul către rețeaua 192.168.3/24 este PE0 și această intrare a fost făcută prin protocolul BGP. În plus, tabelul arată valoarea etichetei Lvpn=2, care definește interfața ruterului de ieșire PE0. Rezultă că deplasarea ulterioară a pachetului către rețeaua 192.168.3/24 este determinată de parametrii tabelului global de rutare GTM PE1.

Orez. 5. Transfer de date între PC2 (192.168.1.2) și PC1 (192.168.3.1) rețelele LAN1 și LAN ale sediului principal al KS SC-3

În tabelul global (GTM PE1), adresa următorului router (NH - Next Hop) PE0 corespunde valorii inițiale a etichetei externe L=105, care determină calea LSP către PE0. Pachetul este transmis de-a lungul LSP pe baza etichetei L de la nivelul superior al stivei (L=105). Pe măsură ce pachetul trece prin routerul P3 și apoi prin routerul P1, eticheta L este analizată și înlocuită cu noi valori. Odată ce pachetul ajunge la punctul final LSP, routerul PE0 elimină eticheta exterioară L din stiva MPLS.

Apoi routerul PE0 scoate din stivă eticheta de jos a stivei Lvpn=2, care definește interfața int2 la care este conectat routerul CE0 al rețelei locale a biroului principal al clientului (HO LAN). Apoi, din tabelul (VRF1 SC-3) care conține toate rutele VPN SC3, routerul PE0 preia intrarea pentru valoarea etichetei Lvpn=2 și ruta asociată către rețeaua 192.168.3/24, care indică CE0 ca următorul router. Din tabel rezultă că intrarea rutei a fost plasată în tabelul VRF1 SC-3 prin protocolul IGP, astfel încât calea pachetului de la PE0 la CE0 este efectuată prin protocolul IP.

Deplasarea ulterioară a pachetului de la CE0 la PC-ul 1 cu adresa IP 192.168.3.1 se realizează folosind adresa MAC, deoarece CE0 și PC-ul 1 (192.168.3.1) sunt pe aceeași LAN. După primirea pachetului de solicitare de la PC-ul 2, sistemul de operare al PC-ului 1 va trimite copii ale directoarelor sale pentru a fi partajate cu PC-ul 2. sistem de operare PC-ul 2, după ce a primit copii ale directoarelor partajate de la PC-ul 1, le afișează pe ecranul monitorului. Astfel, prin rețelele publice MPLS ale furnizorului, datele sunt schimbate prin canale LSP virtuale între două PC-uri aparținând unor rețele LAN diferite ale birourilor aceluiași client.

În ceea ce privește conectarea unui utilizator mobil de la distanță la resursele unei rețele corporative distribuite geografic, aceasta poate fi implementată folosind una dintre tehnologiile Remote Access VPN (Remote Access IPSec VPN și SSL VPN). Trebuie remarcat faptul că tehnologia SSL VPN acceptă două tipuri de acces: acces complet la rețea și fără client. Tehnologia VPN SSL fără client oferă acces la rețea de la distanță printr-un browser web standard, dar numai în acest caz aplicații de rețea cu interfata web. Tehnologia SSL VPN cu acces complet la rețea, după instalarea unei aplicații suplimentare (client VPN) pe un PC, oferă acces la toate resursele unei rețele corporative distribuite geografic.

De regulă, un utilizator de la distanță se conectează la un VPN MPLS L3 printr-un server de acces la distanță (RAS), care se conectează la unul dintre routerele PE ale rețelei MPLS. În cazul nostru, utilizatorul mobil este conectat prin intermediul rețelei de acces (Internet) folosind Remote Access IPSec VPN la RAS, care este conectat la routerul PE0. Astfel, utilizatorul mobil se conectează prin VPN IPSec la rețeaua sa corporativă (corporația SC-3), organizată pe baza VPN MPLS L3.

Model MPLS L2 VPN, în care configurația VPN este furnizată de ISP sau operatorul de telecomunicații (furnizorul de servicii)

Este posibil să se organizeze un singur spațiu de informații în trei birouri (de exemplu, corporația SC-3) situate în același oraș pe baza rețelei de bandă largă Metro Ethernet a operatorului de telecomunicații (L2 VPN). Unul dintre serviciile rețelelor Metro Ethernet este organizarea rețelelor corporative prin rețele MAN backbone (rețele de operator de telecomunicații la nivel de oraș). Pentru a organiza Metro Ethernet VPN (L2 VPN), sunt utilizate diverse tehnologii, de exemplu AToM (în principal EoMPLS), 802.1Q, L2TPv3 și așa mai departe, dar cea mai promițătoare tehnologie este MPLS L2 VPN sau VPLS. În acest caz, livrarea traficului clienților din rețelele locale ale birourilor clientului serviciului către rețeaua centrală MPLS VPN a furnizorului de servicii se realizează folosind tehnologia de al doilea strat (Ethernet, Frame Relay sau ATM).

Operatorii de telecomunicații oferă două tipuri de servicii Rețele Ethernet pentru organizarea rețelelor private virtuale la al doilea nivel al modelului OSI, care sunt formate pe baza tehnologiei MPLS - acestea sunt VPWS (Virtual Private Wire Services) și VPLS (Virtual Private LAN Services). Aceste VPN-uri sunt construite pe baza de pseudo-canale (pseudowire), care conectează routerele PE edge ale rețelei furnizorului (domeniul MPLS). Tunelurile LSP sau canalele logice sunt create folosind etichete, în cadrul cărora sunt așezate pseudo-canale (VC-uri emulate) și sunt transmise pachete MPLS prin aceste pseudo-canale. VPWS se bazează pe Ethernet peste MPLS (EoMPLS). Dar în VPLS, spre deosebire de rețelele VPWS punct-la-punct (P2P), pseudo-canalele sunt organizate folosind conexiuni punct-la-multipunct (P2M).

În VPLS, există două moduri de a stabili pseudo-canale între oricare două PE care fac parte dintr-un VPLS dat (folosind protocolul BGP și protocolul de distribuție a etichetei LDP). Protocolul BGP extins (MP-BGP) oferă detectarea automată a PE-urilor care interacționează la construirea unui LAN distribuit geografic bazat pe serviciul VPLS și semnalizarea etichetelor circuitelor virtuale (vc-labels). Protocolul LDP extins poate fi folosit și pentru semnalizarea vc-labels. În acest caz, identificarea tuturor routerelor PE care fac parte din acest VPLS se realizează în modul de configurare manuală.

De asemenea, puteți utiliza sisteme de management care automatizează căutarea și configurarea dispozitivelor PE pentru organizarea serviciilor VPLS. Folosește un teanc de etichete pentru a transmite cadre, eticheta de sus este pentru tunelurile LSP, care este folosită pentru a ajunge la PE de ieșire. Eticheta de jos este eticheta VC, care este folosită pentru a demultiplex canalele virtuale (pseudowire) transmise în același tunel. Un tunel poate avea mai multe pseudo-canale pentru diferite instanțe VPLS.

Se creează comutatoare virtuale VSI separate pentru fiecare instanță VPLS de pe PE. Switch-urile VSI învață adrese MAC și construiesc tabele de redirecționare a pachetelor MPLS. Pe baza datelor din tabelul de redirecționare, comutatoarele VSI, având cadre primite încapsulate în pachete MPLS, le transmit către pseudo-canale care conduc la PE-uri de margine, la care sunt conectate comutatoarele de margine CE ale segmentelor LAN ale birourilor clientului.

Pe baza VPWS (point-to-point), este posibil să combinați două subrețele de birouri ale corporației într-o singură rețea, cu o singură adresare IP end-to-end. VPLS este o tehnologie care oferă conexiuni multipunct printr-o infrastructură de rețea IP/MPLS bazată pe pachete. VPLS vă permite să combinați mai multe rețele locale distribuite geografic de birouri corporative într-o singură rețea locală. În acest caz, rețeaua principală MPLS a furnizorului de servicii este un comutator Ethernet virtual (comutator L2) care transmite cadre Ethernet între segmentele LAN ale birourilor individuale ale clienților. Diagrama unei rețele locale distribuite geografic (în interiorul orașului) a corporației este prezentată în Fig. 6.

Orez. 6. Schema unei rețele locale distribuite geografic (în interiorul orașului) a corporației

Esența conceptului VPLS este transmisia transparentă a cadrelor Ethernet PC ale rețelelor locale de birouri (segmente ale rețelelor de birouri ale clienților) ale clientului prin rețeaua principală MPLS a furnizorului. Dispozitivele de margine de pe partea clientului a VPLS 1 sunt comutatoarele CE0, CE1, CE2, care sunt conectate la dispozitivele PE0, PE1, PE2. Routerele PE comunică între ele pentru a identifica toate PE-urile conectate la VPLS 1. Dispozitivele PE și P construiesc tabele de rutare din care sunt create LSP-urile și pseudo-legăturile.

Atât BGP, cât și LDP pot fi utilizate ca protocoale de semnalizare. Comutatoarele virtuale VSI 1 ale dispozitivelor PE0, PE1, PE2 construiesc tabele pentru redirecționarea pachetelor MPLS. De exemplu, VSI 1 al dispozitivului PE0 generează tabelul de comutare prezentat în Fig. 6. Când un cadru Ethernet sosește de la unul dintre PC-urile LAN de la biroul principal la intrarea dispozitivului PE0, acesta încapsulează cadrul Ethernet într-un pachet MPLS și, folosind tabelul de comutare, îl transmite către tunelul prin care pachetul ajunge la dispozitiv de ieșire PE1.

Pentru a redirecționa un pachet printr-o rețea MPLS (prin pseudo-canale în tunelurile LSP), se utilizează o stivă de etichete, care constă dintr-o etichetă de tunel LSP și o etichetă VC pseudo-canal, de exemplu, 15. La dispozitivul de ieșire PE1, Pachetele MPLS sunt convertite în cadre Ethernet și redirecționate către comutatorul C1, la care computerul de destinație este conectat cu adresa MAC 90:5C:E7:C8:56:93. Documentele RFC 4761 și RFC 4762 detaliază metodele de semnalizare bazate pe protocoalele BGP și LDP pentru rețelele locale organizate folosind servicii VPLS.

Lista surselor de informare:

1. Rețele de calculatoare. Principii, tehnologii, protocoale: Manual pentru universități. a 4-a ed. / V.G. Olifer, N.A. Olifer – Sankt Petersburg. Peter, 2010. – 944 p.

2. Olwein, Vivec. Structura și implementarea tehnologiei moderne MPLS.: Per. din engleza – M.: Editura Williams, 2004. – 480 p.

Rețeaua companiei noastre imaginare linkmeup este în creștere. Are deja linii principale în diverse orașe, o bază de clienți și un personal excelent de ingineri care au crescut în ciclul SDSM.
Dar totul nu este suficient pentru ei. Serviciile de bandă largă sunt bune și necesare, dar există încă o piață potențială uriașă clienti corporativi care au nevoie de un VPN.
Băieții s-au gândit la asta, și-au bătut creierele și au ajuns la concluzia că nu există nicio modalitate de a face asta fără MPLS.

Dacă multicast a fost primul subiect care a necesitat o oarecare restructurare a înțelegerii rețelelor IP, atunci când studiezi MPLS, cu siguranță va trebui să uiți aproape tot ce știai înainte - aceasta este o lume specială cu propriile reguli.

Problema de azi:

Să începem cu întrebarea: „Ce este în neregulă cu IP?”

Video tradițional

Dar de fapt, ce e în neregulă? De ce gard MPLS?

Da, totul este adevărat. Avantajele și dezavantajele IP provin din faptul că a apărut mai târziu decât rețelele clasice și este incredibil de flexibil. În zilele noastre, există o tranziție pe scară largă la comutarea de pachete, care se bazează pe IP la nivel de rețea, iar Ethernet câștigă din ce în ce mai multă popularitate la nivel de canal.
Acest lucru este bun, deoarece acum, pe baza unei rețele de bază și a unei rețele de acces, este posibil să se furnizeze telefonie IP, IPTV și alte servicii posibile.
Același lucru se poate observa și în rețelele operatorilor de telefonie mobilă. La început, rețelele de a doua generație se bazau în întregime pe . Nucleul rețelelor 3G este în mare parte IP, dar serviciile de telefonie pot fi încă furnizate în modul de comutare a circuitelor. Rețelele 4G sunt deja rețele IP cu drepturi depline, în care transmisia vocală este doar una dintre aplicații, precum și accesul în bandă largă.

Cu toate acestea, există încă un număr mare de segmente în care sunt utilizate tehnologii vechi. De exemplu, undeva este ATM, în alt loc trebuie să transferați PDH dintr-o parte a rețelei în alta, dar aici clientul a vrut ca bucata lui din rețeaua Ethernet să fie accesibilă din celălalt capăt al orașului ca și cum ar fi conectat direct - cu alte cuvinte, VPN.
Cum a fost rezolvat acest lucru înainte: aveți nevoie de ATM între două puncte geografice - construiți un canal între ele pe baza ATM, PDH - construiți PDH.
Dar vreau să fac toate acestea printr-o singură rețea, și nu să construiesc una separată pentru fiecare tip de trafic.
Acesta este motivul pentru care GRE, PPPoE, PPPoA, ATM over Ethernet, TDM over IP și numeroase alte over-uri au fost inventate la un moment dat. Puteți crea încă o mie pentru a acoperi toate combinațiile, iar fericirea universală va veni în haosul standardelor (. Apropo, unii mici producători au luat această cale).

La mijlocul anilor '90, hotheads de la mai multe companii (IBM, Toshiba, Cisco, Ipsilon) au venit cu ideea de a crea un mecanism care să permită, la rutare, să nu se uite în interiorul pachetului și să pieptene tabelul de rutare. în căutarea celei mai bune căi, dar pentru a naviga după o anumită etichetă. A funcționat la Cisco, iar mecanismul a fost numit simplu: TAG Switching.
Mai mult, scopul urmărit de dezvoltatori a fost acela de a permite comutatoarelor de mare viteză să transmită traficul exclusiv în hardware. Faptul este că rutarea IP hardware a fost de multă vreme o plăcere inaccesibilă și nu era practic să o folosești pe switch-uri ieftine, dar luarea unei decizii bazate pe o etichetă ar putea fi simplă și rapidă.
Dar, în același timp, au apărut circuite integrate la scară ultra-largă (chiar dacă nu sunt de acord cu acest termen - VLSI englezesc descrie mult mai bine esența), iar sarcina de a economisi la analiza conținutului pachetului nu a devenit așa. relevante. În plus, a apărut conceptul de FIB, care presupune că pentru fiecare pachet nu este nevoie să căutați destinația în tabelul de rutare și, în consecință, să implicați procesorul central - toate informațiile fierbinți sunt deja pe placa de linie.
Adică, în esență, necesitatea unui astfel de mecanism a dispărut.

Dar brusc A devenit clar că schimbarea etichetelor are un potențial neplanificat - nu contează ce se află sub etichetă - IP, Ethernet, ATM, Frame Relay. De asemenea, face posibilă eliminarea restricțiilor de rutare IP.
De aici își are originea tehnologia aprobată de IETF - MPLS - MultiProtocol Label Switching. Anul era 1997.
Și acest detaliu aparent nesemnificativ a dat naștere unei noi ere în telecomunicații. Astăzi veți găsi MPLS la orice furnizor mai mult sau mai puțin mare.

Principalele aplicații ale MPLS acum:

• MPLS L2VPN
• MPLS L3VPN
• MPLS TE

Vom vorbi despre fiecare dintre ele în articole separate - acestea sunt subiecte monstruos de uriașe. Dar le vom atinge pe scurt la sfârșitul articolului.

MPLS

MPLS pur în sine este rar folosit. Câștigul de performanță este neglijabil, deoarece diferența dintre a privi în FIB/modificarea unor câmpuri din anteturi și a privi tabelul de etichete/schimbarea etichetei în antetul MPLS nu este atât de mare. Desigur, sunt folosite aplicațiile enumerate mai sus.
Dar în acest articol ne vom concentra în continuare pe MPLS pur pentru a înțelege cum funcționează în forma sa cea mai de bază.
de asemenea, o aplicație a MPLS pur.

În ciuda faptului că MPLS nu este legat de tipul de rețea pe care va funcționa, în prezent trăiește în simbioză doar cu IP. Adică, rețeaua în sine este construită pe baza IP, dar în același timp poate transfera date din multe alte protocoale.
Dar să trecem la subiect și mai întâi vreau să spun asta MPLS nu înlocuiește rutarea IP, dar funcționează pe deasupra.

Pentru a fi mai specific, voi lua o rețea ca aceasta.

Acum este în stare de funcționare completă, dar fără niciun indiciu de MPLS. Adică, R1, de exemplu, vede R6 și își poate ping Loopback.
PC1 trimite o cerere ICMP către serverul 172.16.0.2. O solicitare ICMP este un pachet IP. Pe R1 conform principii de baza pachetul trece prin interfața FE0/0 la R2 - asta a spus Tabelul de rutare.
R2, după ce a primit pachetul, verifică adresa de destinație, se uită la FIB-ul său, vede următorul router și trimite pachetul la interfața FE0/0.
Și acest proces se repetă iar și iar. Fiecare router decide independent soarta pachetului.

Iată cum arată o groapă de trafic:

Ce se întâmplă dacă activăm MPLS? Imediat, chiar în acea secundă, lumea se schimbă. După aceasta, tabelele de etichete sunt populate pe routere și sunt construite numeroase LSP-uri.

Și acum aceeași cale va fi făcută puțin diferit.

Când un pachet IP de la PC1 intră în rețeaua MPLS, primul router atașează o etichetă, apoi acest pachet merge la destinație și fiecare router ulterior schimbă o etichetă cu alta. La părăsirea rețelei MPLS, eticheta este îndepărtată și un pachet IP pur este transmis în continuare, așa cum era la început.

Acesta este principiul de bază al MPLS - routerele schimbă pachetele folosind etichete fără a căuta în interiorul pachetului MPLS. Primul adaugă, ultimul șterge.

Să aruncăm o privire pas cu pas asupra transmiterii unui pachet de date de la PC1 la nodul destinație:

1. PC1 - un computer obișnuit - trimite un pachet obișnuit către un server la distanță.

2. Pachetul ajunge la R1. Se adaugă eticheta 18. Aceasta este inserată între antetul IP și Ethernet.
El poate lua aceste informații de la FIB:

FIB arată că pachetul cu destinatarul 6.6.6.6 trebuie etichetat 18 și trimiteți la interfață FE0/0.
Exact asta face: adaugă un titlu și scrie 18 în el:

Dump între R1 și R2.

3. R2 primește acest pachet, vede în antetul Ethernet că este un pachet MPLS (Ethertype 8847), citește eticheta și accesează tabelul său de etichete:

Să explicăm: dacă un pachet MPLS a sosit cu eticheta 18, trebuie schimbat la 20 și pachetul trebuie trimis la interfața FE0/0.

Dump după R2.

4. R5 efectuează acțiuni similare - vede că un pachet a sosit cu eticheta 20, trebuie schimbat la 0 și trimis la FE1/0. Fără acces la tabelul de rutare.

5. R6, după ce a primit pachetul MPLS, vede în tabelul său că eticheta trebuie acum eliminată. Și, după ce l-a eliminat, vede deja că destinația pachetului - 172.16.0.2 - este o rețea Direct Connected. Apoi pachetul este transmis în mod obișnuit prin tabelul de rutare fără nicio etichetă.

Adică, întregul proces arată astfel:

Nu vom lua în considerare nodurile finale pentru a nu complica diagrama.

Până acum, totul pare să fie simplu, chiar dacă nu este clar de ce.

Acum domeniile IGP și MPLS sunt aceleași și MPLS ne promite doar câteva bunătăți în viitor: L2VPN, L3VPN, MPLS TE.
Dar, de fapt, chiar și MPLS de bază ne oferă avantaje dacă ne amintim că suntem furnizori.
În calitate de furnizor, nu folosim protocoale IGP pentru rutarea între AS-uri. Pentru aceasta folosim BGP. Și în combinație cu BGP, avantajele MPLS vor deveni clare.
Să luăm în considerare rețeaua noastră împreună cu AS-urile vecine:

Din problema BGP știm asta pe fiecare Routerul din AS-ul nostru trebuie să fie configurat cu BGP. În caz contrar, nu vom putea transmite trafic de la AS-urile vecine și de la clienții noștri prin AS-ul nostru. Fiecare router trebuie să cunoască toate rutele.

Dar asta a fost înainte de MPLS!
Odată ce avem MPLS configurat în rețeaua noastră, nu mai trebuie să configuram BGP pe fiecare router din rețea. Este suficient să-l configurați doar pe routerele edge din AS, cele care sunt conectate la alți clienți sau furnizori.

Dar asta nu este tot Vești bune. Pe lângă eliminarea necesității de a configura BGP pe fiecare router dintr-un AS, routerele nu mai trebuie să creeze o etichetă pentru fiecare prefix BGP. Este suficient să știți cum să ajungeți la adresa IP care este listată ca următorul hop. Adică, dacă o sesiune BGP este configurată între Loopback0 R1 și Loopback0 R6, atunci nimic nu se va schimba în tabelul de etichete, chiar dacă fiecare dintre ele transmite sute de mii de rute prin BGP:

De exemplu, routerul R1 a primit mai multe rute prin BGP de la routerul R6:

Să vedem cum vor fi procesate pachetele care ajung în rețeaua 100.0.0.0/16:

În rezultatul de mai sus puteți vedea că pachetele vor fi adăugate cu o etichetă de 27.
Și, dacă te uiți la tabelul de etichete, nu există etichete pentru rutele care sunt cunoscute de BGP, dar există eticheta 27 și corespunde cu 6.6.6.6/32. Și aceasta este exact adresa pe care am văzut-o în rutele care veneau prin BGP de la R6:

Puteți găsi un exemplu de configurare.

Ne-am devansat puțin, dar acum că a devenit mai clar ce avantaje oferă chiar și MPLS de bază, ne putem cufunda în aparatul conceptual din lumea MPLS.

Terminologie

Eticheta - etichetă - o valoare de la 0 la 1.048.575 Pe baza acesteia, LSR decide ce să facă cu pachetul: ce etichetă nouă să agăță, unde să o trimită.
Face parte din antetul MPLS.

Stiva de etichete - teancul de etichete. Fiecare pachet poate transporta una, două, trei sau cel puțin 10 etichete - una peste alta. Decizia despre ce să faceți cu pachetul se ia pe baza etichetei de sus. Fiecare strat joacă propriul său rol.
De exemplu, la transmiterea unui pachet, se folosește o etichetă de transport, adică o etichetă care organizează tranzitul de la primul la ultimul router MPLS.
Alții pot transporta informații că un anumit pachet aparține unui anumit VPN.
În această lansare va exista întotdeauna o singură etichetă - nu mai sunt necesare pentru moment.

Apăsați Eticheta - operația de adăugare a unei etichete la un pachet de date se realizează chiar de la început - pe primul router din rețeaua MPLS (în exemplul nostru - R1).

Schimbați eticheta - operațiune de înlocuire a etichetei - are loc pe routerele intermediare din rețeaua MPLS - un nod primește un pachet cu o etichetă, îl schimbă și îl trimite cu altul (R2, R5).

Etichetă pop - operațiune de eliminare a etichetei - efectuată de ultimul router - nodul primește pachetul MPLS și elimină top marcați înainte de a-l trece mai departe (R6).

De fapt, o etichetă poate fi adăugată și eliminată oriunde într-o rețea MPLS.
Totul depinde de serviciile specifice. Ar fi mai corect să spunem că eticheta este adăugată de primul router de pe cale (LSP) și eliminată de ultimul.
Dar în acest articol, pentru simplitate, vom vorbi despre limitele rețelei MPLS.
În plus, eliminarea etichetei de sus nu înseamnă că a mai rămas un pachet IP pur, dacă vorbim de stiva de etichete. Adică, dacă o operațiune Pop Label a fost efectuată pe un pachet cu trei etichete, atunci rămân două etichete și apoi este încă procesată ca MPLS. Dar în exemplul nostru a existat unul, dar după aceea nu va mai rămâne niciunul - și aceasta este deja o chestiune de IP.

LSR- Eticheta Comutați routerul este orice router dintr-o rețea MPLS. Se numește așa pentru că efectuează unele operații cu etichete. În exemplul nostru, acestea sunt toate nodurile: R1, R2, R3, R4, R5, R6.
LSR este împărțit în 3 tipuri:
LSR intermediar - router MPLS intermediar - realizeaza operatia Swap Label (R2, R5).
Intrare LSR - „input”, primul router MPLS - efectuează operația Push Label (R1).
Ieșire LSR - „ieșire”, ultimul router MPLS - efectuează operația Pop Label (R6).
LER- Label Edge Router este un router la marginea unei rețele MPLS.
În special, Ingress LSR și Egress LSR sunt margini, ceea ce înseamnă că sunt și LER.

LSP- Etichetă Cale comutată - cale pentru comutarea etichetelor. Acesta este un canal unidirecțional de la Ingress LSR la Egress LSR, adică calea de-a lungul căreia pachetul va trece efectiv prin rețeaua MPLS. Cu alte cuvinte, aceasta este o secvență LSR.
Este important să înțelegeți că LSP De fapt unidirectional. Aceasta înseamnă că, în primul rând, traficul prin acesta este transmis doar într-o singură direcție, în al doilea rând, dacă există un „acolo”, nu există neapărat „înapoi”, în al treilea rând, „înapoi” nu urmează neapărat aceeași cale, că "Acolo". Ei bine, este ca interfețele de tunel în GRE.

Cum arată LSP?

Da, așa este de neprezentabil.
Acesta este rezultatul compilat de la patru LSR-uri - R1, R2, R5, R6. Adică, pe un LSR nu veți vedea o secvență completă de noduri de la intrare până la ieșire, cum ar fi atributul AS-PATH din BGP. Aici, fiecare nod cunoaște doar etichetele de intrare și de ieșire. Dar LSP încă există.

Acesta este un pic ca rutarea IP. Chiar dacă există o cale de la punctul A la punctul B, tabelul de rutare știe doar următorul hop către unde să trimită trafic. Dar diferența este că LSR-ul nu ia decizii cu privire la fiecare pachet pe baza adresei de destinație - calea este predeterminată.

Și unul dintre cele mai importante concepte pe care trebuie să le înțelegeți este FEC- Clasa de echivalență redirecționare . Din anumite motive mi-a fost foarte greu, deși în esență totul este simplu. FEC-urile sunt clase de trafic. În cel mai simplu caz, identificatorul clasei este prefixul adresei de destinație (în general, adresa IP sau subrețeaua destinației).
De exemplu, există fluxuri de trafic de la diferiți clienți și diferite aplicații care merg toate la o singură adresă - toate aceste fluxuri aparțin aceleiași clase - un FEC - folosesc un LSP.
Dacă luăm alte fluxuri de la alți clienți și aplicații la o adresă de destinație diferită, aceasta va fi o clasă diferită și, respectiv, un LSP diferit.

În teorie, pe lângă adresa de destinație, FEC poate lua în considerare, de exemplu, etichetele QoS, adresa sursă, ID VPN sau tipul de aplicație. Este important să înțelegeți aici că pachetele din același FEC nu trebuie să meargă la aceeași adresă de destinație. Și, în același timp, chiar dacă două pachete merg în același loc, nu vor aparține neapărat aceluiași FEC.

Voi explica de ce este nevoie de toate acestea. Faptul este că pentru fiecare FEC este selectat propriul LSP - propria sa cale prin rețeaua MPLS. Și apoi, de exemplu, pentru navigarea pe WEB setați o prioritate - va fi un FEC - și pentru VoIP - un alt FEC. Și mai departe puteți indica că pentru FEC BE LSP-ul trebuie să urmeze un drum larg, dar lung și negarantat, iar pentru FEC EF poate fi îngust, dar rapid.

Din păcate sau din fericire, dar acum doar un prefix IP poate acționa ca FEC. Lucruri precum marcajele QoS nu sunt luate în considerare.

Dacă acordați atenție tabelului de etichete, FEC este prezent acolo, deoarece parametrii de înlocuire a etichetei sunt determinați pe baza FEC, dar acest lucru se face doar în primul moment - când aceste etichete sunt distribuite. Când traficul real circulă de-a lungul LSP, nimeni, în afară de Ingress LSR, nu se uită la el - doar etichete și interfețe. Toată munca de determinare a FEC și la care LSP să trimită traficul este întreprinsă de Ingress LSR - după ce a primit un pachet curat, îl analizează, verifică cărei clase îi aparține și atașează eticheta corespunzătoare. Pachetele de la diferite FEC vor primi etichete diferite și vor fi trimise la interfețele corespunzătoare.
Pachetele de la același FEC primesc aceleași etichete.

Adică, LSR-urile intermediare sunt mașini de treierat care nu fac altceva decât să schimbe etichetele pentru tot traficul de tranzit. Și toată munca intelectuală este realizată de LSR-uri Ingress.

LIB- Baza de informații pe etichetă - tabel de etichete. Analog cu tabelul de rutare (RIB) în IP. Indică pentru fiecare etichetă de intrare ce trebuie făcut cu pachetul - schimbați eticheta sau eliminați-o și către ce interfață să-l trimiteți.
LFIB- Baza de informații de redirecționare a etichetelor - prin analogie cu FIB, aceasta este o bază de etichete care este accesată de procesorul de rețea. Când primiți un pachet nou, nu este nevoie să contactați CPU și să căutați tabelul de etichete - totul este deja la îndemână.

Una dintre ideile originale ale MPLS - de a separa cât mai mult posibil planul de control și planul de date - a dispărut în uitare.
Dezvoltatorii doreau să nu existe nicio analiză atunci când transmiteau un pachet printr-un router - pur și simplu au citit eticheta, au schimbat-o cu alta și au transmis-o la interfața dorită.
Pentru a realiza acest lucru, au existat două procese separate - o construcție a traseului relativ lungă (planul de control) și transmiterea rapidă a traficului de-a lungul acestei căi (planul de date)

Dar odată cu apariția cipurilor ieftine (ASIC, FPGA) și a mecanismului FIB, transmisia IP obișnuită a devenit, de asemenea, rapidă și ușoară.
Pentru un router, nu are nicio diferență unde să se uite atunci când se transmite un pachet - către FIB sau către LFIB.
Dar ceea ce este, fără îndoială, important și util este că MPLS este indiferent față de ceea ce se transmite sub titlul său - IP, Ethernet, ATM. Nu trebuie să vă deranjați cu GRE sau cu orice alt VPN dureros de incomod. Dar despre asta vom vorbi mai târziu.

Antet MPLS

Întregul antet MPLS este de 32 de biți. Formatul câmpului și lungimea sunt fixe. Adesea, întregul antet este numit etichetă, deși acest lucru nu este în întregime adevărat.

Eticheta - eticheta în sine. Lungime - 20 de biți.
TC - Clasa de trafic. Poartă prioritatea pachetului, ca și câmpul DSCP din IP.
Lungime 3 biți. Adică poate codifica 8 valori diferite.
De exemplu, atunci când un pachet IP este transmis printr-o rețea MPLS, valoarea din câmpul DSCP este atribuită într-un anumit mod valorii TC. Astfel, un pachet poate fi procesat aproape în mod egal în cozi de-a lungul întregii sale trasee, atât în ​​secțiunea IP pură, cât și în MPLS.
Dar, desigur, această conversie are pierderi - șase biți DSCP sunt înghesuiti în 3 biți TC: 64 față de 8. Prin urmare, există un tabel de corespondență special, în care întregul interval este doar o valoare.

Inițial, domeniul a fost numit EXP (experimental), iar conținutul său nu a fost reglementat. S-a presupus că ar putea fi folosit pentru cercetare și introducerea de noi funcționalități. Dar asta e în trecut.
Dacă cineva vă argumentează că acest domeniu este experimental și nu a fost aprobat oficial pentru funcția QoS, el nu bâjbâie, este destul de în urmă.

=====================

Rețeaua este configurată cu o politică QoS simplă în care pachetele IP care trec de la gazda 10.0.17.7 la adresa 6.6.6.6 sunt marcate și transmise prin rețeaua MPLS. Câmpul EXP este folosit pentru a marca pachetele, valoarea câmpului 3.

Sistem

Routerul R6 este configurat cu o politică QoS care clasifică pachetele pe baza câmpului EXP.
Dar, la verificare, s-a dovedit că politica nu funcționează pe R6. Adică, nu există pachete care sosesc cu o valoare EXP de 3 și toate pachetele se încadrează în clasa implicită.

Sarcină: Corectați configurația astfel încât politica de pe R6 să funcționeze.

Routerul R7 este folosit ca client. În consecință, MPLS între R7 și R1 nu este activat.

Sarcină și detalii de configurare.
=====================

S - Bottom of Stack - indicator al fundului stivei de etichete, lungime de 1 bit. Pot exista mai multe anteturi MPLS pe ​​un pachet, de exemplu, unul extern pentru comutarea în rețeaua MPLS și unul intern care indică o anumită VPN. Pentru ca LSR să înțeleagă cu ce are de-a face. „1” este scris în bitul S dacă aceasta este ultima etichetă (a fost atins partea de jos a stivei) și „0” dacă stiva conține mai multe etichete (nu încă partea de jos). Adică, LSR nu știe câte etichete sunt pe stivă, dar știe dacă există una sau mai multe - și acest lucru este de fapt suficient. La urma urmei, orice decizie se ia doar pe baza noului cel mai de sus, indiferent de ceea ce se află dedesubt. Dar, prin eliminarea etichetei, el știe deja ce să facă în continuare cu pachetul: să continue să lucrezi cu procesul MPLS sau să-l dai altuia (IP, Ethernet, ATM, FR etc.).

Această frază: „Dar prin eliminarea semnului, el știe deja ce să facă în continuare cu pachetul” - trebuie să se ofere o explicație. Antetul MPLS, după cum ați observat, nu conține informații despre conținut (cum ar fi Ethertype în Ethernet sau Protocol în IP).
Pe de o parte, acest lucru este bun - orice poate fi în interior - o flexibilitate mai mare, dar, pe de altă parte, cum puteți determina acum către ce proces să transferați toată această gestionare fără a analiza conținutul?
Si aici mic truc- routerul, după cum veți vedea mai târziu, își alocă întotdeauna eticheta în sine și o transmite vecinilor săi, astfel încât să știe de ce a alocat-o - pentru IP sau pentru Ethernet sau altceva. Deci pur și simplu adaugă aceste informații la tabelul său de etichete. Iar data viitoare când efectuează operația Pop Label, știe deja din masă (și nu din pachet) ce să facă în continuare.

În general, stiva de aici este în sensul clasic - last put, first taken (LIFO - Last Input - First Output).

Drept urmare, în ciuda faptului că lungimea antetului MPLS este fixă, pot exista multe antete în sine - și toate sunt situate unul după altul.

TTL - Time To Live - analog complet. Are chiar aceeași lungime - 8 biți. Singura sarcină este să împiedicați pachetul să rătăcească la nesfârșit prin rețea în cazul unei bucle. Când se transmite un pachet IP printr-o rețea MPLS, valoarea IP TTL poate fi copiată în MPLS TTL și apoi înapoi. Sau numărătoarea inversă va începe din nou de la 255, iar la intrarea într-o rețea IP pură, valoarea IP TTL va fi aceeași ca înainte de intrare.

După cum puteți vedea, antetul MPLS este strâns între stratul de legătură de date și datele pe care le transportă - în cazul IP - cea de rețea. Prin urmare, metaforic MPLS se numește tehnologie layer 2.5, iar antetul este Shim-header - wedge header.
Apropo, eticheta nu trebuie să fie în antetul MPLS. Conform deciziei IETF, acesta poate fi încorporat în anteturile ATM, AAL5, Frame Relay.

Iată cum arată în viața reală:

Spațiu de etichetă

După cum sa menționat mai sus, pot exista 2^20 de etichete.

Dintre acestea, mai multe sunt rezervate:

0 : Etichetă NULL explicită IPv4. „Etichetă explicită goală”. Este folosit chiar la ultimul hop MPLS - înainte de Egress LSR - pentru a-l notifica că această etichetă 0 poate fi eliminată fără să se uite la tabelul de etichete (mai precis LFIB).
Pentru acele FEC care provin local (conectate direct), Egress LSR alocă eticheta 0 și o transmite vecinilor săi - penultimul LSR (Penultimul LSR).
La transmiterea unui pachet de date, penultimul LSR schimbă eticheta curentă la 0.
Când Egress LSR primește un pachet, știe cu siguranță că eticheta de sus ar trebui pur și simplu eliminată.

Nu a fost întotdeauna așa. Inițial s-a propus ca eticheta 0 să fie doar în partea de jos a stivei de etichete și, atunci când se primește un pachet cu o astfel de etichetă, LSR-ul ar trebui să ștergă complet referințele la MPLS și să înceapă procesarea datelor.
La un moment dat, teoreticienii, sub presiunea practicienilor, au fost de acord că acest lucru este irațional și nu au putut veni cu o aplicație reală, așa că au abandonat ambele condiții.
Deci acum eticheta 0 nu este neapărat ultima (de jos) și în timpul operațiunii Pop Label doar aceasta este ștearsă, în timp ce cele inferioare rămân și pachetul este procesat în continuare în conformitate cu noua etichetă de sus.

1 : Eticheta Etichetă de alertă router- analog al opțiunii Router Alert în IP - poate fi oriunde, în afară de partea de jos a stivei. Când sosește un pachet cu o astfel de etichetă, acesta trebuie transferat în modulul local și apoi este comutat în conformitate cu eticheta de mai jos - cea de transport real, iar eticheta 1 trebuie adăugată din nou în partea de sus a stivei. .

2 : Etichetă NULL explicită IPv6- la fel ca 0, ajustat doar pentru versiunea de protocol IP.

3 : Nul implicit. O etichetă simulată care este utilizată pentru a optimiza procesul de transmitere a unui pachet MPLS către Egress LSR. Această etichetă poate fi promovată, dar nu este niciodată folosită în antetul MPLS. Să ne uităm la asta mai târziu.

4-15 : Rezervat.

În funcție de furnizor, alte valori ale etichetei pot fi fixate, de exemplu, pe echipamentele Huawei, etichetele 16-1023 sunt folosite pentru LSP-urile statice, iar tot ce este mai mare este folosit pentru LSP-urile dinamice. În Cisco, etichetele disponibile încep din data de 16.

În următoarea diagramă, toate routerele, cu excepția R5, sunt routere Huawei. R5 - Cisco.

Sistem

Pentru configurația routerului R5 de mai jos, trebuie să o configurați astfel încât distribuția valorii etichetei să se potrivească cu Huawei. Ideea este că în Huawei etichetele dinamice încep cu 1024, iar în Cisco cu 16.

Configurația R5

ip cef
!
interfață Loopback0

router ip isis
!
interfață FastEthernet0/0
descriere la R4

router ip isis
mpls ip
!
interfață FastEthernet0/1
descriere la R2

router ip isis
mpls ip
!
interfață FastEthernet1/0
descriere la R6

router ip isis
mpls ip
!
router isis
net 10.0000.0000.0005.00
!

Rapid, simplu, de înțeles, deși nu este întotdeauna necesar ca toată lumea să știe totul.

Al doilea mod - DoD- În aval la cerere . LSR-ul cunoaște FEC-ul, are vecini, dar până când aceștia întreabă care este eticheta pentru un anumit FEC, LSR-ul rămâne tăcut.

Această metodă este convenabilă atunci când anumite cerințe sunt impuse LSP-ului, de exemplu, în ceea ce privește lățimea de bandă. De ce să trimiteți o etichetă așa, dacă va fi imediat aruncată? Este mai bine ca LSR-ul din amonte să-l întrebe pe cel din aval: am nevoie de o etichetă de la tine pentru acest FEC - iar LSR-ul din amonte: „ok, aici mergem”.

Modul de alocare a etichetei este specific interfeței și este determinat în momentul stabilirii conexiunii. Ambele metode pot fi folosite într-o rețea, dar pe aceeași linie, vecinii trebuie să se pună de acord doar asupra uneia anume.

Control ordonat vs control independent

În al doilea rând, LSR-ul poate aștepta ca eticheta acestui FEC să sosească de la Egress LER înainte de a anunța vecinii săi din amonte. Sau ar putea trimite etichete pentru FEC de îndată ce a aflat despre asta.

Primul mod este numit Control comandat

Garantează că până la momentul transmiterii datelor, întreaga cale până la LER de ieșire va fi construită.

Al doilea mod - Control independent .

Adică etichetele sunt transmise în afara ordinului. Este convenabil deoarece traficul poate începe să fie transmis chiar înainte de construirea întregii trasee. Acesta este și motivul pentru care este periculos.

Modul liberal de păstrare a etichetei vs modul conservator de păstrare a etichetei

Al treilea Ceea ce contează este modul în care LSR gestionează etichetele transmise acestuia.
De exemplu, într-o astfel de situație, ar trebui R1 să stocheze informații despre eticheta 20 primită de la vecinul lui R3, care nu este cel mai bun mod ajunge la R6?

Și acest lucru este determinat de modul de păstrare a etichetelor.
Modul liberal de păstrare a etichetei - etichetele sunt salvate. În cazul în care R3 devine următorul pas (de exemplu, probleme cu calea principală), traficul va fi redirecționat mai devreme deoarece eticheta este deja acolo. Adică viteza de reacție este mai mare, dar și numărul de etichete folosite este mare.
Mod conservator de păstrare a etichetei - eticheta suplimentară este aruncată imediat ce este primită. Acest lucru reduce numărul de etichete utilizate, dar MPLS va răspunde și mai lent în cazul unui dezastru.

PHP

Nu, acesta nu este PHP-ul la care vă gândiți. Este despre Penultimul Hop Popping. Toți inginerii Puțin optimizatori și aici băieții s-au gândit: de ce trebuie să procesăm anteturile MPLS de două ori - mai întâi pe penultimul router, apoi din nou pe routerul de ieșire.
Și au decis că eticheta ar trebui să fie eliminată pe penultimul LSR și au numit această acțiune PHP.
Există o etichetă specială pentru PHP - 3.
Revenind la exemplul nostru, pentru FEC 6.6.6.6 și 172.16.0.2, R6 alocă eticheta 3 și o raportează la R5.
La transmiterea unui pachet către R6, R5 trebuie să îi atribuie o etichetă falsă - 3, dar de fapt nu este aplicată și un pachet IP gol este trimis către interfață (de remarcat că PHP funcționează doar pe rețele IP) - adică , procedura Pop Label a fost efectuată pe R5 .

Să urmărim durata de viață a pachetului, ținând cont de tot ce știm acum.

Modul de transmitere a traficului pare a fi mai mult sau mai puțin clar. Dar cine face toată munca titanică de a crea etichete și de a completa tabele?

Protocoale de distribuție a etichetelor

Nu sunt multe dintre ele - trei: LDP, RSVP-TE, MBGP.
Există două obiective globale - distribuirea etichetelor de transport și distribuirea etichetelor de serviciu.
Să explicăm: etichete de expediere sunt folosite pentru transmiterea traficului prin rețeaua MPLS. Acestea sunt exact cele despre care am tot vorbit pe parcursul acestui episod. Pentru ele sunt folosite LDP și RSVP-TE.

Marci de serviciu servi pentru separare diverse servicii. Aici intră în arenă MBGP și filiala LDP.
În special, MBGP permite, de exemplu, să se marcheze că un astfel de traseu aparține unui astfel de VPN. Apoi îi trece pe acest traseu ca familie vpn-ipv4 vecinului său cu o etichetă, pentru ca apoi să poată separa muștele de cotlet.
Deci, pentru ca el să se separe, trebuie să fie informat despre conformitatea etichetei-FEC.
Dar aceasta este acțiunea unei alte piese, pe care o vom juca peste alte șase luni sau un an.

O condiție prealabilă pentru funcționarea tuturor protocoalelor distributie dinamica etichetele este setare de bază conectivitate IP. Adică, IGP-urile trebuie să ruleze în rețea.

Ei bine, acum că te-am derutat complet, poți începe să te descurci.
Deci, care este cel mai simplu mod de a distribui etichetele? Răspunsul este să activați LDP.

LDP

Un protocol cu ​​un nume foarte transparent - Protocol de distribuție etichetat- are un principiu de funcționare corespunzător.
Să aruncăm o privire la asta pe rețeaua linkmeup, pe care am acoperit-o pe parcursul acestui episod:

1. După ce LDP este activat, LSR transmite datagramele UDP către toate interfețele către adresa 224.0.0.2 și portul 646, unde LDP este activat - așa sunt căutați vecinii.
TTL-ul unor astfel de pachete este 1 deoarece adiacența LDP este stabilită între nodurile conectate direct.

În general, nu este întotdeauna cazul - o sesiune LDP poate fi stabilită în anumite scopuri și cu un nod la distanță, atunci se numește tLDP -. Vom vorbi despre asta în alte numere.

Se numesc astfel de mesaje Buna ziua.

2. Când vecinii sunt detectați, se stabilește o conexiune TCP cu aceștia, tot pe portul 646 - Inițializare. Alte mesaje (cu excepția Hello) sunt transmise cu un TTL de 255.

3. LSR-urile schimbă acum mesaje periodic Ține în viață adresată prin TCP și tot nu renunțați să încercați să găsiți vecini folosind Hello.

4. La un moment dat, unul dintre LSR descoperă o a doua personalitate - Egress LSR - adică el este rezultatul pentru un FEC. Acesta este un fapt care trebuie comunicat lumii.
În funcție de mod, așteaptă o solicitare pentru o etichetă pentru un anumit FEC sau o trimite imediat.

Aceste informații sunt transmise într-un mesaj Mesaj de cartografiere a etichetei. Pe baza numelui, poartă corespondența dintre FEC și etichetă.

R5 primește informații despre conformitatea cu FEC 6.6.6.6/32 și eticheta 3 (null implicit) și le scrie în tabelul său de etichete. Acum, când trebuie să trimită date la 6.6.6.6, va ști să îndepărteze antetul MPLS de sus și să trimită pachetul rămas la interfața FE1/0.

Acum R5 știe că dacă sosește un pachet MPLS cu eticheta 20, acesta trebuie transmis către interfața FE1/0 prin eliminarea etichetei, adică prin executarea procedurii PHP.

R2 primește informații de la R5 despre conformitatea etichetei FEC (6.6.6.6 - 20), o introduce în tabel și, după ce a creat propria etichetă de intrare (18), o transmite și mai sus. Și așa mai departe până când toate LSR-urile și-au primit eticheta de ieșire.

Astfel, am construit un LSP de la R1 la R6. R1, când trimite un pachet la 6.6.6.6/32, îi adaugă eticheta 18 (Push Label) și îl trimite la portul FE0/0. R2, după ce a primit un pachet cu eticheta 18, schimbă eticheta la 20 (Swap Label) și o trimite la portul FE0/0. R5 vede ca pentru un pachet cu eticheta 20 este necesar sa se execute PHP (eticheta de iesire - 3 - implicit nul), sterge eticheta (Eticheta Pop) si trimite datele in portul FE1/0.

Totodată, au fost construite în paralel LSP-uri de la R2 la R6, de la R5 la R6, de la R4 la R6 etc. Adică din toate LSR-urile - pur și simplu nu l-am arătat în ilustrație.

Dacă aveți suficientă forță, atunci în gif-ul de mai jos puteți vedea întregul proces în dinamică.

Desigur, înțelegeți că nu numai R6 a început brusc să trimită potrivirile sale de etichete FEC, ci și toate celelalte - R1 despre 1.1.1.1/32, R2 - 2.2.2.2/32 etc. Toate aceste mesaje sunt transmise cu viteza fulgerului în rețeaua MPLS, construind zeci de LSP-uri. Ca rezultat, fiecare LSR va ști despre toate FEC-urile existente și va fi construit LSP-ul corespunzător.

Din nou, în gif-ul de mai sus, procesul nu este afișat complet, R1 transmite apoi informații către R3, R3 către R4, R4 către R5.
Și dacă ne uităm la R5, vedem că pentru FEC 6.6.6.6/32 nu avem o singură etichetă de ieșire, așa cum era de așteptat, ci 3:

Mai mult, R6 însuși va înregistra eticheta pentru FEC 6.6.6.6, pe care o primește de la R5:

In folosinta- corect - imp-nul spre R6. Dar celelalte două din inel sunt de la R2 și R4. Aceasta nu este o eroare sau o buclă - R2 și R4 au generat pur și simplu aceste etichete pentru tabelul de rutare FEC 6.6.6.6/32 pe care îl cunoșteau.

Apar două întrebări:
1) Cum plănuiește să le folosească? Sunt neștii. Răspuns: în niciun caz. Nu poate exista o situație în rețeaua noastră în care 2.2.2.2 sau 4.4.4.4 vor fi următoarele noduri în drum spre 6.6.6.6 - IGP nu va construi o rută ca asta. Aceasta înseamnă că etichetele nu vor fi folosite. LDP este pur și simplu prost - mesajele sale sunt împrăștiate în rețea, făcându-și loc în fiecare crăpătură. Și un LSR inteligent va decide deja pe care să îl folosească.
2) Dar buclele? Mesajele LDP nu vor călători prin rețea până la expirarea TTL?
Dar aici totul este simplu - primirea unui nou Label Mapping Message nu inițiază crearea unuia nou - corespondența rezultată este pur și simplu scrisă în tabelul LDP. Adică, în cazul nostru, R5 a venit deja cu o etichetă pentru FEC 6.6.6.6/32 o dată și a trimis-o vecinilor săi de nivel superior și nu se va schimba până când procesul LDP va reporni.

Poate ați observat deja că atunci când configurați LDP, este posibil să activați funcționalitatea de detectare a buclei, dar mă grăbesc să vă liniștesc - aceasta este pentru rețelele în care nu există TTL, de exemplu, ATM. Această funcționalitate va comuta LDP în modul DoD.

Acestea sunt informații de bază despre cum funcționează LDP.
De fapt, totul aici depinde foarte mult de producător. În principiu, LDP acceptă toate modurile posibile de lucru cu etichete: DoD/DU, Independent Control/Ordered Control și Conservative/Liberal Label Retention. Acest lucru nu este reglementat în niciun fel de RFC, astfel încât fiecare furnizor este liber să-și aleagă propria cale.
De exemplu, practic toată lumea folosește DU pentru LDP, dar în Juniper etichetele sunt distribuite ordonat, iar în Cisco sunt distribuite independent.
Doar interfețele LSR Loopback sunt selectate ca FEC în Huawei și Juniper, în timp ce Cisco FEC este creat pentru toate intrările din tabelul de rutare.

Dar este puțin probabil ca toate acestea să aibă vreun impact asupra rețelei reale.

Cel mai important lucru de înțeles despre LDP este că nu utilizează protocoale în funcționarea sa. rutare dinamică- dupa principiul de functionare, este asemanator cu: inunda intreaga retea cu etichete, dar in acelasi timp se bazeaza pe informatiile din tabelul de rutare LSR. Și dacă R1 primește două etichete pentru același FEC de la vecini diferiți, atunci va selecta pentru LSP doar pe cea primită prin cea mai bună interfață înainte de acest FEC conform informațiilor din TM.
Aceasta înseamnă trei lucruri:

• Sunteți liber să alegeți IGP-ul care vă place cel mai mult, chiar și RIP.
• LDP construiește întotdeauna o singură rută (cea mai bună) și nu poate construi, de exemplu, una de rezervă.
• Când topologia rețelei se schimbă, LSP-ul va fi reconstruit în conformitate cu tabelul de rutare actualizat, adică IGP-ul trebuie mai întâi să convergă și abia apoi LSP-ul va crește.

În general, după activarea LDP, traficul va curge la fel ca și fără acesta, singura diferență fiind că apar etichetele MPLS.
Inclusiv LDP, cum ar fi IP, acceptă , este doar că algoritmii de calcul hash și, prin urmare, echilibrarea, pot diferi.

Pentru a activa MPLS la nivel global, trebuie să lansați două comenzi:
R1(config)#ip cef
R1(config)#mpls ip
Primul este deja un standard de facto și de jure pe aproape orice echipament de rețea - lansează mecanismul CEF pe router, al doilea pornește MPLS și LDP la nivel global (poate fi și dat implicit).

ID-ul routerului (și mai general (non-Cisco) terminologia LSR ID) în MPLS este selectat simplu:

1. Cea mai mare adresă a interfețelor Loopback
2. Dacă nu sunt acolo, atunci cea mai mare adresă IP configurată pe router.

Desigur, nu ar trebui să aveți încredere în automatizare - să configurați manual ID-ul LSR:
R1(config)# mpls ldp router-id Loopback0 force
Dacă nu adăugați un cuvânt cheie "forta", ID-ul routerului se va schimba numai atunci când sesiunea LDP este restabilită. "Forta" forțează ruterul să schimbe ID-ul routerului cu forța și, dacă este necesar (dacă s-a schimbat), restabilește conexiunea LDP.

Apoi, pe interfețele necesare lansăm comanda mpls ip:
R1(config)#interfață FastEthernet 0/0
R1(config-if)#mpls ip
R1(config)#interfață FastEthernet 0/1
R1(config-if)#mpls ip
Cisco folosește din nou principiul său de inginer leneș - efort minim din partea personalului. Echipă mpls ip permite LDP pe interfață simultan cu MPLS, indiferent dacă vrem sau nu. La fel și echipa ip pim sparse-mode activează IGMP pe interfață, așa cum am descris în articolul despre .
După activarea LDP, routerul începe să testeze apele prin UDP:

Verificatorii sunt trimisi la adresa multicast 224.0.0.2.

Acum repetăm ​​toate aceleași manipulări pe R2
R2(config)#ip cef
R2(config)#mpls ip
R2(config)# mpls ldp router-id Loopback0 force
R2(config)#interfață FastEthernet 0/0
R2(config-if)#mpls ip
R2(config)#interfață FastEthernet 0/1
R2(config-if)#mpls ip
și bucurați-vă de rezultat.
R2 cauta si vecini.

Am aflat unul despre celălalt, iar R2 deschide o sesiune LDP:

Dacă vă întrebați cum stabilesc o conexiune TCP

Acum sunt vecini, lucru ușor de verificat de echipă arata vecinul mpls ldp.

Aici puteți vedea deja detaliile - R1 transmite 12 FEC-uri simultan - câte unul pentru fiecare intrare din tabelul său de rutare. În aceeași situație, Huawei sau Juniper ar transmite doar șase adrese FEC ale interfețelor Loopback, deoarece în mod implicit contează doar /32 prefixe ca FEC.
În acest sens, Cisco este foarte risipitor în utilizarea resurselor etichetelor.
Cu toate acestea, acest comportament poate fi schimbat pe orice hardware. În cazul nostru, echipa poate ajuta mpls ldp advertise-labels.

Dar cum este posibil acest lucru, vă întrebați? Este suficient să aveți etichete doar în Loopback?

Dacă ne amintim că am considerat la începutul articolului că prefixele BGP nu primesc propriile etichete și că etichetele sunt necesare doar pentru next-hop, atunci devine clar că etichetele pentru Loopback sunt destul de suficiente.

Pentru a ajunge la alte rețele din AS-ul nostru, avem nevoie doar de un IGP.

=====================

Dacă Cisco în mod implicit face publicitate etichetelor pentru toate rețelele (cu excepția celor primite prin BGP), atunci în Juniper, în mod implicit, este anunțat numai loopback.

Sistem

Toate routerele, cu excepția R5, sunt routere Juniper.

Pentru configurația routerului R5 de mai jos, configurați-o astfel încât setările routerului Cisco să se potrivească cu setările implicite din Juniper.

Configurația R5

ip cef
!
interfață Loopback0
adresa ip 5.5.5.5 255.255.255.255
router ip isis
!
interfață FastEthernet0/0
descriere la R4
adresa ip 10.0.45.5 255.255.255.0
router ip isis
mpls ip
!
interfață FastEthernet0/1
descriere la R2
adresa ip 10.0.25.5 255.255.255.0
router ip isis
mpls ip
!
interfață FastEthernet1/0
descriere la R6
adresa ip 10.0.56.5 255.255.255.0
router ip isis
mpls ip
!
router isis
net 10.0000.0000.0005.00
!
mpls ldp router-id Loopback0 force

Și după aceea, să ne uităm din nou la tabelul de comutare MPLS activat R1:

Etichetele au apărut deja pentru toate FEC-urile.
Să mergem de-a lungul LSP de la R1 la R6 și să vedem cum se schimbă etichetele pe parcurs

Mijloace
1. Când R1 21 Fa0/0și schimbați eticheta în 18 .
2. Când R2 primește un pachet MPLS cu o etichetă 18 , ar trebui să-l transmită interfeței Fa0/0și schimbați eticheta în 20 .
3. Când R5 primește un pachet MPLS cu o etichetă 20 , ar trebui să-l transmită interfeței Fa1/0și scoateți semnul - PHP.

În acest caz, LSR-urile nici măcar nu se gândesc să se uite la nimic din tabelul de rutare sau ip cef - ei doar jonglează cu etichetele.

Tabelul de comutare, pe care ne-am uitat deja cu comanda arată tabelul de redirecționare mpls- Acest LFIB (Baza de informații de redirecționare a etichetei ) - aproape truism pentru transferul de date - acesta este Data Plane. Dar ce zici de Control Plane? E puțin probabil ca LDP să știe atât de multe? Cu siguranță mai are niște atuuri în mânecă?
Asta este adevărat:

Pentru fiecare FEC vedem aici informații despre diverse etichete:
legarea locală- ce transmite acest LSR vecinilor?
legarea la distanță- ce a primit acest LSR de la vecini.

În ilustrația de mai sus puteți vedea cuvântul „tib”. TIB este Baza de informații pentru etichete , care se numește corect Label Information Base - LIB.
Aceasta este o relicvă a strămoșului decedat al LDP.

Vă rugăm să rețineți că peste tot există 2 legături la distanță - acestea sunt două moduri de a obține etichete. De exemplu, puteți ajunge la R2 de la R1 direct sau prin R3-R4-R5-R2.
Adică înțelegi, nu? Nu numai că face FEC din fiecare intrare din tabelul de rutare, dar acest ticălos folosește și Modul Liberal Retention pentru a păstra etichetele.
Să rezumam: în mod implicit, LDP în Cisco operează în următoarele moduri:

• Control independent
• Modul de reținere liberală
• Toate intrările din tabelul de rutare sunt selectate ca FEC

Pe scurt, generozitatea lui nu are limite.

Există o altă echipă afișează legarea ip mpls. Arată ceva similar și, de asemenea, vă permite să aflați rapid care cale este activă în prezent, adică cum este construit LSP-ul:

Și ultima întrebare, probabil, care apare în legătură cu toate aceste LSP-uri este când routerul în sine este un LSR de intrare, cum înțelege el ce trebuie făcut cu pachetele, cum să aleagă un LSP?
Și pentru asta va trebui să te uiți la IP CEF. În general, Ingress LSR este cel care poartă întreaga sarcină de procesare a pachetului, determinând FEC și atribuind etichetele corecte.

Aici aveți Next Hop și interfața de ieșire și eticheta de ieșire

Și aici ar trebui să observați că în LDP conceptele de LER, Ingress LSR, Egress LSR nu sunt rolul niciunui nod specific sau o caracteristică a locației unui nod în rețea. Ele sunt inseparabile de FEC și LSP și sunt individuale pentru ei. Adică, pentru fiecare FEC specific există unul sau mai multe LSR-uri de ieșire și multe LSR-uri de intrare (de obicei toate routerele) la care conduc LSP-urile.
Să spunem chiar că conceptele de LER apar atunci când vorbim despre un anumit LSP, atunci putem spune cine este Ingress și cine este Egress.

MPLS și BGP

Până acum am vorbit despre modul în care MPLS interacționează cu protocoalele IGP. Ne-am asigurat că nu este nimic complicat și că setările sunt, de asemenea, destul de simple.

Dar cel mai interesant lucru constă în interacțiunea MPLS cu BGP. În acest număr vom aborda doar pe scurt acest subiect. Dar în următoarele, vom vorbi mai mult despre ce rol joacă BGP și despre cum cu ajutorul acestuia și MPLS putem organiza diferite tipuri de VPN-uri.
Acum trebuie să înțelegem cum interacționează MPLS și BGP la cel mai elementar nivel.

Principala diferență dintre BGP și IGP este că MPLS nu creează etichete pentru rutele BGP. Dacă vă amintiți câte rute transportă BGP, devine clar că acest lucru este foarte bună idee. Cum se conectează apoi MPLS și BGP?
E simplu:

1. creăm etichete numai pentru adresele care vor fi indicate ca next-hop pentru rutele pe care le primim prin BGP (aici nu trebuie să uităm de next-hop-self pentru vecinii IBGP).
2. Când LSR-ul nostru de intrare trebuie să transmită pachete de-a lungul rutei care a fost primită prin BGP, le trimitem la următorul hop care este specificat în rută și folosim eticheta care a fost creată pentru acesta.

Acum, în loc să configuram BGP pe fiecare router din AS-ul nostru, îl putem configura numai pe routerele edge la care sunt conectați clienții sau alți furnizori.

Să ne uităm la un exemplu de rețea:

Dacă trebuie să ajungem de la R1 la rețelele Filkin Certificate, vedem că acestea sunt accesibile prin R6 și „zboară” prin MPLS la adresa 6.6.6.6. Și când ajungem la R6, el știe deja unde să meargă în continuare. La fel se va întâmpla și invers, în Balagan-Telecom.

Configurația pentru acest circuit și câteva comenzi cu ieșire de informații pot fi găsite la link.

MPLS și OSPF sunt configurate în rețea. MPLS este configurat în întreaga rețea, cu excepția conexiunii dintre R7 și R1.
Între routerele R1-R2-R3-R4-R5-R6, traficul trebuie transmis folosind MPLS.
Rețeaua este, de asemenea, configurată cu BGP, care rulează între R1 și R6.

Nu sunt generate etichete pentru rutele BGP.
Pentru ca R1 să ajungă la rutele care sunt primite prin BGP de la R6, pachetele sunt transmise prin MPLS la adresa IP care este specificată ca următorul hop în rutele BGP.

În prezent, ruta promovată prin BGP de routerul R6 nu este disponibilă de la R7.

Exercițiu:
Restabiliți funcționarea în rețea, astfel încât R7 să poată ping adresa 100.0.0.1.

Restrictii:
Setările BGP nu pot fi modificate.

Sistem

Detalii despre sarcina și configurația nodului.
=====================

RSVP-TE

LDP este bun. Funcționează simplu și clar. Dar există o astfel de tehnologie precum MPLS TE - Traffic Engineering. Și cel mai bun traseu pe care îl poate oferi LDP nu este suficient pentru ea.
Direcția traficului înseamnă că puteți direcționa traficul între noduri după cum doriți, sub rezerva diferitelor restricții.
De exemplu, în rețeaua noastră, clientul are două puncte de conectare pentru nodurile sale - pe R1 și pe R6. Și între ei cere un VPN cu o lățime de canal garantată de 100 Mb/s. Dar, în același timp, în rețeaua noastră avem și utilizatori obișnuiți de bandă largă care transmit videoclipuri de la VKontakte și alți o duzină de clienți care închiriază VPN-uri, dar nu trebuie să rezerve lățimea de bandă.
Dacă nu interviți în această situație, poate apărea o supraîncărcare undeva pe R2, iar 100 Mb/s nu vor fi disponibile pentru un client scump.

MPLS TE vă permite să traversați întreaga rețea de la expeditor la receptor și să rezervați resurse la fiecare nod. Dacă sunteți familiarizat cu conceptul de IntServ, atunci da, exact asta este - oferind QoS de-a lungul întregii căi, mai degrabă decât lăsați fiecare router să ia propriile decizii cu privire la pachetul care trece.
De fapt, protocolul RSVP (Protocolul de rezervare a resurselor ) inițial (în 1993) și a fost conceput pentru a organiza IntServ în rețele IP. A trebuit să transmită informații QoS pentru un anumit flux de date către fiecare nod și să-l forțeze să rezerve resurse.

La o primă aproximare, funcționează simplu.

1) Nodul sursă dorește să trimită un flux de date cu o viteză de 5 Mb/s. Dar înainte de asta, trimite o cerere RSVP pentru a rezerva lățimea de bandă destinatarului - Mesaj de cale. Acest mesaj conține anumiți identificatori de flux, prin care nodul poate identifica apoi apartenența pachetelor IP primite la flux și lățimea de bandă necesară.
2) Mesajul Path este transmis de la nod la nod la destinatar. Unde se trimite este determinat pe baza tabelului de rutare.
3) Fiecare router, după ce a primit Calea, își verifică resursele. Dacă are suficientă lățime de bandă liberă, își ajustează algoritmii interni astfel încât pachetele fluxului să fie procesate corect și să existe întotdeauna suficient debit.
4) Dacă nu are cei 5 Mb/s necesari (ocupați de alte fire), refuză să aloce resurse și returnează expeditorului un mesaj corespunzător.
5) Pachetul Path ajunge la destinatarul fluxului, care trimite înapoi un mesaj Resv, confirmând alocarea resurselor de-a lungul întregului traseu.
6) Expeditorul inițial, după ce a primit Resv, înțelege că totul este gata pentru el și poate trimite date.

De fapt, sub aceste patru în pași simpli Procese mult mai complexe mint, dar nu ne interesează asta.

Dar ceea ce ne interesează este extinderea RSVP pentru Inginerie Trafic, sau mai simplu - RSVP TE, care a fost dezvoltat special pentru MPLS TE.
Sarcina sa este aceeași cu cea a LDP - de a distribui etichete între LSR-uri și, în cele din urmă, de a compila LSP-ul de la destinatar la expeditor. Dar acum, după cum ați înțeles deja, apar nuanțe - LSP trebuie să îndeplinească anumite condiții.

RSVP TE vă permite să construiți un LSP primar și de rezervă, să rezervați resurse pe toate nodurile, să detectați defecțiunile rețelei, să construiți soluții alternative, să redirecționați rapid traficul și să evitați canalele care trec fizic pe o singură cale.
Dar vom discuta toate acestea într-un articol despre MPLS TE în câteva numere. Astăzi ne vom concentra asupra principiilor după care RSVP TE construiește un LSP.

Schimbarea protocolului nu schimbă faptul că LSP-ul este unidirecțional și, în consecință, resursele vor fi rezervate doar într-o singură direcție. Dacă doriți altceva, creați un LSP invers.

Pentru început, vom renunța la funcționalitatea de rezervare a resurselor - lasă ca sarcina noastră să fie doar să creăm un LSP, adică să distribuim etichete între LSR-uri.

Pentru a face acest lucru posibil, RSVP standard este extins pentru a include mai multe obiecte. Să luăm în considerare cea mai simplă opțiune.
0) R1 necesită LSP până la FEC 6.6.6.6/32. Aceasta arată ca o interfață Tunnel pe R1 cu o adresă de destinație de 6.6.6.6 și tip Traffic Engineering.
1) Trimite un mesaj RSVP Path în direcția 6.6.6.6. Un obiect nou apare în acest mesaj - Solicitare etichetă. Mesajul Path determină nodul să aloce o etichetă pentru un anumit FEC - adică este o cerere de etichetă.
2) Următorul nod generează un nou mesaj Path și, de asemenea, îl trimite către 6.6.6.6. etc.
3) Calea ajunge la Egress LSR. El vede că pachetul îi este adresat, selectează o etichetă și trimite un mesaj Resv la sursă. Acesta din urmă a adăugat și un nou obiect - Eticheta. În el, Egress LSR își trece eticheta pentru acest FEC penultimului, penultimul își trece eticheta penultimului etc.
4) Resv ajunge la sursă, distribuind etichete pe parcurs. Acest lucru creează LSP-ul și anunță sursa că totul este gata.

Etichetele sunt solicitate în aval (Mesajul de cale de la expeditor la receptor) și transmise în amonte (mesaj Resv de la receptor la expeditor).
În același timp, vă rugăm să rețineți că acesta este deja cel mai în aval la cerere + control comandat. Calea acționează ca o cerere de etichetă, iar Resv vine de la destinatar pas cu pas, iar până când LSR-ul din aval nu a trimis eticheta, LSR-ul din amonte nu o poate trimite vecinilor săi.

Stop! Am spus că RSVP TE, spre deosebire de LDP, ne permite să construim așa cum ne dorim, fără a fi legați de tabelul de rutare și IGP, dar aici deocamdată este doar „în direcția 6.6.6.6”.
Și aici ne apropiem de diferența fundamentală dintre RSVP TE și LDP. RSVP TE este foarte strâns legat de protocoalele de rutare dinamică, nu se bazează doar pe rezultatele muncii lor - le adaptează pentru sine, le exploatează în sensul literal al cuvântului.
in primul rand, sunt potrivite doar protocoalele bazate pe algoritmi de stare de legătură, adică OSPF și ISIS.
În al doilea rând, OSPF și ISIS sunt extinse prin introducerea de noi elemente în protocoale. Așa apare un nou tip în OSPF LSA - LSA opac, iar în ISIS - nou TLV este vecinȘi Accesibilitate IP.
Al treilea, pentru a calcula calea dintre Ingress LSR și Egress LSR, se utilizează o modificare specială a algoritmului SPF - CSPF ( Calea cea mai scurtă constrânsă mai întâi).

Acum mai multe detalii.

Mesajul Path este, în principiu, trimis de Unicast în funcție de adresă. Adică adresa expeditorului său este R1, iar adresa destinatarului său este 6.6.6.6. Și ar fi putut ajunge pur și simplu prin tabelul de rutare.

Dar, de fapt, Calea este transmisă prin rețea nu ca FIB pe cap de locuitor pe fiecare nod, deoarece atunci nu vom putea oferi nici rezervare, nici căutarea rutelor de rezervă. Nu, el urmează o anumită cale.
Această cale este determinată pe Ingress LSR cu precizie nod cu nod.
Pentru a construi această cale, TE RSVP trebuie să cunoască topologia rețelei. Înțelegi la ce ne apropiem? RSVP în sine nu se deranjează să o studieze și de ce ar trebui să o facă atunci când poate fi obținută de la OSPF sau ISIS. Și devine imediat evident de ce RIP, IGRP și EIGRP nu sunt potrivite aici - la urma urmei, ei nu studiază topologia, maximul de care sunt capabili este Feasible Successor.
Dar algoritmul clasic SPF are o topologie de rețea la intrare, iar la ieșire poate produce doar cea mai rapidă rută ținând cont de metrici și , deși poate calcula toate căile posibile.
Și aici intervine CSPF. Acest algoritm este cel care poate calcula cel mai bun mod, a doua cale prioritară și, de exemplu, o altă cale de rezervă pentru a ajunge cumva acolo, chiar dacă .
Adică, un TE RSVP poate cere CSPF să calculeze o cale pentru el între două noduri.
Ei bine, bine, dar de ce să schimb protocoalele IGP în sine pentru asta? Wow. Și acestea sunt Constrângeri - restricții. RSVP TE poate avea cerințe de cale - lățime de bandă, lățime minimă disponibilă, tip de linie sau chiar nodurile prin care trebuie să treacă LSP. Deci, pentru ca CSPF să țină cont de restricții, trebuie să cunoască despre acestea și despre resursele disponibile pe nodurile din întreaga rețea. Datele de intrare pentru acesta sunt restricțiile specificate în tunel și topologia rețelei - ar fi logic ca topologia să conțină, pe lângă prefixe și metrici, și informații despre resursele disponibile.
În acest scop, routerele schimbă între ele prin mesaje OSPF și ISIS nu numai informații de bază, ci și caracteristici ale liniilor, interfețelor etc. Tocmai în noile tipuri de mesaje sunt transmise aceste informații.
De exemplu, OSPF a introdus 3 tipuri suplimentare de LSA pentru aceasta:

• Tip 9- domeniul de aplicare local-link
• Tip 10- zonă-sfera locală
• Tip 11- Domeniul AS

Opac înseamnă opac (pentru OSPF). Acestea sunt tipuri speciale de LSA care nu sunt luate în considerare în niciun fel de OSPF însuși atunci când calculează tabelul de rutare. Ele pot fi folosite de orice alte protocoale pentru propriile nevoi. Deci TE le folosește pentru a-și construi topologia (se numește TED - Baza de date de inginerie a traficului ). Dar, teoretic, nu sunt alocate TE - dacă scrieți propria dvs. aplicație pentru routere, care va necesita schimbul de informații despre topologie, puteți utiliza și Opaque LSA.
ISIS funcționează în același mod. Mesaje noi: IS-IS TLV 22 (Extended IS Reachability), 134 (Traffic Engineering Router ID), 135 (Extended IP Reachability).

Deci, să aruncăm o privire mai detaliată asupra întregului proces.

0) Pe R1 am activat MPLS TE și am configurat ISIS (OSPF) pentru a transporta date pentru a sprijini TE. Routerele au schimbat informații despre resursele disponibile. În acest pas, se formează TED. RSVP este tăcut.

1) Am creat o interfață de tunel, unde am indicat tipul acesteia (Inginerie de trafic), adresa de destinație (6.6.6.6) și cerințele de resurse necesare. LSR rulează CSPF: trebuie să calculeze calea cea mai scurtă de la R1 la 6.6.6.6, ținând cont de condițiile impuse. La acest pas, obținem calea optimă - o listă de noduri de la sursă la destinație (R2, R5, R6).

2) Rezultatul pasului anterior este transmis la RSVP și transformat într-un obiect ERO. R1 compilează RSPV Path, unde adaugă în mod natural ERO. Destinația pachetului este 6.6.6.6. În plus, există și un obiect Label Request, care indică faptul că atunci când se primește un pachet, trebuie alocată o etichetă pentru acest FEC (6.6.6.6/32).

ERO - Obiect traseu explicit- obiect special mesaj RSVP Path. Conține o listă de noduri prin care acest mesaj este destinat să treacă.

3) Mesajul RSVP Path este transmis într-un mod special - nu conform tabelului de rutare, ci conform listei ERO. În cazul nostru cel mai bun traseu IGP și ERO se potrivesc, deci pachetul este trimis la R2.

4) R2, după ce a primit Calea RSVP, verifică prezența resurselor necesare și, dacă acestea există, alocă o etichetă MPLS pentru FEC 6.6.6.6/32. Vechiul pachet Path este distrus și este creat unul nou, iar obiectul ERO este schimbat - R2 însuși este eliminat din acesta. Acest lucru se face astfel încât următorul nod să nu încerce să returneze pachetul la R2. Adică noul ERO arată deja așa: (R5, R6). În conformitate cu acesta, R2 trimite Calea actualizată către R5.

5) R5 efectuează operații similare: verifică resurse, alocă o etichetă, se îndepărtează singur din ERO, recreează pachetul Path și îl transferă pe interfața prin care cunoaște următorul obiect ERO - R6.

6) R6, după ce a primit coletul, își dă seama că el este vinovat de toată zarva. Distruge Calea, alocă eticheta pentru FEC 6.6.6.6 și o inserează ca obiect Etichetaîn mesajul de răspuns Resv.
Rețineți că înainte de acest pas, etichetele erau doar alocate, dar nu distribuite, dar acum încep să fie făcute publicitate către LSR-urile care le-au solicitat.
7) Mesajul RESV avansează la R1 (Ingress LSR), lăsând în urmă o coadă în creștere a LSP. Resv trebuie să treacă prin aceleași noduri ca Path, dar în ordine inversă.

8) În cele din urmă, LSP-ul de la R1 la 6.6.6.6 este finalizat. Datele pot fi transferate doar de la R1 la R6. Pentru a permite transferul de date în direcția opusă, trebuie să creați o interfață de tunel pe R6 cu o adresă de destinație de 1.1.1.1 - toate acțiunile vor fi exact aceleași.

Se pune întrebarea - de ce este destinația pachetului Calea 6.6.6.6, dacă este transmis nod cu nod și sunt cunoscute adresele acestora? Această întrebare nu este inactivă - ne conduce la o caracteristică importantă. Este posibil ca obiectul ERO să nu conțină de fapt toate nodurile de la Ingress LSR la Egress LSR - unele pot fi omise. Prin urmare, fiecare LSR trebuie să știe unde este în cele din urmă direcționat mesajul. Și acest lucru se poate întâmpla nu pentru că Ingress LSR este prea leneș pentru a calcula întreaga cale.
Problema este în zonele IGP. Știți că atât OSPF, cât și ISIS au acest concept pentru a simplifica rutarea. În rețelele mari (sute și mii de noduri), apare problema difuzării pachetelor de servicii și calculării unui număr mare de combinații folosind algoritmul SPF. Prin urmare, un domeniu global este împărțit în zone de rutare.
Și întreaga captură este că, dacă în interiorul zonei IGP este un protocol de stare de legătură, atunci între ele este un vector de distanță reală - topologia rețelei este construită numai în interiorul zonei, orice router intern nu știu cum sunt aranjate alte zone - sunt informați doar că, pentru a intra într-o anumită rețea, trebuie să trimită pachete către una anume.
Cu alte cuvinte, dacă rețeaua dvs. este împărțită în zone, atunci apar dificultăți cu MPLS TE - CSPF nu poate calcula întreaga cale, deoarece în topologia sa, destinatarul dintr-o altă zonă este un nor, și nu un nod specific.

Și iată că vine în ajutor Calea explicită(a nu se confunda cu obiectul ERO). Acesta este cel mai direct mod de a gestiona construcția unui LSP - administratorul poate seta independent și explicit nodurile prin care LSP-ul trebuie direcționat. Ingress LSR trebuie să urmeze exact astfel de instrucțiuni. Acest lucru adaugă puțin mai multă varietate vieții algoritmului CSPF.
Cum ajută Calea explicită să străpungă o zonă? Să folosim un exemplu.

Vom lua și indica că trebuie să existe puncte intermediare:
Cale explicită: R1, R3, R5.

Când alimentăm această cale explicită către CSPF, ea construiește piesa pe care o poate, adică în Zona 0: de la R1 la R3.
Ceea ce a numărat este introdus în ERO, plus un alt nod din Explicit-path - R5 - i se adaugă. Rezultă: R1, R2, R3. Calea este trimisă prin rețea conform ERO și ajunge la R3. El vede că, în general, nu este o destinație, ci doar un punct de transfer, ia condițiile specificate pentru resursele necesare și adresa nodului destinatar din Explicit-path și lansează CSPF. Acestea din urmă probleme lista plina noduri către destinație (R3, R4, R5), care este convertită în ERO, iar apoi totul se întâmplă conform scenariului standard.
Adică, dacă Ingress LSR și Egress LSR sunt în zone diferite, calculul traseului este efectuat separat pentru fiecare zonă, iar punctul de referință este ABR.

Trebuie înțeles că Calea explicită este folosită nu numai pentru acest caz, dar este în general un instrument convenabil, deoarece puteți indica în mod explicit cum ar trebui direcționat LSP-ul sau, dimpotrivă, prin ce noduri nu ar trebui direcționat LSP-ul.
Vom atinge acest lucru și multe altele în detaliu în numărul dedicat MPLS TE.

S-ar putea să fiu acuzat că sunt necinstit, spunând că Link-State IGP nu este atât de obligatoriu. Ei bine, vreau să rulez EIGRP pe o rețea cu o singură decizie, dar nu am puterea. Sau chiar îndemnurile necrofile te obligă să dezgropi RIP. Deci ce acum? Renunță la TE?
În general, există salvare, dar numai pe echipamentele Cisco - se numește Verbatim.

La urma urmei, de ce avem nevoie de protocolul Link-State? Acesta colectează informații de topologie TE și CSPF construiește o cale de la Ingress LSR la Egress LSR. Soooo. Grozav. Ce se întâmplă dacă luăm și inventăm o cale explicită, unde listăm toate nodurile unul câte unul? La urma urmei, atunci nu trebuie să numeri nimic.
De fapt, indiferent cât de detaliată ai face calea explicită, aceasta va fi totuși transmisă la CSPF.
Dar acest comportament poate fi dezactivat. Doar pentru cazurile descrise mai sus.
Următoarea comandă va ajuta:
Router(config-if)# tunel mpls trafic-eng cale-opțiune 1 nume explicit Test pe cuvânt

Adică, această cale va fi considerată în mod evident corectă fără verificări și recalculări ale CSPF.
Acest scenariu este foarte discutabil, iar avantajele sale sunt foarte evazive. Cu toate acestea, există o oportunitate și nu spune mai târziu că nu ți-am spus despre asta.

RSVP TE Practică

Echipă mpls ip aveam nevoie ca LDP să funcționeze. Acum nu mai este nevoie de el - îl ștergem și începem de la zero.
Acum avem nevoie mpls trafic-eng tuneluri. La nivel global, include suport pentru tunelurile TE și RSVP TE în sine:
R1(config)#mpls trafic-eng tuneluri
De asemenea, trebuie să activați același lucru pe interfețe:

R1(config)# interfață FastEthernet 0/0
R1(config-if)# mpls trafic-eng tuneluri
R1(config)# interfață FastEthernet 0/1
R1(config-if)# mpls trafic-eng tuneluri
Încă nu se întâmplă nimic. RSVP este tăcut.

Vom extinde acum IGP pentru a transporta date TE. În exemplul nostru folosim ISIS:
R1(config)#router isis
R1 (config-router) # lat în stil metric

R1(config-router)# mpls trafic-eng level-2

Este necesar să activați modul etichete extinse, altfel TE nu va funcționa.
Setați LSR-ID, așa cum am făcut în LDP,
Este necesar să setați un anumit nivel ISIS, altfel TE nu va funcționa.

Dacă dintr-o dată utilizați OSPF

R1 (config-router) # mpls trafic-eng zona 0
R1 (config-router) # mpls trafic-eng router-id Loopback0

Acești pași trebuie repetați pe alte routere.

Imediat după aceasta, ISIS începe să facă schimb de informații despre TE:

După cum puteți vedea, sunt transmise informații despre LSR-ID, informații extinse despre vecini (care acceptă TE) și informații extinse despre interfețe.

În această etapă, a fost format TED.

Puteți vedea topologia în sine în ISIS: #show isis database verbose

RSVP este tăcut deocamdată.

Acum, să instalăm un tunel TE.
R1(config)# interfață Tunnel1
R1(config-if)# ip nenumerotat Loopback0
R1(config-if)# destinație tunel 6.6.6.6
R1(config-if)# mod tunel mpls trafic-ing
R1(config-if)# tunel mpls trafic-eng cale-opțiune 10 dinamic
Interfețele tunel sunt un lucru foarte universal pe routere. Ele pot fi folosite pentru L2TP, GRE, IPIP și, după cum puteți vedea, pentru MPLS TE.
ip nenumerotat Loopback0înseamnă că punctul de pornire al tunelului ar trebui să fie adresa interfeței Loopback0.
destinația tunelului 6.6.6.6- o comandă universală pentru interfețele tunelului, determină punctul de terminare, capătul tunelului.
modul tunel mpls trafic-ing- setează tipul. Aici se determină algoritmul de funcționare a tunelului și modul de construire al acestuia.
tunel mpls trafic-eng cale-opțiune 10 dinamic- această comandă permite CSPF să construiască o cale dinamic, fără a specifica noduri intermediare.

Dacă ați făcut totul corect înainte, interfața tunelului ar trebui să urce:
%LINEPROTO-5-UPDOWN: Protocol de linie pe Interface Tunnel1, starea schimbată în sus

Ce s-a întâmplat?
R1 a trimis Calea.

Halda a fost dusă pe linia R1-R2.

Suntem interesați de adresa de destinație, obiectele ERO și Label Request.
Adresa de destinatie- 6.6.6.6, așa cum este configurat în tunel.
Traseu explicit:
10.0.12.2 -> 10.0.25.2 -> 10.0.25.5 -> 10.0.56.5 -> 10.0.56.6.
Adică, conține adresa de legătură a interfeței de ieșire și adresa de legătură a următorului nod. Fiecare LSR știe astfel exact la ce interfață să trimită Calea.
Acest ERO nu are 10.0.12.1 deoarece R1 l-a eliminat deja înainte de a-l trimite.
Faptul de disponibilitate Solicitare etichetă indică faptul că LSR ar trebui să aloce o etichetă pentru acest FEC.
Cu toate acestea, nu răspunde la această Cale în niciun fel Pa- il trimite pe cel actualizat mai departe.
Resv-ul din aval este trimis după ce a sosit Resv-ul din LSR-ul din aval.

Același lucru se întâmplă și pe R5:

Halda a fost dusă pe linia R2-R5.

Halda a fost dusă pe linia R2-R5.

Deci Path ajunge la R6. El trimite înapoi RSPV Resv:

Halda a fost dusă pe linia R5-R6.

Dump-ul arată clar că Resv este transmis de la nod la nod.
În obiect Eticheta Se transmite eticheta alocată acestui FEC.

Vă rugăm să rețineți că R6 a atribuit eticheta 0 - Null explicit. În general, aceasta este o situație normală - aceasta se face astfel încât să existe o etichetă MPLS între R5 și R6 (pentru a procesa pachetul conform valorii din câmpul EXP, de exemplu), dar R6 și-a dat seama imediat că eticheta 0 trebuie să fie a resetat și a procesat ceea ce este sub el și nu a căutat în tabelul de etichete.
Problema este că într-un pachet pot exista mai multe etichete (de exemplu, pentru un VPN), dar conform RFC 3032 (și am mai vorbit despre asta), R5 trebuie să elimine întregul teanc de etichete, indiferent câte există, și transmiteți pachetul cu o singură etichetă 0. În acest caz, desigur, totul se va rupe.
De fapt, cerința ca eticheta 0 să fie singura din stivă pare nerezonabilă - nu are nici un folos. Prin urmare, RFC 4182 a eliminat această restricție. Acum eticheta 0 poate să nu fie singura din stivă.
O caracteristică interesantă este PHP. În ciuda faptului că există o etichetă specială pentru aceasta - 3 - LSR va comite PHP chiar dacă primește eticheta 0. Mai multe detalii de la același Pepelnyak.

R5 transmite Resv la R2 și R2 la R1.


Halda a fost dusă pe linia R1-R2.

Aici, după cum puteți vedea, marca este deja normală - 16.

Indiferent cât de atent te uiți la Resv, nu vei vedea calea pe care trebuie să o urmezi, iar lista de noduri trebuie să fie aceeași pentru a distribui cu succes etichetele și a construi un LSP. Cum se rezolva asta?

Întrebări și răspunsuri

ÎN 1: Care este diferența dintre RSVP TE LSP și LDP LSP?

Strict vorbind, atât din punctul de vedere al protocoalelor de nivel superior, cât și al MPLS în sine, nu există deloc astfel de concepte. LSP - asta este LSP - este doar o cale de comutare a etichetei.
Puteți evidenția termenul CR-LSP (LSP bazat pe ConstRaint) - este construit de RSVP TE. În acest sens, diferența este că CR-LSP îndeplinește condițiile specificate în interfața tunelului.

LA 2: Cum se compară Explicit Path și ERO?

Dacă este specificată o cale explicită pentru tunel, atunci RSVP generează un ERO pe baza cerințelor căii explicite. Mai mult, chiar dacă înregistrați fiecare nod în Explicit-Path înainte de Egress LSR, RSVP va încărca datele în CSPF.

LA 3: Dacă unul dintre nodurile intermediare nu acceptă LDP (RSVP TE) sau protocolul este dezactivat pe interfață/platformă, LSP-ul va fi construit astfel încât, de exemplu, să meargă la IP la acest nod și apoi din nou la MPLS la urmatorul?

În cazul RSVP TE Ingress LSR nu va avea acest nod în TED și nu va putea construi o cale către Egress LSR, în consecință, nu va trimite Calea și, în consecință, nu vor exista etichete și LSP-uri.
Traficul nu va putea trece prin tunel.

Dacă vorbim de LDP, atunci situația este mai interesantă. De exemplu, dacă pe R2 dezactivați LDP pe interfața FE0/0 (spre R5), atunci
1) R1 va avea o etichetă pentru FEC 6.6.6.6/32. Mai mult, vor fi 2 dintre ele: unul prin R2, celălalt prin R3, deoarece conform tabelului de rutare cel mai bun este prin R2, atunci LSP-ul se va întinde spre R2.
2) va fi un marcaj pe R2, dar numai unul - spre 1.1.1.1. Acesta nu este cel mai bun mod, deci nu va fi folosit. Adică, aici LSP-ul de la R1 la FEC 6.6.6.6/32 încetează să mai existe.
3) pe R5 va fi eticheta pentru FEC 6.6.6.6/32

Adică se pare că obținem un LSP rupt: (R1-R2, R5-R6). Dar de fapt nu este. De aceea, LSP este Label Switched, astfel încât etichetele de pe el se schimbă de-a lungul întregii căi, dar ajungem de la R1 la R2 MPLS, de la R2 la R5 IP și din nou de la R5 la R6 MPLS. LSP pentru FEC 6.6.6.6/32 nu este aici. Traficul normal va trece aici, în principiu, dar dacă vorbim despre unele aplicații MPLS, precum VPN, atunci acest lucru nu va funcționa.

LA 4: Ei bine, de ce este nevoie de MPLS va fi clar din articolele următoare - deocamdată este în general un fel de prostie artificială pentru a complica viața unui inginer, dar de ce am nevoie de MPLS TE? La urma urmei, traficul poate fi direcționat în modul în care am nevoie folosind valorile IGP.

Să începem cu faptul că acesta este subiectul problemelor viitoare. Dar…
În general, dacă doriți să determinați calea pe care o va parcurge traficul, atunci acest lucru se poate face cu adevărat prin ajustarea inteligentă a costului legăturilor, interfețelor etc. Dar întreținerea unui astfel de sistem vă va da multe probleme, pe de o parte, și, pe de altă parte, încă nu veți putea direcționa două fluxuri diferite în moduri diferite. Adică, dacă sarcina este să ușurezi rețeaua prin distribuirea traficului, atunci cu ajutorul unor metrici vei transfera pur și simplu problema de la un umăr la altul.
Dar dacă aveți mai multe LSP-uri diferite și le puteți trimite trafic, atunci sunteți binevenit. Deși în ceea ce privește ușurința suportului, TE ridică și întrebări.

Ei bine, în general, gândiți-vă bine, dacă aveți nevoie de canale garantate de 40 Mb/s, respectiv 50 Mb/s pentru doi clienți, cum veți urmări utilizarea liniilor? Ei bine, odată ce ai calculat și configurat miraculos rutarea și QoS astfel încât să ofere nivelul necesar de serviciu, dar dintr-o dată 3 kilometri de optică sunt tăiați în trei locuri deodată și nu o poți repara timp de o săptămână. Și ai chiar și trei canale de rezervă de 50 Mb/s, dar traficul ambilor clienți a mers într-un singur loc, fără să-i pese de toți cei formali.

LA 5: Deci, care este diferența dintre etichetele Explicit Null și Implicit Null? Chiar trebuie să știu despre ei?

Trebuie sa. Inițial, se presupune că prin rețeaua MPLS pachetul este întotdeauna comutat după etichetă de la primul până la ultimul LSR. Și la ultimul zbor marcajul va fi „0”, astfel încât Egress LSR va ști imediat că trebuie eliminat. Această etichetă asigură că prioritatea specificată în câmpul TC al antetului MPLS, care este copiată pe măsură ce pachetul este transmis prin rețea, nu se pierde. Drept urmare, chiar și ultimul router va procesa datele în cozile corecte.

În conceptul care folosește eticheta „3”, am decis să renunțăm la acțiunile inutile pe Egress LSR. Dacă nu vă pasă de QoS (sau ați copiat prioritatea, de exemplu, în câmpul DSCP), atunci nu este nevoie urgentă de o etichetă de transport la ultimul hop - principalul lucru este să o trimiteți la interfața corectă , iar Egress LSR o va rezolva acolo. Dacă a existat un pachet IP pur, dați-l procesului IP dacă a existat E1, transmiteți fluxul la interfața dorită, dacă a existat o stivă de etichete, apoi faceți o căutare în LFIB și vedeți ce acțiuni suplimentare trebuie; a fi luat.

LA 6: Pentru un FEC, LSR va aloca întotdeauna aceeași etichetă tuturor vecinilor săi?

Există un concept de spațiu de etichetă:

• spațiu eticheta interfeței
• spațiu pentru eticheta slotului


• spațiu eticheta platformei

Dacă etichetele sunt specifice fiecărei interfețe, atunci pentru un FEC la porturi diferite poate sa să fie trimise diferite etichete.
Și invers - dacă etichetele sunt specifice platformei (a se citi doar LSR), atunci routerul către toate porturile pentru un FEC trebuie sa trimite etichete identice.
În exemplele de mai jos, veți vedea că pentru un FEC trimitem aceleași etichete către diferiți vecini, dar acest lucru nu indică încă cum este organizat spațiul etichetelor. Acesta este un lucru pur individual și este legat de hardware.

Este important de înțeles că tehnologia MPLS nu reglementează în niciun fel protocolul de distribuție a etichetelor, ci rezultatele finale rețea specifică poate diferi atunci când sunt utilizate protocoale diferite. Protocoalele și aplicațiile upstream folosesc LSP-uri indiferent de cine sau cum sunt construite.
Apropo, scenariul LDP peste TE este adesea întâlnit în rețelele moderne. În acest caz, RSVP-TE este folosit pentru a organiza transportul și implementarea Ingineriei Traficului, iar LDP este folosit pentru a schimba etichete VPN, de exemplu.
Ingress LSR, prin scrierea primei etichete în antetul MPLS, determină întreaga cale a pachetului. Routerele intermediare schimbă pur și simplu o etichetă cu alta. Conținutul poate fi absolut orice. Această natură multi-protocol este cea care permite MPLS să servească drept bază pentru o varietate de servicii VPN.

Mulți dintre cei care lucrează constant cu rețelele de internet au auzit probabil despre o tehnologie atât de minunată precum MPLS.
MPLS ne deschide noi oportunități, cum ar fi AToM (Any Transport over Mpls), Traffic Engineering etc.
AToM permite ca traficul protocoalelor de nivel 2, cum ar fi ATM, Frame Relay, Ethernet, PPP și HDLC să fie transmis printr-o rețea IP/MPLS.
În acest articol aș dori să mă concentrez pe tehnologia EoMPLS.

Puțină teorie

MPLS- (Engleză: Multiprotocol Label Switching) - comutare multiprotocol label.
În modelul OSI, teoretic poate fi poziționat între straturile doi și trei.

În conformitate cu tehnologia MPLS, pachetelor li se atribuie etichete pentru transmiterea prin rețea. Etichetele sunt incluse în antetul MPLS care este introdus în pachetul de date.

Aceste etichete scurte, cu lungime fixă, poartă informații care îi spun fiecărui nod de comutare (router) cum să proceseze și să transmită pachetele de la sursă la destinație. Ele contează doar în zonă conexiune localăîntre două noduri. Pe măsură ce fiecare nod transmite un pachet, înlocuiește eticheta curentă cu eticheta corespunzătoare pentru a se asigura că pachetul este direcționat către următorul nod. Acest mecanism oferă comutare de pachete de foarte mare viteză rețea centrală MPLS.

MPLS combină cele mai bune dintre rutarea IP Layer 3 și comutarea Layer 2.
În timp ce routerele necesită inteligență stratul de rețea Pentru a determina unde să redirecționeze traficul, comutatoarele trebuie doar să trimită datele către următorul hop, care este în mod natural mai simplu, mai rapid și mai ieftin. MPLS se bazează pe protocoalele tradiționale de rutare IP pentru a face publicitate și a stabili topologia rețelei. MPLS este apoi suprapus peste această topologie. MPLS predetermină calea de călătorie a datelor printr-o rețea și codifică aceste informații sub forma unei etichete care este înțeleasă de routerele rețelei.
Deoarece planificarea rutei are loc în amonte și la marginea rețelei (unde se întâlnesc rețelele consumatorilor și furnizorilor de servicii), datele etichetate MPLS necesită mai puțină putere de procesare de la routere pentru a traversa nucleul rețelei furnizorului de servicii.

Atom
Pentru a crea VPN Layer 2 punct la punct, a fost dezvoltată tehnologia Any Transport Over MPLS (AToM), care asigură transmiterea cadrelor Layer 2 printr-o rețea MPLS. AToM este o tehnologie integrată care include Frame Relay peste MPLS, ATM peste MPLS, Ethernet peste MPLS.

EoMPLSîncapsulează cadre Ethernet în pachete MPLS și utilizează un teanc de etichete pentru a transmite prin rețeaua MPLS.

Un canal construit pe tehnologia EoMPLS arată ca un cordon virtual pentru consumatorul serviciilor furnizorului.

Deci, aici mergem... Cum se creează un VPN Layer 2 folosind EoMPLS?

Să ne imaginăm că avem un client foarte important care trebuie să combine două sucursale (Moscova și Vladivostok) într-un singur segment de rețea, cu o singură adresare IP end-to-end. Aici AToM vine în ajutor.

Cum îl vede clientul

Cum îl vede furnizorul

Înainte de a configura direct VPN, trebuie să vă asigurați că MPLS funcționează.

Configurarea acestuia este mult mai ușoară decât pare la prima vedere (vorbim despre o configurare de bază minimă).

1. Mai întâi, să activăm IP CEF și MPLS în configurația globală a routerului nostru.
   

   MSK-1#conf t
   MSK-1(config)#ip cef
   MSK-1(config)#mpls ip

   
   Dacă routerul refuză să înțeleagă o astfel de comandă, atunci fie Versiune curentă IOS sau echipamentul în sine nu acceptă MPLS.
2. Creăm o interfață loopback prin care MPLS-ul nostru va funcționa.
   

   MSK-1#conf t
   MSK-1(config)#int lo1
   MSK-1(config-if)#adresă ip 1.1.1.1 255.255.255.255
   

   
   Din punct de vedere tehnic, poate funcționa și direct pe interfețele care asigură comunicarea între două routere. Dar o astfel de schemă creează doar dificultăți suplimentare. De exemplu, schimbarea adresei IP în zona dintre routere.
3. Configuram rutarea pentru a asigura comunicarea intre routere prin interfete loopback.
   Puteți utiliza fie rute statice, fie protocoale de rutare dinamică. Să luăm OSPF de exemplu.
   

   MSK-1#conf t
   MSK-1(config)#router ospf 100
   MSK-1(config-router)#log-adjacency-changes
   MSK-1(config-router)#network 1.1.1.1 0.0.0.0 zona 0
   MSK-1(config-router)#network 1.0.0.0 0.0.0.3 zona 0
   MSK-1(config-router)#

   
   Rețeaua specifică interfața loopback și rețeaua de interfețe pentru comunicarea între routere.

   Verificăm cu comanda ping că totul funcționează.
   

   MSK-1#ping 1.1.1.3
   Tastați secvența de evacuare la avort.
   Trimiterea ecourilor ICMP de 5, 100 de octeți la 1.1.1.3, timeout este de 2 secunde:
   ! ! ! ! !
   Rata de succes este de 100 la sută (5/5), dus-întors min/media/max = 1/3/4 ms
   MSK-1#

4. Să îi indicăm routerului nostru că interfața loopback va fi folosită ca „router-id”.
   

   MSK-1#conf t
   MSK-1(config)#mpls ldp router-id Loopback1 force

5. Activem MPLS pe ​​interfețele care conectează routerele între ele.
   

   MSK-1#conf t
   MSK-1(config)#int gi0/2
   MSK-1(config-if)#mpls ip

6. Vedem că conexiunea prin MPLS este stabilită.
   

   MSK-1#sh mpls ldp vecin Peer LDP Ident: 1.1.1.2:0; Local LDP Ident 1.1.1.1:0 Conexiune TCP: 1.1.1.2.12817 - 1.1.1.1.646 Stare: Oper; Mesaje trimise/rcvd: 36243/37084; Timp de upstream în aval: 01:39:49 Surse de descoperire LDP: Salutare țintită 1.1.1.1 -> 1.1.1.2, GigabitEthernet0/2 activ, pasiv, Adresă IP Src: 1.0.0.2 Adrese legate de peer LDP Ident: 1.1.1.2 1.0. 0.2 1.1.1.6 Peer LDP Ident: 1.1.1.3:0; Local LDP Ident 1.1.1.1:0 Conexiune TCP: 1.1.1.3.48545 - 1.1.1.1.646 Stare: Oper; Mesaje trimise/rcvd: 347/127; Timp de upstream în aval: 01:39:49 Surse de descoperire LDP: Salutare țintită 1.1.1.1 -> 1.1.1.3, activ, pasiv Adrese legate de peer LDP Ident: 1.0.0.5 1.1.1.3 MSK-1#

Configurația de bază MPLS este acum completă.
Aici am prezentat configurația unui singur router. La sfârșitul articolului puteți vedea configurațiile tuturor routerelor.

Să trecem la configurarea unui canal EoMPLS pentru clientul nostru imaginar.

Întreaga configurare se reduce la crearea de sub-interfețe pe ambele routere.

Pe de o parte:

MSK-1#conf t
MSK-1(config)int gi0/1.100
MSK-1(config-subif)#capsulation dot1Q 100
MSK-1(config-subif)#xconnect 1.1.1.3 123456789 încapsulare mpls

Pe de alta parte:

Vladi-1#conf t
Vladi-1(config)int gi0/1.40
Vladi-1(config-subif)#capsulation dot1Q 40
Vladi-1(config-subif)#xconnect 1.1.1.1 123456789 încapsulare mpls

Câteva puncte mai detaliat:
încapsulare dot1Q 100 - specificați eticheta dot1Q. Pentru a spune simplu, este numărul VLAN prin care traficul clientului va călători de la router la portul său de pe switch. Această valoare poate fi diferită pe alt router. Ceea ce ne permite să combinăm două VLAN-uri complet diferite.
xconnect 1.1.1.3 - creați un xconnect la routerul necesar. Acolo, unde este inclus al doilea punct al clientului nostru.
123456789 - Valoarea circuitului virtual. Ar trebui să fie același pe ambele routere. Această valoare este cea care ne identifică canalul. Valorile VC pot varia de la 1 la 4294967295.

Acum nu mai rămâne decât să verificăm dacă canalul nostru funcționează și să ne bucurăm de viață.

MSK-1#sh mpls l2transport vc 123456789 Local intf Circuit local Adresă de destinație VC ID Stare Gi0/1.100 Eth VLAN 100 1.1.1.3 123456789 UP MSK-1#

ȘI informatii detaliate:

MSK-1#sh mpls l2transport vc 123456789 detaliu Interfață locală: Gi0/1.100 up, line protocol up, Eth VLAN 100 up Adresă de destinație: 1.1.1.3, VC ID: 123456789, VC status: up Următorul hop: interfață de ieșire 1.0.00. : Gi0/2, stivă de etichete impuse (599 17) Ora creării: 02:33:18, ora ultimei modificări a stării: 02:33:14 Protocol de semnalizare: LDP, peer 1.1.1.3:0 up Etichete MPLS VC: local 140, la distanță 17 ID grup: local 0, la distanță 0 MTU: local 1500, la distanță 1500 Descrierea interfeței la distanță: Secvențiere: primire dezactivată, trimitere dezactivată Statistici VC: totaluri pachete: primire 1391338893, trimitere 1676515662 totaluri de octeți: primire 20375702 totaluri de octeți: primire 20377502 primiți 0, trimiteți 0 MSK-1#

Probleme MTU

Trebuie reținut că atunci când MPLS funcționează, la pachetul Ethernet sunt adăugați 12 octeți suplimentari.
Pentru a evita fragmentarea pachetelor, puteți specifica „mpls mtu 1512” pe interfețe. Dar, în acest caz, toate dispozitivele de-a lungul rutei trebuie să suporte transmisia de pachete cu Dimensiunea MTU, peste 1500.

P.S. Configurațiile tuturor routerelor așa cum a fost promis.

Moscova
#mpls ip #router ospf 100 jurnal-adiacența-modificări reţea 1.1.1.1 0.0.0.0 zona 0 rețea 1.0.0.0 0.0.0.3 zona 0 #interfață GigabitEthernet0/2 adresa ip 1.0.0.1 255.255.255.252 mpls ip #interfaceLoopback1 adresa ip 1.1.1.1 255.255.255.255 #interfață GigabitEthernet0/1.100 încapsulare dot1Q 100 xconnect 1.1.1.3 123456789 încapsulare mpls

Este imposibil să descrii absolut toate aspectele într-un singur articol. Am încercat să spun cât mai pe scurt posibil minimul necesar pentru lucrare.

Mulți dintre cei care lucrează constant cu rețelele de internet au auzit probabil despre o tehnologie atât de minunată precum MPLS.
MPLS ne deschide noi oportunități, cum ar fi AToM (Any Transport over Mpls), Traffic Engineering etc.
AToM permite ca traficul protocoalelor de nivel 2, cum ar fi ATM, Frame Relay, Ethernet, PPP și HDLC să fie transmis printr-o rețea IP/MPLS.
În acest articol aș dori să mă concentrez pe tehnologia EoMPLS.

Puțină teorie

MPLS- (Engleză: Multiprotocol Label Switching) - comutare multiprotocol label.
În modelul OSI, teoretic poate fi poziționat între straturile doi și trei.

În conformitate cu tehnologia MPLS, pachetelor li se atribuie etichete pentru transmiterea prin rețea. Etichetele sunt incluse în antetul MPLS care este introdus în pachetul de date.

Aceste etichete scurte, cu lungime fixă, poartă informații care îi spun fiecărui nod de comutare (router) cum să proceseze și să transmită pachetele de la sursă la destinație. Ele au semnificație doar asupra conexiunii locale dintre două noduri. Pe măsură ce fiecare nod transmite un pachet, înlocuiește eticheta curentă cu eticheta corespunzătoare pentru a se asigura că pachetul este direcționat către următorul nod. Acest mecanism oferă comutare de pachete de foarte mare viteză prin rețeaua de bază MPLS.

MPLS combină cele mai bune dintre rutarea IP Layer 3 și comutarea Layer 2.
În timp ce routerele necesită inteligență la nivel de rețea pentru a determina unde să redirecționeze traficul, comutatoarele trebuie doar să transmită datele către următorul hop, care este în mod natural mai simplu, mai rapid și mai ieftin. MPLS se bazează pe protocoalele tradiționale de rutare IP pentru a face publicitate și a stabili topologia rețelei. MPLS este apoi suprapus peste această topologie. MPLS predetermină calea de călătorie a datelor printr-o rețea și codifică aceste informații sub forma unei etichete care este înțeleasă de routerele rețelei.
Deoarece planificarea rutei are loc în amonte și la marginea rețelei (unde se întâlnesc rețelele consumatorilor și furnizorilor de servicii), datele etichetate MPLS necesită mai puțină putere de procesare de la routere pentru a traversa nucleul rețelei furnizorului de servicii.

Atom
Pentru a crea VPN Layer 2 punct la punct, a fost dezvoltată tehnologia Any Transport Over MPLS (AToM), care asigură transmiterea cadrelor Layer 2 printr-o rețea MPLS. AToM este o tehnologie integrată care include Frame Relay peste MPLS, ATM peste MPLS, Ethernet peste MPLS.

EoMPLSîncapsulează cadre Ethernet în pachete MPLS și utilizează un teanc de etichete pentru a transmite prin rețeaua MPLS.

Un canal construit pe tehnologia EoMPLS arată ca un cordon virtual pentru consumatorul serviciilor furnizorului.

Deci, aici mergem... Cum se creează un VPN Layer 2 folosind EoMPLS?

Să ne imaginăm că avem un client foarte important care trebuie să combine două sucursale (Moscova și Vladivostok) într-un singur segment de rețea, cu o singură adresare IP end-to-end. Aici AToM vine în ajutor.

Cum îl vede clientul

Cum îl vede furnizorul

Înainte de a configura direct VPN, trebuie să vă asigurați că MPLS funcționează.

Configurarea acestuia este mult mai ușoară decât pare la prima vedere (vorbim despre o configurare de bază minimă).

1. Mai întâi, să activăm IP CEF și MPLS în configurația globală a routerului nostru.
   

   MSK-1#conf t
   MSK-1(config)#ip cef
   MSK-1(config)#mpls ip

   
   Dacă routerul refuză să înțeleagă o astfel de comandă, atunci fie versiunea actuală a IOS, fie echipamentul în sine nu acceptă MPLS.
2. Creăm o interfață loopback prin care MPLS-ul nostru va funcționa.
   

   MSK-1#conf t
   MSK-1(config)#int lo1
   MSK-1(config-if)#adresă ip 1.1.1.1 255.255.255.255
   

   
   Din punct de vedere tehnic, poate funcționa și direct pe interfețele care asigură comunicarea între două routere. Dar o astfel de schemă creează doar dificultăți suplimentare. De exemplu, schimbarea adresei IP în zona dintre routere.
3. Configuram rutarea pentru a asigura comunicarea intre routere prin interfete loopback.
   Puteți utiliza fie rute statice, fie protocoale de rutare dinamică. Să luăm OSPF de exemplu.
   

   MSK-1#conf t
   MSK-1(config)#router ospf 100
   MSK-1(config-router)#log-adjacency-changes
   MSK-1(config-router)#network 1.1.1.1 0.0.0.0 zona 0
   MSK-1(config-router)#network 1.0.0.0 0.0.0.3 zona 0
   MSK-1(config-router)#

   
   Rețeaua specifică interfața loopback și rețeaua de interfețe pentru comunicarea între routere.

   Verificăm cu comanda ping că totul funcționează.
   

   MSK-1#ping 1.1.1.3
   Tastați secvența de evacuare la avort.
   Trimiterea ecourilor ICMP de 5, 100 de octeți la 1.1.1.3, timeout este de 2 secunde:
   ! ! ! ! !
   Rata de succes este de 100 la sută (5/5), dus-întors min/media/max = 1/3/4 ms
   MSK-1#

4. Să îi indicăm routerului nostru că interfața loopback va fi folosită ca „router-id”.
   

   MSK-1#conf t
   MSK-1(config)#mpls ldp router-id Loopback1 force

5. Activem MPLS pe ​​interfețele care conectează routerele între ele.
   

   MSK-1#conf t
   MSK-1(config)#int gi0/2
   MSK-1(config-if)#mpls ip

6. Vedem că conexiunea prin MPLS este stabilită.
   

   MSK-1#sh mpls ldp vecin Peer LDP Ident: 1.1.1.2:0; Local LDP Ident 1.1.1.1:0 Conexiune TCP: 1.1.1.2.12817 - 1.1.1.1.646 Stare: Oper; Mesaje trimise/rcvd: 36243/37084; Timp de upstream în aval: 01:39:49 Surse de descoperire LDP: Salutare țintită 1.1.1.1 -> 1.1.1.2, GigabitEthernet0/2 activ, pasiv, Adresă IP Src: 1.0.0.2 Adrese legate de peer LDP Ident: 1.1.1.2 1.0. 0.2 1.1.1.6 Peer LDP Ident: 1.1.1.3:0; Local LDP Ident 1.1.1.1:0 Conexiune TCP: 1.1.1.3.48545 - 1.1.1.1.646 Stare: Oper; Mesaje trimise/rcvd: 347/127; Timp de upstream în aval: 01:39:49 Surse de descoperire LDP: Salutare țintită 1.1.1.1 -> 1.1.1.3, activ, pasiv Adrese legate de peer LDP Ident: 1.0.0.5 1.1.1.3 MSK-1#

Configurația de bază MPLS este acum completă.
Aici am prezentat configurația unui singur router. La sfârșitul articolului puteți vedea configurațiile tuturor routerelor.

Să trecem la configurarea unui canal EoMPLS pentru clientul nostru imaginar.

Întreaga configurare se reduce la crearea de sub-interfețe pe ambele routere.

Pe de o parte:

MSK-1#conf t
MSK-1(config)int gi0/1.100
MSK-1(config-subif)#capsulation dot1Q 100
MSK-1(config-subif)#xconnect 1.1.1.3 123456789 încapsulare mpls

Pe de alta parte:

Vladi-1#conf t
Vladi-1(config)int gi0/1.40
Vladi-1(config-subif)#capsulation dot1Q 40
Vladi-1(config-subif)#xconnect 1.1.1.1 123456789 încapsulare mpls

Câteva puncte mai detaliat:
încapsulare dot1Q 100 - specificați eticheta dot1Q. Pentru a spune simplu, este numărul VLAN prin care traficul clientului va călători de la router la portul său de pe switch. Această valoare poate fi diferită pe alt router. Ceea ce ne permite să combinăm două VLAN-uri complet diferite.
xconnect 1.1.1.3 - creați un xconnect la routerul necesar. Acolo, unde este inclus al doilea punct al clientului nostru.
123456789 - Valoarea circuitului virtual. Ar trebui să fie același pe ambele routere. Această valoare este cea care ne identifică canalul. Valorile VC pot varia de la 1 la 4294967295.

Acum nu mai rămâne decât să verificăm dacă canalul nostru funcționează și să ne bucurăm de viață.

MSK-1#sh mpls l2transport vc 123456789 Local intf Circuit local Adresă de destinație VC ID Stare Gi0/1.100 Eth VLAN 100 1.1.1.3 123456789 UP MSK-1#

Si informatii detaliate:

MSK-1#sh mpls l2transport vc 123456789 detaliu Interfață locală: Gi0/1.100 up, line protocol up, Eth VLAN 100 up Adresă de destinație: 1.1.1.3, VC ID: 123456789, VC status: up Următorul hop: interfață de ieșire 1.0.00. : Gi0/2, stivă de etichete impuse (599 17) Ora creării: 02:33:18, ora ultimei modificări a stării: 02:33:14 Protocol de semnalizare: LDP, peer 1.1.1.3:0 up Etichete MPLS VC: local 140, la distanță 17 ID grup: local 0, la distanță 0 MTU: local 1500, la distanță 1500 Descrierea interfeței la distanță: Secvențiere: primire dezactivată, trimitere dezactivată Statistici VC: totaluri pachete: primire 1391338893, trimitere 1676515662 totaluri de octeți: primire 20375702 totaluri de octeți: primire 20377502 primiți 0, trimiteți 0 MSK-1#

Probleme MTU

Trebuie reținut că atunci când MPLS funcționează, la pachetul Ethernet sunt adăugați 12 octeți suplimentari.
Pentru a evita fragmentarea pachetelor, puteți specifica „mpls mtu 1512” pe interfețe. Dar, în acest caz, toate dispozitivele de-a lungul rutei trebuie să accepte transmiterea de pachete cu o dimensiune MTU mai mare de 1500.

P.S. Configurațiile tuturor routerelor așa cum a fost promis.

Moscova
#mpls ip #router ospf 100 jurnal-adiacența-modificări reţea 1.1.1.1 0.0.0.0 zona 0 rețea 1.0.0.0 0.0.0.3 zona 0 #interfață GigabitEthernet0/2 adresa ip 1.0.0.1 255.255.255.252 mpls ip #interfaceLoopback1 adresa ip 1.1.1.1 255.255.255.255 #interfață GigabitEthernet0/1.100 încapsulare dot1Q 100 xconnect 1.1.1.3 123456789 încapsulare mpls

Este imposibil să descrii absolut toate aspectele într-un singur articol. Am încercat să spun cât mai pe scurt posibil minimul necesar pentru lucrare.