Mikrotik na poważnie. Odwaga czy głupota? [z archiwum ICT Professional]

 
[miejsce publikacji] ICT Professional, Nr 13 – Zima 2016/2017, strona 33.
[rubryka] Case Study
[autor] Łukasz Szwajka
[tytuł] Mikrotik na poważnie. Odwaga czy głupota?
___________________________________________________________________________________________________________________
MikrotikRouterOS stał się bardzo popularnym systemem dla urządzeń sieciowych. Swoje korzenie ma wprawdzie w sieciach WLAN, ale w obecnej wersji jego zastosowanie jest znacznie szersze. Coraz większa grupa administratorów decyduje się na wdrożenie Mikrotika w swoich sieciach do wielu poważnych zadań.
Zawsze powtarzałem, że największa zaleta Mikrotika, czyli prostota obsługi, jest jednocześnie jego wadą. Z jednej strony doświadczony administrator nie ma problemu ze skonfigurowaniem tego systemu, ale z drugiej – nie trzeba posiadać dużej wiedzy, by uruchomić zaawansowane usługi takie, jak np. BGP. Dzięki temu bardzo często w naszym środowisku do Mikrotika przykleja się łatkę systemu dla niedoświadczonych administratorów, a samo używanie Mikrotika bywa wręcz powodem do wstydu. Chciałbym w tym artykule trochę powalczyć z tym krzywdzącym stereotypem.
Sieć ART-COM w Jaworznie obsługuje ponad 6000 abonentów. Stosujemy zasadę, że każdy abonent powinien być widoczny w Internecie pod unikalnym adresem IP. Klientom komercyjnym przyznajemy rzeczywiste adresy IP, natomiast klientów indywidualnych NAT-ujemy na zasadzie SNAT 1:1, natomiast DNAT uruchamiamy na życzenie klienta. Zaletą tego rozwiązania jest to, że na DNAT decyduje się mniej niż 10% abonentów, co w znacznym stopniu ogranicza problemy związane z botnetami, ddosami i innymi problemami związanymi z wystawieniem przez klienta urządzeń do Internetu. Do niedawna do obsługi sieci służyły nam głównie routery oparte o system operacyjny Linux. Rozwiązanie programowe nie było nasze, korzystaliśmy z usługi firmy zewnętrznej. O ile w kwestii wydajności byliśmy zadowoleni, tak problematyczne stawało się ograniczenie w zakresie obsługi routerów przez nasz autorski system do zarządzania siecią ISAS. Brakowało nam pewnych funkcjonalności, bez których ograniczony byłby dalszy rozwój sieci. Zapadła decyzja o zmianie rozwiązania.
Poza routerami do obsługi NAT i zarządzania pasmem postanowiliśmy wymienić również routery odpowiedzialne za realizację BGP. O ile w przypadku BGP wybór jest całkiem spory i tak naprawdę zależny tylko od preferencji administratora (ewentualnie finansów), tak z wyborem wydajnego urządzenia dla usługi NAT dla 6000 klientów mieliśmy spory problem. Największym wyzwaniem było znalezienie rozwiązania, które pozwoli na bezproblemową integrację z naszym systemem ISAS. Do roli BGP finalnie zdecydowaliśmy się na Cisco ASR1001-X, które przez moment rozważaliśmy również do wykorzystania jako NAT/BRAS, ale mimo kilku prób nie udało nam się znaleźć wydajnego rozwiązania na integrację tych wszystkich funkcji z ISAS-em. W ten sposób na tapetę trafił Mikrotik, który spełniał nasze podstawowe założenia, czyli posiadał szybkie API oraz dobrą dokumentację i support. Zależało nam też na rozwiązaniu, które każdy z naszych administratorów będzie potrafił bez większego problemu opanować. Mikrotik idealnie się wpisał w te założenia.
Rozpoczęliśmy przygotowania do pierwszych testów. Na początek nasz programista Adam Kubica w oparciu o API Mikrotika przygotował aplikację na potrzeby integracji z ISAS-em. MTIK-CTL, bo taką aplikacja nosi nazwę, jest kontrolerem konfiguracji routerów. Odpowiada za konfigurację wszystkich elementów potrzebnych do działania Internetu dla abonenta takich, jak VLAN, adresy IP, routing, SNAT/DNAT, taryfy, DHCP relay. Funkcjonalność aplikacji jest ograniczona tylko tym, co potrafi API, więc w praktyce pozwala na skonfigurowanie dowolnej funkcji Mikrotika.
Mając już aplikację do naszego systemu, mogliśmy zacząć dobierać sprzęt. Zachęcony doświadczeniami kolegów z platformami MikrotikRouterBoard CCR, zdecydowałem się na zakup CCR1036-8G-2S+ wierząc, że wydajnościowo da sobie radę z obsługę ponad 6000 klientów i ruchem w szczycie sięgającym trochę ponad 3Gbps. Przy pierwszym podejściu postanowiliśmy funkcje routera z NAT oraz zarządzanie pasmem w oparciu o Simple Queues (SQ) zrobić na jednym urządzeniu (do tej pory realizowały nam to dwa routery linuksowe). Przełączenie ruchu zrobiliśmy w nocy. Przed południem już wiedzieliśmy, że zabraknie nam wydajności CPU. Wieczorny szczyt okazał się zabójstwem dla tego urządzenia, procesor skończył się około godziny 18.00.
Zanim zdecydowaliśmy się na drugi test, postanowiłem skonsultować naszą konfigurację z supportemMikrotika. Dostałem kilka cennych wskazówek dotyczących optymalizacji tablicy NAT za pomocą tzw.customchain. Chodziło o zbudowanie drzewka,aby maksymalnie skrócić czas przeszukiwania tablicy NAT. Wiedząc jednak, że to za mało, by udźwignąć taki ruch w szczycie, zdecydowaliśmy się drugi test przeprowadzić z wykorzystaniem dwóch routerów CCR1036 rozdzielając router z NAT od zarządzania pasmem. W takiej konfiguracji router z NAT nawet podczas godzin szczytu nie przekraczał 20% użycia CPU. Na pewno poza optymalizacją NAT pomogło uruchomienie funkcji fasttrack, która była możliwa z racji braku Simple Queues na tym routerze (jak wiadomo SQ nie działają w połączeniu z fasttrack). Niestety router do zarządzania pasmem zaczął mieć problemy przy ruchu powyżej 1,5Gbps. Objawiało się to skokami CPU z 10% do 100% na wszystkich rdzeniach. Doszliśmy do tego, że skoki CPU pojawiają się w momencie, gdy dodajemy/edytujemy kolejki SQ. Nie miało jednak znaczenia, czy robimy to przez API, czy ręcznie. Ciekawostką jest, że poniżej 1,5Gbps ten efekt nie miał miejsca. Konsultacja z supportem niestety nie przyniosła dobrych wiadomości. Dostałem potwierdzenie, że jest to znane zachowanie SQ na platformie CCR i procesorach Tilera i najprawdopodobniej problem ten zostanie rozwiązany dopiero w RouterOS v7. Niestety nikt nie wie, kiedy ta wersja się ukaże.
Byliśmy już zniechęceni dalszymi testami i w zasadzie zrezygnowaliśmy z myśli o wykorzystaniu Mikrotika. Przez przypadek jednak wdałem się w dyskusję na temat powyższego problemu z CCR na forum trzepak.pl. Kolega o nicku midland1 podsunął mi pomysł, aby spróbować tej samej konfiguracji wykorzystując platformę Supermicro z procesorem E3-1230v3 i kartą 10G SFP+. Na takich właśnie urządzeniach (model 512L-X10SLL+-F, karta AOC-STGN-i2s) pracowała nasza sieć z routerami linuksowymi. Wiedząc, że niewiele mamy do stracenia, postanowiliśmy spróbować. Zdecydowaliśmy się wykorzystać dwa komputery Supermicro zamiast dwóch CCR1036, czyli powtórzyć drugi test. Wynik przerósł nasze oczekiwania. Oba routery w szczycie zachowywały się bardzo stabilnie, nie było żadnych skoków CPU czy innych anomalii znanych nam już z testów z CCR.
Po dopracowaniu konfiguracji oraz aplikacji MTIK-CTL zdecydowaliśmy się na produkcyjne wdrożenie. Posiadamy dwie serwerownie, dlatego wszystkie routery zostały zdublowane i za pomocą protokołu BGP oraz VRRP zapewniają nam redundancję. Aplikacja MTIK-CTL w pełni pozwoliła zautomatyzować działania na routerach. Pełna synchronizacja bazy danych naszego systemu z routerami trwa kilkanaście sekund. Obecne platformy Supermicro dają nam jeszcze pewną rezerwę zasobów na przyszłość. Na ten moment ruch w szczycie sięga ponad 3,5Gbps, a zarówno router z NAT jak i ten z SQ nie przekracza 40% CPU. Szacujemy, że obecna konfiguracja powinna wystarczyć do ok. 5-6Gbps, zachowując jeszcze niewielką rezerwę na anomalia w sieci. Całość pracuje produkcyjnie od sierpnia 2016 roku.
Podsumowując nasze doświadczenia z wymiany routerów. Bardzo rozczarowałem się platformą RouterBoard CCR1036. Spodziewałem się znacznie więcej po tym urządzeniu. Wygląda na to, że mimo już stosunkowo długiej obecności na rynku, wciąż oprogramowanie MikrotikRouterOS nie jest dopracowane pod takąplatfomę sprzętową. W między czasie miałem okazję osobiście sprawdzić, jak CCR1036-8G-2S+ radzi sobie w roli routera BGP. Zachęcony byłem tym dlatego, że zauważyłem olbrzymią popularność w stosowaniu CCR jako BGP wśród ISP. Niestety też się rozczarowałem. Proces BGP w MT pracuje na jednym rdzeniu, a ten w CCR w porównaniu do platform x86 jest bardzo nisko taktowany (1,2GHz w przypadku CCR1036). W efekcie po pobraniu pełnej tablicy BGP jeden z rdzeni cały czas miał 100% obciążenie. Operacje na tablicy routingu przy takim obciążeniu były bardzo czasochłonne, wyszukanie konkretnego prefixu trwało nawet kilkanaście minut. Krótko mówiąc do urządzeń z linii CCR się zraziłem i polecał ich póki co nie będę. Natomiast co do samego systemu MikrotikRouterOS, jak widać przy dobraniu odpowiedniego sprzętu, przygotowaniu konfiguracji zgodnie z dokumentacją i zaleceniami, można się cieszyć stabilnym, elastycznym i wydajnym rozwiązaniem. Z niecierpliwością czekam na dalszy rozwój tego systemu. Zwłaszcza na wersję v7, która ma wprowadzić sporo obiecanych zmian. Ciekawostką jest też na pewno wersja RouterOS CHR przeznaczona do uruchomienia na wirtualizacji. Uważnie śledzę ten projekt. Być może następna modernizacja urządzeń w naszej sieci pójdzie właśnie w tym kierunku.