Cisco Catalyst 9200 i tryb Cloud Monitoring w panelu Meraki

Migracja do chmury danych i usług to zjawisko, które przypomina rozpędzanie się ogromnego, kolejowego składu towarowego. Początki tego zjawiska mamy już bardzo dawno za sobą i obecnie jesteśmy na etapie, w którym to żelazne monstrum rozpędziło się już na tyle, że nie sposób go zatrzymać. Wciąż nabiera prędkości, przybiera na sile, pociąga za sobą coraz więcej i robi to coraz sprawniej. Wkracza w nowe obszary i rozszerza swoje możliwości. Świat bardzo chętnie poddaje się migracji do chmury w każdym znaczeniu. Obecnie chyba już niemal każda firma ma, bądź lada moment mieć będzie usługi, dane i narzędzia, które funkcjonują poza lokalną infrastrukturą. 

Zarządzanie infrastrukturą IT w chmurze to nic nowego. Pojawiło się lata temu i – szczególnie obecnie – nikogo już nie dziwi. Za rozwojem tego aspektu często nie nadążają jednak administratorzy, którzy z wielu różnych (często bardzo sensownych!) powodów opóźniają ten nieuchronny proces tak długo, jak tylko się da. Administracja infrastrukturą sieciową i serwerową to obszar krytyczny, nie dziwi więc podejście, w którym występuje awersja do wynoszenia rzeczy „ściśle tajnych” w „przestrzeń publiczną” (jaką jest szeroko pojęty Internet).

Co jednak, gdy ostatecznie zdecydujemy się zarządzać naszymi urządzeniami sieciowymi za pośrednictwem usług chmurowych? Można spróbować konwersji istniejącego sprzętu. Zapraszam do przewodnika po konwersji przełączników Cisco Catalyst serii 9200, 9300 i 9500 do dashboardu Meraki.

Jakie przełączniki obsługuje dashboard Meraki? 

Serie 9200, 9200L, 9300, 9300L, 9300X, 9500. Dokładną listę sprawdzić można na stronie producenta. Wspierane wersje oprogramowania na dzień publikacji tego artykułu to IOS-XE 17.3.1-17.9.2. 

Modele migracji i licencjonowanie 

Przełącznik Catalyst może pojawić się w naszym dashboardzie Meraki w dwóch wersjach: 

• jako przełącznik monitorowany (tzw. Cloud Monitoring), bez możliwości wprowadzania zmian w konfiguracji. Ten model działa obecnie bezproblemowo i to na nim skupimy się w tym artykule. 

• jako przełącznik monitorowany i zarządzany (tzw. Cloud Management) – obecnie obsługiwany wyłącznie przez wybrane przełączniki serii 9300 z wersją oprogramowania IOS-XE 17.8.1 lub nowszą. 

Przełączniki monitorowane używać będą licencji Meraki, natomiast te w pełni zarządzane (Cloud Management) wymagają licencji DNA Advantage (DNA-A) lub DNA Essentials (DNA-E). Różnica jest taka, że w wersji DNA-E nie ma możliwości wykrywania i monitorowania aplikacji oraz sprawdzania aktywności sieciowej Klienta – i to dotyczy także trybu „Cloud Monitoring”. Szczegółowe różnice przedstawia Cisco w swoich materiałach. 

Uwaga! Przełącznik Catalyst 9300 zarządzany przez dashboard Meraki nie będzie już urządzeniem działającym w oparciu o IOS-XE! Uruchomi się na nim software Meraki i ta zmiana jest w pełni odwracalna. Stacki także są obsługiwane. W przypadku przełączników wyłącznie monitorowanych, oprogramowanie pozostaje bez zmian i wciąż można zalogować się do jego CLI oraz zarządzać nimi w dotychczasowy, tradycyjny sposób. 

Potencjalne problemy i uwagi do migracji w modelu Cloud Monitoring 

Cisco zastrzega, że proces ten może wprowadzić problemy w kilku obszarach i warto się zapoznać z nimi zanim zdecydujesz się na migrację. Są to: 

1. Brak wsparcia uwierzytelnienia logowania do przełącznika za pośrednictwem serwera RADIUS (prace nad udostępnieniem tej funkcjonalności trwają). 

2. Obsługiwany jest tylko default VRF – jeżeli masz utworzoną większą liczbę wirtualnych tablic routingu, to nie zostaną one uwzględnione. 

3. Brak wsparcia dla proxy. Zarówno przełącznik, jak i narzędzie migracyjne Cisco (o nim później) wymagają bezpośredniego dostępu do wskazanych w dalszej części artykułu zasobów w Internecie, na porcie TCP 443. 

4. Jeżeli przełącznik jest zarządzany przez Cisco DNA Center, telemetria wprowadzona do konfiguracji przełącznika po migracji do Meraki dashboard celem monitorowania ruchu i urządzenia może powodować konflikty z tą, która zasila DNA Center. Cisco zastrzega, że na chwilę obecną nie bierze odpowiedzialności za efekty działania współistniejących mechanizmów telemetrii i zaleca wyłączyć tę dla DNA Center. 

5. Jeżeli na przełączniku skonfigurowano NetFlow, narzędzie migracyjne pozostawi tę konfigurację bez zmian, wobec czego nie będzie można obserwować ruchu sieciowego oraz rozpoznawać aplikacji przy pomocy dashboardu Meraki. 

Pre-flight check 

Lista wymagań jest długa i koniecznie należy poświęcić trochę czasu na jej weryfikację, by proces przebiegł bezproblemowo: 

1. Sprawdź, czy możesz zalogować się do swojego dashboardu Meraki. Jeżeli nie masz konta, możesz zarejestrować się za darmo, instrukcja tutaj. 

2. Pozyskaj klucz API z istniejącego dashboardu. Najpierw sprawdź, czy w sekcji Organization -> Settings opcja „Dashboard API Access” jest zaznaczona. Jeśli nie jest, zaznacz ją i zapisz zmiany. 

Następnie z sekcji My profile (prawy górny róg) wybierz opcję Generate new API key, bądź użyj takiego, który już istnieje. Uwaga! Musisz używać konta z uprawnieniami full admin, by mieć możliwość wygenerowania klucza. Pamiętaj także, że klucz potrzebuje nawet 15 minut od chwili wygenerowania by zacząć działać. 

Więcej szczegółów dotyczących odblokowywania dostępu do API znajdziesz tutaj. 

3. Sprawdź dostępność usług na komputerze, z którego będziesz dokonywać migracji. Musisz mieć możliwość połączenia się z api.meraki.com oraz meraki-cloud-monitoring-onboarding-app.s3.amazonaws.com przez port TCP 443. Uwaga! Jeżeli skonfigurowano, to zaleca się wyłączenie inspekcji ruchu HTTPS na czas przeprowadzania migracji. Wszelka forma ingerencji w certyfikaty może spowodować niepowodzenie procesu. 

4. Sprawdź konfigurację przełącznika i dostępność usług bezpośrednio na nim: 

• przełącznik musi łączyć się z Internetem przez port frontowy (nie może to być interfejs managementowy!) 
• musisz mieć dostęp do przełącznika za pomocą SSH z komputera, z którego będziesz dokonywać migracji 
• na urządzeniu musi być uruchomiony ip routing. Brama domyślna ustawiona poleceniem ip default-gateway nie jest wspierana podczas migracji! 

• uruchom tryb AAA poleceniem aaa new-model 
• użytkownik na przełączniku używany do procesu onboardingu musi mieć uprawnienia poziomu 15 
• upewnij się, że został skonfigurowany serwer DNS, zdolny rozwiązać FQDN eu.tlsgw.meraki.com (dla obszaru europejskiego). Jeżeli go nie ma, dodaj go poleceniem ip name-server [adres IP serwera DNS] 
• uruchom rozpoznawanie nazw poleceniem ip domain lookup 
• upewnij się, że masz poprawnie ustawiony czas i datę na przełączniku oraz skonfigurowany serwer NTP. Jeśli takowego nie masz, dodaj go poleceniem ntp server [adres IP serwera NTP]. Poprawność godziny i daty sprawdzisz poleceniem show clock 

5. Przygotuj dashboard Meraki: jeżeli trzeba go jeszcze skonfigurować, dodaj nową sieć typu „switch” lub „combined” (uwaga: sieć „combined” powinna zawierać w sobie sieć „switch”). Informację o tym, jak to zrobić, znajdziesz tutaj. 

6. Wykonaj kopię zapasową konfiguracji przełącznika przed przystąpieniem do procesu migracji. 

7. Pobierz i zainstaluj aplikację Cisco do migracji. Istnieją wersje dla Windows, macOS oraz Linux. Alternatywnie, aplikację pobrać można bezpośrednio z dashboardu Meraki (Network wide -> Add Devices) 

Migracja do dashboardu Meraki krok po kroku

Krok 1

Proces migracji rozpoczynamy od uruchomienia aplikacji. Ja zainstalowałem ją w środowisku Windows. Po zaakceptowaniu regulaminu, zaczynamy od podania wygenerowanego wcześniej klucza API. 

Krok 2

Następnie odpowiadamy na szereg pytań związanych z procesem onboardingu: 

Krok 3

W międzyczasie wykonujemy wstępne sprawdzenie konfiguracji przyciskiem Start pre-check. Jeżeli tylko poprawnie przygotowaliśmy nasz(e) przełącznik(i), dashboard Meraki oraz komputer, za pomocą którego dokonujemy onboardingu, test powinien wypaść pozytywnie: 

W troubleshootingu ewentualnych błędów przydatna będzie sekcja Logs, widoczna w dolnej części okna programu. 

Krok 4

Przypisujemy migrowany przełącznik do sieci, którą wcześniej przygotowaliśmy w dashboardzie Meraki. 

Krok 5

Ostateczne potwierdzenie, że decydujemy się na migrację. 

Krok 6 – po stronie Meraki

Program przystępuje do pracy. 

Całość trwa około 3-5 minut, z czego najdłużej trwającą czynnością jest przetwarzanie przez platformę Meraki informacji o przełączniku. O powodzeniu procesu poinformuje nas czytelny komunikat. 

Efekt migracji do dashboardu Meraki

Należy zaznaczyć, że proces provisioningu switcha w dashboardzie Meraki trochę trwa. Bezbłędny status przełącznika zobaczyłem dopiero po około 30 minutach i prezentował się on następująco: 

Widoczne są wszystkie podstawowe informacje dotyczące jednostki jak i to, że uruchomiony został model „Monitor Only”.  

Zgodnie z tym, co głosi Cisco, mogę się zalogować do CLI przełącznika i dokonywać w nim zmian: 

Usunięcie przełącznika z dashboardu i powrót do poprzedniej konfiguracji 

Proces ten jest bardzo prosty i wymaga jedynie zaznaczenia w dashboardzie przełącznika, którego chcemy się z niego pozbyć oraz wybrania opcji Remove from network. 

To inicjuje skrypt, który wykonuje zmiany w konfiguracji przełącznika de facto przywracając go do ustawień sprzed migracji. Jednakże dla zachowania całkowitej pewności co do poprawności tego procesu, sugerowałbym odtworzenie kopii zapasowej konfiguracji, która została wykonana przed dołączeniem switcha do dashboardu Meraki. 

Korzyści z migracji przełącznika Catalyst do dashboardu Meraki

Warto rozważyć opcję przesunięcia monitoringu przełącznika Catalyst do dashboardu Meraki. Otrzymujemy przejrzysty interfejs dzięki któremu dokonywać możemy przeglądu naszych urządzeń, możemy wykonywać prosty troubleshooting sieci oraz mamy przejrzysty wgląd do ustawień switcha w trybie read only dla osób które takiego dostępu wymagają (np. młodsi administratorzy). Proces migracji jest stosunkowo prosty, nie zabiera dużej ilości czasu i jest w pełni odwracalny. 

Opcja przesunięcia monitoringu i zarządzania do dashboardu Meraki może być interesującą propozycją dla firm z rozproszonymi biurami czy punktami handlowymi typu „internet only”, w których urządzenie brzegowe styku z Internetem dostarcza operator (ISP), a dział IT chce wciąż utrzymywać kontrolę nad infrastrukturą LAN w danej lokalizacji. Taka formuła nie wymaga inwestycji w urządzenia specjalizowane do budowy sieci WAN/VPN/IPSec.

Jeśli zastanawiasz się, jak jeszcze możesz usprawnić zarządzanie przełącznikami lub innymi elementami infrastruktury sieciowej, umów się na konsultację techniczną. Pomożemy Ci zoptymalizować konfigurację Twoich urządzeń.