Border6 czyli jak optymalizować BGP.

Na ostatnim PLNOG mieliśmy okazję porozmawiać dłużej z przedstawicielami Border6. Firma ta dostarcza rozwiązanie, które ma pomóc klientowi w inżynierii WAN poprzez optymalizację BGP. Udało nam się przetestować ten produkt i wyrobić swoją opinie na jego temat.

Optymalizacja BGP, ale po co?

Jak wiemy BGP nie jest już najmłodszym rozwiązaniem bo zrodziło się w 1989, po naszym kraju w tym czasie jeździły maluchy i syrenki :). Mimo, że BGP przy wyborze tras wykorzystuję dość zawiłą logikę, bazującą na szerokim zestawie atrybutów, to jednak przychodzi nam zmierzyć się z takim problemami jak np.:

  • Prefiksy które rozgłasza nasz peer niekoniecznie są przez niego osiągalne.
  • Mimo, że wybór trasy jest dość skomplikowany to jednak nie bierze pod uwagę jakości danej trasy.

Lekarstwem Border6.

Z takim hasłem przychodzi do nas producent uważając, że jego produkt jest praktycznie dla każdego klienta, używającego BGP:

  • Prowajderzy
  • Dostawcy treści
  • Enterprise

Urządzenie poprzez szereg operacji sprawia, że ruch który kierujemy do klienta wypychany jest najlepszą scieżką. Dodatkowo otrzymujemy graficzną interpretację tego co się dzieje na naszym styku z operatorami. Możemy podejrzeć np, jak ruch rozkłada się na łącza, którędy są lepsze trasy, kto z kim się peer’uje itp.

Przykładowe rysunki poniżej przedstawiają wolumen ruchu OUT oraz IN wraz z podziałem na TOP 20 ASs:

border6_topASN

border6_top20_list

Z przedstawionego zestawienia otrzymujemy jasny wizerunek z jakimi AS-ami wymieniamy ile ruchu, oraz ile w którym kierunku ruchu jest generowane.

Możemy również podejrzeć jak ruch całościowo rozkłada się na naszych łączach:

border6_summary

Jak to działa?

Sposób działania tego mechanizmu można podzielić na trzy etapy:

1. Zbieranie danych:

System zbiera informacje o prefiksach sieciowych z którymi wymieniamy ruch (domyślnie jest to 1000 prefiksów). Do tego celu wykorzystywany jest Netflow oraz SNMP. Właśnie dzięki temu procesowi otrzymujemy wykresy jak powyżej.

2. Pomiary:

Na tym etapie system wybiera sobie konkretne adresy z zebranych prefiksów i dokonuje pomiaru jakości połączenia poprzez każdy z posiadanych ISP. W ten sposób może ocenić, które z połączeń oferuje lepsze czasy do danego punktu. Wybierając z Menu: Probing -> Gaps otrzymuje się ciekawe zestawienie tych pomiarów:

border6-gaps

Wynikiem jest lista prefixów dla których pokazane jest co wg border6 jest lepszym wyborem (Best transit) oraz to co tak naprawdę preferuje samo BGP (BGP choice). Kolumna GAP (RTD) pokazuje o ile „gorsza” jest trasa wg tego co wybrało BGP, a tym co można by otrzymać wg wyników pomiarów urządzenia. Ostatnia kolumna pokazuje ilość ruchu wymienionego z danym prefiksem, ma to nam pomóc zrozumieć czy dana różnica w jakości ma dla nas duże znaczenie (jeśli się okaże, że wolumen danych jest znaczący).

3. Route orders:

Jeśli włączymy moduł RDE (Route Decision Engine), wtedy urządzenia na podstawie zebranych danych i swoich pomiarów zacznie wprowadzać rozkazy mające wpływać na wybór tras przez nasze routery.

Z naszych obserwacji po uruchomieniu tego modułu zauważyliśmy duża zmianę rozłożenia ruchu na łączach. Do tej pory rozkładał się on w stosunku 80/20. Po włączeniu RDE ruch rozlał się na łącza bardziej równomiernie. Dodatkowo jeśli skonfigurujemy sobie Commitment’y naszych łącz, wtedy moduł dodatkowo będzie tak sterował ruchem, aby optymalizować koszty jakie ponosimy za wygenerowany na nich ruch.

Dodatkowo zauważyliśmy również, że przez okres naszych testów (około 1,5 tygodnia) moduł zarejestrowała 341 tzw BGP blind failures. Oznacza to tyle, że dokonał 341 decyzji  o zmianie tranzytu do danego prefiksu, gdyż mimo, że BGP wskazywało tranzyt A jako lepszy, to jednak był on przez niego nieosiągalny i ruch został przerzucony na tranzyt B.

Również w tym okresie moduł dokonał prawie 300 tysięcy rozkazów wynikających z pomiarów jakości.

W wyniku tych wszystkich operacji moduł wyliczył, że nastąpiło zmniejszenie czasów dostępu dla większości ruchu o około 25,49%.

Strona techniczna

Rozwiązanie to dostarczone może zostać albo jako fizyczne urządzenie z całym oprogramowaniem, bądź w postaci wirtualnego appliance’u. Oprogramowanie zawiera w sobie dwa moduły, serwer, który odpowiedzialny jest za całościowe działanie urządzenia, konfigurację, obliczenia itp. Oraz tzw sondy, których ilość zależy od ilości styków operatorskich.

Przykładowa architektura rozwiązania:

border6_schemat

Do poprawnego działania całego rozwiązania należy dokonfigurować kilka rzeczy w swojej architekturze:

1. Dodatkowe sesje iBGP między routerami i border6. Dzięki temu urządzenie będzie wydawało Route Orders. Działa to tak, że gdy dla prefixu np 90.100.100.0/24 który jest preferowany przez Tranzyt A, a urządzenie chce dokonać modyfikacji aby ruch szedł przez Tranzyt B. Wtedy „wstrzykuje” ten prefiks ale podzielony na pół czyli 90.100.100.0/25 i 90.100.100.128/25. Dzięki temu jako trasy bardziej precyzyjne wybierane są przez Tranzyt B.

2. Konfiguracja PBR. Każda sonda ma swój Adres IP, którego używa do próbkowania zdalnych sieci. Chodzi oto aby jedna sonda zawsze wychodziła jednym tranzytem a druga drugim.

3. No i zostaje jeszcze konfiguracja netflow, aby wysyłać dane do serwera border6.

We wszystkich detalach konfiguracyjnych otrzymujemy wsparcie od producenta.

Podsumowując

Border6 to ciekawe rozwiązanie jeśli chcemy  w dość prosty i zautomatyzowany sposób zapanować bardziej nad swoim stykiem ze światem. Jeśli zależy nam na dużej dostępności, jak najlepszych parametrach jakościowych, a może na optymalizacji kosztów łącz czy lepszej kontroli to rozwiązanie dobrze wpasowuje się w te wymagania.

Producent zapewnia, że w najbliższej przyszłości pojawiać się będą kolejne funkcjonalności. Wynikają one zazwyczaj z potrzeb klientów, z których opiniami bardzo się liczy.