modified on 21 lip 2010 at 09:48 ••• 15 244 views

MPLS/LDP

Z MikroTik Wiki

Spis treści

Wprowadzenie do MPLS

Wprowadzenie do MPLS

Przykład sieci

Rozważmy dostawcę usługi sieci łączącej 3 odległe miejsca Klienta A (A1,A2 i A3) i dwa odległe miejsca Klienta B (B1 i B2) używającego swoją sieć szkieletowa IP składającą się z routerów (R1-R5):

Network map

Klienci żądają przezroczystego łączenia segmentów ethernetowych pomiędzy miejscami. Póki co robiło się to poprzez tunele EoIP z fizycznymi interfejsami ethernetowymi.

Włączenie forwardowania MPLS może przyspieszyć proces forwardowania pakietów w takiej sieci. Używając jednej z aplikacji MPLS - VPLS może nalej zwiększyć wydajność forwardowania ramek ethernetowych poprzez wyłączenie enkapsulacji ramek ethernetowych w ramkach IP (poprzez usunięcie narzutu nagłówka IP).

Artykuł opisuje krok po kroku jak zaimplementować VPLS aby uzyskać pożądaną usługę.

Wymagania MPLS

Adres IP "Loopback"

Pomimo, że nie jest to wymagane, poleca się skonfigurować routery uczestniczące w sieci MPLS z adresem IP pętli zwrotnej (nie polączonego z żadnym fizycznym interfejsem sieciowym) używanym przez LDP do zestawiania sesji.

Uzyskujemy 2 zastosowania:

  • ponieważ może być tylko jedna sesja LDP pomiędzy dwoma routerami, niezależnie, jak wiele łączy jest zestawionych pomiędzy nimi, adres IP pętli zwrotnej zapewnia, że sesja LDP nie jest zależna od stanów interfejsów ani zmian adresu.
  • użycie adresu pętli zwrotnej jako adresu transportowego LDP zapewnia poprawne zachowanie wstawiania przedostatniego skoku gdy przydzielone jest wiele etykiet do pakietu, tak samo jak w przypadku VPLS.

W RouterOS adres IP "loopback" może być skonfigurowane poprzez stworzenie imitacji interfejsu mostkowego bez żadnych portów, ani dodanych adresów. Na przykład, na R1:

/interface bridge add name=lobridge
/ip address add address=9.9.9.1/32 interface=lobridge

Pozostałe routery konfigurowane są w podobny sposób.

Łączność IP

Ponieważ LDP rozsyła etykiety aktywnych tras, podstawowym wymaganiem jest poprawna konfiguracja routingu IP. LDP domyślnie rozsyła etykiety aktywnych tras IGP (połączonych, statycznych i tras dostarczonych za pomocą protokołów routingu, poza BGP).

W danym przykładzie konfiguracja OSPF używana jest do dystrybucji tras. Na przykład, na R5 OSPF konfigurowany jest za pomocą poniższych poleceń:

/routing ospf set redistribute-connected=as-type-1
/routing ospf network add area=backbone network=4.4.4.0/24
/routing ospf network add area=backbone network=5.5.5.0/24

Na innych routerach OSPF konfigurowany jest podobnie.

Tablica routingu zapełniana jest na R5 mniej więcej tak:

[admin@R5] > ip route print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY-STATE GATEWAY         DISTANCE             INTERFACE
 0 ADo  1.1.1.0/24                         reachable     4.4.4.3         110                  ether1
 1 ADo  2.2.2.0/24                         reachable     4.4.4.3         110                  ether1
 2 ADo  3.3.3.0/24                         reachable     4.4.4.3         110                  ether1
                                           reachable     5.5.5.4                              ether2
 3 ADC  4.4.4.0/24         4.4.4.5                                       0                    ether1
 4 ADC  5.5.5.0/24         5.5.5.5                                       0                    ether2
 5 ADo  9.9.9.1/32                         reachable     4.4.4.3         110                  ether1
 6 ADo  9.9.9.2/32                         reachable     4.4.4.3         110                  ether1
 7 ADo  9.9.9.3/32                         reachable     4.4.4.3         110                  ether1
 8 ADo  9.9.9.4/32                         reachable     5.5.5.4         110                  ether2
 9 ADC  9.9.9.5/32         9.9.9.5                                       0                    lobridge

a traceroute z R5 co R1 wygląda tak:

[admin@R5] > /tool traceroute 9.9.9.1
     ADDRESS                                    STATUS
   1         4.4.4.3 11ms 1ms 4ms
   2         2.2.2.2 23ms 3ms 2ms
   3         9.9.9.1 26ms 3ms 3ms

Konfiguracja LDP

Aby rozsyłać etykiety tras, LDP powinien być włączony. Na R1 (interfejs ether3 należy do sieci 1.1.1.0/24):

/mpls ldp set enabled=yes transport-address=9.9.9.1 lsr-id=9.9.9.1
/mpls ldp interface add interface=ether3

Transport-address ustawiany jest na 9.9.9.1. Powoduje to, ze połączenia sesji LDP należących do routera z tym adresem również są rozgłaszane jako adresy transportowe do sąsiadów LDP.

Pozostałe routery konfigurowane są podobnie - LDP jest włączany na interfejsach łączących routery i wyłączony na interfejsach połączonych z sieciami klientów. Na przykład na R5:

[admin@R5] > /ip address print
Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         BROADCAST       INTERFACE
 0   4.4.4.5/24         4.4.4.0         4.4.4.255       ether1
 1   5.5.5.5/24         5.5.5.0         5.5.5.255       ether2
 2   9.9.9.5/32         9.9.9.5         9.9.9.5         lobridge
[admin@R5] > /mpls ldp interface print
Flags: I - invalid, X - disabled
 #   INTERFACE                                             HELLO-INTERVAL       HOLD-TIME
 0   ether1                                                5s                   15s
 1   ether2                                                5s                   15s

Po zestawieniu sesji LDP na R5 są 2 sąsiedzi LDP:

[admin@R5] > /mpls ldp neighbor print
Flags: X - disabled, D - dynamic, O - operational, T - sending-targeted-hello, V - vpls
 #      TRANSPORT       LOCAL-TRANSPORT PEER                           SEND-TARGETED ADDRESSES
 0 DO   9.9.9.4         9.9.9.5         9.9.9.4:0                      no            3.3.3.4
                                                                                     5.5.5.4
                                                                                     9.9.9.4
 1 DO   9.9.9.3         9.9.9.5         9.9.9.3:0                      no            2.2.2.3
                                                                                     3.3.3.3
                                                                                     4.4.4.3
                                                                                     9.9.9.3

/mpls local-bindings wyświetla etykiety, które ten router przydzielił do tras i etykiety peerów, którzy je rozgłaszali. Pokazuje, że R5 rozgłasza etykiety do wszystkich tras, swoich jak i sąsiadów - R3 i R4

[admin@R5] > /mpls local-bindings print
Flags: X - disabled, A - advertised, D - dynamic, L - local-route, G - gateway-route, e - egress
 #      DST-ADDRESS        LABEL      PEERS
 0 ADLe 4.4.4.0/24         impl-null  9.9.9.4:0
                                      9.9.9.3:0
 1 ADLe 9.9.9.5/32         impl-null  9.9.9.4:0
                                      9.9.9.3:0
 2 ADG  9.9.9.4/32         17         9.9.9.4:0
                                      9.9.9.3:0
 3 ADLe 5.5.5.0/24         impl-null  9.9.9.4:0
                                      9.9.9.3:0
 4 ADG  1.1.1.0/24         18         9.9.9.4:0
                                      9.9.9.3:0
 5 ADG  2.2.2.0/24         19         9.9.9.4:0
                                      9.9.9.3:0
 6 ADG  9.9.9.1/32         20         9.9.9.4:0
                                      9.9.9.3:0
 7 ADG  9.9.9.2/32         21         9.9.9.4:0
                                      9.9.9.3:0
 8 ADG  9.9.9.3/32         22         9.9.9.4:0
                                      9.9.9.3:0
 9 ADG  3.3.3.0/24         23         9.9.9.4:0
                                      9.9.9.3:0

/mpls remote-bindings pokazuje etykiety przydzielone do tras sąsiednich routerów i rozgłaszanych do tego routera:

[admin@R5] > /mpls remote-bindings print
Flags: X - disabled, A - active, D - dynamic
 #    DST-ADDRESS        NEXTHOP         LABEL      PEER
 0  D 4.4.4.0/24                         16         9.9.9.4:0
 1 AD 3.3.3.0/24         5.5.5.4         impl-null  9.9.9.4:0
 2  D 9.9.9.5/32                         17         9.9.9.4:0
 3 AD 9.9.9.4/32         5.5.5.4         impl-null  9.9.9.4:0
 4  D 5.5.5.0/24                         impl-null  9.9.9.4:0
 5  D 1.1.1.0/24                         18         9.9.9.4:0
 6  D 2.2.2.0/24                         19         9.9.9.4:0
 7  D 9.9.9.1/32                         20         9.9.9.4:0
 8  D 9.9.9.2/32                         21         9.9.9.4:0
 9  D 9.9.9.3/32                         22         9.9.9.4:0
10 AD 1.1.1.0/24         4.4.4.3         16         9.9.9.3:0
11 AD 2.2.2.0/24         4.4.4.3         impl-null  9.9.9.3:0
12  D 4.4.4.0/24                         impl-null  9.9.9.3:0
13  D 3.3.3.0/24                         impl-null  9.9.9.3:0
14 AD 9.9.9.1/32         4.4.4.3         17         9.9.9.3:0
15 AD 9.9.9.3/32         4.4.4.3         impl-null  9.9.9.3:0
16  D 9.9.9.4/32                         18         9.9.9.3:0
17  D 5.5.5.0/24                         19         9.9.9.3:0
18 AD 9.9.9.2/32         4.4.4.3         20         9.9.9.3:0
19  D 9.9.9.5/32                         21         9.9.9.3:0

Tutaj możemy zaobserwować, że R5 odebrał wiązania etykiet do wszystkich tras swoich sąsiadów - R3 i R4, ale tylko jeden następny skok u każdego sąsiada jest aktywny. Na przykład:

[admin@R5] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        G GATEWAY         DISTANCE             INTERFACE
...
 5 ADo  9.9.9.1/32                         r 4.4.4.3         110                  ether1
...
[admin@R5] > /mpls remote-bindings print
Flags: X - disabled, A - active, D - dynamic
 #    DST-ADDRESS        NEXTHOP         LABEL      PEER
...
 7  D 9.9.9.1/32                         20         9.9.9.4:0
...
14 AD 9.9.9.1/32         4.4.4.3         17         9.9.9.3:0
...

Widzimy, że R3, którego następny skok do sieci 9.9.9.1/32 z R5, przydzielił etykietę 17 dla ruchu idącego do 9.9.9.1/32. Gdy R5 będzie trasował ruch do tej sieci, przydzieli etykietę 17.

Reguły komutacji etykiet wyświetlone są w /mpls forwarding-table. Na przykład, na R3 wygląda to tak:

[admin@R3] > /mpls forwarding-table print
 # IN-LABEL             OUT-LABELS           DESTINATION        INTERFACE            NEXTHOP
 ...
 2 17                   17                   9.9.9.1/32         ether1               2.2.2.2
 ...

Ta reguła mówi, że R3 odbierający pakiet z etykietą 17 zmieni go na etykietę 17 przydzieloną przez R2 do sieci 9.9.9.1/32 (R2 jest następnym skokiem do 9.9.9.1/32 z R3):

[admin@R2] > /mpls local-bindings print
Flags: X - disabled, A - advertised, D - dynamic, L - local-route, G - gateway-route, e - egress
 #      DST-ADDRESS        LABEL      PEERS
 ...
 3 ADG  9.9.9.1/32         17         9.9.9.1:0
                                      9.9.9.3:0
 ...

Tablica forwardingu MPLS na R2:

[admin@R2] > /mpls forwarding-table print
 # IN-LABEL             OUT-LABELS           DESTINATION        INTERFACE            NEXTHOP
 ...
 1 17                                        9.9.9.1/32         ether1               1.1.1.1
 ...

Reguła forwardingu nie ma żadnych wychodzących etykiet. Dzieje się tak ponieważ R2 wstawia przedostatni skok do tej sieci. r! nie przydziela żadnych etykiet do sieci 9.9.9.1/32 ponieważ znane jest, że r! jest punktem wyjściowym dla sieci 9.9.9.1/32 (router jest punktem wyjściowym dla sieci, gdy jest bezpośrednio z nią połączony, ponieważ następny skok dla ruchu nie jest routerem MPLS), z tego powodu rozgłasza etykietę "implicit null" dla tej trasy:


[admin@R2] > /mpls remote-bindings print
Flags: X - disabled, A - active, D - dynamic
 #    DST-ADDRESS        NEXTHOP         LABEL      PEER
 ...
13 AD 9.9.9.1/32         1.1.1.1         impl-null  9.9.9.1:0
 ...

Mówi to, że R2 forwarduje ruch dla 9.9.9.1/32 do R1 bez etykiety, co jest zgodne z tym co mówi wpis w tablicy mpls forwarding-table na R2. Wstawianie przedostatniego skoku zapewnia, że routery nie muszą wykonywać niepotrzebnego wyszukiwania etykiety, gdy wiadome jest, ze router musi trasować pakiet.

Używanie traceroute w sieciach MPLS

RFC 4950 wprowadza rozszerzenia do protokołu ICMP dla MPLS. Podstawową ideą jest to, że niektóre wiadomości ICMP mogą przenosić MPLS "obiekt stosu etykiet" ("label stack object")(lista etykiet, które przydzielone były do pakietu gdy wywołał wiadomość ICMP). Wiadomość ICMP istotne dla MPLS to Time Exceeded i Need Fragment.

Etykieta MPLS przenosi nie tylko wartość etykiety, ale również pole TTL. Podczas nakładania etykiety na pakiet IP, MPLS TTL jest ustawiany na wartość z nagłówka IP, gdy usuwana jest ostatnia etykieta z pakietu IP, IP TTL ustawiany jest na wartość MPLS TTL. Z tego powodu sieć komutowana MPLS może być zdiagnosowana przez narzędzie traceroute, jako wspierająca rozszerzenia MPLS.

Na przykład, traceroute z R5 do R1 wygląda tak:

[admin@R5] > /tool traceroute 9.9.9.1 src-address=9.9.9.5
     ADDRESS                                    STATUS
   1         4.4.4.3 15ms 5ms 5ms
                      mpls-label=17
   2         2.2.2.2 5ms 3ms 6ms
                      mpls-label=17
   3         9.9.9.1 6ms 3ms 3ms

Wynik traceroute wyświetla etykiety MPLS przydzielone do pakietu, gdy wyprodukował on ICMP Time Exceeded. Oznacza to: gdy R3 odebrał pakiet z MPLS TTL 1, miał on etykietę 17. To pasuje do etykiety rozsyłanej przez R3 dla 9.9.9.1/32. W ten sam sposób R2 obserwuje etykietę 17 na pakiecie dla następnej iteracji treaceroute - R3 zmienił etykietę 17 na etykietę 17, jak wspomniano powyżej. R1 odebrał pakiet bez etykiet - R2 wykonał wstawienie przedostatniego skoku jak wspomniano powyżej.

Wady używania traceroute w sieciach MPLS

Błędy ICMP komutacji etykiet

Jedną z wad używania traceroute w sieciach MPLS jest sposób, w jaki MPLS obsługuje pojawianie się błędów ICMP. W sieciach IP błędy ICMP są po prostu kierowane do źródła pakietu, który wygenerował błąd. W sieciach MPLS możliwe jest, że router generujący wiadomość o błędzie nie ma trasy do źródła pakietu IP (na przykład, w przypadku ścieżek asymetrycznej komutacji etykiet lub tunelowania MPLS, tzn. transport ruchu MPLS VPN).

Z tego powodu wygenerowane błędy ICMP nie są kierowane do źródła pakietu, ale przesyłane są dalej wzdłuż ścieżki etykiet, zakładając, że punkt końcowy ścieżki etykiet odbierze błąd ICMP, będzie wiedział jak skierować go do źródła.

Powoduje to sytuację, że traceroute w sieci MPLS nie jest używany w ten sam sposób jak w sieci IP - w celu określenia punktu awarii w sieci. Jeśli ścieżka komutowana etykietami załamała się w środku, nie będą zwracane odpowiedzi ICMP, ponieważ nie będzie możliwości dotarcia ich do punktu końcowego ścieżki.

Wstawianie przedostatniego skoku i źródłowy adres traceroute

Aby zrozumieć mechanizm działania przedostatniego skoku i trasowanie wymagane jest zrozumienie i unikanie problemów, jakie wstawianie przedostatniego skoku powoduje w traceroute.

W przykładowej konfiguracji, normalnie działający traceroute z R5 do R1 zwraca poniższe wyniki:

[admin@R5] > /tool traceroute 9.9.9.1
     ADDRESS                                    STATUS
   1         0.0.0.0 timeout timeout timeout
   2         2.2.2.2 37ms 4ms 4ms
                      mpls-label=17
   3         9.9.9.1 4ms 2ms 11ms

w porównaniu z:

[admin@R5] > /tool traceroute 9.9.9.1 src-address=9.9.9.5
     ADDRESS                                    STATUS
   1         4.4.4.3 15ms 5ms 5ms
                      mpls-label=17
   2         2.2.2.2 5ms 3ms 6ms
                      mpls-label=17
   3         9.9.9.1 6ms 3ms 3ms

Powód, dla którego pierwsze użycie traceroute nie dostaje odpowiedzi z R3 jest taki, że domyślnie traceroute na R5 używa adresu źródłowego 4.4.4.5 dla swoich sond, ponieważ jest to preferowane źródło dla trasy, której następny skok do 9.9.9.1/32 jest osiągalny:

[admin@R5] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        G GATEWAY         DISTANCE             INTERFACE
 ...
 3 ADC  4.4.4.0/24         4.4.4.5                           0                    ether1
 ...
 5 ADo  9.9.9.1/32                         r 4.4.4.3         110                  ether1
 ...

Gdy jest transmitowana pierwsza próbka traceroute (źródło: 4.4.4.5, cel: 9.9.9.1), R3 odrzuca ją i generuje wiadomość ICMP error (źródło: 4.4.4.3, cel: 4.4.4.5), która jest kierowana przez całą drogę do R1. R1 wysyła ICMP error z powrotem - wiadomość jest kierowana wzdłuż ścieżki komutowanej etykietami do 4.4.4.5.

R2 jest routerem wstawiającym przedostatni skok dla sieci 4.4.4.0/24, ponieważ 4.4.40/24 jest bezpośrednio połączona z R3. Z tego powodu R2 usuwa ostatnią etykietę i wysyła błąd ICMP do R3 bez etykiety:

[admin@R2] > /mpls forwarding-table print
 # IN-LABEL             OUT-LABELS           DESTINATION        INTERFACE            NEXTHOP
 ...
 3 19                                        4.4.4.0/24         ether2               2.2.2.3
 ...

R3 odrzuca odebrany pakiet IP, ponieważ odbiera pakiet ze swoim adresem jako adresem źródłowym. Błąd ICMP wygenerowany przez poniższe sondy zwracany jest poprawnie, ponieważ R3 odbiera pakiety bez etykiet z adresami źródłowymi 2.2.2.2 i 9.9.9.1, które mogą być trasowane.

Poleceni:

[admin@R5] > /tool traceroute 9.9.9.1 src-address=9.9.9.5
 ...

wytwarza oczekiwane wyniki, ponieważ adres źródłowy sond traceroute to 9.9.9.5. Gdy błędy ICMP wracają z R1 do R5, wstawianie przedostatniego skoku dla sieci 9.9.9.5/32 zachodzi w routerze R3 i nie musi kierować pakietu ze swoim adresem jako adresem źródłowym.

Konfiguracja VPLS

Konfiguracja interfejsów VPLS

Interfejs VPLS może być uważany za interfejs tunelowy, tak samo jak interfejs EoIP. Aby otrzymać przezroczyste forwardowanie segmentów ethernetowych pomiędzy miejscami klienckimi należy zestawić połączenia między:

  • R1-R5 (klient A)
  • R1-R4 (klient A)
  • R4-R5 (klient A)
  • R1-R5 (klient B)

Każda konfiguracja tunelu niesie ze sobą potrzebę utworzenia interfejsów VPLS na obu końcach tunelu.

Negocjacje tuneli VPLS odbywają się przez protokół LDP - obydwa końce tunelu wymieniają etykiety, które będą używane dla tunelu. Forwardowanie danych w tunelu odbywa się poprzez przydzielenie 2 etykiet do pakietów: etykiety tunelu i etykiety transportową - etykietę, która zapewnia dostarczenie ruchu do drugiego końca tunelu.

Tunele VPLS są konfigurowane w menu /interface vpls. Parametr vpls-id identyfikuje tunel VPLS i musi być niepowtarzalny dla każdego tunelu pomiędzy dwoma końcami.

Konfiguracja:

  • na R1:
/interface vpls add name=A1toA2 remote-peer=9.9.9.5 mac-address=00:00:00:00:00:a1 vpls-id=10 disabled=no
/interface vpls add name=A1toA3 remote-peer=9.9.9.4 mac-address=00:00:00:00:00:a1 vpls-id=10 disabled=no
/interface vpls add name=B1toB2 remote-peer=9.9.9.5 mac-address=00:00:00:00:00:b1 vpls-id=11 disabled=no
  • na R4:
/interface vpls add name=A3toA1 remote-peer=9.9.9.1 mac-address=00:00:00:00:00:a3 vpls-id=10 disabled=no
/interface vpls add name=A3toA2 remote-peer=9.9.9.5 mac-address=00:00:00:00:00:a3 vpls-id=10 disabled=no
  • na R5:
/interface vpls add name=A2toA1 remote-peer=9.9.9.1 mac-address=00:00:00:00:00:a2 vpls-id=10 disabled=no
/interface vpls add name=A2toA3 remote-peer=9.9.9.4 mac-address=00:00:00:00:00:a2 vpls-id=10 disabled=no
/interface vpls add name=B2toB1 remote-peer=9.9.9.1 mac-address=00:00:00:00:00:b2 vpls-id=11 disabled=no

Konfigurowanie tunelu VPLS powoduje, że dynamicznie tworzony jest sąsiad LDP i zestawiana jest "celowa" sesja LDP. Celowa sesja LDP jest sesją, która jest zestawiona pomiędzy dwoma routerami, które nie są bezpośrednimi sąsiadami. Po Konfiguracji R1 sąsiedzi LDP:

[admin@R1] > mpls ldp neighbor pr
Flags: X - disabled, D - dynamic, O - operational, T - sending-targeted-hello, V - vpls
 #      TRANSPORT       LOCAL-TRANSPORT PEER                         SEND-TARGETED ADDRESSES
 0 DO   9.9.9.2         9.9.9.1         9.9.9.2:0                    no            1.1.1.2
                                                                                   2.2.2.2
                                                                                   9.9.9.2
 1 DOTV 9.9.9.5         9.9.9.1         9.9.9.5:0                    yes           4.4.4.5
                                                                                   5.5.5.5
                                                                                   9.9.9.5
 2 DOTV 9.9.9.4         9.9.9.1         9.9.9.4:0                    yes           3.3.3.4
                                                                                   5.5.5.4
                                                                                   9.9.9.4

Wszystkie etykiety dla routerów IP są wymieniane pomiędzy peerami VPLS, pomimo, że nie będzie potrzeby ich używania. Na przykład, bez dodania dodatkowych łączy, R4 nie stanie się następnym skokiem na dowolnej trasie na R1, więc etykiety pochodzące od R4 raczej nie będą nigdy używane. Jednak wciąż routery będą przechowywać etykiety, aby mogły zostać natychmiast użyte, jeśli zajdzie taka potrzeba. To domyślne zachowanie może zostać zastąpione poprzez filtrowanie, które zostanie opisane później. Note that labels for IP routes are also exchanged between VPLS peers, although there is no chance any of them

Przez monitorowanie stanu interfejsu VPLS można obejrzeć powiązane z nim informacje:

[admin@R1] /interface vpls> monitor A1toA3 once
    remote-label: 24
     local-label: 27
   remote-status:
      igp-prefix: 9.9.9.4/32
     igp-nexthop: 1.1.1.2
  imposed-labels: 21,24

Tutaj widzimy, że R1 przydzielił etykietę 27 dla tunelu pomiedzy R1 i R4. Tablica forwardowania MPLS pokazuje, że ta etykieta jest rozpoznawana i zamiast forwardowania do następnego skoku, odbierana przez ten tunel:

[admin@R1] > /mpls forwarding-table print
 # IN-LABEL             OUT-LABELS           DESTINATION        INTERFACE          NEXTHOP
 ...
11 27                                        A1toA3
 ...

Podobnie zdalny koniec (R4) przydzielił etykietę 24.

igp-prefix pokazuje trasę, która jest używana do dostępu do zdalnego końca tunelu. To powoduje, że gdy ruch forwardowany jest do zdalnego punktu tunelu, ten router nakłada etykietę transportową - etykietę rozgłaszaną przez następny skok (który jest oznaczony jako igp-nexthop) do 9.9.9.4/32 dla trasy 9.9.9.4/32. Można to potwierdzić na R2:

[admin@R2] > /mpls forwarding-table print
 # IN-LABEL             OUT-LABELS           DESTINATION        INTERFACE          NEXTHOP
 ...
 5 21                   18                   9.9.9.4/32         ether2             2.2.2.3
 ...

Etykieta tunelu przydzielona do pakietów będzie przydzielona przez zdalny router (R4) dla tego tunelu.

imposed-labels odzwierciedla tą konfigurację: pakiety przechodzące przez tunel będą miały 2 etykiety: 21 i 24.

Efekty wstawiania przedostatniego skoku w tunelach VPLS

Wstawianie przedostatniego skoku etykiety transportowej powodue, że pakiety przybywają do punktu końcowego tunelu VPLS z jednym znacznikiem - znacznikiem tunelu. To powoduje, że punkt końcowy tunelu VPLS wykonuje tylko wyszukiwanie jednej etykiety, aby dowiedzieć się co zrobić z pakietem. Zachowanie etykiety transportowej może być obserowane za pomocą narzędzia traceroute. Na przykład, traceroute z R1 do R4 wygląda tak:

[admin@R1] > /tool traceroute 9.9.9.4 src-address=9.9.9.1
     ADDRESS                                    STATUS
   1         1.1.1.2 7ms 5ms 3ms
                      mpls-label=21
   2         2.2.2.3 5ms 4ms 18ms
                      mpls-label=18
   3         9.9.9.4 4ms 5ms 3ms

wynik traceroute pokazuje, że punkt końcowy tunelu odbiera dane sondujące nie posiadające etykiety. To samo dzieje się z ruchem w tunelu VPLS - na R3 etykieta transportowa (18) jest dodawana do pakietu, który następnie jest komutowany z dodaną etykietą tunelu.

Wymaganie dostarczenia pakietu z etykietą tunelu do końca tunelu wyjaśnia zalecenie, aby w konfiguracji używać adresów IP pętli zwrotnej jako punktów końcowych tunelu. W tym przypadku R4 zestawiałby sesje LDP z adresem 3.3.3.4, wstawianie przedostatniego skoku nie będzie odbywać się na R3 ale na R2, ponieważ R3 połączony jest bezpośrednio z siecią 3.3.3.0/24 (i rozgłasza etykietę null). Mogłoby to powodować, że R3 (a nie R4) będzie odbierać pakiet tylko z etykietą tunelu, co mogłoby powodować odrzucanie ramki, gdy R3 nie rozpozna pakietu lub prześle go w złym kierunku.

Kolejną sprawą jest bezpośrednie połączenie punktów końcowych tunelu VPLS, jak w przypadku R4 i R5. Nie mogą używać między sobą etykiet transportowych, ponieważ obydwaj podają drugi router jako przedostatni skok dla ich adresu końcowego tunelu. Na przykład dla R5:

[admin@R5] > /mpls remote-bindings print
Flags: X - disabled, A - active, D - dynamic
 #    DST-ADDRESS        NEXTHOP         LABEL      PEER
 ...
 3 AD 9.9.9.4/32         5.5.5.4         impl-null  9.9.9.4:0
 ...

Powoduje to, że tunel VPLS będzie używać tylko etykiety tunelu podczas wysyłania pakietów:

[admin@R5] > /int vpls monitor A2toA3 once
    remote-label: 23
     local-label: 27
   remote-status:
      igp-prefix: 9.9.9.4/32
     igp-nexthop: 5.5.5.4
  imposed-labels: 23

Łączenie segmentów ethernetowych za pomocą VPLS

Tunele VPLS zapewniają wirtualne łącze ethernetowe pomiędzy routerami. Aby połączyć dwa fizyczne segmenty ethernetowe, muszą być połączone mostkowo przez tunel VPLS. Ogólnie robi się to tak samo jak z użyciem interfejsów EoIP.

Aby przezroczyście połączyć sieci klienta B podłączone z R1 i R5 należy wykonać poniższe polecenia na R1:

/interface bridge add name=B
/interface bridge port add bridge=B interface=ether1
/interface bridge port add bridge=B interface=B1toB2

oraz na R5:

/interface bridge add name=B
/interface bridge port add bridge=B interface=ether3
/interface bridge port add bridge=B interface=B2toB1

Nie ma potrzeby uruchamiać protokołu (R)STP na połączeniu mostkowym, ponieważ istnieją już łącza pomiędzy segmentami B1 i B2 łącznie z pojedynczym tunelem VPLS pomiędzy R1 i R5.

Połączenia mostowe z rozdzielonym horyzontem

W przykładowej konfiguracji są 3 tunele łączące segmenty A1, A2 i A3, zestawiając tzw. "pełną siatkę" tuneli pomiędzy segmentami. Jeśli włączone jest mostkowanie bez (R)STP , wystąpi pętla ruchu. Można ją zniwelować na kilka sposobów:

  • włączenie (R)STP. Ten sposób ma pewną wadę - protokół (R)STP wyłączy przekazywanie pakietów przez jeden tunel i będzie go utrzymywał wyłącznie jako awaryjny. W ten sposób ruch pomiędzy 2 segmentami będzie przechodził przez 2 tunele zmniejszając wydajność
  • użycie firewalla mostkowego aby upewnić się , że ruch nie jest zapętlony - wiążę się z konfiguracją reguł firewalla zmniejszając wydajność łącz
  • użycie funkcji horyzontu mostka

Podstawową ideą mostkowania z rozdzielonym horyzontem jest nakłonienie ruchu przychodzącego portu, aby nigdy nie przechodził przez pewne porty. Dla VPLS będzie to oznaczać, że nigdy nie będzie wysyłany pakiet, który przybył przez jeden tunel VPLS, przez inny tunel VPLS, ponieważ znane jest, że nadawca pakietu ma połączenie z docelową siecią.

Na przykład, jeśli urządzenie w A1 wysyła pakiet na adres broadcastowy lub nieznany adres MAC (co powoduje, że przesyłany jest pakiet przez wszystkie interfejsy), to pakiet zostanie wysłany przez obydwa tunele VPLS. W normalnej konfiguracji, R5 po odebraniu takiego pakietu przez tunel VPLS wyśle go do A2, oraz przez tunel VPLS do R4. W ten sposób R4 odbiera dwie kopie tego samego pakietu i powoduje zapętlenie ruchu.

Usługa horyzontu mostkowego pozwala na skonfigurowanie portów mostka z ustawieniem horyzontu, dzięki czemu pakiet odebrany przez port z wartością goryzontu X nie jest przekazywany przez inny port z tą samą wartością horyzontu X. W przypadku tuneli VPLS w konfiguracji siatki, każdy router musi mieć tą samą wartość horyzontu dla tuneli VPLS.

Na przykład, polecenie dla R1 włączające mostkowanie dla klienta A:

/interface bridge add name=A
/interface bridge port add bridge=A interface=A1toA2 horizon=1
/interface bridge port add bridge=A interface=A1toA3 horizon=1

W podobny sposób powinien być skonfigurowany mostek na R4 i R5. Fizyczny port ethernetowy nie jest konfigurowany z wartością horyzontu. Gdyby był, zatrzymałoby to całe przekazywanie danych.

Wartość horyzontu ma znaczenie wyłącznie lokalne - nie jest transmitowana przez sieć i nie ma znaczenia, czy taka sama wartość ustawiona jest na wszystkich routerach biorących udział w sieci połączonej mostkowo.

Optymalizacja dystrybucji etykiet

Filtrowanie przydzielania etykiet

Podczas implementacji przykładowej konfiguracji, stało się jasne, że nie są potrzebne wszystkie powiązania etykiet. Na przykład, nie ma potrzeby wymiany powiązań etykiet tras IP pomiędzy R1 i R5 lub R1 i R4, ponieważ nie zostaną nigdy użyte. Ponadto, jeśli dany węzeł sieci zapewnia łączność tylko z danym segmentem klienckiej sieci, nie ma potrzeby używania dystrybucji etykiet dla sieci, które łączą routery ze sobą, jedynymi znaczącymi trasami są trasy /32 do punktów końcowych tuneli VPLS.

Filtrowanie przydzielania etykiet może być użyte do dystrybucji tylko określonego zestawu etykiet aby zredukować wykorzystanie zasobu oraz obciążenie sieci.

Są 2 typy filtrów przydzielania etykiety:

  • które przydzielenie etykiety powinno być rozgłaszane do sąsiadów LDP, skonfigurowanych w /mpls ldp advertise-filter
  • które przydzielenie etykiety pochodzące od sąsiadów LDP powinny być akceptowane, skonfigurowane w /mpls ldp accept-filter

Filtry są organizowane w listę porządkową, określając prefiks, który musi zawierać prefiks, który będzie testowany prze filtry i sąsiadów (lub wildcard).

W powyższym przykładzie wszystkie routery mogą być skonfigurowane, aby rozgłaszały etykiety tylko dla tras, które pozwalają na dotarcie do punktów końcowych tunelu. Należy ustawić dwa filtry na wszystkich routerach:

/mpls ldp advertise-filter add prefix=9.9.9.0/24 advertise=yes
/mpls ldp advertise-filter add prefix=0.0.0.0/0 advertise=no

Filtr powoduje, że routery tylko rozgłaszają powiązania (bindings) dla tras powiązanych z prefiksem 9.9.9./24 zawierającym punkty końcowe tunelu (9.9.9.1/32, 9.9.9.4/32, 9.9.9.5/32). Druga reguła jest potrzebna, ponieważ domyślną zachowaniem filtru, gdy nie można dopasować żadnej reguły jest zezwolenie na wykonanie akcji z reguły.

W tym przykładzie nie ma potrzeby ustawienie filtru akceptującego, ponieważ w zachowaniu określonym przez dwie powyższe reguły, żaden router LDP nie będzie dystrybuował niepotrzebnych powiązań.

Zmiany filtru nie powodują zmiany istniejącego mapowania, więc aby filtr zaczął poprawnie działać należy zrestartować połączenia między sąsiadami. Robi się to poprzez usunięcie ich:

[admin@R1] /mpls ldp neighbor> print
Flags: X - disabled, D - dynamic, O - operational, T - sending-targeted-hello, V - vpls
 #      TRANSPORT       LOCAL-TRANSPORT PEER                         SEND-TARGETED ADDRESSES
 0 DO   9.9.9.2         9.9.9.1         9.9.9.2:0                    no            1.1.1.2
                                                                                   2.2.2.2
                                                                                   9.9.9.2
 1 DOTV 9.9.9.5         9.9.9.1         9.9.9.5:0                    yes           4.4.4.5
                                                                                   5.5.5.5
                                                                                   9.9.9.5
 2 DOTV 9.9.9.4         9.9.9.1         9.9.9.4:0                    yes           3.3.3.4
                                                                                   5.5.5.4
                                                                                   9.9.9.4
[admin@R1] /mpls ldp neighbor> remove [find]

Na przykład, na R1 otrzymujemy:

[admin@R1] > /mpls remote-bindings print
Flags: X - disabled, A - active, D - dynamic
 #    DST-ADDRESS        NEXTHOP         LABEL      PEER
 0  D 9.9.9.1/32                         30         9.9.9.5:0
 1  D 9.9.9.5/32                         impl-null  9.9.9.5:0
 2  D 9.9.9.4/32                         31         9.9.9.5:0
 3  D 9.9.9.2/32                         32         9.9.9.5:0
 4  D 9.9.9.3/32                         33         9.9.9.5:0
 5 AD 9.9.9.2/32         1.1.1.2         impl-null  9.9.9.2:0
 6  D 9.9.9.1/32                         24         9.9.9.2:0
 7 AD 9.9.9.3/32         1.1.1.2         25         9.9.9.2:0
 8 AD 9.9.9.4/32         1.1.1.2         26         9.9.9.2:0
 9 AD 9.9.9.5/32         1.1.1.2         27         9.9.9.2:0
10  D 9.9.9.1/32                         27         9.9.9.4:0
11  D 9.9.9.5/32                         28         9.9.9.4:0
12  D 9.9.9.4/32                         impl-null  9.9.9.4:0
13  D 9.9.9.2/32                         29         9.9.9.4:0
14  D 9.9.9.3/32                         30         9.9.9.4:0

Nadal występują niepotrzebne powiązania, lecz tym razem są to powiązania dystrybuowane przez zestawienie wybranych sesji LDP ze zdalnymi końcami tuneli VPLS (powiązania z 9.9.9.5 i 9.9.9.4)

Aby je przefiltrować, skonfigurujemy routery aby nie dystrybuowały żadnych powiązań IP do żadnego routera będącego końcem tunelu. Na przykład na R1 tablica filtra powinna wyglądać tak:

[admin@R1] /mpls ldp advertise-filter> print
Flags: X - disabled
 #   PREFIX             NEIGHBOR        ADVERTISE
 0   0.0.0.0/0          9.9.9.4         no
 1   0.0.0.0/0          9.9.9.5         no
 2   9.9.9.0/24         all             yes
 3   0.0.0.0/0          all             no

Powoduje to, że routery mają możliwie małe tablice powiązań, na przykład na R1:

[admin@R1] > /mpls local-bindings print
Flags: X - disabled, A - advertised, D - dynamic, L - local-route, G - gateway-route, e - egress
 #      DST-ADDRESS        LABEL      PEERS
 0 ADLe 9.9.9.1/32         impl-null  9.9.9.2:0
 1 ADG  9.9.9.3/32         40         9.9.9.2:0
 2 ADG  9.9.9.4/32         41         9.9.9.2:0
 3 ADG  9.9.9.2/32         42         9.9.9.2:0
 4 ADG  9.9.9.5/32         43         9.9.9.2:0
[admin@R1] > /mpls remote-bindings print
Flags: X - disabled, A - active, D - dynamic
 #    DST-ADDRESS        NEXTHOP         LABEL      PEER
 0 AD 9.9.9.2/32         1.1.1.2         impl-null  9.9.9.2:0
 1  D 9.9.9.1/32                         24         9.9.9.2:0
 2 AD 9.9.9.3/32         1.1.1.2         25         9.9.9.2:0
 3 AD 9.9.9.4/32         1.1.1.2         26         9.9.9.2:0
 4 AD 9.9.9.5/32         1.1.1.2         27         9.9.9.2:0

Dystrybucja powiązań IP nie może być wyłączona pomiędzy R4 i R5 ponieważ są końcami tuneli. Ponieważ R4 i R5 nie potrzebują powiązań IP z tunelem VPLS, ale w przypadku, gdy łącze pomiędzy R3 i R5 zostanie zerwane, cały ruch z R1 do R5 będzie przekierowany przez R4. W takim przypadku R5 nie będzie dystrybuował powiązań IP do R4 i R4 nie będzie w stanie przekierowywać ruchu MPLS do R5.

Efekty filtrowania przydzielania etykiet na forwardowanie danych w sieci

Wyniki działania traceroute ulegną zmianie. Traceroute z R1 do R5 z użyciem adresu pętli zwrotnej R1 jako adresu źródłowego będzie zachowywać się tak samy - każdy skok będzie zgłaszał otrzymane etykiety:

[admin@R1] > tool traceroute 9.9.9.5 src-address=9.9.9.1
     ADDRESS                                    STATUS
   1         1.1.1.2 11ms 4ms 5ms
                      mpls-label=27
   2         2.2.2.3 4ms 4ms 4ms
                      mpls-label=25
   3         9.9.9.5 12ms 3ms 3ms

Lecz w przypadku traceroute używającego adresu R1 po stronie sieci:

[admin@R1] > tool traceroute 9.9.9.5 src-address=1.1.1.1
     ADDRESS                                    STATUS
   1         0.0.0.0 timeout timeout timeout
   2         0.0.0.0 timeout timeout timeout
   3         9.9.9.5 3ms 3ms 3ms

Wszystkie skoki poza ostatnim nie odpowiadają. Dzieje się tak ponieważ nie ma ustawionej zwrotnej ścieżki komutowanej etykietowo z R5 do R1 (w tym przypadku używającej adresu 1.1.1.1), ponieważ nie ma dystrybuowanych powiązań etykiet - więc odpowiedź ICMP jest kierowana inną drogą i routery będące na drodze powrotnej (R3 i R2) odbierają pakiety, adres źródłowy jest ich własnym adresem i odrzucają je bez transmitowania ich ich dalej.

Z drugiej strony, traceroute z R1 do R5 używający ich adresów innych niż pętli zwrotnej:

[admin@R1] > tool traceroute 4.4.4.5 src-address=1.1.1.1
     ADDRESS                                    STATUS
   1         1.1.1.2 13ms 1ms 1ms
   2         2.2.2.3 3ms 2ms 2ms
   3         4.4.4.5 3ms 3ms 23ms

Nie zachodzi komutacja etykietami i traceroute działa tak jak w sieci bez MPLS.

Zobacz również