Materiały przygotowawcze do laboratorium

Materiały przygotowawcze do laboratorium Badanie właściwości wieloprotokołowej komutacji etykietowej MPLS (Multi-Protocol Label Switching). Wznawianie pracy po wystąpieniu uszkodzenia w sieciach rozległych Piotr Chołda, Mirosław Kantor 21 marca 2011 Przed zajęciami należy dokładnie zapoznać się z niniejszym materiałem. 1 Podstawy 1.1 Wieloprotokołowa komutacja etykietowa MPLS Wieloprotokołowa komutacja etykietowa MPLS (Multi-Protocol Label Switching) została opracowana pod koniec lat 90-tych. W stosunku do podstawowej koncepcji protokołu IP (Internet Protocol), według której głównym zadaniem urządzeń sieciowych jest tylko dostarczenie informacji do odbiorcy, technika MPLS dodaje wiele nowych funkcji. Jest to odpowiedź na rosnące zapotrzebowanie na oferowanie różnych poziomów jakości obsługi QoS (Quality of Service) oraz zapewnienie szybkiego wznawiania pracy po wystąpieniu uszkodzenia w sieci rozległej. Technika MPLS współpracuje z tradycyjnymi siecimi pakietowymi IP, przyspieszając przetwarzanie datagramów oraz umożliwiając odpowiednie zarządzanie ruchem (np. metody optymalizowania użycia zasobów przy równoczesnym wdrożeniu QoS, tj. mechanizmy inżynierii ruchu TE, Traffic Engineering). Technika ta, obecnie coraz cześciej używana (nie tylko w sieciach szkieletowych) znacznie upraszcza proces zarządzania i sterowania siecią oraz zmniejsza koszty utrzymania sieci. Podstawową ideą techniki MPLS jest komutowanie pakietów na podstawie 20-bitowej etykiety. 32-bitowy nagłówek MPLS (przedstawiony na rys. 1, str. 2; proszę pamiętać, że nagłówków MPLS może następować kilka po kolei, tzn. mogą tworzyć stos) składa się ze wspomnianej etykiety; bitu S, Stack używanego do określania wierzchołka stosu etykiet; pola TTL, Time to Live pełniącego funkcje analogiczne jak pole o tej samej nazwie w nagłówku IP (służące do ochrony przed zapętleniem pakietów w sieci). Ponadto, pole Exp może służyć do określania jakości obsługi. Pakiet IP wchodzący do sieci MPLS jest przez ruter brzegowy LER 1 (Label Switching Router, LSR, Edge Router) przypisywany do tzw. klasy równoważności przekazywania FEC (Forwarding Equivalence Class). Klasa ta służy do grupowania wszystkich paketów, które są ze sobą powiązane (np. pakiety pochodzą z jednej sesji TCP albo ze względu na reguły zarządzania ruchem powinny być obsługiwane w jednakowy sposób, np. przechodzić w sieci tą samą trasą). Przydzielenie do danej klasy FEC odbywa się głównie na podstawie nagłówka IP i ewentualnie nagłówka protokołu warstwy transportowej (adres źródłowy i docelowy 2, pole TOS, Type of Service, przenoszony protokół, port nadawcy i odbiorcy) oraz interfejsu wejściowego, ale może być również dokonywane na podstawie określonych przez klienta wymagań związanych z jakością połączenia (tj. żądanej wartości przepływności, opóźnienia, poziomu odporności 1 Albo ruter wejściowy. Por. dalsze objaśnienia. 2 Domyślnie dzieje się to tylko na podstawie adresu docelowego. Strona 1

Nagłówek warstwy łącza danych Nagłówek MPLS Nagłówek warstwy sieciowej Etykieta Label Exp S TTL 0 19 20 22 23 24 31 Rysunek 1: Format nagłówka MPLS i jego umiejscowienie na tle nagłówków innych warstw modelu OSI/ISO. Pola: Exp trzybitowe pole do określania poziomu QoS (nazwa eksperymentalne ma znaczenie historyczne), S wskaźnik wierzchołka stosu (hierarchii) etykiet, TTL ośmiobitowe pole czas życia. na uszkodzenia itp.). Na podstawie przypisania pakietu do klasy FEC ruter brzegowy przydziela pakiet do odpowiedniego tunelu MPLS. Następnie do pakietu dodawany jest nagłówek MPLS z odpowiednią etykietą, która posłuży następnemu ruterowi pośredniczącemu LSR do odpowiedniego skierowania pakietu w ramach ścieżki LSP (Label Switching Path), aktualnie obsługującej tunel MPLS związany z daną FEC. Tunel może być oczywiście również tworzony wewnątrz domeny MPLS (a nie tylko między ruterami LER). Ruter początkowy dla tunelu nazywa się ruterem wejściowym (ingress router), natomiast końcowy ruterem wyjściowym (egress). Etykieta ma typowo znaczenie jedynie lokalne; ruter pośredniczący dokonuje na etykiecie (po uwzględnieniu interfejsu wejściowego) operacji ze zbioru trzech podstawowych działań na etykiecie: swap, push i pop. Według wcześniejszych koncepcji, to dopiero rutery końcowe obsługujące dany tunel usuwały nagłówki MPLS, ale w celu przyśpieszenia przekazywania pakietów funkcję tę przejął przedostatni ruter z punktu widzenia danej ścieżki LSP. Do wymiany informacji o topologii sieci rutery używają tradycyjnych protokołów trasowania typu link state: OSPF (Open Shortest Path First) czy IS-IS (Intermediate System-to-Intermediate System), ewentualnie poszerzonych o mechanizmy inżynierii ruchu TE (warto pamiętać, że w niektórych sytuacjach istnieje również możliwość użycia protokołu BGP). W sytuacji gdy ścieżka LSP jest tworzona automatycznie, a nie zadawana wprost przez administratora (typ explicit), protokoły rutingu są stosowane do wyznaczenia jej przebiegu (zazwyczaj w węźle, w którym zaczyna się ścieżka, tzw. ruting źródłowy, source-based routing). Technika MPLS wykorzystuje również protokoły sygnalizacyjne LDP (Label Distribution Protocol) i RSVP (ReSource reservaton Protocol) w celu zarządzania połączeniami (m.in. dystrybucja etykiet, rezerwacja przepływności) i zapewnienia działania mechanizmów inżynierii ruchu. Protokoły sygnalizacyjne umożliwiają kontrolę przepływu danych, pomagają zapewnić QoS, informują o uszkodzeniach łączy lub węzłów oraz uczestniczą w przełączaniu na ścieżki zapasowe. 1.1.1 Protokół sygnalizacji LDP W związku z tym że MPLS używa etykiet do przekazywania ruchu przez sieć, potrzebny jest mechanizm do ich dystrybuowania. W tym celu powstał protokół LDP (Label Distribution Protocol). W celu przesłania pakietu za pomocą MPLS rutery muszą mieć uruchomiony protokół LDP. Skonfigurowane urządzenia zaczną dystrybuować powiązania etykiet z adresami IP z tablicy rutingu. Dzięki temu każdy ruter utworzy u sobie tablicę LIB (Label Information Base), zawierająca odwzorowania etykiet wejściowych na wyjściowe. LDP pełni cztery główne funkcje: wykrywanie urządzeń LSR z uruchomionym protokołem LDP, Strona 2

zestawianie i podtrzymywanie sesji LDP (w oparciu o protokoły transportowe zarówno TCP jak i UDP), dystrybuowanie etykiet oraz wysyłanie powiadomień o wystąpieniu zdarzeń. Rutery LSR wysyłają komunikaty LDP Hello na wszystkich interfejsach, na których został uruchomiony protokół LDP. Służą one do wykrywania sąsiadów oraz podtrzymywania zestawionej wcześniej sesji. Wiadomości LDP Hello są wysyłane na adres grupowy (multikastowy) 224.0.0.2. Urządzenie które otrzyma taką wiadomość jest informowane, że na tym interfejsie sąsiaduje z nim ruter LDP. Wiadomości Hello zawierają zegary przetrzymania (hold timers, wartość domyślna to: 15 s). Jeżeli w tym czasie żadna wiadomość Hello nie zostanie odebrana od sąsiada, zostanie on usunięty z tablicy sąsiadów LDP (mechanizm podobny jak w przypadku działania protokołów rutingu typu link state). Kiedy dwa rutery LSR dowiedzą się o sobie dzięki wymianie wiadomości LDP Hello spróbują zestawić sesję LDP między sobą. Zestawienie jej odbywa się w dwóch etapach: ustanowienie połączenia warstwy transportowej (TCP), inicjalizacja sesji LDP. Najpierw rutery wymieniają się wiadomościami LDP Hello zestawiając sąsiedztwo LDP. Jeżeli nie istniała między nimi sesja, urządzenie próbuje utworzyć połączenie TCP z sąsiadem. Gdy zostanie ono ustanowione następuje inicjalizacja sesji LDP. W jej trakcie zachodzi negocjacja parametrów takich jak: wersja protokołu LDP, metoda dystrybucji etykiet, parametry czasowe (np. czas przetrzymania). Pomyślne zakończenie negocjacji skutkuje powstaniem sesji LDP między sąsiadami oraz wymianą informacji nt. LIB. 1.1.2 Protokół sygnalizacji RSVP(-TE) RSVP (Resource ReSerVation Protocol) jest protokołem, który zaprojektowano w celu dostarczania aplikacjom internetowym, a dokładniej generowanemu przez nie ruchowi, różnych poziomów jakości obsługi QoS (pierwotnie planowano jego użycie łącznie z IntServ). Dotyczy to przede wszystkim rezerwacji zasobów (pierwotnie przepływność, później np. etykiety). Wiadomości protokołu RSVP nie korzystają z żadnego protokołu transportowego (są wprost przenoszone w datagramach IP). Protokół ten jest wykorzystywany przez rutery w celu zapewnienia odpowiedniej jakości usług żądanych we wszystkich węzłach komunikacyjnych wzdłuż określonej ścieżki transmisji strumieni danych, głosu, obrazu itp. RSVP został opracowany w celu współpracy z istniejącymi protokołami rutingu. Protokół ten dobrze współdziała również z techniką MPLS. Protokół RSVP-TE (Resource ReSerVation Protocol with Traffic Engineering extensions) jest rozszerzeniem protokołu RSVP, które powstało w celu zestawiania ścieżek LSP w sieciach MPLS. Nowymi funkcjami protokołu jest dystrybucja etykiet, jak również przenoszenie informacji o tunelu MPLS. Tunel pozwala na implementację różnych polityk obsługi ruchu w celu optymalizacji działania sieci. Protokół ten pomaga w zestawieniu ścieżki LSP rozsyłając do wszystkich urządzeń, które mają uczestniczyć w transmisji wiadomości: Path w kierunku wysyłania danych, Resv w kierunku przeciwnym do transmitowanych danych. Wiadomość RSVP Path używa pola LABEL REQUEST do zażądania powiązania etykiety wejściowej z wyjściową w każdym węźle. Pole SESSION ATTRIBUTE zawarte w RSVP Path określa atrybuty ścieżki LSP (np. priorytet, wymagany poziom protekcji). Pole EXPLICIT ROUTE zawiera ścieżkę, którą podąża Strona 3

wiadomość RSVP Path. Wiadomość RSVP Resv używa z kolei bloku LABEL do dystrybucji etykiet. Pole RECORD ROUTE obecne zarówno w RSVP Path, jak i RSVP Resv gromadzi informacje o węzłach/etykietach, które zostały odwiedzone/przyznane po drodze. W ten sposób wiadomości RSVP Resv przenoszą numery etykiety nadanej danemu węzłowi w kontekście określonego tunelu, dzięki czemu nowa ścieżka zostaje zestawiona. Rezultatem żądania RSVP będzie rezerwacja zasobów w każdym węźle należącym do ścieżki, ale tylko w jednym kierunku (tunele są jednokierunkowe). Proces RSVP korzystając w węźle wejściowym z lokalnej tablicy rutingu stara się dobrać przebieg ścieżki LSP do określonego rutera końcowego (na tym polega właśnie ruting źródłowy). RSVP nie jest więc odpowiedzialny za wybór trasy. W praktyce rezerwacja etykiet za pomocą RSVP wygląda następująco: ruter wejściowy dla tunelu (ścieżki) generuje wiadomość RSVP Path, która jest przesyłana do kolejnych urządzeń na trasie aż do rutera kończącego tunel (ścieżkę). W odpowiedzi ruter kończący ścieżkę generuje wiadomość RSVP Resv, która jest przesyłana do każdego węzła na ścieżce. W trakcie trwania tej operacji każdy ruter na ścieżce dokonuje rezerwacji zasobów (o ile nimi dysponuje). Oprócz omówionych wcześniej wiadomości Path i Resv, RSVP używa kilku innych. Służą one głównie do poinformowania o wystąpieniu jakiegoś problemu. PathTear jest wysyłana przez ruter w celu powiadomienie o usunięciu aktywnej ścieżki. ResvTear jest odpowiedzią na PathTear. PathErr jest to wiadomość przesyłana w kierunku urządzenia wejściowego. Najbardziej prawdopodobną przyczyną jej wygenerowania jest uszkodzenie łącza, a co za tym idzie przerwanie ścieżki lub niepowodzienie w ustanowieniu ścieżki. 1.1.3 Przykład podstawowej konfiguracji MPLS na ruterze Cisco Poniżej przedstawiono wycinek konfiguracji pewnego rutera, na którym uruchomiono przełączanie pakietów za pomocą MPLS: hostname Router ip cef mpls ldp router-id Loopback0 interface Loopback0 ip address 10.0.0.22 255.255.255.255 interface FastEthernet0/1 ip address 192.168.4.22 255.255.255.0 mpls ip no shutdown interface FastEthernet1/0 ip address 192.168.6.22 255.255.255.0 mpls ip no shutdown Na ruterze o nazwie Router dystrybucja etykiet (domyślnie za pomocą protokołu LDP) została uruchomiona na dwóch interfejsach FastEthernet komendą mpls ip. Polecenie ip cef służy do uruchomienia mechanizmu CEF (Cisco Express Forwarding). Jest to metoda przyspieszonego przełączania pakietów stosowana przez urządzenia Cisco: mechanizm ten używa zaawansowanego algorytmu służącego do unikania rekursywnego przeszukiwania tablicy rutingu. Mechanizm CEF jest niezbędny do uruchomienia MPLS na ruterach Cisco (inne mechanizmy służące do przełączania pakietów IP na tych ruterach nie mogą działać wspólnie z MPLS). Strona 4

Komendy interface Loopback0 i ip address 10.0.0.21 255.255.255.255 uruchamiają wirtualny interfejs Loopback0 o adresie 10.0.0.22/32. Dzięki komendzie mpls ldp router-id Loopback0 adres ten identyfikuje ruter z punktu widzenia protokołu LDP (za pomocą tej komendy można również ustawić inny identyfikator rutera; komenda służy do wymuszenia identyfikatora, w przypadku ustawionego interfejsu loopback mogłoby jej nie być). 1.1.4 Przykład konfiguracji MPLS-TE na ruterze Cisco Z tunelem powiązane są następujące elementy: rutery kończące tunelu, przypisana przepływność, priorytety, przypisane ścieżki. Zakończeniem tunelu jest identyfikator rutera wyjściowego. Najczęściej jest to ustanowiony wcześniej adres interfejsu loopback. Przypisana przpływność (bandwidth) określa wymaganą wartość dla tego tunelu. Tunel MPLS TE konfiguruje się na urządzeniu wejściowym. Można go utworzyć na dwa sposoby: statycznie (explicit) i dynamicznie (dynamic). Według pierwszej z metod, należy określić wszystkie węzły tworzące tunel, za pomocą ich identyfikatorów, lub po prostu za pomocą odpowiednich adresów IP interfejsów. Według drugiej natomiast, wystarczy zdefiniować miejsce docelowe. Ruter na podstawie informacji uzyskanych przez protokół rutingu określi najlepszą ścieżkę dla niego (zestawienie zostanie dokonane przez RSVP). Z punktu widzenia rutera Cisco, tunel jest wirtualnym interfejsem. Dla jednego tunelu można skonfigurować do 1000 ścieżek rozróżnianych za pomocą parametru path option. Im mniejsza jego wartość, tym ścieżka jest bardziej preferowana w stosunku do innych ścieżek zdefiniowanych dla tego tunelu. W sytuacji, kiedy żadna ze ścieżek nie będzie mogła zostać zestawiona, cały interfejs zostanie wyłączony. Z każdym tunelem są powiązane dwa priorytety: setup i hold. Niższa wartość wskazuje na wyższy priorytet. Parametr setup związany jest z nowo zestawianymi ścieżkami LSP. Hold określa stosunek do zarezerwowanych zasobów im wyższa wartość, tym tunel ten jest bardziej skłonny do rezygnacji z nich: w przypadku próby utworzenia dodatkowego tunelu, w sytuacji kiedy nie można mu zapewnić wystarczającej szerokości pasma z powodu zajęcia zasobów przez już istniejące tunele, nowa ścieżka zostanie zestawiona, jeżeli wartość setup dla związanego z nią tunelem będzie mniejsza (wyższy priorytet) od wartości hold tunelu konkurencyjnego. Fragment konfiguracji przedstawiono poniżej: hostname Router mpls traffic-eng tunnels interface Loopback0 ip address 10.0.0.21 255.255.255.255 interface Tunnel0 ip unnumbered Loopback0 tunnel destination 10.0.0.22 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 explicit name LSP1 tunnel mpls traffic-eng path-option 2 dynamic name LSP2 router ospf 1 mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 network 10.0.0.21 0.0.0.0 area 0 Strona 5

network 192.168.2.0 0.0.0.255 area 0 network 192.168.7.0 0.0.0.255 area 0 network 192.168.9.0 0.0.0.255 area 0 ip explicit-path name LSP1 enable next-address 192.168.2.31 next-address 192.168.4.33 next-address 192.168.10.34 next-address 192.168.11.22 next-address 10.0.0.22 mpls ldp router-id Loopback0 mpls traffic-eng tunnels uruchamia MPLS-TE na ruterze Router. W przedstawionej konfiguracji został skonfigurowany jeden interfejs tunelu Tunnel0. Komenda interface Tunnel0 uaktywnia go, umożliwiając administratorowi konfigurację. Zakończenie tunelu wskazuje na ruter z identyfikatorem 10.0.0.22/32 (komenda tunnel destination 10.0.0.22). Z kolei komenda ip unnumbered Loopback0 wiąże adres IP interfejsu Loopback0 z początkiem tunelu. tunnel mode mpls traffic-eng konfiguruje tryb tunelu na TE, natomiast dzięki komendzie tunnel mpls traffic-eng autoroute announce tunel będzie rozgłaszany przez protokół rutingu wewnętrznego: w tablicy rutingu pojawi się Tunnel0. Wartość 512 podana w komendzie tunnel mpls traffic-eng bandwidth 100 określa wymaganą dla niego przepływność w kb /s. Oprócz tego zastosowano dwie metody zestawienia ścieżki. Pierwsza ze ścieżek, LSP1, została wpisana ręcznie (typ explicit, por. komenda tunnel mpls traffic-eng path-option 1 explicit name LSP1), węzeł po węźle (komenda ip explicit-path i następnie name LSP1 enable next-address 192.168.2.31... ). Gdyby jednak zawiodła, MPLS TE spróbuje zestawić drugą ścieżkę (LSP2) dynamicznie na podstawie znajomości topologii sieci dostarczonej przez protokół rutingu (por. komenda tunnel mpls traffic-eng path-option 2 dynamic name LSP2). Prorytety tunelu są definiowane za pomocą polecenia: tunnel mpls traffic-eng priority 1 1 (pierwsza jedynka odnosi się do setup, a druga do hold). W protokole rutingu (tutaj: OSPF) również definiuje się parametry związane z MPLS-TE: mpls traffic-eng router-id Loopback0 określa identyfikator rutera dla procesu Traffic Engineering i pozwala na rozgłaszanie interfejsu Loopback0 w procesie rutingu. Natomiast mpls traffic-eng area 0 uaktywnia MPLS TE dla obszaru 0.0.0.0 OSPF. 1.2 Odporność sieci rozległych na uszkodzenia We współczesnych sieciach rozległych szybka i efektywna reakcja na uszkodzenia jest niezwykle istotna, ze względu na dużą przepływność łączy (utrata dużej ilości danych w przypadku dłużej trwających niezdatności) oraz zróżnicowanie oferowanych usług. Łatwość realizacji niektórych procedur wznawiania pracy w MPLS wynika ze zorientowania tej techniki na połączenie. Wskutek tego ruch z łączy niezdatnych w wyniku wystąpienia uszkodzenia można bardzo łatwo i szybko przekierować na alternatywne połączenia i to w miejscu najbliższym uszkodzenia, zapewniając oszczędne użycie zasobów (ponieważ nie są one blokowane po uszkodzeniu, wobec czego można je przydzielić nowym połączeniom). Dotyczy to głównie procedur protekcyjnych (proaktywnych). Technika MPLS, w związku z tym, że korzysta z transmisji pakietowej, nie wyklucza jednak procedur odtworzeniowych (reaktywnych), które również mają swoje zalety (wydajność, decentralizacja samodzielność działania). 1.2.1 Wznawianie pracy w sieciach opartych na MPLS-TE MPLS TE zapewnia różne metody wznawiania pracy: Strona 6

1. odtwarzanie (domyślny mechanizm MPLS) zwane przekierowaniem LSP (LSP reroute); 2. protekcja: globalna; lokalna (tzw. FRR: fast re-route): facility backup, one-to-one backup. Przekierowanie LSP jest do domyślna technika MPLS TE służąca do przywracania ruchu w tunelu. Opiera się tylko na konfiguracji dodatkowych opcji ścieżek dla tunelu (path option). W razie wykrycia awarii na czynnej ścieżce LSP, ruter wejściowy tunelu jest o niej informowany za pomocą tzw. sygnału FIS (Fault Indication Signal). W praktyce jest to albo uaktualnienie protokołu rutingu albo wiadomość RSVP PathErr. Następnie ruter wejściowy zestawia nową ścieżkę, którą sygnalizuje za pomocą protokołu RSVP. Z punktu widzenia niezawodności protekcja globalna jest dużo bardziej efektywną metodą niż odtwarzanie. W przypadku protekcji 1 : 1 dla każdego tunelu zestawiana jest oprócz ścieżki roboczej również ścieżka zapasowa, dlatego nie jest to metoda dobrze skalowalna. Ważne jest, aby obie ścieżki miały jak najmniej punktów wspólnych. Najlepiej, żeby były całkowicie rozłączne oprócz oczywiście ich punktów końcowych. W razie wykrycia uszkodzenia ruch jest natychmiast przekierowywany na wcześniej zasygnalizowaną ścieżkę LSP. Protekcja lokalna odnosi się tylko do fragmentu roboczej ścieżki LSP (pojedynczego łącza lub węzła). Podobnie jak w przypadku globalnej protekcji ścieżki, zapasowa LSP musi być wcześniej zasygnalizowana. Jest jednak od niej szybsza i lepiej skalowalna, ze względu na to, że z tej samej rezerwowej LSP może korzystać więcej niż jeden tunel (protekcja typu 1 : N). W metodzie tej po wystąpieniu uszkodzenia ścieżka robocza jest enkapsulowana w tunelu zapasowym, który ma obiegać uszkodzone łącze lub niezdatny węzeł. W metodzie o nazwie facility backup tworzony jest pojedynczy tunel wznawiający na raz pracę wiele ścieżek korzystających z chronionego łącza (węzła). W kontraście do niej protekcja one-to-one (znowu przykład 1 : 1) wymaga osobnej rezerwowej ścieżki LSP, która jest tworzona w węźle sąsiadującym z chronionym łączem (węzłem) dla każdej ścieżki, której pracę się wznawia. Jest to rozwiązanie niezbyt skalowalne, za to zapewniające najwyższy poziom niezawodności. 1.2.2 Przykład konfiguracji wznawiania pracy z użyciem MPLS na ruterze Cisco Przykład konfiguracji dla odtwarzania podano poniżej: interface Tunnel0 ip unnumbered Loopback0 tunnel destination 10.0.0.2 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 dynamic name LSP1 W przypadku uszkodzenia na ścieżce LSP1, ruter przeliczy i zasygnalizuje ją ponownie. Przykład konfiguracji dla protekcji globalnej 1 : 1: interface Tunnel0 ip unnumbered Loopback0 tunnel destination 10.0.0.8 Strona 7

tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 explicit name LSP1 tunnel mpls traffic-eng path-option 2 explicit name LSP1P Dla tunelu Tunnel0 ustanawia się dwie ścieżki: LSP1 i LSP1P. Ta drugia nie musi być w przypadku wystąpienia uszkodzenia na LSP1 obliczana, ale należy ją zasygnalizować przed użyciem. Przykład konfiguracji dla protekcji globalnej 1 + 1: interface Tunnel0 ip unnumbered Loopback0 tunnel destination 10.0.0.8 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 explicit name LSP1 tunnel mpls traffic-eng path-option protect 1 explicit name LSP1P Komenda tunnel mpls traffic-eng path-option protect 1 explicit name LSP1P definiuje ścieżkę protekcyjną LSP1P, sygnalizowaną przed wystąpieniem uszkodzenia na LSP1. Przykład konfiguracji dla protekcji lokalnej typu facility backup (na ruterze, w którym zaczyna się chroniony tunel Tunnel0): interface Tunnel0 ip unnumbered Loopback0 tunnel destination 10.0.0.8 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 1 1 tunnel mpls traffic-eng bandwidth 100 tunnel mpls traffic-eng path-option 1 explicit name LSP1 tunnel mpls traffic-eng fast-reroute Polecenie tunnel mpls traffic-eng fast-reroute oznacza, że ścieżki związane z tunelem Tunnel0 będą chronione za pomocą protekcji lokalnej. W wiadomości RSVP Path służącej do utworzenia ścieżki LSP1 w obiekcie SESSION ATTRIBUTE zostaje ustawiona flaga 0x01 oznaczająca żądanie użycia protekcji lokalnej. Ruter, w którym ma zostać dokonane przełączenie tunelu (ruter sąsiadujący z chronionym łączem/węzłem za pomocą interfejsu Serial0/0/0), tzw. PLR (Point of Local Repair) powinien w konfiguracji zawierać następujące elementy: hostname PLR interface Tunnel1 ip unnumbered Loopback0 tunnel destination 10.0.0.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng path-option 1 explicit name LSP1FB Strona 8

interface Serial0/0/0 ip address 192.168.6.2 255.255.255.0 mpls traffic-eng tunnels mpls ip ip rsvp bandwidth 1024 1024 mpls traffic-eng backup-path Tunnel1 no shutdown ip explicit-path name LSP1FB enable next-address 192.168.7.5 next-address 192.168.8.6 next-address 192.168.9.3 next-address 10.0.0.3 Tunel zapasowy Tunnel1 jest powiązany z chronionym łączem przyłączonym do interfejsu Serial0/0/0 za pomocą komendy mpls traffic-eng backup-path Tunnel1. Komenda ip rsvp bandwidth 1024 1024 włącza RSVP na konkretnym interfejsie. Dodatkowo można za jej pomocą skonfigurować wielkość przepływności, jaka musi być zarezerwowana dla całego interfejsu (wartość pierwsza) oraz dla pojedynczego strumienia danych (wartość druga). Wartości te podawane są w kb /s. 1.3 Przydatne komendy służące do wyświetlania aktualnej konfiguracji rutera Poniżej podano kilka komend, które mogą się przydać w trakcie laboratorium do wyświetlania konfiguracji związanej z MPLS (czasem można zastępować mpls przez tag-switching). Podglądanie utworzonych tuneli MPLS: show mpls traffic-eng tunnels; Wyświetlenie tablicy przełączania dla rutera: show mpls forwarding-table show mpls forwarding-table <address> show mpls forwarding-table <address> detail; Wyświetlenie informacji, które interfejsy biorą udział w komutacji etykietowej: show mpls interfaces; Wyświetlenie informacji specyficznej dla MPLS nt. interfejsu/ów: show mpls interfaces <interface> details; Wyświetlenie parametrów konfiguracyjnych protokołu LDP: show mpls ldp parameters; Podgląd informacji na temat węzłów sąsiadujących z punktu widzenia protokołu LDP: show mpls ldp discovery [detail]; Wyświetlenie sesji TCP związanych z LDP: show mpls ldp neighbor [<address>] [detail]; Strona 9

Wyświetlenie bazy etykiet LIB dla protokołu LDP: show mpls ldp bindings show mpls ip binding; Wyświetlenie liczby komunikatów wysłanych i odebranych w ramach protokołu RSVP: show ip rsvp counters; Wyświetlenie ogólnej informacji nt. RSVP: show ip rsvp installed; Wyświetlenie ruterów sąsiadujących z punktu widzenia protokołu RSVP: show ip rsvp neighbor; Wyświetlenie informacji nt. TE: show mpls traffic-eng link-management admission-cont; show mpls traffic-eng link-management advertisements; show mpls traffic-eng link-management bandwidth-alloc; show mpls traffic-eng link-management igp-neighbors; show mpls traffic-eng link-management interfaces; show mpls traffic-eng link-management summary; show mpls traffic-eng forwarding-adjacency; show mpls traffic tunnel backup; show mpls traffic-eng fast-reroute database; show mpls traffic-eng tunnels; show mpls traffic-eng tunnels summary; Wyświetlanie przychodzących komunikatów protokołu LDP: debug mpls ldp messages received; Wyświetlenie bazy FIB procesu CEF zawierającej przypisania etykiet: show ip cef [<address>] detail. 2 Zadania do samodzielnego wykonania przed laboratorium Przygotowanie do zajęć polega na samodzielnym zapoznaniu się z podstawami MPLS oraz metodami zapewniania wznawiania pracy po wystąpieniu uszkodzeniu w kontekście sieci MPLS. Przede wszystkim trzeba zaznajomić się z następującymi koncepcjami: idea przełączania etykietowego, podstawy inżynierii ruchu, koncepcja automatycznego wznawiania pracy po wystąpieniu uszkodzenia w sieciach rozległych, trasowanie i sygnalizacja w sieciach rozległych. Zalecane pozycje literatury: Strona 10

pozycja podstawowa: [1, rozdz. 1-4, 8, 12-14]; pozycje uzupełniające (mniej więcej w sugerowanej kolejności sięgnięcia): [2 11]; wykłady dra Wajdy do przedmiotu. Następnie, należy dokładnie przeczytać polecenia do wykonania w trakcie laboratorium. Przed przystąpieniem do laboratorium prowadzący sprawdzi (na ocenę) wiedzę uczestników. Osoby, które nie będą posiadały dostatecznej wiedzy na temat opracowywany w ramach laboratorium, będą zmuszone odrabiać zajęcia w innym terminie. Uwaga: informacje zawarte w sekcji 1 niniejszego dokumentu są z pewnością niewystarczające do poprawnego wykonania laboratorium sięgnięcie do zalecanej literatury jest więc niezbędne. Pytania do samodzielnego przestudiowania Należy przygotować się do wyczerpujących odpowiedzi na poniższe zagadnienia: 1. Opisać nagłówek MPLS, znaczenie zawartych w nim pól i miejsce MPLS w stosie protokołów. 2. Omówić relację między TTL w nagłówku IP i MPLS oraz zmiany pola TTL w przypadku różnych operacji na etykietach, a także zachowanie sieci w przypadku wyzerowania pola. 3. Scharakteryzować pulę etykiet zastrzeżonych i związanych z nimi właściwości sieciowych. 4. Scharakteryzować rozróżnienie między bazami RIB, LIB i LFIB. 5. Omówić metody dystrybucji etykiet w sieci MPLS. 6. Opisać rodzaje definiowania przestrzeni etykiet w sieciach MPLS. 7. Omówić wszystkie operacje dokonywane na etykietach (nagłówkach etykiet) w sieci MPLS na ruterach Cisco. 8. Omówić przydatność MPLS do realizacji Traffic Engineering. 9. Opisać różnice między przekazywaniem pakietów w IP a przełączaniem etykietowym. 10. Podać różnice między metodami wznawiania pracy nazywanymi protekcja i odtwarzanie. 11. Scharakteryzować różnice między metodami protekcyjnymi 1 : 1 i 1+1, a także między 1 : 1 i 1 : N. 12. Omówić sens hierarchizacji (zagnieżdżania) ścieżek LSP w MPLS. 13. Omówić koncepcję FEC. 14. Omówić rolę i działanie protokołu RSVP-TE w MPLS-TE. 15. Omówić rolę wewnątrzdomenowych protokołów trasowania w MPLS. 16. Opisać problemy wynikające ze zróżnicowanego działania wewnątrzdomenowego protokołu trasowania i protokołu LDP. Strona 11

Literatura [1] L. De Ghein, MPLS Fundamentals. Cisco Press, Inc. Indianapolis 2007. [2] C. Filsfils, J. Evans, MPLS Tutorial. Cisco Systems, 2001. http://www.ripe.net/ripe/meetings/ripe-39/presentations/mpls-arch/sld001.html [3] P. Brittain, A. Farrel, MPLS Traffic Engineering: A Choice of Signaling Protocols. Analysis of Similarities and Differences Between the Two Primary MPLS Label Distribution Protocols: RSVP and CR-LDP. Data Connection Limited. http://www.dataconnection.com/network/download/whitepapers/crldprsvp.pdf [4] Cisco Systems, Resource Reservation Protocol. http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/rsvp.pdf [5] E. Harrison, A. Farrel, B. Miller, Protection and Restoration in MPLS Networks. Data Connection Limited. http://www.dataconnection.com/network/download/whitepapers/mplsprotwp2.pdf [6] Trillium c, Multiprotocol Label Switching (MPLS). Web ProForum Tutorial. http://www.iec.org/online/tutorials/acrobat/mpls.pdf [7] Cisco Systems, MPLS/Tag Switching. http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/mpls_tsw.pdf [8] R. Stankiewicz, A. Jajszczyk, Wieloprotokołowa komutacja etykietowa (MPLS) i jej rola w zapewnianiu jakości usług w sieciach IP. Przegląd Telekomunikacyjny + Wiadomości Telekomunikacyjne, nr 4, 2002. [9] E. Rosen, A. Viswanathan, and R. Callon, Multiprotocol Label Switching Architecture, RFC 3031, 2001. [10] Cisco Systems, Multiprotocol Label Switching Architecture White Papers. http://www.cisco.com/en/us/products/ps6609/prod_white_papers_list.html [11] L. Andersson, P. Doolan, N. Feldman, A. Fredette and B. Thomas, LDP Specification, RFC 3036, 2001. Strona 12