Przy okazji protokołu BGP, a konkretnie iBGP, często słyszy się o konieczności tworzenia tak zwanego full mesh między routerami, czyli połączeń każdy z każdym. Postaram się krótko opisać co to jest i po co się tworzy takie połączenia.

Co to jest full mesh w iBGP? – Full mesh jest to połączenie sesją iBGP każdego z każdym routerem BGP wewnątrz AS. Należy pamiętać, że BGP to połączenie TCP warstwy 4 więc nie oznacza to konieczności istnienia tylu połączeń fizycznych. Aby zestawić sesję BGP wystarczy łączność na poziomie IP. Przy nawet niewielkich sieciach ilość połączeń iBGP może być znaczna, gdzie ich ilość można łatwo wyliczyć ze wzoru n*(n-1)/2 gdzie n jest liczbą routerów BGP. Dla 10 routerów będzie to 45 sesji iBGP!

Po co potrzebny jest full mesh? – Full mesh (lub mechanizmy go zastępujące) w iBGP jest niezbędny, gdyż routery iBGP nie przekazują sobie nawzajem informacji routingowych, które otrzymane zostały z wewnątrz AS (czyli z iBGP). Dla lepszego zobrazowania takiej sytuacji wyobraźmy sobie 3 routery A-B-C połączone a-do-b-do-c. Jeżeli zestawimy tylko sesję pomiędzy A i B oraz B i C to router B będzie miał pełną wiedzę od obydwu sąsiadów, ale nie przekaże jej dalej, czyli router C nie będzie znał tras routera A. Ten mechanizm jest konieczny, gdyż BGP wewnątrz AS nie ma mechanizmu zapobiegania pętlom, więc zapobieganie pętlom jest zrobione na tym poziomie. W eBGP pętlom zapobiega atrybut as-path, gdzie są wymienione wszystkie ASy przez które przechodzi ścieżka (więc jak wróci do nas to zobaczymy swojego ASa w as-path i wyrzucimy update) – w iBGPnie mamy możliwości dodawania własnego ASa gdyż wszystkie routery mają taki sam numer AS.

Czy jestem skazany na full mesh i dużą ilość połączeń iBGP? – I tak i nie. Full mesh w jakiejś postaci będzie, ale możemy mieć bardzo zredukowaną ilość połączeń iBGP. W większych sieciach, gdzie jest kilkadziesiąt routerów nie byłoby możliwe sprawne zarządzanie taką ilością połączeń, nie mówiąc o marnowaniu zasobów routerów, które byłyby obciążone utrzymaniem kilkudziesięciu sesji każdy. Mamy dwie możliwości redukcji ilości połączeń: konfederacje oraz route-reflectory. O ile konfederacje używane są dość rzadko (jak już to w największych sieciach) ze względu na problemy z migracją to tych struktur i niełatwym zarządzaniem, to route-reflectory mogą znaleźć zastosowanie nawet w najmniejszych sieciach. Implementacja i utrzymanie są naprawdę bardzo proste.