Jak wygląda obsługa, administracja i utrzymanie sieci SPB?

Dla nas, inżynierów sieciowych, pojęcie OA&M, czyli skrót od angielskiego operations, administration, and management, obejmuje wszystkie procesy, aktywności, narzędzia i standardy związane z obsługą, administracją, utrzymaniem i zarządzaniem sieci komputerowych. W kontekście sieci typu SPB, mówimy tutaj o trzech kluczowych obszarach:

Już od dłuższego czasu w branży sieciowej, coraz więcej zadań i procesów poddaje się automatyzacji. Jest to bez wątpienia obszar, w którym powraca dyskusja na temat tego, na ile potrzebna jest kompleksowości, a na ile prostota. W większości przypadków, w celu zwiększenia automatyzacji dostawcy rozwiązań sieciowych wprowadzają dość zaawansowane i mocno złożone systemy orkiestracji. Jednak jak już podkreślałem w poprzednim wpisie, pięknem technologii Shortest Path Bridging, a co za tym idzie również Extreme Fabric Connect, jest prostota. Prostota ta sprzyja automatyzacji, ale nie tylko!

Korzystając z owej prostoty, Extreme Networks wbudowało automatyzację już na samym poziomie systemów operacyjnych przełączników. Oznacza to, że nie potrzeba żadnego zewnętrznego narzędzia odpowiedzialnego za orkiestrację! Jest to niezwykle istotne, dlatego podkreślam to z całą mocą: funkcjonalność, którą nazywamy Zero Touch Fabric, oznacza że przełączniki same z siebie rozumieją, że są połączone z innymi węzłami fabricowymi SPB, dowiadują się od nich kluczowych informacji i automatycznie dołączają do sieci fabric. Innymi słowy: włączasz switcha, podpinasz go do sieci i voila, jest już jej pełnoprawną, w pełni funkcjonującą częścią. Jeżeli jest to pierwszy przełącznik w naszej nowej sieci fabricowej, musimy wprowadzić kilka kluczowych parametrów. Więcej na temat funkcjonalności Zero Touch Fabric dowiecie się z tego artykułu.

Jeżeli jednak tego typu rzeczy wolicie robić „w starym stylu”, czyli ręcznie (czemu sprzyjać może nieduża liczba przełączników w Waszej sieci), to konfigurowanie i podłączanie switchy poprzez komendy interfejsu CLI również jest bardzo proste. Extreme Fabric Connect umożliwia nam skonfigurowanie węzła przy pomocy nieco ponad 20 komend (kilku więcej, jeśli chcemy to zrobić naprawdę porządnie).

Zapewne możecie się teraz zastanawiać, czy rzeczy typu tworzenie L2VSNów, L3VSNów czy usług multicastowych nie byłoby łatwiejsze z narzędziem do zarządzania posiadającym graficzny interfejsie. I w rzeczy samej, ExtremeCloud IQ – Site Engine jest aplikacją, która radzi sobie z tym bardzo dobrze. Jak już jednak ustaliliśmy w jednym z poprzednich rozdziałów, stworzenie usługi warstwy 2 w przypadku Extreme Fabric Connect wymaga zaledwie jednej komendy w CLI (np. VLAN I-SID 20 10020), ewentualnie trzech jeśli VLAN nie znajduje się jeszcze na przełączniku brzegowym (BEB). Stworzenie usługi warstwy 3 wymaga siedmiu komend, jeżeli istnieje już przypisany do niej VRF, lub trzynastu jeśli musimy go dopiero stworzyć.

Oczywiście są też inne metody na tworzenie i zarządzanie nowymi usługami, w tymi interfejsy programowania aplikacji, czyli API. Przełączniki SPB od Extreme Networks obsługują od jakiegoś czasu interfejsy RESTCONF API, co oznacza że aplikacje klienckie mają dostęp oraz możliwość zmiany danych konfiguracyjnych za pomocą typowych metod HTTP takich jak GET, POST, PATCH czy DELETE. W rzeczywistości możemy zatem wykorzystać szereg różnych aplikacji i narzędzi to tworzenia i zarządzania usługami, które chcemy mieć w naszej sieci.

W jednym z wcześniejszych rozdziałów wspomniałem już, że da się zbudować sieć SPB bez ani jednego adresu IP. I w rzeczy samej, wszystkie opisane wcześniej zadania związane z zarządzaniem możemy wykonywać bez przypisywania adresów IP do przełączników – na przykład podłączając komputer do portu konsolowego switcha, który chcemy skonfigurować lub tam, gdzie chcemy dodać nową usługę.

Byłoby to jednak dość żmudne i uciążliwe, zwłaszcza w przypadku sieci składających się z nieco większej liczby przełączników. W większości (choć powinienem raczej powiedzieć we wszystkich) przypadków będziemy raczej woleli przypisać adres IP do każdego przełącznika. I teraz mamy trzy możliwości (lub ich kombinację):

Aby to lepiej zilustrować, posłużę się diagramem, który stworzył mój kolega z Extreme Networks, Ludovico Stevens:

Jednym, łatwym sposobem na stworzenie „globalnej” sieci do zarządzania jest po prostu utworzenie L2VSNa przeznaczonego specjalnie do tego celu i rozciągnięcie owej sieci wirtualnej na wszystkie przełączniki SPB. Na każdym ze switchy musimy skonfigurować VLAN do zarządzania, przypisać do niego adres IP oraz zmapować go do wirtualnej sieci warstwy 2. Oto kilka prostych komend, które wprowadzamy na każdym z przełączników (zakładając, że VLAN 10 oraz identyfikator I-SID 100010 służą do zarządzania):

vlan create 10 name management type port-mstprstp 0
vlan i-sid 10 100010
mgmt vlan 10
ip address 10.255.255.2/24 (oczywiście każdy przełącznik otrzyma unikatowy adres)
enable
(jeżeli chcemy umożliwić dostęp z zewnętrznej sieci, dodajemy statyczną ścieżkę):
ip route <net>/<mask> next-hop <nhop> [weight <val>]

(i nie przywiązujmy się aż tak bardzo do tej części “type port-mstprstp 0” w pierwszej komendzie)

Na kilku przełącznikach zapewne przypiszemy też fizyczny port do VLANa 10, aby umożliwić podłączenie komputera, na którym będziemy wykonywać zadania związane z zarządzaniem. Zakładając, że na kilku przełącznikach chcemy zarezerwować w tym celu port 1, komenda będzie wyglądać następująco:

Poniższy schemat przedstawia zarządzanie za pomocą L2VSNa. Aby go nieco uprościć, przedstawiona sieć do zarządzania urządzeniami rozciągnięta jest jedynie na część przełączników. Pokazuje on także, jak umożliwić dostęp z sieci zewnętrznej.

Alternatywną metodą jest skonfigurowanie adresu CLIP (Circuitless IP) na VRFie pod cele związane z zarządzaniem. Tym VRFem może być globalna tablica routingu (= VRF 0) lub inny, dowolny VRF. Ogólnie dobrą praktyką jest zarezerwowanie VRFu 0 na zarządzanie i niewykorzystywanie go do żadnego ruchu klientów. Oczywiście za routing IP odpowiedzialny będzie IS-IS, więc nie musimy korzystać z OSPF ani żadnego innego protokołu routingu.

W tym celu na wszystkich przełącznikach konfigurujemy interfejs „loopback” na VFR 0 i nadajemy mu adres IP z maską hosta (32-bitowy). Musimy nakazać też protokołowi IS-IS, aby korzystał z tego interfejsu jako adresu źródłowego, gdy komunikuje się z węzłami równorzędnymi.

Oczywiście, chcielibyśmy też pewnie podłączyć do sieci jakieś stacje robocze, na których będziemy mogli wykonywać nasze codzienne zadania. Nie chcemy ich jednak podłączyć gdziekolwiek. Załóżmy więc, że chcemy zarezerwować port na dwóch różnych przełącznikach. Na poniższym schemacie, który przedstawia wykorzystanie VRFu 0 do zarządzania, dodałem VLAN do VRFu 0 na dwóch przełącznikach i przypisałem do nich port fizyczny.

Czesem będziemy chcieli (lub musieli) połączyć obie opisane wyżej opcje zarządzania. W każdym razie obie metody otwierają nam możliwość konfigurowania usług, sprawdzania danych statystycznych, dokonywania zmian w sieci itd., czy to za pomocą wizualnego interfejsu do zarządzania lub po prostu poprzez SSH (lub telnet).

Uwaga: Wybór odpowiedniej strategii zarządzania jest istotny i należy go dokładnie przemyśleć. W niniejszym wpisie jedynie sygnalizuję ten temat. Ponadto, architektura do zarządzania siecią fabricową SPB od Extreme Networks przeszła w ostatnich latach pewne modyfikacje. Dlatego też zalecam sprawdzenie aktualnych przewodników Extreme Networks dla użytkowników, które szczegółowo opisują infrastrukturę zarządzania i jak z niej korzystać.

Trzecim kluczowym obszarem OA&M, o którym wspomniałem na początku tego rozdziału, jest monitorowanie stanu sieci, w tym m.in. sprawdzanie połączeń. Jak zwykle, możemy do tego podejść na kilka różnych sposobów, aczkolwiek jedną sprawdzoną metodą jest wykorzystanie funkcji IEEE 802.1ag Connectivity Fault Management (w skrócie CFM), w którą wyposażone są przełączniki Extreme obsługujące SPB. CFM sam w sobie jest dość złożonym tematem, aczkolwiek jego wprowadzenie znacząco ułatwiło konfigurowanie i korzystanie z urządzeń.

Jak już prawdopodobnie się domyśleliście, CFM jest wykorzystywanym przez przełączniki protokołem, który dostarcza bardzo przydatnych informacji na temat sieci. Do owych informacji (i powiązanych z nich komend) zaliczamy:

Uwaga: Powyższe komendy stanowią autorską funkcjonalność rozwiązania Extreme Fabric Connect.

Oczywiście istnieje cały szereg innych przydatnych komend wbudowanych w system operacyjny wspomnianych przełączników. Te wymienione przydają się zarówno do zarządzania, jak i przy rozwiązywaniu problemów z siecią, gdy coś pójdzie nie tak. Zgadza się, kiedyś w końcu coś musi pójść nie tak, nawet w przypadku sieci SPB/Fabric Connect. Zasadniczą różnicą jest jednak to, jak łatwo rozwiązuje się wówczas problemy, w porównaniu do klasycznych sieci komputerowych (a także sieci fabricowych opartych na technologii EVPN). Badanie zrealizowane jakiś czas temu przez firmę Dynamic Markets potwierdziło, że klienci korzystający z Extreme Fabric Connect zauważyli znaczną poprawę w czasie potrzebnym na rozwiązywanie problemów z awarią sieci – średnio został on skrócony 6,5x (poprawa o 85%). Największa zanotowana poprawa to 8,5x szybszy czas rozwiązywania problemów (poprawa o 92%)¹.

Wspomniałem też nieco wcześniej rozwiązanie ExtremeCloud IQ – Site Engine, które jest naprawdę potężnym narzędziem do zarządzania, które dziś pozwala na monitorowanie i wizualizację sieci fabric, ścieżek ruchu, drzew multicastowych itd. Pozwala ono także tworzyć przepływy pracy, które jeszcze bardziej automatyzują zadania związane z zarządzaniem i utrzymaniem sieci. W niniejszym wpisie nie skupiam się jednak na rozwiązaniu ExtremeCloud IQ – Site Engine. Jeżeli chcecie dowiedzieć się o nim więcej, sprawdźcie informacje na tej stronie.

W kolejnej części „Shortest Path Bridging dla Początkujących”: