Co to jest route reflector?
Route reflector to router iBGP, który rozsyła trasy między klientami i znosi pełną siatkę sesji. Omawiamy klastry, ochronę przed pętlami i route server.
Ostatnia aktualizacja:
Route reflector (RR) to router BGP, który łamie regułę zakazującą rozsyłania tras nauczonych przez iBGP do innych sąsiadów iBGP. Pozwala to skalować wewnętrzny BGP bez budowania pełnej siatki sesji. W klasycznym iBGP każdy router musi mieć sesję z każdym innym routerem (full mesh), bo trasy nauczone od jednego peera iBGP nie są przekazywane dalej. Route reflector, opisany w RFC 4456, znosi to ograniczenie. Wyznaczony router (reflektor) odbiera trasy od swoich klientów i odbija je do pozostałych klientów oraz peerów, przez co liczba wymaganych sesji spada.
Problem pełnej siatki iBGP
Wewnątrz jednego systemu autonomicznego routery wymieniają trasy przez iBGP, a zasada antypętlowa zabrania ponownego rozgłaszania trasy nauczonej od innego routera iBGP. Aby każdy router znał wszystkie trasy, klasyczne rozwiązanie wymaga pełnej siatki sesji iBGP. Liczba sesji rośnie kwadratowo: dla n routerów potrzeba n*(n-1)/2 sesji. Dla 10 routerów to 45 sesji, dla 50 routerów już 1225. Taka konfiguracja jest trudna w utrzymaniu i obciąża pamięć urządzeń.
Jak działa odbijanie tras i klastry
Reflektor dzieli swoich sąsiadów iBGP na klientów i nie-klientów. Reguły rozsyłania zależą od tego, skąd przyszła trasa. Trasa od klienta jest odbijana do wszystkich pozostałych sąsiadów, a trasa od nie-klienta (zwykłego peera iBGP) trafia tylko do klientów. Reflektor wraz z przypisanymi klientami tworzy klaster (cluster). Aby zapobiec pętlom, RFC 4456 wprowadza dwa atrybuty oraz typowe wzorce wdrożenia:
- ORIGINATOR_ID: niesie router ID źródła trasy. Router odrzuca trasę z własnym ORIGINATOR_ID.
- CLUSTER_LIST: lista identyfikatorów klastrów, przez które przeszła trasa. Reflektor odrzuca trasę zawierającą jego własny cluster ID.
- Redundancja przez wiele reflektorów w jednym klastrze lub nadmiarowe sesje klient-reflektor.
- Hierarchia reflektorów. Reflektor może sam być klientem reflektora wyższego poziomu w dużych sieciach.
Route reflector a route server
Route reflector i route server bywają mylone, bo oba pośredniczą w wymianie tras, lecz działają w zupełnie innych domenach. Route reflector pracuje w iBGP, wewnątrz jednego systemu autonomicznego, i skaluje routing wewnętrzny operatora. Route server pracuje w eBGP, na punkcie wymiany ruchu (IXP), i pośredniczy w peeringu między różnymi, niezależnymi systemami autonomicznymi, pozostając transparentny w AS_PATH (RFC 7947). Reflektor zachowuje atrybuty iBGP i nie zmienia NEXT_HOP, ale jest narzędziem czysto wewnętrznym. Nie ma związku z peeringiem na IXP.
Route reflectory a AS202520 SkyPass
AS202520 SkyPass wykorzystuje route reflectory w swojej sieci szkieletowej między PoP-ami w Warszawie i Wrocławiu, aby skalować iBGP bez pełnej siatki sesji i utrzymywać spójny obraz tras na wszystkich routerach brzegowych. Dzięki temu trasy nauczone od naszych dostawców tranzytu IP oraz partnerów peeringowych w THINX, TPIX, we WRIX i w 1-IX rozkładają się stabilnie po całej sieci. Klienci kupujący tranzyt IP lub peering nie muszą znać tej warstwy. Route reflectory działają wewnętrznie, a my dbamy o ich redundancję i poprawną konfigurację klastrów.
Najczęstsze pytania
Czym różni się route reflector od route servera?
Route reflector działa w iBGP wewnątrz jednego systemu autonomicznego i skaluje routing wewnętrzny, a route server działa w eBGP na IXP i pośredniczy w peeringu między różnymi systemami autonomicznymi. To dwa odrębne narzędzia.
Po co wprowadzono route reflectory?
Aby uniknąć pełnej siatki sesji iBGP, której liczba rośnie jak n*(n-1)/2. Route reflector (RFC 4456) pozwala rozsyłać trasy iBGP bez konfigurowania sesji każdy-z-każdym.
Czy route reflector tworzy ryzyko pętli routingu?
RFC 4456 chroni przed pętlami atrybutami ORIGINATOR_ID i CLUSTER_LIST. Router odrzuca trasę z własnym ORIGINATOR_ID lub własnym cluster ID, co zatrzymuje zapętlenie.
Czy potrzebuję wielu route reflectorów?
Tak, dla redundancji. Pojedynczy reflektor jest pojedynczym punktem awarii, dlatego zwykle wdraża się co najmniej dwa reflektory na klaster lub nadmiarowe sesje klient-reflektor.