modified on 29 gru 2009 at 09:49 ••• 7 284 views

Tunele TE

Z MikroTik Wiki

Spis treści

Wprowadzenie

Wprowadzenie do MPLS i wsparcia usług MPLS w RouterOS zobacz Wprowadzenie do MPLS.

Tunele MPLS RSVP TE są sposobem zestawienia dwukierunkowych, komutowanych etykietowo ścieżek. Ogólnie RSVP TE ma podobne zastosowanie jak dystrybucja etykiet przy pomocy protokołu LDP - zestawienie ścieżki komutowanej etykietami, zapewniającej dostarczenie ramek z routera wejściowego do wyjściowego, z kilkoma dodatkowymi możliwościami:

  • zestawienie ścieżki komutowanej etykietami przy użyciu znania całej lub części trasy;
  • wymuszenie zestawienia w oparciu o LSP - ścieżka komutowana etykietami jest zestawiana na łączach spełniających wymagania, jak szerokość pasma i właściwości łącza


MPLS RSVP TE oparty jest o protokół RSVP z rozszerzeniami przedstawionymi w RFC 3209 dodające wsparcie sprecyzowanej trasy i wymiany etykiet.

Wymuszenia zestawienia ścieżki są kontrolowane przez administratora - na przykład, pasmo łącza wykorzystywane w sieci RSVP TE ustawiane jest przez administratora i nie musi odzwierciedlać prawdziwej szerokości pasma łącza. W taki sam sposób pasmo zarezerwowane przez tunel ustalane jest przez administratora i nie sugeruje automatycznie ograniczeń ruchu przesyłanego przez tunel. W dowolnym momencie dostępne pasmo dla łącza TE jest szerokością pasma określoną dla danego łącza minus suma wszystkich rezerwacji na łączu, a nie fizycznie dostępne pasmo, które może być mniejsze (gdy dane są forwardowane przez tunele z prędkością przekraczającą zarezerwowane pasmo dla tunelu lub forwardowane są dane nie przechodzące przez tunel RSVP) lub mniejsze (gdy dane są forwardowane przez tunele z mniejszą prędkością niż zarezerwowana dla tunelu) niż pasmo możliwe do zarezerwowania.

Tunele RSVP TE są inicjalizowane przez (początek (router wejściowy) tunelu. Router początkowy wysyła wiadomość RSVP Path zawierającą wymagane parametry do końca tunelu. Routery wzdłuż ścieżki zapewniają, że mogą przesłać wiadomość Path do następnego skoku, biorąc pod uwagę wymagania dla ścieżki. Gdy wiadomość Path osiągnie koniec tunelu, router końcowy wysyła wiadomość RSVP Resv w przeciwnym kierunku. Wiadomość Resv podróżuje dokładnie tą samą ścieżką co wiadomość Path, tylko w przeciwnym kierunku. Każdy router forwardujący wiadomość Resv rezerwuje wymagane pasmo na odpowiednim łączu, jeśli jest to możliwe. Gdy router początkowy odbierze wiadomość Resv odpowiadającą wysłanej wiadomości Path, tunel może być uznany za zestawiony. Tunel jest utrzymywany poprzez okresowe odświeżanie stanu używając wiadomości Path i Resv.

Tunele RSVP TE mogą być zestawione z kilkoma parametrami ścieżki:

  • wzdłuż ścieżki, która dane są kierowane z początku do końca tunelu - w tym przypadku każdy router wzdłuż ścieżki tunelu określi następny skok dla tunelu w oparciu o tablice routingu. Jeśli trasa nie zostanie odnaleziona, lub interfejs odbierający nie może spełnić wymagań (na przykład gdy wymagane pasmo jest większe niż pasmo dostępne), tunel nie może zostać zestawiony.
  • wzdłuż statycznie skonfigurowanej dokładnie sprecyzowanej ścieżki - każdy router wzdłuż ścieżki tunelu określa następny skok w oparciu o ściśle określoną trasę wpisaną w wiadomości Path. Trasa może być całkowicie określona (określone są wszystkie routery wzdłuż trasy w odpowiedniej kolejności) lub częściowo określona (określone są jedynie niektóre routery, przez które musi przechodzić trasa). Aby określić router następnego skoku, każdy router wzdłuż ścieżki wyszukuje trasę do następnego routera w listy trasy ściśle określonej. Jeśli trasa nie zostanie odnaleziona, lub interfejs odbierający nie może spełnić wymagań, tunel nie może zostać zestawiony.
  • Określona Najpierw Najkrótsza Ścieżka - w tym przypadku początkowy router oblicza trasę do końca używając swojej mapy sieci - parametry łączy i dostępne pasma. Opcja potrzebuje wsparcia protokołu routingu IGP (np OSPF) aby rozsyłać informację o paśmie przez sieć. Gdy używany jest CSPF, początkowy router oblicza trasę spełniającą wymagania i wytwarza z góry określoną trasę dla wiadomości Path. Jeśli nie można obliczyć trasy spełniającej wymagania, tunel nie może zostać zestawiony. Dynamicznie obliczana trasa może być częściowo określona z góry - w takim przypadku CSPF wyszukuje najkrótszą ścieżkę, spełniającą wymagania, pomiędzy każdymi dwoma określonymi z góry skokami. Jeśli trasa jest cała określona z góry i używany jest CSPF, CSPF sprawdza, czy ścieżka spełnia wymagania biorąc po uwagę wiedzę danego węzła o stanach łączy w sieci - zamiast niepowodzenia zestawiania tunelu podczas przesyłania wiadomości Path przez sieć, wiadomość Path nie jest wogóle wysyłana, ponieważ od razu wiadomo, że nie uda się zestawić tunelu.

Forwardowanie ruchu przez tunele TE

Początek tunelu RSVP TE pojawia się jako interfejs w RouterOS. Tunele RSVP TE są dwukierunkowe - nie ma potrzeby posiadania odpowiedniego tunelu w przeciwnym kierunku. Gdy router końcowy odbiera dane przesłane przez tunel, odbierając je z tunelu bez etykiety tunelu TE usuniętą przez przedostatni skok (zachowanie niedomyślne) lub z etykietą explicit-null, która zostaje usunięta i pakiet przetwarzany jest dalej (jeśli etykieta tunelu jest ostatnią etykietą w stosie, pakiet jest routowany, w przeciwnym wypadku przetwarzany jest dalej w oparciu o następną etykietę na stosie, tak jak np pakiet VPLS). Tunel dwukierunkowy może być symulowany poprzez utworzenie jednego tunelu w jednym kierunku i drugiego w drugim kierunku pomiędzy tymi samymi punktami końcowymi. Nie będą liczone żadne dane odebrane przez Tunel TE, ponieważ w rzeczywistości obydwa tunele nie są ze sobą powiązane.

Jednym sposobem forwardowania ruchu przez tunel jest użycie routingu, ale ogranicza to użycie tunelu TE tylko do routowanych pakietów IP.

Dodatkowo, kilka typów ruchu może automatycznie być przesyłane przez tunel TE, jeśli wiadomo, że ruch przeznaczony jest do punktu końcowego tunelu i tunel jest aktywny:

  • ruch, który jest kierowany używając trasy otrzymanej z BGP, jeśli następny skok BGP jest punktem końcowym tunelu (do domyślne zachowanie może być zmieniona poprzez ustawienie parametru trasy "use-te-nexhop_ na "no"), obydwie - normalna IP i VPNv4 (MP-BGP IP VPN) trasy należą do tej kategorii
  • ruch dla interfejsów VPLS, jeśli zdalny punkt końcowy pseudołącza VPLS jest taki sam jak punkt końcowy tunelu TE.

Na przykład, dla trasy IP BGP posiadającej następny skok BGP x.x.x.x, metoda forwardowania zostanie wybrana w oparciu o poniższe reguły:

  • jeśli tunel TE z punktem końcowym x.x.x.x jest aktywny, użyj go;
  • w przeciwnym wypadku, jeśli otrzymywane jest mapowanie etykiet LDP z następnego skoku do x.x.x.x, użyj go;
  • w innym razie użyj normalnego trasowania (bez enkapsulacji MPLS).

W podobny sposób, jeśli zdalny adres pseudołącza VPLS jest x.x.x.x, metoda forwardowania zostanie wybrana wg poniższej kolejności:

  • jeśli tunel TE z punktem końcowym x.x.x.x jest aktywny, użyj go;
  • w przeciwnym wypadku, jeśli otrzymywane jest mapowanie etykiet LDP z następnego skoku do x.x.x.x, użyj go;
  • w innym razie tunel VPLS nie może być aktywny.

Tunele TSVP TE jako sposób zestawienia LSP mogą być używane razem z LDP. Użycie RSVP TE nie zamienia ani wyłącza LDP, ale LSP zestawione po tunelu TE zazwyczaj jest preferowane nad zestawione z użyciem LDP.

Przykładowa Sieć

Rozważmy tą samą sieć, która używana jest w przykładzie dla sygnalizacji LDP w VPLS w LDP i VPLS oparty o LDP:

Image:VPLS.png

Klient A chce zestawić IP VPN pomiędzy swoimi 3 miejscami i klient B chce przezroczyste połączenie dla segmentów ethernetowych do wszystkich swoich miejsc.

Wymagania MPLS TE

W ogólności, wymagania MPLS TE są takie same jak te opisane w LDP i VPLS oparty o LDP z kilkoma małymi szczegółami:

  • domyślnie końcowy router tunelu TE rozsyła etykietę explicit-null i z tego powodu wyskakiwanie przedostatneigo skoku nie zachodzi (celem użycia etykiety explicit-null jest rozesłanie informacji QoS w polu Exp etykiety MPLS), więc głównym celem posiadania "zwrotnego" adresu IP dla każdego router jest zapewnienie, że punkty końcowe tunelu nie będą zależne od zmian stanu łącza;
  • w celu użycia wyboru ścieżki CSPF dla tuneli, OSPF musi być skonfigurowany i włączone w sieci.

Włączanie obsługi TE

W celu użycia OSPF do dystrybucji informacji TE , parametry OSPF powiązane z TE muszą być ustawione:

[admin@R1] > /routing ospf set mpls-te-area=backbone mpls-te-router-id=lobridge

To mówi OSPF aby dystrybuował informację TE w sieci szkieletowej używając adresu IP "lobridge" jako ID routera.

Aby router mógł brać udział w tunelu TE (jako początek, koniec lub router pośredniczący) musi być włączone wsparcie TE. Wsparcie TE musi być włączone na wszystkich interfejsach obierających i wysyłających pakiety protokołu RSVP TE. Na R1 robi się to poprzez polecenia (interfejs ether3 należy do sieci 1.1.1.0/24): In order for router to be able to participate in TE tunnel (either as head-end, tail-end or forwarding router), TE support must be enabled. TE support must be enabled on all interfaces that will receive and

[admin@R1] > /mpls traffic-eng interface add interface=ether3 bandwidth=100000

To konfiguruje interfejs ether3 ze wsparciem TE i pasmem 100000 Bps. Inne routery konfigurowane są w podobny sposób.

Jak tylko włączone zostanie wsparcie TE na interfejsie, odpowiednie nieprzezroczyste LSA jest dystrybuowane w obszarze OSPF. Na przykład, na R1 można zauważyć, że jest łącznie 15 nieprzezroczystych LSA w bazie LSA:

[admin@R1] > /routing ospf lsa print 
  ...
backbone                                                          opaque-area  1.0.0.0        1.1.1.2        0x80000004      1038      
backbone                                                          opaque-area  1.0.0.0        2.2.2.3        0x80000004      1039      
backbone                                                          opaque-area  1.0.0.0        3.3.3.4        0x80000004      1038      
backbone                                                          opaque-area  1.0.0.0        4.4.4.5        0x80000004      1038      
backbone                                                          opaque-area  1.0.0.0        11.11.11.1     0x80000004      1037      
backbone                                                          opaque-area  1.0.0.1        1.1.1.2        0x80000004      1038      
backbone                                                          opaque-area  1.0.0.1        2.2.2.3        0x80000004      1039      
backbone                                                          opaque-area  1.0.0.1        3.3.3.4        0x80000004      1037      
backbone                                                          opaque-area  1.0.0.1        4.4.4.5        0x80000004      1038      
backbone                                                          opaque-area  1.0.0.2        1.1.1.2        0x80000004      1038      
backbone                                                          opaque-area  1.0.0.2        2.2.2.3        0x80000004      1039      
backbone                                                          opaque-area  1.0.0.2        3.3.3.4        0x80000004      1037      
backbone                                                          opaque-area  1.0.0.2        4.4.4.5        0x80000004      1038      
backbone                                                          opaque-area  1.0.0.3        2.2.2.3        0x80000004      1039      
backbone                                                          opaque-area  1.0.0.3        11.11.11.1     0x80000004      1037 
  ...

Tworzenie prostego tunelu TE

Załóżmy, że chcemy utworzyć tunel TE z R1 do R5. Aby to zrobić, należy utworzyć specyfikacje ścieżki tunelu:

[admin@R1] > /mpls traffic-eng tunnel-path add use-cspf=yes name=dyn

Zostanie stworzony szablon ścieżki dla czysto dynamicznej ścieżki używającej CSPF.

Następnie należy utworzyć tunel TE:

[admin@R1] /interface traffic-eng> add name=te1 bandwidth=1000 primary-path=dyn from-address=9.9.9.1 to-address=9.9.9.5 disabled=no record-route=yes

Możemy monitorować tunel aby zobaczyć jego stan:

[admin@R1] /interface traffic-eng> monitor 0
             tunnel-id: 7
    primary-path-state: established
          primary-path: dyn
  secondary-path-state: not-necessary
           active-path: dyn
          active-lspid: 1
          active-label: 29
        explicit-route: "S:1.1.1.2/32,S:2.2.2.2/32,S:2.2.2.3/32,S:4.4.4.3/32,S:4.4.4.5/32"
        recorded-route: "1.1.1.2[30],2.2.2.3[29],4.4.4.5[0]"

Zauważ, że CSPF utworzył określoną z góry trasę przechodzącą przez R2, R3 i R5 (koniec). Tunel TE zażądał zapisywania trasy, po której jest przesyłany (przez ustawienie "record-route=yes"), zapisana trasa jest wyświetlana w statusie włącznie z etykietami, które poszczególny router przydzielił dla tego tunelu.

Po zestawieniu tunelu TE, interfejs VPLS z R1 do R5 automatycznie przełącza się na użycie tunelu TE:

[admin@R1] /interface vpls> monitor 0
       remote-label: 24
        local-label: 25
      remote-status: 
          transport: te1
  transport-nexthop: 1.1.1.2
     imposed-labels: 30,24

Na routerach pomiędzy R1 i R5, stan ścieżki RSVP i rezerwacji może być monitorowany, na przykład na R2:

[admin@R2] > /mpls traffic-eng path-state print
Flags: L - locally-originated, E - egress, F - forwarding, P - sending-path, R - sending-resv
 #      SRC                  DST                  BANDWIDTH  OUT-INTERFACE                                           OUT-NEXT-HOP
 0  FPR 9.9.9.1:1            9.9.9.5:2            1000       ether2                                                  2.2.2.3
[admin@R2] > /mpls traffic-eng resv-state print
Flags: E - egress, A - active, N - non-output, S - shared
 #    SRC                  DST                  BANDWIDTH  LABEL                         INTERFACE                   NEXT-HOP
 0 AS 9.9.9.1:1            9.9.9.5:7            1000       30                            ether2                      2.2.2.3

Dostępne pasmo na interfejsie ether2 (połączonym z R3) na R2 uległo zmianie:

[admin@R2] > /mpls traffic-eng interface print
Flags: X - disabled, I - invalid
 #   INTERFACE                                                                                    BANDWIDTH  TE-METRIC  REMAINING-BW
 0   ether1                                                                                       100000     1          100000
 1   ether2                                                                                       100000     1          99000