fbpx
Zaznacz stronę

Route Reflector – Skalowalność iBGP

Niektórzy mówią, że BGP to Bardzo Groźny Protokół, ponieważ od jego prawidłowego działania, zależy działanie całego Internetu. BGP ma pewne ograniczenia. Dzisiejszy wpis jest i skalowaniu iBGP za pomocą route reflector.

4 czy 5 routerów – mała różnica?

Pamiętasz jak w artykule o iBGP napisałem, że każdy router w systemie autonomicznym powinien mieć ustawioną sesję iBGP z każdym routerem w tym systemie?

Wiesz co? Nic się od tego czasu nie zmieniło.

Nadal jak masz 3 routery, to musisz skonfigurować 3 sesje.

 

Liczba routerów Ilość sesji
2 1
3 3
4 6
5 10
6 15
7 21
8 28
9 36
21 210

 

Liczbę sesji można wyliczyć ze wzoru:

 

n(n-1)/2 gdzie n to liczba routerów w sieci.

 

Jak widzisz, problemu z konfiguracją i utrzymaniem sesji BGP nie ma w sieciach z 3 routerami, to są zaledwie po dwie sesje per router. Problem pojawia się, gdy mamy więcej routerów.

Jakie są problemy z iBGP?

Nakład pracy wymagany do konfiguracji – trzeba poświęcić czas i zasoby aby, skonfigurować wszystkie sesji. Dodanie każdego nowego routera wymaga zestawianie kolejnych sesji iBGP ze wszystkimi routerami.

OK, ale ja mam w sieci skrypty i automaty, które to zrobią,

Super, to przeczytaj kolejny punkt

Każdy router musi utrzymywać sesje iBGP – cykle procesora i pamięć muszą zostać przeznaczone, aby obsługiwać każdą sesję. Oprócz sesji iBGP dochodzą też sesje BGP do innych AS i wiele innych zadań, które muszą być wykonane.

 

iBGP w takiej postaci się nie skaluje. Jest trudne w utrzymaniu i zarządzaniu. Pożera cenne zasoby routera.

Rozwiązanie problemu z iBGP 

Na pomoc w takiej sytuacji przychodzi nam Route Reflector (RR) i Konfederacja. W dzisiejszym wpisie zajmę się tylko Router Reflectorem.

Co to jest Route Reflector?

Jest to mechanizm pozwalający na drobne rozluźnienie zasady, że każdy router iBGP musi mieć zestawioną sesję z każdy routerem iBGP. W sieci nie musimy mieć full mesh iBGP. Wystarczy jedna sesja iBGP do routera działającego jako Route Reflector. Route reflector wysyła (odbija) najlepsze(best) trasy/route-y, których nauczył się z iBGP do wszystkich swoich klientów.

Sieć bez route reflectora:

Sieć z route reflectorem (jednym, niezalecane działanie, ale o tym poźniej):

Route reflector = pojedynczy punkt awarii?

Aby mieć redundancje w sieci i pozbyć się pojedynczego punktu awarii zalecane jest skonfigurowanie klastra route reflectorów. W klastrowaniu route reflektorów mamy dwie możliwości.

Takie same cluster-id

Mamy dwa route reflectory z identycznymi cluster-id (RR-1 i RR2) oraz cztery routery (R1, R2, R3, R4). Każdy z routerów ma ustawioną sesje iBGP do RR-1 i RR-2.

R1 dostaje trasę z sesji eBGP i rozgłasza ją do obu route reflectorów (RR-1 i RR-2). RR-1 tworzy wiadomość update z atrybutem cluster-id o wartości X.X.X.X (swoje cluster-id) oraz id routera, z którego “nauczył” się trasy, w tym przypadku id router R1.

Tak przygotowany update wysyła do R2, R3 i R4 oraz do RR-2. Takie samo działanie podejmuje RR-2. RR-2 nie akceptuje trasy od RR-1, ponieważ atrybut cluster-id zawiera jego własne id. R2, R3 i R4 dostają dwa razy taki sam update. Route reflectory przechowują tylko jeden wpis.

Różne cluster-id

Mamy dwa route reflectory z różnymi cluster-id (RR-1 i RR2) oraz cztery routery (R1, R2, R3, R4). Każdy z routerów ma ustawioną sesje iBGP do RR-1 i RR-2.

Router R1 dostaje trasę z sesji eBGP i rozgłasza ją do obu route reflectorów (RR-1 i RR-2). Route reflector RR-1 tworzy wiadomość update z atrybutem cluster-id o wartości X.X.X.X (swoje cluster-id) oraz id routera, z którego “nauczył” się trasy, w tym przypadku id router R1.

Tak przygotowany update wysyła do R2, R3 i R4 oraz do RR-2. Route reflector RR-2 akceptuje trasę i do atrybutu cluster-id dodaje swoje id (X.X.X.X, Y.Y.Y.Y) RR-2 dostał też trasę od R1, do której dodał jako atrybut cluster-id swoje id (Y.Y.Y.Y).

RR-2 mając dwie trasy, musiał użyć algorytmu wyboru najlepszej ścieżki i preferuje trasę, którą nauczył się od R1 niż od RR-1, ponieważ atrybut cluster-id zawiera tylko jedno id, a nie dwa. Tylko najlepsza ścieżka zostanie wysłana do R2, R3, R4 i RR-1

Takie samo działanie podejmuje RR-1 i również preferuje trasę bezpośrednio od R1, którą rozsyła do R2, R3, R4 i RR-2.

Każdy z route reflectorów dostanie dwa update-y. Jeden od R1 a drugi od sąsiedniego RR. Oba update zostaną zaakceptowane, ale tylko najlepszy zostanie dalej rozgłoszony.

Wady route reflectorów

Nieoptymalny routing – route reflector podejmuje decyzje, która ścieżka jest najlepsza. Najlepsza z jego punktu widzenia, a nie z punktu klienta i taką ścieżkę wysyła do klienta.

Czas konwergencji sieci – w przypadku sieci full mesh, update musi “przejść” tylko przez jeden “skok”. W przypadku sieci z route reflectorami update przechodzi przez jeden lub więcej route reflectorów, zanim dotrze do końcowego routera iBGP.

Brak wiedzy o innych ścieżkach – route reflector wysyła tylko najlepszą jedną ścieżkę do klienta. Klient nie ma pełnej informacji o sieci i nie ma ścieżki zapasowej (backup path). Ważne przy MPLS FRR.

Podsumowanie

Nie ma rozwiązań idealnych. Decyzja o wdrożeniu route reflectorów powinna być poparta analizą sieci i potrzeb. Tego, co chcemy osiągnąć i z czego możemy zrezygnować. Route reflectory upraszczają nam sieć, ale też mogą powodować problemy.

Podobne wpisy

Next-hop self – BGP

Parę wpisów temu pisałem o tym, że iBGP nie zmienia atrybuty next-hop gdy “przekazuje” prefiksy do innych routerów iBGP. Dzisiejszy wpis jest, jak rozwiązać ten problem - next-hop self.Inżynier sieciowy lubiący dzielić się wiedzą i pomagać innym zrozumieć zawiłości...

czytaj dalej

Wyrażenia regularne w BGP – regexp

     Regexp, a dokładniej regular expressions, czyli wyrażenia regularne są to wzorce, które opisują ciągi znaków. Bardzo często spotykane w językach programowanie. Dobra, ale co wyrażenia regularne mają wspólnego z BGP? W BGP takim ciągiem znaków jest...

czytaj dalej

Algorytm wyboru trasy w BGP – RFC4271

     Pamię­ta­cie może ze szkoły zda­nie, które pra­wie każdy nauczy­ciel wygła­szał: < wsta­w_co­kol­wie­k> musisz znać, nawet jak Cię obu­dzą w środku nocy? To dzi­siaj wpis na bar­dzo ważny temat: Algo­rytm wyboru trasy w BGP.Poprzednie wpisy z...

czytaj dalej
Tomasz Mikołajek

Tomasz Mikołajek

Założyciel Showroute.pl

Inżynier sieciowy lubiący dzielić się wiedzą i pomagać innym zrozumieć zawiłości działania sieci i Internetu.