modified on 6 sty 2010 at 09:25 ••• 8 380 views

VPLS oparty o BGP

Z MikroTik Wiki

Spis treści

Prowadzenie

Strona LDP i VPLS oparty o LDP zawiera ogólny opis usługi VPLS i konfiguracji tunelu VPLS opartych o LDP. Z powodu statycznej natury tuneli VLPS opartych o LDP występują problemy ze skalowalnością występujące, gdy VPLS i węzły uczestniczą podczas rozrastania się VPLS. Jednym z problemów jest wymagania utrzymywania siatkowej struktury tuneli LDP pomiędzy węzłami tworzącymi VPLS. W przypadku dużej ilości węzłów w VPLS, dodanie nowego węzła do VPLS może być bardzo czasochłonne.

Do unikania złożoności konfiguracji pomocne może być autowykrywanie oparte o BGP i sygnalizacja w tunelach VPLS kosztem protokołu BGP pomiędzy routerami VPLS. Ogólnie, VPLS oparty o BGP spełnia dwa zadania:

  • autowykrywanie: nie ma potrzeby konfiguracji każdego routera VPLS z wszystkimi zdalnymi końcami tuneli VPLS, ponieważ routery same wykrywają punkty końcowe tuneli z odbieranych aktualizacji BGP (wysyłając między sobą multiprotokołowe NLRI);
  • sygnalizacja: etykiety używane w tunelach VPLS przez zdalne końce są dystrybuowane w aktualizacjach BGP, oznacza to, że nie ma potrzeby zestawiania sesji LDP pomiędzy punktami końcowymi tuneli jak to odbywa się w VPLS z sygnalizacją LDP.


Na przykład, jeśli używany jest VPLS z sygnalizacją LDP, dodanie nowego węzła do istniejącej sieci VPLS będzie oznaczało konfigurację routera łączącego nowy węzeł aby zestawiał tunele z pozostałymi węzłami, oraz konfigurację wszystkich innych routerów zestawiających połączenie z nowym węzłem. VPLS oparty o BGP, jeśli poprawnie skonfigurowany eleminuje potrzebę modyfikacji konfiguracji na pozostałych routerach tworzących VPLS.

Wymaganie wymiany BGP NLRI pomiędzy routerami VPLS oznaczają, że albo muszą być zestawione sesję BGP pomiędzy wszystkimi rotuerami tworzącymi VPLS lub należy użyć reflektora trasy. Wyższość zestawiania sesji BGP pomiędzy routerami nad VPLS z sygnalizacją LDP jest kwestionowana - gdy dodana jest nowa sieć, nadal należy modyfikować konfigurację wszystkich peerów BGP. Użycie reflektora trasy BGP powoduje znacznie prostsze dodawanie nowych elementów sieci - router połączony z nową częścią sieci musi być tylko połączony z reflektorem trasy. Nie ma potrzeby modyfikacji innych routerów. Reflektor trasy może być jednym z routerów tworzącycg VPLS, nie ma potrzeby stosowania dodatkowego sprzętu. Oczywiście należy brać pod uwagę skalowalność i dostępność - do ochrony przed awariami jaki i sygnalizacji o obciążeniu należy stosować wiele reflektorów tras.

Wadą VPLS opartym o BGP jest potrzeba konfiguracji BGP, wymagająca od administratora sieci przynajmniej ogólnego zrozumienia BGP, jego możliwości wieloprotokołowych i reflektorów tras. Dlatego zalecamy stosowanie VPLS z sygnalizacją LDP jeśli ilość węzłów i podsieci jest mała, topologia jest bardziej statyczna - w tych przypadkach zalety BGP nie są tak istotne.

VPLS oparty o BGP jest wyłącznie metodą wymiany etykiet tuneli VPLS, nie zajmuje się transmisją ruchu pomiędzy punktami końcowymi tuneli, więc należy zapewnić transmisję ramek MPLS pomiędzy końcami tunelu jak opisano w LDP i VPLS oparty o LDP .

Polecamy przeczytanie poniższych artykułów:

  • RFC 4761, Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling
  • RFC 4456, BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)

Przykład sieci

Rozważmy taką samą sieć, jak użyta w przykładzie w LDP i VPLS oparty o LDP:

Image:VPLS.png

Wymagania klientów A i B są takie same - segmenty ethernetowe muszą być połączone. Biorąc pod uwagę prostotę topologi sieci, Dostawca Usługi zdecydował się używać R5 jako reflektora trasy bez reflektora zapasowego. Zakładamy, że komutacja MPLS jest ustawiona i działa, jak omówiono w LDP i VPLS oparty o LDP , ale nie wprowadzono jeszcze żadnej konfiguracji VPLS. Pozostała część tego artykułu zajmie się opisem użycia BGP jako sygnalizacji w VPLS.

Konfiguracja sesji IBGP dla sygnalizacji VPLS

Najpierw należy skonfigurować instancję BGP, można użyć domyślnej instancji:

[admin@R1] /routing bgp instance> print
Flags: X - disabled
 0   name="default" as=65530 router-id=0.0.0.0 redistribute-connected=no redistribute-static=no
     redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no out-filter=""
     client-to-client-reflection=yes ignore-as-path-len=no

Aby włączyć dostarczanie VPLS NLRI przez BGP, należy użyć możliwości wieloprotokołowego BGP, poprzez ustawienie wartości l2vpn w konfiguracji address-families peera BGP.

Na przykład, aby skonfigurować połączenie BGP pomiędzy R1 i R5, należy wykonać poniższe polecenia.

Na R1:

[admin@R1] /routing bgp peer> add remote-address=9.9.9.5 remote-as=65530 address-families=l2vpn update-source=lobridge

Na R5:

[admin@R5] /routing bgp peer> add remote-address=9.9.9.1 remote-as=65530 address-families=l2vpn update-source=lobridge

Powinno zostać zestawione połączenie BGP pomiędzy R1 i R5. Można to sprawdzić poprzez:

[admin@R1] /routing bgp peer> print status
Flags: X - disabled
 0   name="peer1" instance=default remote-address=9.9.9.5 remote-as=65530 tcp-md5-key=""
     nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter=""
     out-filter="" address-families=l2vpn update-source=lobridge remote-id=4.4.4.5
     local-address=9.9.9.1 uptime=3s prefix-count=0 updates-sent=0 updates-received=0
     withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m used-hold-time=3m
     used-keepalive-time=1m refresh-capability=yes state=established

Należy podkreślić kilka rzeczy odnoście konfiguracji peera BGP:

  • nie ma potrzeby dystrybucji żadnych tras IP lub IPv6 ani nie ma potrzeby używania IP lub IPv6 na połączeniach BGP aby móc wymieniać VPLS NLRI, należy tylko określić address-families=l2vpn
  • adresy pętli zwrotnych na routerach używane są jako adresy peerów BGP (lokalne adresy konfigurowane są za pomocą uparametru update-source). Peer BGP określi swój adres lokalny, podczas tworzenia VPLS NRLI jako następny skok BGP (nap przykład, R1 podczas tworzenia BGP NLRI będzie używać adresu 9.9.9.1 jako adres następnego skoku BGP), odbierający router VPLS używa otrzymany adres następnego skosku BGP jako adres końca tunelu i używa etykiety transportowej zapewniając dostarczanie do następnego skoku BGP. Aby wstawianie przedostatniego skoku odbywało się poprawnie, zaleca się użycie adresu pętli zwrotnej. Zobacz dział o wstawianiu przedostatniego skoku w LDP i VPLS oparty o LDP .

Konfiguracja reflektora trasy

Ogólnie mówiąc reflektor trasy BGP rozsyła dalej odebrane trasy IBGP bez zmiany następnego skoku BGP dla tras. Używane jest to do uniknięcia zestawienia wszystkich połączeń przez sesje BGP. Aby router mógł działać jako reflektor trasy dla VPLS NLRI, nie ma potrzeby aby uczestniczył w VPLS, nie jest nawet wymagane aby miał wsparcie MPLS. Nadal jest wymagane, aby routery VPLS mogły zestawiać sesje BGP z reflektorem trasy, dlatego wymagane jest połączenie IP.

Należy skonfigurować instancję BGP reflektora trasy z parametrem client-to-client-reflection=yes:

[admin@R5] /routing bgp instance> print
Flags: X - disabled
 0   name="default" as=65530 router-id=0.0.0.0 redistribute-connected=no redistribute-static=no
     redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no out-filter=""
     client-to-client-reflection=yes ignore-as-path-len=no

Dodatkowo, peery muszą być ustawione z parametrem route-reflect=yes:

[admin@R5] /routing bgp peer> print
Flags: X - disabled
 0   name="peer1" instance=default remote-address=9.9.9.1 remote-as=65530 tcp-md5-key=""
     nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter=""
     out-filter="" address-families=l2vpn update-source=lobridge
[admin@R5] /routing bgp peer> set 0 route-reflect=yes
[admin@R5] /routing bgp peer> print
Flags: X - disabled
 0   name="peer1" instance=default remote-address=9.9.9.1 remote-as=65530 tcp-md5-key=""
     nexthop-choice=default multihop=no route-reflect=yes hold-time=3m ttl=255 in-filter=""
     out-filter="" address-families=l2vpn update-source=lobridge

Aby nakłonić R5 aby pracował jako reflektor trasy, jego wszystkie peery powinny być dodane z parametrem route-reflect=yes. Aby włączyć poprawną dystrybucję VPLS NLRI, R5 musi być ustawiony z dwoma peerami BGP - R1 i R4:

[admin@R5] /routing bgp peer> print status
Flags: X - disabled
 0   name="peer1" instance=default remote-address=9.9.9.1 remote-as=65530 tcp-md5-key=""
     nexthop-choice=default multihop=no route-reflect=yes hold-time=3m ttl=255 in-filter=""
     out-filter="" address-families=l2vpn update-source=lobridge remote-id=1.1.1.1
     local-address=9.9.9.5 uptime=5m55s prefix-count=0 updates-sent=0 updates-received=0
     withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m used-hold-time=3m
     used-keepalive-time=1m refresh-capability=yes state=established

 1   name="peer2" instance=default remote-address=9.9.9.4 remote-as=65530 tcp-md5-key=""
     nexthop-choice=default multihop=no route-reflect=yes hold-time=3m ttl=255 in-filter=""
     out-filter="" address-families=l2vpn update-source=lobridge remote-id=3.3.3.4
     local-address=9.9.9.5 uptime=23s prefix-count=0 updates-sent=0 updates-received=0
     withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m used-hold-time=3m
     used-keepalive-time=1m refresh-capability=yes state=established

Ale R1 i R4 muszą być peerami tylko z R5. Na R1:

[admin@R1] /routing bgp peer> print status
Flags: X - disabled
 0   name="peer1" instance=default remote-address=9.9.9.5 remote-as=65530 tcp-md5-key=""
     nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter=""
     out-filter="" address-families=l2vpn update-source=lobridge remote-id=4.4.4.5
     local-address=9.9.9.1 uptime=6m33s prefix-count=0 updates-sent=0 updates-received=0
     withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m used-hold-time=3m
     used-keepalive-time=1m refresh-capability=yes state=established

Na R4:

[admin@R4] /routing bgp peer> print status
Flags: X - disabled
 0   name="peer1" instance=default remote-address=9.9.9.5 remote-as=65530 tcp-md5-key=""
     nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=255 in-filter=""
     out-filter="" address-families=l2vpn update-source=lobridge remote-id=4.4.4.5
     local-address=9.9.9.4 uptime=3s prefix-count=0 updates-sent=0 updates-received=0
     withdrawn-sent=0 withdrawn-received=0 remote-hold-time=3m used-hold-time=3m
     used-keepalive-time=1m refresh-capability=yes state=established

Użycie reflektora trasy oznacza, że aby dodać nowy element sieci do VPLs, np. połączony z routerem Ry, oznaczałoby dodanie Ry jako peer BGP do R5 (z parametrem route-reflect=yes) i dodanie R5 jako peera BGP do Ry.

Konfiguracja VLPS z sygnalizacją BGP

Konfiguracja mostkowych połączeń ethernetowych

Tunele VPLS z sygnalizacją BGP są tworzone dynamicznie, gdy otrzymane zostaną BGP NLRI. Dlatego nie ma potrzeby konfiguracji interfejsów VPLS. Aby przezroczyście dostarczać pakiety pomiędzy segmentami ethernetowymi przez VPLS należy skonfigurować połączenia mostkowe. Na przykład, na R1 utworzone zostały dwa mosty nazwane "A" i "B" z dodanymi do nich odpowiednimi interfejsami ethernetowymi po stronie klienckiej:

[admin@R1] /interface bridge> print
Flags: X - disabled, R - running
 0  R name="lobridge" mtu=1500 arp=enabled mac-address=00:00:00:00:00:00 protocol-mode=none
      priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s
      forward-delay=15s transmit-hold-count=6 ageing-time=5m

 1  R name="A" mtu=1500 arp=enabled mac-address=00:01:50:E7:00:09 protocol-mode=none priority=0x8000
      auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s
      transmit-hold-count=6 ageing-time=5m

 2  R name="B" mtu=1500 arp=enabled mac-address=00:01:50:E7:00:08 protocol-mode=none priority=0x8000
      auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s
      transmit-hold-count=6 ageing-time=5m
[admin@R1] /interface bridge> port print
Flags: X - disabled, I - inactive, D - dynamic
 #    INTERFACE                             BRIDGE PRIORITY PATH-COST            HORIZON
 0    ether2                                A      0x80     10                   none
 1    ether1                                B      0x80     10                   none

Konfiguracja instancji VPLS z sygnalizacją BGP

Konfiguracja VPLS z sygnalizacją BGP powoduje, że router rozgłasza VPLS BGP NLRI oznaczające, że konkretny router należy do VPLS. Po odebraniu tej informacji, inni członkowie tego samego VPLS wiedzą, jak zestawić tunel VPLS z tym routerem.

Aby skonfigurować VPLS dla klientów A i B, należy wpisać poniższe polecenia na R1:

[admin@R1] /interface vpls bgp-vpls> add bridge=A bridge-horizon=1 route-distinguisher=1:1 site-id=1 \
   import-route-targets=1:1 export-route-targets=1:1
[admin@R1] /interface vpls bgp-vpls> add bridge=B bridge-horizon=1 route-distinguisher=2:2 site-id=1 \
   import-route-targets=2:2 export-route-targets=2:2

Uwaga: Od v3.20 vpls-id został zastąpiony oddzielnym import/export-route-targets w celu zapewnienia większej elastyczności.

Ustawienie route-distinguisher określa wartość przydzieloną do VPLS NLRI więc routery odbiorcze mogą odróżnić ogłoszenia, które mogłyby wyglądać tak samo. Powoduje to, że należy używać unikalnego rozróżniacza tras każdego VPLS. Nie ma potrzeby używania tego samego rozróżniacza VPLS na wszystkich routerach tworzących ten VPLS, ponieważ rozróżniacz nie jest używany do określenia czy BGP NLRI są powiązane z konkretnym VPLS (do tego używany jest atrybut Route Target), ale należy mieć różne rozróżniacze dla różnych VPLS.

Parametr export-route-targets używany jest do znakowania BGP NLRI

Parametr import-route-targets używany jest do sprawdzenia czy BGP NLRI jest powiązany z konkretnym VPLS.

Parametr site-id musi być niepowtarzalny wśród członków konkretnego VPLS. Zalecane jest, ale nie wymagane, aby zarezerować wartości site-id w możliwie wąskim przedziale, ponieważ zwiększa to efektywność BGP (zobacz RFC 4761).

Parametr bridge określa mostek, do którego należy dodać dynamicznie tworzone tunele VPLS.

bridge-horizon określa wartość horyzontu używaną dla portów dodanych do mostka (zobacz rozdział o rozdzielonym horyzoncie w LDP i VPLS oparty o LDP).

Według powyższych poleceń, VPLS dla klienta A został przydzielony do vpls-id 100:1, a VPLS dla klienta B do vpls-id 100:2

Po ustawieniu F4 jako członka VPLS 100:1 (dla klienta A) za pomocą polecenia:

[admin@R4] /interface vpls bgp-vpls> add bridge=A bridge-horizon=1 route-distinguisher=1:1 site-id=4 \
   import-route-targets=1:1 export-route-targets=1:1

Zostaje utworzony na R1 i R4 dynamiczny tunel VPLS. Utworzenie można potwierdzić na R1:

[admin@R1] > /interface vpls print
Flags: X - disabled, D - dynamic, R - running, B - bgp-signaled
 0 RDB name="vpls1" mtu=1500 mac-address=02:FA:33:C4:7A:A9 arp=enabled 
       disable-running-check=no remote-peer=9.9.9.4 cisco-style=no 
       cisco-style-id=0 vpls=bgp-vpls1 
[admin@R1] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic
 #    INTERFACE                             BRIDGE PRIORITY PATH-COST            HORIZON
 0    ether2                                A      0x80     10                   none
 1    ether1                                B      0x80     10                   none
 2  D vpls1                                 A      0x80     50                   1

Potwierdziliśmy także, że reflektor trasy ustawiony na R5 działa poprawnie i nie ma relacji BGP pomiędzy R1 i R4.

Dodatkowo musimy dodać R5 do uczestnictwa w VPLS dla klienta A:

[admin@R5] /interface vpls bgp-vpls> add bridge=A bridge-horizon=1 route-distinguisher=1:1 site-id=5 \
   import-route-targets=1:1 export-route-targets=1:1

Powoduje to zestawienie dodatkowego tunelu VPLS R1 i R4 z R5. Na przykład na R1:

[admin@R1] > /interface vpls print
Flags: X - disabled, D - dynamic, R - running, B - bgp-signaled
 0 RDB name="vpls1" mtu=1500 mac-address=02:FA:33:C4:7A:A9 arp=enabled 
       disable-running-check=no remote-peer=9.9.9.4 cisco-style=no 
       cisco-style-id=0 vpls=bgp-vpls1 
 1 RDB name="vpls2" mtu=1500 mac-address=02:FF:B7:0E:4B:97 arp=enabled 
       disable-running-check=no remote-peer=9.9.9.5 cisco-style=no 
       cisco-style-id=0 vpls=bgp-vpls1 

Został także dodany port mostkowy z odpowiednią wartością horyzontu:

[admin@R1] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic
 #    INTERFACE                             BRIDGE PRIORITY PATH-COST            HORIZON
 0    ether2                                A      0x80     10                   none
 1    ether1                                B      0x80     10                   none
 2  D vpls1                                 A      0x80     50                   1
 3  D vpls2                                 A      0x80     50                   1

Aby zakończyć ustawianie sieci, należy jeszcze skonfigurować VPLS na R5 dla klienta B:

[admin@R5] /interface vpls bgp-vpls> add site-id=5 route-distinguisher=2:2 bridge=B bridge-horizon=1 \
   import-route-targets=2:2 export-route-targets=2:2

W wyniku powinniśmy otrzymać pełną siatkę tuneli VPLS, na przykład na R5:

[admin@R5] /interface vpls> print
Flags: X - disabled, D - dynamic, R - running, B - bgp-signaled

 0 RDB name="vpls1" mtu=1500 mac-address=02:FA:5C:28:29:D3 arp=enabled 
       disable-running-check=no remote-peer=9.9.9.1 cisco-style=no 
       cisco-style-id=0 vpls=bgp-vpls1 
 1 RDB name="vpls2" mtu=1500 mac-address=02:EA:51:31:3E:2B arp=enabled 
       disable-running-check=no remote-peer=9.9.9.4 cisco-style=no 
       cisco-style-id=0 vpls=bgp-vpls1 
 2 RDB name="vpls3" mtu=1500 mac-address=02:F6:CF:06:1E:CB arp=enabled 
       disable-running-check=no remote-peer=9.9.9.1 cisco-style=no 
       cisco-style-id=0 vpls=bgp-vpls2 

Zdalnym peerem dla tuneli VPLS jest adres następnego skoku BGP otrzymanym z aktualizacji BGP. Na przykład logi BGP na R5 po otrzymaniu aktualizacji dla VPLS 2:2 (klient B) mówią:

11:24:06 route,bgp,debug,packet UPDATE Message
11:24:06 route,bgp,debug,packet     RemoteAddress=9.9.9.1
11:24:06 route,bgp,debug,packet     MessageLength=79
11:24:06 route,bgp,debug,packet
11:24:06 route,bgp,debug,packet     PathAttributes
11:24:06 route,bgp,debug,packet         bgp-origin=INCOMPLETE
11:24:06 route,bgp,debug,packet         bgp-nexthop=9.9.9.1
11:24:06 route,bgp,debug,packet         bgp-localpref=100
11:24:06 route,bgp,debug,packet         bgp-extended-communities=RT:100:2
11:24:06 route,bgp,debug,packet
11:24:06 route,bgp,debug,packet     NLRI= rd
11:24:06 route,bgp,debug,packet         type=0
11:24:06 route,bgp,debug,packet         administrator=2
11:24:06 route,bgp,debug,packet         assigned-number=2 veId=1 veBlockOffset=0 veBlockSize=16 labelBase=40

Odpowiada to dynamicznemu tunelowi VPLS, w którym zdalnym peerem tunelu z vpls-is 100:2 jest 9.9.9.1. Powoduje to, że R5 używa trasy IGP prowadzącą do 9.9.9.1 aby zdecydować jaka etykietę użyć. W tym przypadku są /32 trasy IGP dystrybuowane w sieci jak OSPF, dlatego:

[admin@R5] /interface vpls> monitor 2 once
    remote-label: 45
     local-label: 40
   remote-status:
      igp-prefix: 9.9.9.1/32
     igp-nexthop: 4.4.4.3
  imposed-labels: 17,45

Pokazuje, że trasa 9.9.9.1/32 jest używana i bezpośredni następny skok to 4.4.4.3. Etykiety przydzielone do pakietów VPLS to 17 45, gdzie 45 jest mapowaniem etykiety otrzymane z BGP Update, a 17 jest etykietą przydzieloną przez R3 do prefiksu 9.9.9.1/32:


[admin@R5] > /mpls remote-bindings print
Flags: X - disabled, A - active, D - dynamic
 #    DST-ADDRESS        NEXTHOP         LABEL      PEER
 ...
14 AD 9.9.9.1/32         4.4.4.3         17         9.9.9.3:0
 ...

Zobacz również

LDP i VPLS oparty o LDP