Technika przełączania etykiet, znana dziś powszechnie jako MPLS, narodziła się w odpowiedzi na fundamentalne wyzwanie stojące przed operatorami telekomunikacyjnymi w połowie lat dziewięćdziesiątych: jak efektywnie routować pakiety IP z szybkościami sięgającymi gigabitów na sekundę bez konieczności stosowania kosztownych, programowych routerów o ograniczonej wydajności. Przełom polegał na wprowadzeniu koncepcji krótkiej etykiety o stałej długości, która mogła być przetwarzana przez dedykowane układy sprzętowe znacznie szybciej niż tradycyjne wyszukiwanie najdłuższego prefiksu w tablicy routingu. Rozwiązanie to okazało się tak skuteczne, że IETF zdecydowała się ustandaryzować je jako MPLS w roku 2001 w dokumencie RFC 3031.
Fundamentalną zaletą architektury MPLS jest rozdział między płaszczyzną sterowania a płaszczyzną danych, który umożliwia niezależną ewolucję obu tych obszarów. W płaszczyźnie sterowania protokoły takie jak OSPF, IS-IS i BGP odpowiadają za wykrywanie topologii sieci i dystrybucję informacji o trasach, podczas gdy dedykowane protokoły dystrybucji etykiet (LDP lub RSVP-TE) mapują te trasy na etykiety MPLS. Płaszczyzna danych natomiast wykonuje wyłącznie mechaniczne operacje na etykietach: PUSH, SWAP i POP, które są zaimplementowane w szybkich układach ASIC lub NPU. To rozdzielenie odpowiedzialności pozwala na elastyczne wprowadzanie nowych usług bez modyfikacji sprzętu sieciowego.
Z perspektywy inżyniera sieci operatorskiej MPLS jest nie tylko protokołem transportowym, ale przede wszystkim platformą usługową, która umożliwia świadczenie zaawansowanych usług o wartości dodanej. Możliwość tworzenia wirtualnych sieci prywatnych, precyzyjna kontrola ścieżek ruchu oraz szybka ochrona przed awariami to funkcjonalności, które przesądzają o dominacji MPLS w sieciach szkieletowych. Mimo pojawienia się nowszych technologii takich jak Segment Routing, MPLS pozostaje standardem, który musi znać każdy specjalista ds. sieci teleinformatycznych pracujący w środowisku operatorskim.
W połowie lat dziewięćdziesiątych największym wyzwaniem dla producentów sprzętu sieciowego była przepaść między rosnącą szybkością łączy transmisyjnych a wydajnością jednostek centralnych routerów. Podczas gdy łącza światłowodowe oferowały już przepustowości rzędu 155 Mb/s (STM-1) i 622 Mb/s (STM-4), routery programowe mogły przetwarzać zaledwie kilkadziesiąt tysięcy pakietów na sekundę. Wyszukiwanie najdłuższego prefiksu w tablicy routingu, która w tamtym okresie zawierała już ponad trzydzieści tysięcy tras, wymagało wielu cykli procesora i stanowiło wąskie gardło całego systemu. Sytuacja ta zmuszała inżynierów do poszukiwania alternatywnych metod przekazywania pakietów.
Przełączanie etykiet okazało się rozwiązaniem eleganckim, ponieważ zamieniało złożoną operację LPM na proste indeksowanie tablicy. Router LSR nie musi analizować nagłówka IP ani podejmować decyzji routingowej dla każdego pakietu z osobna, co stanowi istotę przyspieszenia. W praktyce operacja SWAP na górnej etykiecie może być wykonana w jednym cyklu zegara 40 MHz, co przekłada się na przepustowość rzędu 25 milionów pakietów na sekundę dla pojedynczej ścieżki danych. Osiągnięcie podobnej wydajności w czystym routingu IP wymagałoby znacznie bardziej złożonych i kosztownych układów scalonych.
Współczesne routery brzegowe wykorzystują dedykowane procesory sieciowe NPU zdolne do przetwarzania setek milionów pakietów na sekundę i obsługi tysięcy sesji LDP jednocześnie. Jednak sama wydajność nie jest już głównym powodem utrzymywania MPLS w sieciach operatorskich. Kluczowe znaczenie mają dziś zaawansowane funkcje, takie jak możliwość budowania hierarchicznych stosów etykiet dla wielu usług, precyzyjna kontrola ścieżek za pomocą inżynierii ruchu oraz gwarantowany czas odtwarzania po awarii poniżej 50 milisekund. Te cechy sprawiają, że MPLS pozostaje niezastąpionym narzędziem w arsenale każdego operatora telekomunikacyjnego.
Umiejscowienie nagłówka MPLS pomiędzy warstwą łącza danych a warstwą sieciową ma głębokie konsekwencje dla sposobu, w jaki routery przetwarzają pakiety w sieci szkieletowej. Gdy router odbiera ramkę Ethernet z polem EtherType ustawionym na 0x8847, natychmiast wie, że zawiera ona stos etykiet MPLS i powinien przetwarzać pakiet w oparciu o górną etykietę, bez konieczności zaglądania do nagłówka IP. Ten prosty mechanizm pozwala na budowanie sieci, w której routery rdzeniowe są całkowicie odciążone od złożonych obliczeń związanych z routingiem IP, co znacząco przyspiesza transmisję.
Określenie Multiprotocol w nazwie MPLS nie jest przypadkowe i odnosi się do zdolności tej technologii do przenoszenia różnorodnych protokołów warstwy 3 i warstwy 2 w ramach jednej, ujednoliconej infrastruktury szkieletowej. Oprócz oczywistych zastosowań dla ruchu IPv4 i IPv6, MPLS może transportować ramki Ethernet dla usług L2VPN, komórki ATM, ramki Frame Relay, a także protokoły starszej generacji, takie jak IPX. Ta uniwersalność ma kluczowe znaczenie dla operatorów, którzy często muszą obsługiwać klientów korzystających z różnych technologii dostępowych.
Z punktu widzenia architektury sieci operatorskiej, umieszczenie MPLS między warstwami 2 i 3 pozwala na wyraźne rozdzielenie odpowiedzialności między poszczególne elementy infrastruktury. Routery P w rdzeniu odpowiadają wyłącznie za szybkie przełączanie etykiet i nie muszą przechowywać tras klientów, podczas gdy routery PE na brzegu sieci zarządzają złożonymi funkcjami, takimi jak VRF, MP-BGP i QoS. Taka separacja upraszcza projektowanie sieci, zwiększa jej skalowalność i umożliwia dodawanie nowych usług bez konieczności modyfikacji rdzenia.
Nagłówek etykiety MPLS o długości zaledwie 32 bitów jest przykładem minimalistycznego, a zarazem niezwykle funkcjonalnego projektu. Pole Label o długości 20 bitów pozwala na adresację do 1 048 575 różnych etykiet, z czego wartości 0-15 są zarezerwowane dla celów specjalnych. Szczególnie istotne są etykieta 0 (Explicit NULL) wykorzystywana w mechanizmach QoS oraz etykieta 3 (Implicit NULL) stosowana w optymalizacji PHP. Pole EXP (obecnie nazywane Traffic Class) umożliwia klasyfikację ruchu do ośmiu klas kolejkowych, co jest podstawą mechanizmów QoS w sieciach MPLS.
Bit Bottom of Stack pełni rolę znacznika końca stosu etykiet i ma fundamentalne znaczenie dla implementacji hierarchicznych usług MPLS. Gdy router przetwarza pakiet z bitem S ustawionym na 0, wie, że pod bieżącą etykietą znajduje się kolejna etykieta MPLS i musi ją zachować podczas operacji SWAP. Natomiast bit S równy 1 sygnalizuje, że po tej etykiecie następuje bezpośrednio nagłówek protokołu warstwy 3, co nakazuje routerowi przygotowanie się do ekstrakcji pakietu IP. Pole TTL, analogiczne do TTL w nagłówku IP, zapobiega zapętleniu pakietów w sieci, co jest szczególnie istotne w złożonych topologiach z wieloma ścieżkami LSP.
Możliwość tworzenia stosów wielu etykiet jest cechą odróżniającą MPLS od prostych mechanizmów przełączania i stanowi podstawę zaawansowanych usług operatorskich. W typowym scenariuszu L3VPN stos dwupoziomowy składa się z etykiety transportowej LDP odpowiadającej za dostarczenie pakietu do zdalnego routera PE oraz etykiety usługowej MP-BGP identyfikującej konkretną instancję VRF. W przypadku inżynierii ruchu z użyciem RSVP-TE stos może zawierać trzy lub więcej etykiet, gdzie dodatkowe etykiety wymuszają przejście pakietu przez określone węzły pośrednie, co pozwala na precyzyjną kontrolę ścieżki w sieci szkieletowej.
Routery LSR stanowią kręgosłup sieci MPLS, wykonując szybkie operacje przełączania etykiet w oparciu o tablicę LFIB. Przyjrzyjmy się szczegółowo procesowi: gdy pakiet MPLS dociera do interfejsu wejściowego LSR, układ ASIC lub NPU natychmiast odczytuje górną etykietę, wykorzystuje jej wartość jako indeks w tablicy LFIB i pobiera odpowiadający jej wpis. Wpis ten zawiera operację do wykonania (zazwyczaj SWAP), nową wartość etykiety wyjściowej oraz identyfikator interfejsu wyjściowego. Cały proces trwa zaledwie kilka nanosekund, co pozwala na osiągnięcie przepustowości rzędu setek gigabitów na sekundę na pojedynczym routerze.
Routery LER są zdecydowanie bardziej złożone funkcjonalnie niż LSR, ponieważ muszą obsługiwać zarówno interfejsy klienckie (CE-facing), jak i międzyoperatorskie. Na interfejsie klienckim LER może otrzymywać czyste pakiety IP, które muszą być sklasyfikowane, przypisane do odpowiedniego VRF, a następnie opatrzone zestawem etykiet MPLS przed wysłaniem w głąb sieci szkieletowej. W przypadku usług L2VPN, LER dodatkowo musi zarządzać uczeniem adresów MAC i mostkowaniem ruchu między interfejsami fizycznymi a wirtualnymi pseudowire. LER pełni zatem funkcję inteligentnej bramy między światem klienta a siecią operatorską.
W nomenklaturze operatorskiej routery LSR określa się mianem routerów P (Provider), a routery LER jako PE (Provider Edge). Routery P pracują w rdzeniu sieci i są zoptymalizowane wyłącznie pod kątem maksymalnej wydajności płaszczyzny danych, podczas gdy routery PE obsługują klientów na brzegu sieci i odpowiadają za funkcje takie jak VRF, MP-BGP i QoS. Router klienta CE (Customer Edge) nie wymaga żadnej konfiguracji MPLS, co stanowi istotną zaletę dla klientów korzystających z usług MPLS VPN. Komunikacja między CE a PE odbywa się za pomocą standardowych protokołów IP, takich jak BGP, OSPF czy trasy statyczne.
Routery P w sieci operatorskiej pełnią funkcję szybkich węzłów tranzytowych, których konfiguracja ogranicza się do minimum niezbędnego do poprawnego działania MPLS. W praktyce oznacza to uruchomienie protokołu IGP (najczęściej OSPF lub IS-IS) do wykrywania sąsiadów i wymiany tras sieciowych oraz protokołu LDP do dystrybucji etykiet dla tych tras. Routery P nie przechowują tras klientów, nie utrzymują sesji BGP ani nie zarządzają instancjami VRF, co drastycznie upraszcza ich konfigurację i zmniejsza wymagania pamięciowe. W rezultacie routery P mogą być zoptymalizowane wyłącznie pod kątem wydajności płaszczyzny danych, osiągając przepustowości rzędu terabitów na sekundę.
Routery PE są najbardziej złożonymi urządzeniami w sieci operatorskiej, pełniącymi funkcję inteligentnej bramy między siecią szkieletową a klientami. Każdy PE może obsługiwać od kilkudziesięciu do kilku tysięcy instancji VRF, z których każda ma własną tablicę routingu, własne protokoły routingu i własne interfejsy. Routery PE utrzymują sesje MP-BGP z innymi PE w domenie oraz z ewentualnymi route reflectorami, wymieniając się trasami VPNv4 dla wszystkich obsługiwanych klientów. Dodatkowo PE odpowiadają za mechanizmy QoS, filtrowanie ruchu, autoryzację dostępu oraz zbieranie statystyk, co czyni je najważniejszymi węzłami sieci MPLS pod względem funkcjonalnym.
Routery CE należą do klienta i łączą jego sieć lokalną z siecią operatora za pośrednictwem routera PE. Z punktu widzenia klienta, CE jest zwykłym routerem IP, który komunikuje się z PE za pomocą standardowych protokołów routingu, bez jakiejkolwiek wiedzy o technologii MPLS stosowanej w sieci szkieletowej operatora. Dla klienta infrastruktura operatorska jest całkowicie przezroczysta, a usługa MPLS VPN jest postrzegana jako gwarantowane połączenie między lokalizacjami o określonej przepustowości i parametrach SLA. Ta przezroczystość jest kluczową zaletą komercyjną, ponieważ klient nie musi inwestować w kosztowny sprzęt ani szkolić personelu.
Podział na płaszczyznę sterowania i płaszczyznę danych jest fundamentalną koncepcją architektoniczną sieci MPLS, która ma bezpośrednie przełożenie na sposób projektowania i zarządzania infrastrukturą operatorską. W płaszczyźnie sterowania działają złożone protokoły, takie jak OSPF lub IS-IS do wykrywania topologii sieci, LDP do wymiany mapowań między etykietami a prefiksami IP oraz MP-BGP do dystrybucji tras VPN między routerami PE. Te protokoły budują tablice RIB i LIB, które są następnie wykorzystywane do wygenerowania tablic FIB i LFIB dla płaszczyzny danych. Operacje w płaszczyźnie sterowania są wykonywane tylko przy zmianach konfiguracji sieci, a nie dla każdego pakietu, co minimalizuje narzut obliczeniowy.
Płaszczyzna danych w MPLS jest z założenia prosta i wysoce zoptymalizowana pod kątem wydajności. Gdy pakiet dociera do routera, układ ASIC odczytuje górną etykietę, indeksuje tablicę LFIB i wykonuje zdefiniowaną operację w czasie kilku nanosekund. Cały proces przekazywania pakietu w Data Plane nie wymaga analizy nagłówka IP, wyszukiwania najdłuższego prefiksu ani podejmowania decyzji routingowych. To właśnie ta prostota i determinizm operacji na etykietach pozwalają osiągać przepustowości rzędu terabitów na sekundę na pojedynczej platformie sprzętowej, przy jednoczesnym zachowaniu bardzo niskiego i przewidywalnego opóźnienia.
Rozdzielenie płaszczyzny sterowania od płaszczyzny danych ma również głęboki wpływ na ewolucję sieci w kierunku architektury SDN. W klasycznym modelu MPLS obie płaszczyzny współistnieją na tym samym urządzeniu, co upraszcza wdrożenie, ale ogranicza elastyczność zarządzania siecią. W modelu SDN płaszczyzna sterowania jest scentralizowana w kontrolerze, który zarządza ścieżkami LSP i politykami routingu dla całej sieci, podczas gdy urządzenia sieciowe pełnią wyłącznie funkcję Data Plane. MPLS doskonale wpisuje się w tę koncepcję, ponieważ jego mechanizm przełączania etykiet jest naturalnie dostosowany do scentralizowanego zarządzania ścieżkami.
Operacja PUSH, zwana również imposition, jest wykonywana przez wejściowy router LER i rozpoczyna proces enkapsulacji pakietu IP w sieci MPLS. Gdy pakiet IP dociera do interfejsu klienckiego, router Ingress PE klasyfikuje go na podstawie adresu docelowego i przypisuje do odpowiedniego VRF, a następnie uzyskuje z tablic BGP i LDP odpowiednie etykiety usługową i transportową. Etykiety te są dodawane w odpowiedniej kolejności na wierzch pakietu przy jednoczesnej zmianie EtherType ramki Ethernet na 0x8847, co sygnalizuje odbiorcy, że ramka zawiera stos etykiet MPLS. Operacja PUSH może dodać jednocześnie wiele etykiet, tworząc hierarchiczny stos dla zaawansowanych usług.
Operacja SWAP jest najczęściej wykonywaną operacją w sieci MPLS i charakteryzuje się wyjątkową prostotą implementacyjną. Każdy router LSR na ścieżce LSP odczytuje górną etykietę przychodzącą, indeksuje tablicę LFIB i zastępuje ją etykietą wychodzącą wskazaną w znalezionym wpisie. Istotne jest, że SWAP nie zmienia liczby etykiet w stosie ani nie modyfikuje etykiet znajdujących się poniżej górnej. Router P działa wyłącznie na górnej etykiecie, co czyni tę operację niezwykle szybką i prostą pod względem implementacji w sprzęcie. Wpis w tablicy LFIB dla operacji SWAP zawiera trójkę: etykieta przychodząca, etykieta wychodząca i interfejs wyjściowy.
Operacja POP kończy proces transmisji w sieci MPLS i przywraca pakiet do standardowej postaci IP. Wykonywana jest przez router wyjściowy Egress PE lub, w ramach optymalizacji PHP, przez router przedostatni na ścieżce LSP. Po zdjęciu górnej etykiety router sprawdza bit S odsłoniętej etykiety: jeśli S jest ustawione na 0, stos zawiera kolejną etykietę i router kontynuuje przetwarzanie MPLS, natomiast jeśli S wynosi 1, router przechodzi do analizy nagłówka IP i dostarcza pakiet do docelowego interfejsu klienckiego. Operacja POP jest kluczowa dla poprawnego zakończenia tunelu i musi być wykonana z zachowaniem integralności całego stosu etykiet.
Penultimate Hop Popping to elegancki mechanizm optymalizacyjny, który eliminuje konieczność wykonywania przez router wyjściowy Egress PE dwóch następujących po sobie operacji: zdjęcia etykiety MPLS, a następnie wyszukiwania w tablicy FIB dla odsłoniętego pakietu IP. W scenariuszu bez PHP, router wyjściowy musiałby po otrzymaniu pakietu z etykietą MPLS najpierw wykonać POP, a potem standardowe wyszukiwanie LPM w tablicy routingu, co stanowi operację dwuetapową i zwiększa opóźnienie przetwarzania. PHP przenosi odpowiedzialność za zdjęcie górnej etykiety na router przedostatni, który i tak musi przetworzyć pakiet MPLS, więc dodatkowy koszt operacji POP jest znikomy.
Mechanizm PHP jest sygnalizowany za pomocą specjalnej etykiety Implicit Null o wartości 3, którą router Egress PE rozgłasza sąsiadom przez protokół LDP. Gdy router przedostatni odbiera wiadomość LDP z etykietą Implicit Null dla prefiksu docelowego, wie, że powinien wykonać operację POP na górnej etykiecie przed wysłaniem pakietu do następnego skoku. W tablicy LFIB routera przedostatniego pojawia się wówczas wpis z wartością Pop Label w kolumnie Outgoing Label, co nakazuje wykonanie operacji POP i wysłanie odsłoniętego pakietu do sąsiada. Dzięki temu router Egress PE otrzymuje już czysty pakiet IP lub pakiet z samą etykietą usługową.
Należy podkreślić, że PHP działa wyłącznie na górnej etykiecie transportowej i nie wpływa na etykiety usługowe znajdujące się niżej w stosie. W przypadku MPLS L3VPN, gdzie stos zawiera dwie etykiety, PHP zdejmuje tylko górną etykietę LDP, a router wyjściowy otrzymuje pakiet z samą etykietą VPN. Dzięki temu router Egress PE wykonuje tylko jedną operację POP dla etykiety VPN i ewentualnie wyszukiwanie w tablicy VRF, co minimalizuje opóźnienie przetwarzania na routerze wyjściowym. PHP jest domyślnie włączone we wszystkich głównych implementacjach MPLS i stanowi standardową optymalizację, która nie wymaga dodatkowej konfiguracji.
Label Distribution Protocol (LDP), zdefiniowany w RFC 5036, jest podstawowym protokołem dystrybucji etykiet w sieciach MPLS i odpowiada za automatyczne tworzenie mapowań między etykietami MPLS a prefiksami IP. Działanie LDP opiera się na nawiązywaniu sesji między sąsiednimi routerami za pomocą połączeń TCP na porcie 646. Proces rozpoczyna się od wysłania pakietów Hello na adres multicast 224.0.0.2, które umożliwiają wykrycie sąsiadów LDP w bezpośrednio podłączonych sieciach. Po wykryciu sąsiada routery nawiązują sesję TCP i wymieniają się informacjami o etykietach w trybie downstream unsolicited.
Dystrybucja etykiet w LDP przebiega dwuetapowo. W pierwszej fazie routery nawiązują sesje LDP z sąsiadami i negocjują parametry połączenia, w tym wersję protokołu oraz czas przetrzymywania sesji (hold time). W drugiej fazie każdy router generuje lokalną etykietę dla każdego prefiksu IP w swojej tablicy routingu, ze szczególnym uwzględnieniem adresów loopback, które służą jako identyfikatory LSR. Następnie router rozgłasza te mapowania wszystkim sąsiadom, co w efekcie prowadzi do utworzenia pełnej mapy etykiet w całej domenie MPLS. Każdy LSR może na tej podstawie zbudować kompletną tablicę LFIB, zawierającą wpisy dla wszystkich ścieżek LSP.
Istotną cechą LDP jest jego ścisłe uzależnienie od działania protokołu IGP. OSPF lub IS-IS musi działać poprawnie, zanim LDP zacznie dystrybuować etykiety, ponieważ to właśnie IGP dostarcza informacji o prefiksach IP niezbędnych do tworzenia mapowań. Jeśli w sieci występują problemy z IGP, LDP również będzie niestabilny, co może prowadzić do zrywania sesji i błędów w tablicy LFIB. LDP oferuje dwa tryby dystrybucji etykiet: downstream unsolicited (DU), w którym router aktywnie wysyła etykiety do sąsiadów bez wcześniejszego żądania, oraz downstream on-demand (DoD), w którym etykiety są wysyłane na żądanie. Zdecydowana większość implementacji produkcyjnych używa trybu DU jako domyślnego ze względu na szybszą konwergencję.
R1(config)# ip cef R1(config)# mpls ip ! Globalnie R1(config)# interface GigabitEthernet0/1 R1(config-if)# mpls ip ! Na interfejsie R1(config-if)# exit
Przed przystąpieniem do konfiguracji MPLS na routerze Cisco należy upewnić się, że spełnione są wszystkie wymagania wstępne, z których najważniejszym jest włączenie mechanizmu CEF poleceniem `ip cef`. CEF buduje ustrukturyzowane tablice FIB i adjacency table na podstawie tablicy routingu RIB, a MPLS bezpośrednio wykorzystuje te struktury do tworzenia tablicy LFIB. Na nowszych platformach Cisco CEF jest domyślnie aktywny, jednak na starszych routerach, takich jak seria 7200 czy 3800, może wymagać ręcznej aktywacji. Weryfikację stanu CEF można przeprowadzić poleceniem `show ip cef summary`, które pokazuje liczbę tras w tablicy FIB oraz liczbę brakujących wpisów.
Po potwierdzeniu działania CEF należy włączyć MPLS globalnie poleceniem `mpls ip`, które aktywuje zarówno protokół MPLS, jak i domyślny protokół dystrybucji etykiet LDP. W razie potrzeby można zmienić protokół dystrybucji etykiet na TDP, który jest starszym, proprietarnym protokołem Cisco, lub skonfigurować RSVP-TE dla potrzeb inżynierii ruchu. Kluczowym krokiem jest konfiguracja LSR-ID poleceniem `mpls ldp router-id loopback0 force`, który powinien wskazywać adres loopback, zapewniający stabilność sesji LDP niezależnie od stanu poszczególnych interfejsów fizycznych. Adres LSR-ID musi być osiągalny przez IGP dla wszystkich routerów w domenie MPLS.
Aktywacja MPLS na interfejsach odbywa się za pomocą polecenia `mpls ip` w konfiguracji interfejsu i powinna być ograniczona wyłącznie do interfejsów wewnętrznych skierowanych do rdzenia sieci. Interfejsy klienckie powinny pozostać w czystej postaci IP, bez aktywacji MPLS. Po skonfigurowaniu interfejsów router automatycznie rozpoczyna wysyłanie pakietów Hello LDP i nawiązuje sesje z sąsiednimi routerami. Weryfikację poprawności konfiguracji można przeprowadzić za pomocą poleceń `show mpls ldp neighbor` do sprawdzenia sąsiadów LDP oraz `show mpls interfaces` do potwierdzenia, które interfejsy mają włączony MPLS. Polecenie `show mpls ldp bindings` pozwala dodatkowo zweryfikować, jakie mapowania etykiet zostały odebrane od sąsiadów.
R1# show mpls ldp neighbor Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0 TCP connection: 2.2.2.2.646 - 1.1.1.1.49832 State: Oper; Msgs sent/rcvd: 15/14; Downstream R1# show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or VC or Tunnel Switched interface 16 17 2.2.2.2/32 0 Gi0/1 10.0.12.2 17 Pop Label 3.3.3.3/32 0 Gi0/1 10.0.12.2
Podstawowym narzędziem diagnostycznym w systemie Cisco IOS do weryfikacji działania LDP jest polecenie `show mpls ldp neighbor`, które wyświetla listę sąsiadów LDP wraz z ich adresami, identyfikatorami LDP, stanem sesji oraz statystykami wymienionych komunikatów. Sesja LDP powinna znajdować się w stanie Operational, co oznacza pełną wymianę etykiet między routerami. Jeśli sesja znajduje się w stanie Idle lub Broken, należy w pierwszej kolejności sprawdzić łączność IP między adresami transportowymi LDP za pomocą polecenia ping, a następnie zweryfikować działanie protokołu IGP. Polecenie `show mpls ldp neighbor` jest pierwszym i najważniejszym krokiem w diagnostyce problemów z MPLS.
Polecenie `show mpls forwarding-table` wyświetla tablicę LFIB używaną przez płaszczyznę danych do przełączania pakietów. Każdy wpis w tablicy zawiera lokalną etykietę przypisaną przez ten router, etykietę wyjściową, prefiks docelowy, interfejs wyjściowy oraz adres następnego skoku. Obecność wpisów w LFIB świadczy o poprawnym działaniu LDP i dystrybucji etykiet w domenie MPLS. Wartość Pop Label w kolumnie Outgoing Label informuje o konieczności wykonania PHP przez router przedostatni, natomiast wartość Untagged lub No Label może wskazywać na problem z dystrybucją etykiet dla danego prefiksu, wymagający dalszej diagnostyki.
Dodatkowymi przydatnymi poleceniami są `show mpls ldp bindings` do wyświetlenia wszystkich mapowań etykiet znanych routerowi, `show mpls interfaces` do weryfikacji interfejsów z włączonym MPLS oraz `show mpls ldp discovery` do podglądu procesu wykrywania sąsiadów. W trudnych przypadkach można użyć polecenia `debug mpls ldp events`, jednak należy zachować ostrożność, ponieważ generuje ono dużą ilość informacji i może obciążyć procesor routera produkcyjnego. W środowiskach laboratoryjnych zaleca się również testowanie ścieżek LSP za pomocą polecenia `ping mpls ipv4` z odpowiednimi parametrami, co pozwala zweryfikować integralność poszczególnych ścieżek LSP bez konieczności wysyłania ruchu użytkownika.
[admin@MikroTik] > /mpls ldp set enabled=yes transport-address=1.1.1.1 lsr-id=1.1.1.1 [admin@MikroTik] > /mpls ldp interface add interface=ether1 [admin@MikroTik] > /mpls ldp interface print Flags: X - disabled, I - invalid, D - dynamic # INTERFACE HELLO-INTERVAL HOLD-TIME TRANSPORT-ADDRESS 0 ether1 5s 15s 0.0.0.0
System RouterOS firmy MikroTik oferuje wsparcie dla MPLS od wersji 6.x, co umożliwia budowanie zaawansowanych sieci szkieletowych z wykorzystaniem stosunkowo niedrogiego sprzętu. Składnia konfiguracji MPLS w RouterOS różni się od Cisco IOS, ale jest logicznie spójna i dobrze udokumentowana w oficjalnym podręczniku. Podstawowym krokiem jest ustawienie LSR-ID oraz adresu transportowego dla LDP, którymi najczęściej jest adres loopback routera. Użycie adresu loopback zapewnia stabilność sesji LDP niezależnie od stanu poszczególnych interfejsów fizycznych, ponieważ adres ten jest zawsze osiągalny przez protokół IGP, o ile istnieje jakakolwiek ścieżka do routera docelowego.
Aktywacja LDP w RouterOS rozpoczyna się od polecenia `/mpls ldp set enabled=yes transport-address=1.1.1.1 lsr-id=1.1.1.1`, a następnie dodania interfejsów uczestniczących w wymianie etykiet za pomocą `/mpls ldp interface add interface=ether1`. RouterOS umożliwia konfigurację parametrów LDP takich jak Hello Interval (domyślnie 5 sekund) i Hold Time (domyślnie 15 sekund), które można dostosować do specyficznych wymagań sieci operatorskiej. Należy pamiętać, że protokół IGP musi być skonfigurowany przed LDP, ponieważ LDP wymaga znajomości prefiksów IP w tablicy routingu, aby móc przypisać im lokalne etykiety i rozgłosić mapowania sąsiadom.
MikroTik oferuje również zaawansowane funkcje MPLS, w tym VPLS do tworzenia rozległych sieci Ethernet L2VPN oraz L3VPN z wykorzystaniem VRF i MP-BGP. VPLS jest szczególnie popularny w środowiskach MikroTik, ponieważ umożliwia transparentne łączenie wielu lokalizacji klienta w jedną sieć warstwy 2. Konfiguracja VPLS polega na utworzeniu interfejsu VPLS dla każdej zdalnej lokalizacji z parametrami remote-peer i vpls-id, a następnie dodaniu tych interfejsów do mostka wraz z fizycznymi portami klienckimi. RouterOS w wersjach 7.x dodatkowo wspiera Segment Routing oraz zaawansowane mechanizmy QoS dla MPLS, co czyni go atrakcyjnym wyborem dla mniejszych operatorów i przedsiębiorstw.
[admin@MikroTik] > /mpls forwarding-table print # LABEL VRF PREFIX PATH INTERFACE NEXTHOP 0 16 2.2.2.2/32 ether1 10.0.12.2 1 17 3.3.3.3/32 ether1 10.0.12.2
Diagnostyka MPLS w systemie RouterOS opiera się na zestawie poleceń konsolowych umożliwiających szczegółową weryfikację wszystkich elementów konfiguracji. Podstawowym poleceniem jest `/mpls forwarding-table print`, które wyświetla tablicę LFIB z lokalnymi etykietami, prefiksami docelowymi, interfejsami wyjściowymi i adresami następnych skoków. Jeśli tablica forwardingowa jest pusta, oznacza to, że LDP nie dystrybuuje etykiet i należy w pierwszej kolejności sprawdzić działanie IGP oraz sąsiedztwo LDP. Warto zwrócić uwagę na kolumnę PATH, która wskazuje typ ścieżki LSP i może pomóc w identyfikacji problemów z routowaniem.
Stan sesji LDP można sprawdzić poleceniem `/mpls ldp neighbor print`, które wyświetla listę sąsiadów, ich adresy transportowe, stan sesji oraz statystyki wysłanych i odebranych komunikatów. Sesja LDP powinna znajdować się w stanie Operational. Jeśli sesja jest w stanie Idle lub Broken, należy sprawdzić łączność IP między adresami transportowymi LDP, najlepiej za pomocą ping z adresu loopback do adresu loopback sąsiada, oraz poprawność konfiguracji IGP. Problem może również wynikać z braku trasy do adresu transportowego sąsiada w tablicy routingu lub z niewłaściwie skonfigurowanego LSR-ID.
Dodatkowe polecenia diagnostyczne w RouterOS to `/mpls ldp binding print` do wyświetlenia wszystkich mapowań etykiet, `/mpls ldp interface print` do podglądu interfejsów z włączonym LDP oraz `/mpls ldp server print` do sprawdzenia globalnych ustawień serwera LDP. RouterOS umożliwia również testowanie ścieżek LSP za pomocą wbudowanego narzędzia `/tool mpls ping`, które pozwala na wysłanie pakietów testowych wzdłuż konkretnej ścieżki LSP i pomiar czasu odpowiedzi. W przypadku problemów warto sprawdzić logi systemowe za pomocą `/log print where topics=mpls` oraz upewnić się, że używana wersja RouterOS obsługuje wszystkie wymagane funkcje MPLS.
Usługi VPN w technologii MPLS stanowią główne źródło przychodów operatorów telekomunikacyjnych w segmencie klientów korporacyjnych i są jednym z kluczowych powodów wdrażania MPLS w sieciach szkieletowych. MPLS VPN umożliwiają tworzenie wirtualnie wydzielonych sieci prywatnych na współdzielonej infrastrukturze operatora, co eliminuje konieczność budowania dedykowanych łączy fizycznych między lokalizacjami klienta. Każdy klient otrzymuje gwarantowaną izolację swojego ruchu od innych klientów, a usługa jest całkowicie przezroczysta dla jego urządzeń końcowych. MPLS VPN mogą być skalowane od prostych połączeń między dwiema lokalizacjami po złożone sieci korporacyjne z setkami oddziałów.
L3VPN to rozwiązanie, w którym operator przejmuje odpowiedzialność za routing między lokalizacjami klienta, co znacząco odciąża dział IT klienta. Router PE przechowuje trasy klienta w dedykowanej instancji VRF i wymienia się nimi z innymi routerami PE za pomocą protokołu MP-BGP z rozszerzeniami dla adresacji VPNv4. Klient nie musi zarządzać routingiem między swoimi lokalizacjami, a jego router CE komunikuje się z PE za pomocą standardowych protokołów, takich jak BGP, OSPF czy trasy statyczne. L3VPN jest preferowany, gdy klient chce odciążyć swój zespół IT od zarządzania siecią rozległą i skoncentrować się na aplikacjach biznesowych.
L2VPN oferują przezroczyste połączenia warstwy 2, w których sieć operatora jest postrzegana przez klienta jako długi kabel w trybie punkt-punkt lub długi przełącznik w trybie punkt-wielopunkt. W L2VPN ramki Ethernet są transportowane przez sieć MPLS w oryginalnej postaci, z zachowaniem wszystkich znaczników VLAN, ramek STP BPDU i innych informacji warstwy 2. Rozwiązania L2VPN są idealne do łączenia centrów danych, migracji maszyn wirtualnych między lokalizacjami w ramach klastrów vMotion oraz w scenariuszach, gdzie klient chce zachować pełną kontrolę nad adresacją IP i routingiem w swoich lokalizacjach. Szczególnym przypadkiem L2VPN jest VPLS, który umożliwia komunikację wielu lokalizacji w jednej domenie L2.
VRF jest podstawowym mechanizmem izolacji ruchu w usługach MPLS L3VPN, który pozwala na współistnienie wielu niezależnych sieci na jednym fizycznym routerze PE. Każda instancja VRF tworzy wirtualny router z własną tablicą routingu, własną tablicą przekazywania, własnym zestawem interfejsów oraz własnymi protokołami routingu. Dzięki VRF różni klienci mogą używać tych samych adresów IP bez ryzyka kolizji, ponieważ ruch między instancjami VRF jest domyślnie blokowany, a dostęp do tras innych klientów jest możliwy wyłącznie poprzez jawną konfigurację route leaking. To sprawia, że VRF jest fundamentem separacji ruchu w sieciach operatorskich.
Konfiguracja VRF na routerze Cisco rozpoczyna się od utworzenia instancji poleceniem `ip vrf KLIENT_A`, a następnie zdefiniowania parametrów RD i RT w trybie konfiguracji VRF. RD jest niezbędny do utworzenia unikalnych prefiksów VPNv4, które są dystrybuowane przez MP-BGP, natomiast RT kontroluje import i eksport tras między VRF a sesjami MP-BGP. Po utworzeniu VRF należy przypisać do niego interfejsy za pomocą polecenia `ip vrf forwarding KLIENT_A` w konfiguracji interfejsu. Należy pamiętać, że przypisanie interfejsu do VRF automatycznie czyści jego adresację IP, którą trzeba skonfigurować ponownie po przypisaniu do VRF.
Liczba VRF na jednym routerze PE może sięgać od kilkudziesięciu do kilku tysięcy, w zależności od platformy sprzętowej i dostępnej pamięci RAM. Każdy VRF wymaga osobnej tablicy routingu, co oznacza, że im więcej VRF, tym większe zapotrzebowanie na pamięć i moc obliczeniową. Zarządzanie dużą liczbą VRF może być wyzwaniem, dlatego w środowiskach operatorskich stosuje się automatyzację za pomocą skryptów konfiguracyjnych, narzędzi SDN oraz systemów orkiestracyjnych. W praktyce często używa się scentralizowanego systemu zarządzania konfiguracją do provisioningu VRF i monitorowania ich stanu, co znacząco upraszcza administrację siecią.
Route Distinguisher to 64-bitowa wartość dodawana do prefiksu IP klienta w celu utworzenia globalnie unikalnego adresu VPNv4. Ponieważ różni klienci mogą używać nakładających się adresów IP, RD rozróżnia te trasy podczas dystrybucji przez MP-BGP. Format zapisu RD to najczęściej ASN:nn, gdzie ASN oznacza numer autonomicznego systemu klienta lub operatora, a nn jest dowolną liczbą. Możliwy jest również format IP-address:nn, w którym jako identyfikatora używa się adresu IP. Dzięki RD router PE może odróżnić prefiks 10.0.0.0/8 klienta A od tego samego prefiksu klienta B, co jest kluczowe dla zachowania separacji ruchu.
Route Target to atrybut BGP sterujący importem i eksportem tras między VRF a sesjami MP-BGP. Każdy VRF ma zdefiniowane dwie listy: Import RT określa, które atrybuty RT musi zawierać trasa, aby została zaimportowana do VRF, natomiast Export RT definiuje atrybuty dołączane do tras eksportowanych z VRF do MP-BGP. RT jest mechanizmem filtrowania, który decyduje o tym, które trasy VPN są dostępne w danym VRF. Dzięki odpowiedniej kombinacji Import RT i Export RT można precyzyjnie kontrolować topologię sieci VPN, tworząc pełne siatki połączeń, topologie hub-and-spoke lub izolowane grupy klientów z ograniczoną komunikacją między sobą.
W praktyce projektowej RD i RT są często identyczne dla prostych sieci VPN, ale mogą się różnić w bardziej złożonych scenariuszach. W topologii hub-and-spoke centrala ma Import RT obejmujący trasy oddziałów i Export RT oznaczający trasy centrali, podczas gdy oddziały eksportują swoje trasy wyłącznie do centrali, nie importując tras innych oddziałów. Dzięki temu ruch między oddziałami jest kierowany przez centralę, co umożliwia centralne zarządzanie bezpieczeństwem, filtrowanie ruchu i kontrolę dostępu do Internetu. Taka topologia jest powszechnie stosowana w sieciach korporacyjnych i stanowi jeden z najczęstszych przypadków użycia MPLS L3VPN.
MP-BGP jest rozszerzeniem standardowego protokołu BGP-4 zdefiniowanym w RFC 4760, które wprowadza możliwość przenoszenia tras dla różnych rodzin adresów, w tym adresów VPNv4 i VPNv6. W architekturze MPLS L3VPN każdy router PE ustanawia sesje MP-BGP z innymi routerami PE w domenie MPLS i wymienia się trasami VPNv4 za pośrednictwem tych sesji. MP-BGP przenosi nie tylko prefiksy sieci, ale również atrybuty takie jak RD, RT, etykieta VPN oraz informacje o następnym skoku. Dzięki MP-BGP routery PE mają pełen obraz topologii VPN w całej domenie MPLS, co pozwala na podejmowanie optymalnych decyzji routingowych.
Rola MP-BGP w dystrybucji etykiet VPN jest kluczowa, ponieważ każdy router PE dołącza do tras VPNv4 etykietę usługową identyfikującą konkretny VRF na routerze docelowym. Ta etykieta jest unikalna w skali danego PE i jest używana przez zdalne routery PE do określenia, do którego VRF skierować pakiet po zdjęciu etykiety transportowej. MP-BGP wykorzystuje mechanizm Next Hop do wskazania adresu loopback zdalnego PE, który jest następnie używany przez LDP do ustanowienia tunelu transportowego między PE. W ten sposób MP-BGP i LDP współpracują, tworząc kompletny system dystrybucji tras i etykiet dla L3VPN.
W praktyce MP-BGP jest konfigurowany na routerach PE z aktywacją odpowiedniej rodziny adresów za pomocą polecenia `address-family vpnv4`. Sesje MP-BGP między PE mogą być ustanawiane za pośrednictwem route reflectora w celu poprawy skalowalności, ponieważ w dużych sieciach operatorskich z setkami routerów PE pełna siatka sesji iBGP byłaby niepraktyczna. MP-BGP oferuje również zaawansowane mechanizmy filtrowania tras za pomocą polityk oraz atrybutów takich jak Local Preference i AS Path, które umożliwiają precyzyjne sterowanie przepływem ruchu VPN. Dzięki tym mechanizmom operatorzy mogą elastycznie kształtować topologię sieci VPN i optymalizować wykorzystanie zasobów.
VPWS, znany również jako EoMPLS lub xConnect, to usługa L2VPN typu punkt-punkt, która emuluje bezpośrednie połączenie kablowe między dwoma oddalonymi geograficznie lokalizacjami. Dla urządzeń klienta sieć operatora jest całkowicie przezroczysta, a ramki Ethernet wprowadzone na porcie PE w jednej lokalizacji pojawiają się na porcie PE w drugiej lokalizacji bez żadnych modyfikacji. VPWS jest często określany jako długi kabel, ponieważ zachowuje się jak zwykłe połączenie miedziane między przełącznikami, niezależnie od odległości geograficznej. Rozwiązanie to jest szczególnie przydatne w scenariuszach, gdzie klient potrzebuje prostego, niezawodnego połączenia między dwoma punktami.
VPWS przenosi kompletne ramki Ethernet w oryginalnej postaci, z zachowaniem wszystkich informacji warstwy 2, w tym tagów VLAN 802.1Q, ramek STP BPDU, protokołów CDP i LLDP oraz LACP. Dzięki temu VPWS jest rozwiązaniem uniwersalnym, które może przenosić dowolny protokół warstwy 3 i jest kompatybilne z urządzeniami różnych producentów. VPWS znajduje zastosowanie w łączeniu oddziałów firm w jednej podsieci L2, w połączeniach między centrami danych oraz w scenariuszach disaster recovery, gdzie wymagana jest transparentna migracja maszyn wirtualnych między lokalizacjami bez zmiany adresacji IP.
Konfiguracja VPWS na routerze Cisco polega na zdefiniowaniu pseudowire za pomocą polecenia `xconnect` w konfiguracji interfejsu, z podaniem adresu zdalnego PE i identyfikatora VC. Pseudowire może być ustanowiony z wykorzystaniem protokołu LDP lub BGP, które różnią się mechanizmem sygnalizacji i autodetekcji. VPWS jest stosunkowo prosty w konfiguracji, ale jego głównym ograniczeniem jest topologia punkt-punkt, co oznacza, że połączenie więcej niż dwóch lokalizacji wymaga oddzielnego pseudowire dla każdej pary. Dla topologii punkt-wielopunkt stosuje się VPLS, który umożliwia komunikację między wieloma lokalizacjami w ramach jednej, rozległej sieci Ethernet.
[admin@MikroTik] > /interface vpls add name=vpls1 remote-peer=2.2.2.2 vpls-id=10 [admin@MikroTik] > /interface bridge add name=bridge1 [admin@MikroTik] > /interface bridge port add bridge=bridge1 interface=ether2 [admin@MikroTik] > /interface bridge port add bridge=bridge1 interface=vpls1
VPLS to zaawansowana usługa L2VPN w topologii punkt-wielopunkt, która tworzy rozległą sieć Ethernet łączącą wiele lokalizacji klienta w ramach jednej domeny warstwy 2. W przeciwieństwie do VPWS, które łączy tylko dwie lokalizacje, VPLS umożliwia bezpośrednią komunikację między wszystkimi lokalizacjami tak, jakby były podłączone do jednego przełącznika Ethernet. VPLS jest często nazywany długim przełącznikiem i jest idealnym rozwiązaniem dla klientów, którzy chcą utrzymać jedną podsieć L2 między oddziałami, na przykład dla systemów wymagających rozgłaszania ARP lub korzystających z protokołu NetBIOS.
Konfiguracja VPLS na MikroTik wymaga utworzenia interfejsu VPLS dla każdej zdalnej lokalizacji za pomocą polecenia `/interface vpls add name=vpls1 remote-peer=2.2.2.2 vpls-id=10`. Parametr remote-peer wskazuje adres IP zdalnego routera PE, a vpls-id musi być identyczny na wszystkich uczestniczących routerach. Następnie wszystkie interfejsy VPLS oraz fizyczne porty klienckie są dodawane do jednego mostka za pomocą polecenia `/interface bridge port add`. RouterOS automatycznie zarządza uczeniem adresów MAC na mostku, co pozwala na efektywne przekazywanie ramek tylko do odpowiednich tuneli VPLS, minimalizując niepotrzebny ruch w sieci.
Zarządzanie pętlami L2 w sieci VPLS jest kluczowym wyzwaniem, ponieważ rozległa sieć Ethernet jest podatna na pętle, które mogą prowadzić do burzy broadcastowej i całkowitego zatrzymania usługi. Standardowym mechanizmem ochronnym jest Split Horizon na poziomie PE, który zapobiega wysyłaniu ramek odebranych z jednego tunelu VPLS do innych tuneli VPLS. W pełni połączona siatka VPLS z włączonym Split Horizon całkowicie eliminuje ryzyko pętli, ponieważ ramki są transmitowane wyłącznie między tunelami a portami klienckimi. Dodatkowo można włączyć STP na urządzeniach klienta, jednak w sieci rozległej konwergencja STP może trwać zbyt długo dla usług wrażliwych na czas.
Traffic Engineering w MPLS to zaawansowana funkcjonalność umożliwiająca operatorom świadome sterowanie przepływem ruchu w sieci szkieletowej, wykraczająca poza ograniczenia tradycyjnych protokołów IGP. Standardowe protokoły routingu zawsze wybierają najkrótszą ścieżkę według metryki kosztu, co może prowadzić do nieefektywnego wykorzystania zasobów sieci, gdy najkrótsza ścieżka jest przeciążona, a alternatywne trasy pozostają niewykorzystane. MPLS TE pozwala na jawne definiowanie ścieżek LSP dla różnych strumieni ruchu, umożliwiając optymalne wykorzystanie dostępnego pasma we wszystkich łączach sieci szkieletowej i zapobiegając powstawaniu wąskich gardeł.
MPLS TE wykorzystuje protokół RSVP-TE do sygnalizowania i rezerwowania zasobów wzdłuż ścieżki tunelu. Proces rozpoczyna się od wysłania wiadomości PATH z węzła początkowego Ingress wzdłuż zamierzonej trasy do węzła docelowego Egress. Każdy router na trasie może zaakceptować lub odrzucić rezerwację pasma w zależności od dostępnych zasobów, co gwarantuje, że ścieżka tunelu ma wystarczającą przepustowość. Po zaakceptowaniu rezerwacji router wysyła wiadomość RESV z powrotem do węzła początkowego, potwierdzając rezerwację. Po ustanowieniu tunelu TE ruch może być do niego kierowany na podstawie polityk routingu lub mapowania klas ruchu, co zapewnia elastyczność zarządzania.
Tunele MPLS TE są jednokierunkowe, co oznacza, że dla komunikacji dwukierunkowej wymagane są dwa tunele w przeciwnych kierunkach. Ścieżka tunelu może być wyznaczona jawnie jako lista konkretnych routerów, przez które pakiet musi przejść, lub dynamicznie za pomocą algorytmu CSPF. CSPF uwzględnia nie tylko koszt IGP, ale również dostępne pasmo na łączach, opóźnienia oraz inne ograniczenia zdefiniowane przez operatora. MPLS TE znajduje zastosowanie w optymalizacji wykorzystania łączy, zapewnianiu gwarantowanego pasma dla usług premium oraz w ochronie przed awariami za pomocą mechanizmu Fast Reroute, który przełącza ruch na zapasowe ścieżki w czasie poniżej 50 milisekund.
Fast Reroute to mechanizm ochrony przed awariami w sieciach MPLS, który zapewnia przełączenie ruchu na ścieżkę zapasową w czasie poniżej 50 milisekund, co stanowi standard telekomunikacyjny wymagany przez usługi wrażliwe na przerwy w transmisji. Dla porównania, tradycyjne protokoły IGP potrzebują od kilku do kilkudziesięciu sekund na wykrycie awarii, przeliczenie tras i aktualizację tablic routingu, co jest całkowicie nieakceptowalne dla usług czasu rzeczywistego, takich jak VoIP, IPTV czy transmisje wideo na żywo. FRR rozwiązuje ten problem poprzez preinstalację ścieżek zapasowych jeszcze przed wystąpieniem awarii.
FRR opiera się na koncepcji preinstalacji ścieżek zapasowych, zanim dojdzie do awarii chronionego elementu sieci. Operator lub automatyczny system CSPF wyznacza i rezerwuje tunele backupowe dla każdego chronionego łącza lub węzła, a tunele te są gotowe do natychmiastowego użycia i omijają chroniony element. Gdy dojdzie do awarii, router wykrywający ją na podstawie utraty sygnału lub braku ramek natychmiast przełącza ruch z tunelu głównego na tunel zapasowy za pomocą techniki protection switching. Proces ten jest realizowany w sprzęcie ASIC i nie wymaga interwencji płaszczyzny sterowania, co gwarantuje czas przełączenia poniżej 50 milisekund.
Wyróżniamy dwa podstawowe typy FRR: ochrona łącza, w której tunel zapasowy omija uszkodzone łącze między sąsiednimi routerami, oraz ochrona węzła, w której tunel zapasowy omija cały uszkodzony router, kierując ruch bezpośrednio do routera następnego po uszkodzonym. FRR może być implementowany z użyciem RSVP-TE lub z użyciem LDP. W nowoczesnych sieciach operatorskich coraz częściej stosuje się Segment Routing z mechanizmem TI-LFA, który oferuje ochronę przed awariami niezależną od topologii sieci i nie wymaga preinstalacji tuneli zapasowych, co znacząco upraszcza zarządzanie siecią.
traceroute pokazuje routery MPLS, stosując pewien mechanizm pomocniczy.ping mpls ipv4 10.0.0.1 - specjalne narzędzie do testowania poprawności ścieżek LSP (Label Switched Path).
Diagnostyka ścieżek LSP w sieci MPLS wymaga wyspecjalizowanych narzędzi, ponieważ standardowy ping ICMP i traceroute nie zawsze działają poprawnie wewnątrz domeny MPLS. Routery P w rdzeniu sieci często nie mają tras IP do adresów klientów ani do adresów loopback innych routerów P, ponieważ ich tablica routingu zawiera wyłącznie trasy do prefiksów IGP niezbędnych do utrzymania spójności sieci. Oznacza to, że standardowy ping ICMP Echo Request wysłany z pakietem MPLS może nie otrzymać odpowiedzi ICMP Echo Reply, ponieważ router P nie wie, jak wysłać pakiet powrotny do nadawcy.
Rozwiązaniem problemu diagnostyki LSP jest mechanizm ICMP Tunneling zdefiniowany w RFC 4950 (ICMP Extensions for MPLS). Gdy TTL pakietu MPLS wygaśnie na routerze P, router generuje komunikat ICMP Time Exceeded i enkapsuluje go w nowy pakiet MPLS, który jest wysyłany przez tunel do końca LSP. Stamtąd pakiet ICMP jest przekazywany do oryginalnego nadawcy. Dzięki temu narzędzia takie jak traceroute mogą działać w sieci MPLS, wyświetlając adresy IP routerów P na trasie LSP. Należy jednak pamiętać, że nie wszystkie implementacje routerów obsługują ICMP Tunneling, a w niektórych przypadkach traceroute może pokazywać gwiazdki zamiast adresów.
Specjalne narzędzie ping mpls dostępne na routerach Cisco pozwala na bezpośrednie testowanie ścieżek LSP z pominięciem warstwy IP. Polecenie `ping mpls ipv4 10.0.0.1` wysyła pakiet MPLS z etykietą dla prefiksu 10.0.0.1 i oczekuje odpowiedzi od routera końcowego LSP. Możliwe jest również testowanie konkretnych stosów etykiet za pomocą `ping mpls ipv4 10.0.0.1 label 16 17`, co pozwala na diagnostykę poszczególnych tuneli VPN. W systemie MikroTik podobną funkcję pełni narzędzie `/tool mpls ping`, które umożliwia testowanie ścieżek MPLS z określonymi etykietami i kontrolą ich integralności.
Problem MTU w sieciach MPLS wynika z narzutu wprowadzanego przez nagłówki etykiet, które zwiększają całkowity rozmiar ramki Ethernet. Standardowa ramka Ethernet ma maksymalny rozmiar 1518 bajtów, co pozwala na przenoszenie do 1500 bajtów ładunku warstwy 3. Gdy router dodaje pojedynczą etykietę MPLS, całkowity rozmiar ramki wzrasta do 1522 bajtów, a w przypadku L3VPN stosuje się dwie etykiety, co daje narzut 8 bajtów. Przy użyciu TE FRR może być trzy lub więcej etykiet, co daje narzut 12, 16 lub więcej bajtów. Jeśli łącze ma skonfigurowany standardowy MTU 1500, ramka z etykietami może zostać odrzucona.
Jeśli na łączu jest skonfigurowane standardowe MTU 1500, a ramka z etykietami MPLS przekracza 1518 bajtów, może dojść do odrzucenia pakietu lub fragmentacji IP, co znacząco obniża wydajność i zwiększa opóźnienia. Fragmentacja jest szczególnie problematyczna w kontekście MPLS, ponieważ etykiety są dodawane do pakietu po fragmentacji IP. Jeśli fragmentacja nastąpi przed dodaniem etykiet, poszczególne fragmenty mogą trafić do różnych routerów P, co może zakłócić działanie mechanizmów inżynierii ruchu i ochrony przed awariami. Dlatego zarządzanie MTU jest kluczowym aspektem projektowania sieci MPLS.
Rozwiązaniem problemu MTU w sieciach MPLS jest zwiększenie wartości MTU na wszystkich interfejsach uczestniczących w domenie MPLS do co najmniej 1504 bajtów dla jednej etykiety, a zalecane jest 1508-1526 bajtów dla obsługi dwóch lub więcej etykiet. W sieciach operatorskich często stosuje się Jumbo Frames z MTU 9000 bajtów, co całkowicie eliminuje problem narzutu MPLS i dodatkowo poprawia wydajność transmisji dużych pakietów. Należy pamiętać o skonfigurowaniu MTU na wszystkich urządzeniach na całej trasie transmisji, w tym na przełącznikach Ethernet między routerami, ponieważ brak spójności MTU jest jedną z najczęstszych przyczyn problemów wydajnościowych w sieciach MPLS.
Wybór odpowiedniego typu usługi MPLS VPN powinien być podyktowany wymaganiami biznesowymi klienta, jego kompetencjami technicznymi oraz architekturą sieci korporacyjnej. L3VPN jest zalecany dla klientów, którzy chcą odciążyć swój dział IT od zarządzania routingiem między lokalizacjami, ponieważ operator przejmuje pełną odpowiedzialność za dystrybucję tras i zapewnienie łączności IP. Klient widzi operatora jako kolejny skok routingu, a jego router CE komunikuje się z PE za pomocą standardowych protokołów. L3VPN oferuje najwyższą skalowalność i elastyczność, ale wymaga zaufania do operatora w zakresie zarządzania routingiem i bezpieczeństwem.
VPWS jest najprostszym i najbardziej transparentnym rozwiązaniem, idealnym dla klientów potrzebujących połączenia między dwiema lokalizacjami w jednej podsieci warstwy 2. VPWS jest często stosowany do łączenia oddziałów firm, połączeń między centrami danych oraz w scenariuszach disaster recovery. VPLS rozszerza koncepcję VPWS na wiele lokalizacji, tworząc rozległą sieć Ethernet, w której wszystkie lokalizacje klienta znajdują się w jednej domenie L2. VPLS jest preferowany, gdy aplikacje klienckie wymagają bezpośredniego dostępu L2 między lokalizacjami, na przykład dla systemów wykorzystujących rozgłaszanie ARP, protokoły NetBIOS lub migrację maszyn wirtualnych.
Każdy z typów VPN ma swoje zalety i ograniczenia. L3VPN jest najbardziej skalowalny i łatwy w zarządzaniu, ale nie oferuje przezroczystości warstwy 2. VPWS jest prosty i przezroczysty, ale ograniczony do topologii punkt-punkt. VPLS oferuje pełną łączność L2 między wieloma lokalizacjami, ale wymaga zarządzania pętlami i może być podatny na problemy związane z burzami broadcastowymi. W praktyce operatorskiej często stosuje się kombinację różnych typów VPN w zależności od potrzeb klienta, na przykład L3VPN dla dostępu do Internetu i aplikacji korporacyjnych oraz VPLS dla połączeń między centrami danych wymagających przezroczystości L2.
Segment Routing stanowi naturalną ewolucję technologii MPLS, adresującą główne ograniczenia klasycznej architektury, czyli złożoność płaszczyzny sterowania i konieczność utrzymywania stanu LSP na każdym routerze. W klasycznym MPLS każdy router LSR musi utrzymywać stan dla każdej ścieżki LSP, a protokoły LDP i RSVP-TE wymagają nawiązywania sesji, wymiany komunikatów i utrzymywania tablic stanu. Segment Routing wprowadza koncepcję source routing, w której to węzeł początkowy decyduje o całej ścieżce pakietu i koduje tę informację w nagłówku jako listę segmentów, eliminując potrzebę utrzymywania stanu LSP w routerach pośrednich.
Segment ID są dystrybuowane przez rozszerzenia protokołów IGP, bez potrzeby stosowania osobnych protokołów dystrybucji etykiet. Każdy router ogłasza swój Node SID identyfikujący router oraz Adjacency SID dla każdego swojego łącza. Dzięki temu każdy router w domenie ma pełną wiedzę o topologii sieci i może zbudować dowolną ścieżkę jako listę segmentów. Aby utworzyć tunel SR, węzeł początkowy tworzy stos etykiet odpowiadający żądanej ścieżce i wysyła pakiet z tym stosem do sieci. Routery pośrednie wykonują operacje na stosie etykiet zgodnie z instrukcją zawartą w nagłówku, bez potrzeby odwoływania się do lokalnych tablic stanu LSP.
Segment Routing oferuje szereg istotnych zalet w porównaniu do klasycznego MPLS: eliminację protokołów LDP i RSVP-TE, lepszą skalowalność, zaawansowane mechanizmy ochrony przed awariami oraz wsparcie dla inżynierii ruchu bez rezerwacji pasma. SR może działać zarówno na płaszczyźnie MPLS, jak i na płaszczyźnie IPv6, gdzie segmenty są kodowane w rozszerzeniach nagłówka IPv6. Segment Routing jest wspierany przez wszystkich głównych producentów sprzętu sieciowego i jest obecnie standardem w nowych wdrożeniach sieci szkieletowych, szczególnie w kontekście automatyzacji SDN i zarządzania sieciami w modelu intent-based networking.
Technologia MPLS oferuje szereg istotnych zalet, które uczyniły ją standardem w sieciach operatorskich na całym świecie i fundamentem nowoczesnych usług telekomunikacyjnych. Przede wszystkim MPLS umożliwia konsolidację wielu usług na jednej, wspólnej infrastrukturze szkieletowej, co znacząco obniża koszty inwestycyjne i operacyjne w porównaniu do budowania osobnych sieci dla każdej usługi. Wirtualizacja sieci za pomocą mechanizmów VRF i pseudowire pozwala na logiczną separację ruchu różnych klientów na współdzielonej infrastrukturze, zapewniając izolację porównywalną z sieciami fizycznie odizolowanymi.
Jakość usług w MPLS jest realizowana za pomocą 3-bitowego pola EXP w nagłówku etykiety, które umożliwia klasyfikację ruchu do ośmiu klas. Routery MPLS na podstawie wartości EXP stosują odpowiednie mechanizmy kolejkowania i szeregowania, co pozwala na zagwarantowanie niskich opóźnień i małych drgań dla ruchu wrażliwego na czas, takiego jak VoIP czy transmisje wideo na żywo. QoS w MPLS jest szczególnie istotny w scenariuszach, gdzie na jednym łączu są przesyłane zarówno dane krytyczne dla biznesu, jak i zwykły ruch internetowy klientów. Odpowiednie skonfigurowanie polityk QoS pozwala operatorowi na spełnienie wymagań SLA dla usług premium.
MPLS jest agnostyczny protokołowo, co oznacza, że może przenosić IPv4, IPv6, ramki Ethernet, a nawet starsze protokoły takie jak IPX czy ATM, co czyni go uniwersalnym rozwiązaniem transportowym. Bezpieczeństwo w MPLS VPN jest zapewnione przez ścisłą separację na poziomie VRF, gdzie ruch między różnymi instancjami VRF jest domyślnie blokowany. MPLS nie zapewnia szyfrowania danych w przeciwieństwie do IPsec, ale izolacja na poziomie sieci jest uznawana za wystarczającą dla większości zastosowań korporacyjnych. W razie potrzeby izolacja MPLS może być łączona z szyfrowaniem MACsec lub IPsec na poziomie łącza, co zapewnia kompleksowe zabezpieczenie transmisji.
Przykład podróży pakietu przez sieć MPLS L3VPN obrazuje praktyczne zastosowanie wszystkich mechanizmów omówionych w tej części kursu w jednym, spójnym scenariuszu end-to-end. Proces rozpoczyna się na urządzeniu klienta CE1, które wysyła standardowy pakiet IP do routera PE1 przez interfejs przypisany do VRF klienta. PE1 odbiera pakiet na interfejsie VRF, analizuje adres docelowy w tablicy routingu VRF i stwierdza, że trasa do celu wiedzie przez zdalny router PE2 za pośrednictwem sieci szkieletowej MPLS. Na podstawie tablicy LFIB, PE1 wykonuje podwójną operację PUSH: najpierw dodaje etykietę VPN pochodzącą z MP-BGP, a następnie etykietę transportową z LDP kierującą pakiet do adresu loopback PE2.
Ramka Ethernet z dwoma etykietami MPLS opuszcza PE1 i wchodzi do sieci szkieletowej operatora. Na każdym routerze P na trasie między PE1 a PE2 wykonywana jest operacja SWAP na górnej etykiecie transportowej, gdzie router odczytuje górną etykietę, znajduje odpowiadający wpis w LFIB, zamienia ją na etykietę wychodzącą i przekazuje pakiet przez odpowiedni interfejs. Routery P nie analizują dolnej etykiety VPN ani nie zaglądają do nagłówka IP, a ich zadanie sprowadza się do szybkiego przełączania na podstawie górnej etykiety, realizowanego w układach ASIC z maksymalną szybkością. Proces SWAP jest powtarzany na każdym przeskoku, aż pakiet dotrze do przedostatniego routera przed PE2.
Router przedostatni na ścieżce LSP wykonuje PHP, zdejmując górną etykietę transportową i wysyłając do routera PE2 pakiet zawierający wyłącznie etykietę VPN. PE2 otrzymuje pakiet, odczytuje etykietę VPN i na jej podstawie identyfikuje właściwy VRF oraz interfejs wyjściowy klienta. Po zdjęciu etykiety VPN, PE2 wysyła czysty pakiet IP do routera CE2, który dostarcza go do docelowego hosta w sieci klienta. Cały proces jest całkowicie przezroczysty dla urządzeń klienta, które widzą wyłącznie standardowe pakiety IP i nie mają świadomości istnienia infrastruktury MPLS. Ta przezroczystość, w połączeniu z elastycznością i skalowalnością MPLS, stanowi kluczową wartość komercyjną usług VPN dla klientów korporacyjnych.
Trzecia część kursu dostarczyła kompleksowej wiedzy o technologii MPLS, która stanowi fundament współczesnych sieci szkieletowych operatorów telekomunikacyjnych na całym świecie. W trakcie wykładu poznaliśmy architekturę MPLS, budowę nagłówka etykiety, rodzaje routerów oraz fundamentalny podział na płaszczyznę sterowania i płaszczyznę danych. Omówiliśmy protokół LDP odpowiadający za automatyczną dystrybucję etykiet między routerami oraz trzy podstawowe operacje na etykietach, ze szczególnym uwzględnieniem mechanizmu PHP optymalizującego działanie routera wyjściowego. Każdy z tych elementów został przedstawiony w kontekście praktycznych zastosowań w sieciach operatorskich.
Kluczową część materiału stanowiły usługi MPLS VPN, zarówno L3VPN z mechanizmem VRF, RD i RT, jak i L2VPN umożliwiające tworzenie przezroczystych połączeń warstwy 2. Przedstawiliśmy również zaawansowane funkcjonalności, takie jak Traffic Engineering z protokołem RSVP-TE do świadomego sterowania ruchem, Fast Reroute zapewniający ochronę przed awariami w czasie poniżej 50 milisekund oraz problematykę MTU w sieciach MPLS. Praktyczne przykłady konfiguracji na routerach Cisco IOS i MikroTik RouterOS umożliwiły studentom zrozumienie różnic między platformami i samodzielne eksperymenty w laboratorium.
MPLS to nie tylko technologia transportowa, ale przede wszystkim platforma usługowa umożliwiająca operatorom świadczenie wielu usług na jednej, współdzielonej infrastrukturze z zachowaniem izolacji i gwarancji jakości. Segment Routing, będący ewolucją MPLS, wskazuje kierunek rozwoju w stronę prostszych, bardziej skalowalnych i sterowanych programowo sieci SDN. W czwartej części kursu omówimy technologię SDH, która przez dekady stanowiła kręgosłup sieci telekomunikacyjnych na całym świecie i wciąż jest obecna w wielu infrastrukturach operatorskich, szczególnie w zakresie transmisji głosu i dzierżawionych łączy.