warianty peeringu #1

Jako kontynuację dyskusji z forum CCIE.pl http://ccie.pl/viewtopic.php?t=21090 chciałbym rozważyć różne warianty topologii logicznej oraz sesji BGP.

1. Topologia klasyczna

W tej topologii korzystamy z dwóch typów sesji BGP. Sesja eBGP do połączeń zewnętrznych oraz sesje iBGP do połączeń w ramach własnej domeny AS100. Sesje iBGP najczęściej zestawia się pomiędzy adresami IP interfejsów Loopback. Są to więc sesje multihop. W związku z tym potrzebna jest informacja o adresach Loopback w tablicy routingu. Można to zrobić za pomocą protokołu IGP lub routingu statycznego. Poglądowa topologia jest pokazana na poniższym rysunku. Dla uproszczenia routery mają pojedyncze sesje eBGP z zewnętrznymi operatorami ISP.

post3-1

Rozwiązanie jest klarowne od strony polityki routingu. Są jasne granice występowania sesji eBGP oraz iBGP. Trasy routingu pokrywają się z topologią fizyczną. Wszystkie połączenia są routed, a co za tym idzie, jest łatwiejsza diagnostyka sieci.

Od strony projektowej można się zastanowić, czy rozwiązanie ma jakieś wady? Rozważmy następujące z nich:
Skalowalność: przy trzech routerach nie ma problemów ze skalowalnością. Jeżeli jednak domena AS100 składałaby się ze 100 urządzeń, to ilość sesji iBGP zwiększyłaby się do prawie 5 tysięcy. Konieczne byłoby zastosowanie route-reflektorów (RR) lub konfederacji BGP. Wada łatwa do obejścia w przypadku RR. Inną wadą może być skalowalność portów w ramach jednego urządzenia. Jeżeli w jednym punkcie styku jest wielu klientów trzeba by dodatkowo wstawić przełącznik lub router.
Konwergencja: wykrywanie awarii sąsiada iBGP bazuje domyślnie na osiągalności adresów Loopback w tablicy routingu. Powiadamianie może być zrobione na bazie protokołu IGP, ale również sesji multihop BFD, co jeszcze bardziej przyspiesza reakcję na awarię sąsiada. Co w przypadku topologii z route-reflektorem? Wówczas router brzegowy czeka na reakcję RR, który musi zauważyć zmianę i wyznaczyć nową najlepszą trasę. Może to być operacja, która trwa poniżej sekundy, a może to trwać wiele sekund. Zależy od platformy sprzętowej oraz ilości prefiksów do przeliczenia. Nie to jednak zabiera najwięcej czasu. Najdłużej trwa aktualizacja tablic FIB. Co prawda zapis pojedynczego prefiksu trwa setki us, ale wolumen prefiksów sprawia, że łączny czas update’u może być powyżej minuty. Zatem konwergencja jest wadą, ale nie tyle rozważanej topologii, co po prostu posiadania pełnej tablicy BGP. Jest to charakterystyka połączeń internetowych i trzeba po prostu z tym żyć.
Koszt: trzy routery nie będą drogie, ale efekt skali oraz konieczność dotarcia do klienta znajdującego się poza głównymi kolokacjami będzie podrażał rozwiązanie bazujące wyłącznie na routerach. Co zrobić by koszt rozwiązania obniżyć i zastąpić część routerów prostymi przełącznikami L2? Spójrzmy dalej.

2. Topologia mieszana

Zastępujemy R1 oraz R2 przełącznikami warstwy 2. Sesje eBGP będą prowadzone wówczas zarówno przez łącza natywne L3, jak i połączenia L2 wykreowane na bazie VLAN-ów. Sesji iBGP na poniższym rysunku nie widać, ale w ramach redundancji można sobie wyobrazić, że R3 jest kolokacją złożoną z dwóch urządzeń, pomiędzy którymi jest takie sąsiedztwo.

post3-2

Rozwiązanie skaluje się bardziej, niż topologia złożona z samych routerów. Jest tutaj więcej portów, do których można podłączyć klientów. Koszt rozwiązania będzie również niższy, niż przy topologii klasycznej.

Przyjrzyjmy się wadom:
Nieoptymalna trasa routingu/switchingu: z uwagi na większą koncentrację routingu ruch niejednokrotnie będzie się zawijał. Przy odpowiedniej lokalizacji routerów np. w głównych miastach oraz biorąc pod uwagę generalne opóźnienia występujące w Internecie nie będzie to znacząca wada.
Bardziej skomplikowany QoS: konieczność zapewnienia QoS dla różnych znaczników oraz klientów mogących pojawiać się na różnych interfejsach typu trunk lub routed. Z drugiej strony może QoS na pierwszym porcie dostępowym wystarczy? Później i tak jest multipleksacja podobna do tej, jak jest w topologii w pełni routowalnej. Nie jest to raczej istotna wada dla usług dostępu do Internetu.
Konieczność korzystania z protokołów spanning-tree: jeżeli jest możliwość użycia w topologii protokołu/rozwiązania ringowego np. REP lub MSTAG, to już sukces. Jeżeli jednak  spanning-tree jest jedyną opcją, to trzeba starać się ograniczać topologię L2 do połączeń punkt-punkt lub ring. Im większa płaska struktura warstwy 2, tym większa szansa na niestabilności, nadmierny flooding oraz pętle. Dodatkową wadą jest trudniejsza diagnostyka sieci.

3. Topologia peeringowa

W rozwiązaniu peeringowym idziemy jeszcze dalej. Pozbywamy się routerów zupełnie i tworzymy topologię, w której każdy może się peerować z każdym tak, jak jest to pokazane na poniższym rysunku.

post3-3

Można przy tym wydzielić konkretne VLAN-y, które będą służyć określonym grupom klientów, operatorów lub klas usługowych. Zaletą będzie niewątpliwie koszt rozwiązania. Nie ma też problemu ze skalowalnością prefiksów oraz sesji BGP. Przełączniki L2 nie zajmują się tymi zadaniami. Zaletą jest swoboda decyzji, którą pozostawia się operatorom z kim będą zestawiać sesje BGP. Niekoniecznie jest to jednak zaleta dla klientów. Część z nich woli krótki punkt styku z jedną odpowiedzialną stroną za ich sesję, niż tranzyt przez nieznane i dwóch operatorów, do których trzeba się zgłaszać w razie problemów. Dodatkowe wady:
Spanning-tree: to, co pojawiło się w topologii mieszanej tutaj uwidacznia się ze zdwojoną siłą. Im bardziej rozproszona architektura, tym większe ryzyko, że nie obejdzie się bez spanning-tree. Protokół wnosi sam w sobie wady związane z redundancją, konwergencją oraz diagnostyką. Chyba, że zastosuje się wirtualizację łączy i urządzeń, kaskadową topologię pierścieni, rozwiązania typu SPB/TRILL, H-VPLS lub mechanizmy nakładkowe np. VxLAN.
Dochód z usług biznesowych: Dla samego operatora AS100 rozwiązanie może oznaczać mniejszy dochód z oferowanych usług. Im niższa warstwa oferowanych usług, a tym samym ich mniejsza granulacja, tym mniejszy sumaryczny dochód, jakiego można się spodziewać. Co nie oznacza oczywiście, że biznes nie będzie dochodowy.

Czy są jeszcze jakieś warianty? Pewnie coś się znajdzie. Na przykład topologia zapewniająca full-feed BGP, ale złożona z przełączników, z których żaden pełnej tablicy BGP nie zmieści. O tej gimnastyce już w następnym odcinku.

Facebooktwittergoogle_plusredditpinterestlinkedinmail