warianty peeringu #2

W poprzednim odcinku przedstawione zostały trzy topologie, jako różne warianty peeringu: http://netdesign.zone/2015/04/warianty-peeringu-1/

Dzisiejszy wariant, to rozwiązanie oferujące peering BGP z pełną tablicą publiczną, a jednocześnie wykorzystujące zamiast routerów trzy przełączniki. Każdy z nich mieści tylko 256 tys. prefiksów (może to być np. Catalyst 4500-X). Z uwagi na brak miejsca w tablicy każdy z przełączników ma przydzieloną inną cześć sieci publicznej, którą może przyjąć. Reszta prefiksów jest odfiltrowana. Tym samym w celu rozgłoszenia pełnej tablicy BGP do klienta trzeba zestawić trzy osobne sesje do urządzeń operatora AS100 tak, jak jest to pokazane na poniższym rysunku.

post4-1

Switche są połączone trunkami, które przenoszą VLAN-y tranzytowe dla sesji eBGP. Każda sesja eBGP rozgłasza inną pulę prefiksów. Łącznie jest rozgłaszana pełna tablica routingu do klientów BGP.

Jeżeli przyjmiemy okrągłą wartość dla pełnej tablicy BGP, czyli 512 tys. prefiksów (obecnie jest już prawie 550 tys.), to w takim rozwiązaniu jeden przełącznik zapewni redundancję dla pozostałych węzłów. Czy nie za mało o dodatkowy switch? Czy nie powinny być cztery switche, by pomieścić zapasową tablicę BGP? – ktoś mógłby zapytać. Nie jest to konieczne jeżeli rozpatrujemy redundancję całego węzła, a nie poszczególnych prefiksów. Pomiędzy przełącznikami można zestawić sesję kontrolną np. BFD lub IGP, od której będzie zależało, która pula adresów zostanie zaakceptowana w sesji eBGP na switchu zapasowym. Trudniejsze byłoby wdrożenie redundacji per prefiks. Przykładowo, jeżeli SW1 straciłby prefiks 210.51.225.0/24, to SW2, który pełniący rolę zapasowego węzła musiałby tą trasę pobrać od swojego sąsiada, aby dostarczyć ją do klienta BGP. Bezpośredniego wykrywania prefiksów między przełącznikami nie można by zrobić, gdyż brakuje miejsca w tablicy routingu. Pamiętajmy, że jest tylko 256 tys. tras dla omawianego przykładu. A co, gdyby wykorzystać router klienta? Można by powiązać pole Withdrawn Routes w komunikacie UPDATE BGP, który otrzymuje klient z polem Prefix w komunikacie ORF (Outbound Route Filter) BGP, który klient mógłby wysyłać. Zautomatyzowałoby to proces pozyskiwania prefiksu od sąsiedniego ISP. Jeżeli SW1 zasygnalizowałby utratę trasy, to router klienta BGP wysłałby prośbę o update do SW2, zaś SW2 pobrałby trasę od ISP2 i wysłał do klienta. Takiej wbudowanej opcji niestety nie ma, więc trzeba posłużyć się skryptem EEM/TCL, który zareaguje w przypadku wycofania trasy i zaktualizuje ORF.

Jakie są zalety tej gimnastyki? Jest to niższy koszt urządzeń w porównaniu do ceny routerów. Otrzymujemy również możliwość oferowania usług peeringu, a jednocześnie routingu z innymi stronami. Podskórnie jednak czujemy, że wady operacyjne są znaczące. Jest większy narzut administracyjny, trudniejsza diagnostyka, więcej interakcji z sąsiednimi ISP, jak i klientami, by rozwiązanie działało.

Dodatkowo AS100 z trzema urządzeniami bez pełnej tablicy BGP nie może zaoferować pełnego tranzytu między ISP. Aby to zmienić potrzebne są również trzy sesje eBGP do zewnętrznych ISP tak, jak na poniższym schemacie. Tym samym przełączniki brzegowe muszą być podłączone trunkami do poszczególnych operatorów.

post4-2

Czy w powyższym rozwiązaniu może dojść do trwałej pętli routingu w AS100 z powodu przecinających się sesji BGP? O pętlach już niebawem.

A powyższe rozważania potraktujmy bardziej jako ciekawostkę, niż rekomendację do wdrożenia. Choć kto wie, może ktoś się skusi na taki design? ;)

Facebooktwittergoogle_plusredditpinterestlinkedinmail