Route Reflector – Skalowalność iBGP

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.

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-list o wartości X.X.X.X (swoje cluster-id) oraz z atrybutem originator id, czyli id routera, z którego “wprowadził” trase do sieci, 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-list 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-list o wartości X.X.X.X (swoje cluster-id) oraz z atrybutem originator id czyli id routera, z którego “wprowadził” trase, 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-list 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-list 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.

Atrybut originator id chroni przed pętlą pomiędzy klientami route reflectorów.

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.

Problem z Next hop self – gdy RR jest routrem brzegowym trzeba pamiętać aby podmieć tylko i wyłącznie next hop dla prefixów nauczonych z eBGP. Jeśli podmienimy dla wszystkich to może powstać problem nieoptymalnego routingu. Cały ruch będzie przechodził przez RR.

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