Protokół BGP powszechnie wykorzystujemy do zapewnienia wymiany informacji o prefiksach (podsieciach) pomiędzy systemami autonomicznymi. Jednak także wewnątrz naszego AS-a (ang. Autonomous System), czyli sieci zrządzanej przez nas, routery muszą wymieniać ze sobą informacje o prefiksach. Teoretycznie mogłyby to robić za pośrednictwem protokołów z rodziny IGP takich jak OSPF czy EIGRP. Jednak w trakcie redystrybucji pomiędzy protokołami administratorzy traciliby to co najcenniejsze – atrybuty, czyli informacje przypisane do prefiksów BGP. Dlatego także wewnątrz systemu autonomicznego wykorzystujemy BGP, a dokładniej iBGP, aby informacji zapisanych w atrybutach nie zgubić.

Protokół iBGP do poprawnego działania wymaga, aby wszystkie routery wymieniające informacje o prefiksach były ze sobą połączone, czyli skonfigurowane i aktywne były pomiędzy nimi sesje iBGP. Ilość potrzebnych sesji iBGP wyliczamy według wzoru N(N-1)/2. Jeżeli mamy 5 routerów w naszym systemie autonomicznym, to musimy utworzyć 10 sesji iBGP. Gdyby w naszej sieci routerów iBGP było 10, to pełna siatka połączeń składałaby się z 45 sesji. Duża liczba niezbędnych do utrzymania konfiguracji sesji iBGP jest niepraktyczna oraz zwiększa ryzyko pomyłki. Każda zmiana w tablicy BGP wymaga od routera ponownego przeprowadzenia całego procesu wyboru najlepszej trasy i rozesłania zaktualizowanej informacji do wszystkich swoich sąsiadów.

Route Reflector to jedna z metod zmniejszenia wymaganej liczby połączeń iBGP między routerami wewnątrz systemu autonomicznego. Routery zamiast wymieniać się informacjami o prefiksach bezpośrednio między sobą, przesyłają i odbierają informację jedynie od dedykowanych urządzeń zwanych właśnie route reflectorami. Nie ma potrzeby już konfigurowania sesji iBGP bezpośrednio pomiędzy samymi routerami. W pojedynczym systemie autonomicznym powinniśmy mieć ich co najmniej dwa dla redundancji. W sieci z 10 routerami iBGP i dwoma route reflectorami liczba sesji iBGP ograniczy się jedynie do dwóch.

Rozgłaszanie aktualizacji

Z technologią route reflectorów wiąże się kilka pojęć:

  • Route Reflector – router skonfigurowany do pracy w charakterze route reflectora
  • Route Reflector Client – router pracujący jako klient route reflectora
  • Klaster – route reflector, routery klienckie oraz sesje iBGP pomiędzy nimi

Kolejnym ważnym rozróżnieniem są dwa typy sąsiedztwa:

Peer Type Połączenia Klaster
Route Reflector Client Jedynie między RR a klientem Wraz z RR i pozostałymi klientami tworzy klaster
Non-Client (zwykłe połączenie iBGP) Wymagane połączenia z każdym z routerów iBGP Nie jest częścią klastra

Jedynie urządzenia pełniące rolę Route Reflectora mają wiedzę, które z pozostałych routerów pracują w charakterze Route Reflector Client, a które jako Non-Client. Dlatego Route Reflectory muszą zapewnić mechanizm split horizon zapobiegając w ten sposób powstawaniu pętli. W zależności od typu sąsiedztwa nieco inaczej następuje rozgłaszanie informacji o prefiksach.

Aktualizacja odebrana przez RR od jednego z klientów jest rozgłaszana do pozostałych routerów klienckich w klastrze, a także do wszystkich routerów nie-klienckich
Aktualizacja odebrana od routera niebędącego klientem Route Reflectora jest rozgłaszana przez RR jedynie do routerów klienckich w ramach klastra

Informacje o prefiksach odebranych od sąsiadów eBGP zawsze są rozgłaszane zarówno do routerów klienckich w ramach klastra jak i tych Non-Client.

Nowe atrybuty

W sieci, w której skonfigurowane zostały Route Reflectory do prefiksów przypisywane są trzy nowe atrybuty:

  • CLUSTER_ID – zapobiega powstawaniu pętli przy wymianie aktualizacji pomiędzy samymi Route Reflectorami. Routery RR działające w ramach jednego klastra muszą mieć przypisany 4-bajtowy identyfikator, dzięki czemu pozostałe routery RR w klastrze mogą łatwo zidentyfikować i odrzucić informacje wysłaną przez inny Route Reflector
  • CLUSTER_LIST – pojedynczy Route Reflector może wchodzić w skład więcej niż jednego klastra. W takim wypadku RR używa atrybutu CLUSTER_LIST aby zignorować informacje o trasie, która już została przetworzona przez klaster, do którego należy
  • ORIGINATOR_ID – kiedy Route Reflector “odbija” do klientów informację o prefiksie przypisuje w atrybucie ORIGINATOR_ID identyfikator routera od którego aktualizację odebrał. Jeżeli jakikolwiek router kliencki odbierze aktualizację zawierająca w tym atrybucie własny identyfikator to ją zignoruje.

Konfiguracja Route Reflectorów

Konfiguracja iBGP z Route Reflectorami jest bardzo prosta. Na urządzeniach pracujących w roli Route Reflector Client sesję iBGP do RR konfigurujemy w tradycyjny sposób jak dla każdego innego sąsiada iBGP:

router bgp 100
 bgp router-id 1.1.1.2
 neighbor 10.0.0.1 remote-as 100

Natomiast na routerze pełniącym funkcję Route Reflectora musimy wskazać, które z sąsiadujących urządzeń będzie klientem:

router bgp 100
 bgp router-id 1.1.1.1
 neighbor 10.0.0.2 remote-as 100
 neighbor 10.0.0.2 route-reflector-client