Ten artykuł jest drugi w cyklu artykułów „Jak przejąć kontrolę nad infrastrukturą sieciową”. Spis treści wszystkich artykułów w cyklu oraz linki można znaleźć .
Naszym celem na tym etapie jest uporządkowanie dokumentacji i konfiguracji.
Na wyjściu tego procesu powinniście mieć odpowiedni zestaw dokumentów oraz sieć skonfigurowaną zgodnie z nimi.
Teraz nie będziemy mówić o audycie bezpieczeństwa – to będzie przedmiotem trzeciej części.
Trudność realizacji postawionego na tym etapie zadania oczywiście znacznie różni się w zależności od firmy.
Idealna sytuacja to taka, kiedy
- wasza sieć została stworzona zgodnie z projektem i posiadacie kompletny zestaw dokumentów,
- w waszej firmie wdrożono dla sieci.
- Zgodnie z tym procesem dysponujecie dokumentami (w tym wszystkimi niezbędnymi schematami), które dostarczają pełnych informacji o aktualnym stanie rzeczy.
W takim przypadku wasze zadanie jest dość proste. Musicie przestudiować dokumenty i przejrzeć wszystkie zmiany, które zostały wprowadzone.
W najgorszym przypadku będziecie mieli
- sieć, stworzoną bez projektu, bez planu, bez akceptacji, przez inżynierów, którzy nie posiadają wystarczających kwalifikacji,
- z chaotycznymi, nieudokumentowanymi zmianami, z dużą ilością „śmieci” i nieoptymalnych rozwiązań.
Oczywiście, że wasza sytuacja leży gdzieś pomiędzy, ale niestety na tej skali lepsze – gorsze z dużym prawdopodobieństwem, że będziecie bliżej gorszego końca.
W takim przypadku od was będzie się wymagać również umiejętności czytania myśli, bowiem będziecie musieli nauczyć się rozumieć, co zamierzali zrobić „projektanci”, odbudować ich logikę, dokończyć to, co nie zostało ukończone oraz usunąć „śmieci”.
I oczywiście będziecie musieli zlikwidować ich błędy, zmieniać (na tym etapie w miarę możliwości minimalnie) projekty oraz poprawiać lub tworzyć schematy od nowa.
Ten artykuł w żadnym wypadku nie rości sobie pretensji do pełności. Opiszę tutaj jedynie ogólne zasady i skupię się na niektórych powszechnych problemach, które trzeba rozwiązać.
Zestaw dokumentów
Zacznijmy od przykładu.
Poniżej znajdują się niektóre dokumenty, które zazwyczaj tworzy się w firmie Cisco Systems przy projektowaniu.
CR – Wymagania klienta, wymagania klienta (specyfikacja techniczna).
Tworzony wspólnie z klientem i określa wymagania dotyczące sieci.HLD – High Level Design, projekt wysokiego poziomu oparty na wymaganiach sieci (CR). Dokument tłumaczy i uzasadnia podjęte decyzje architektoniczne (topologia, protokoły, wybór sprzętu,…). HLD nie zawiera szczegółów projektu, takich jak używane interfejsy i adresy IP. Nie omawia również konkretnej konfiguracji sprzętu. Dokument ten ma na celu wyjaśnienie kluczowych koncepcji projektu technicznemu kierownictwu klienta.
LLD – Low Level Design, projekt niskiego poziomu oparty na wysokopoziomowym (HLD).
Musi zawierać wszystkie szczegóły potrzebne do realizacji projektu, takie jak informacje o tym, jak podłączyć i skonfigurować sprzęt. Jest to pełny przewodnik po wdrażaniu projektu. Dokument powinien zapewniać wystarczające informacje do jego realizacji nawet przez mniej wykwalifikowany personel.Coś, na przykład, adresy IP, numery AS, schemat fizycznej komunikacji (okablowanie), może być "wyodrębnione" do osobnych dokumentów, takich jak NIP (Plan Wdrożenia Sieci).
Budowa sieci rozpoczyna się po stworzeniu tych dokumentów i odbywa się ściśle zgodnie z nimi, a następnie jest sprawdzana przez klienta (testy) w celu zapewnienia zgodności z projektem.
Oczywiście różne integratory, różni klienci, w różnych krajach mogą mieć różne wymagania dotyczące dokumentacji projektowej. Ale chcielibyśmy uniknąć formalności i rozważyć sprawę merytorycznie. Ten etap nie dotyczy projektowania, ale wprowadzenia porządku, a potrzebujemy wystarczającego zestawu dokumentów (schematów, tabel, opisów …) do realizacji naszych zadań.
I moim zdaniem istnieje pewien absolutny minimalny zestaw dokumentów, bez którego nie można efektywnie kontrolować sieci.
Są to następujące dokumenty:
- schemat (dziennik) fizycznej komunikacji (okablowanie)
- schemat lub schematy sieci z istotnymi informacjami L2/L3
Schemat fizycznej komunikacji
W niektórych mniejszych firmach prace związane z instalacją sprzętu i fizyczną komunikacją (okablowanie) leżą w gestii inżynierów sieciowych.
W takim przypadku zadanie jest częściowo rozwiązywane w następujący sposób.
- użyj opisu na interfejsie, aby opisać, co jest do niego podłączone
- Dezaktywuj administracyjnie (shutdown) wszystkie niepodłączone porty sprzętu sieciowego
Dzięki temu nawet w przypadku problemu z łączem (gdy na tym interfejsie nie działa cdp lub lldp) szybko określisz, co jest podłączone do tego portu.
Ponadto łatwo zobaczysz, które porty są zajęte, a które wolne, co jest niezbędne do planowania podłączeń nowego sprzętu sieciowego, serwerów lub stacji roboczych.
Jednak oczywiście, jeśli stracisz dostęp do sprzętu, stracisz również dostęp do tych informacji. Poza tym w ten sposób nie będziesz w stanie zarejestrować tak ważnych informacji, jak to, jaki sprzęt, jaką moc pobiera, ile portów ma, w której szafie się znajduje, jakie są tam panele krosowe i gdzie (w którą szafę/panel krosowy) są one skomunikowane. Dlatego dodatkowe dokumentowanie (nie tylko opisy na sprzęcie) jest bardzo przydatne.
Idealnym rozwiązaniem jest użycie aplikacji zaprojektowanych do pracy z tego rodzaju informacjami. Można się jednak ograniczyć do prostych tabel (na przykład w Excelu) lub przedstawić informacje, które uważasz za niezbędne w schematach L1/L2.
WAŻNE!
Inżynier sieciowy oczywiście może dość dobrze znać szczegóły i standardy strukturalnych systemów kablowych, rodzaje szaf, rodzaje źródeł zasilania bezprzerwowego, czym jest zimny i gorący korytarz, a także prawidłowe uziemienie… tak samo jak w zasadzie może znać fizykę cząstek elementarnych lub C++. Należy jednak zrozumieć, że wszystko to nie jest jego obszarem wiedzy.
Dlatego dobrą praktyką jest mieć wydzielone działy lub osoby do rozwiązywania problemów związanych z instalacją, podłączeniem, utrzymaniem sprawności sprzętu, jak również fizycznym okablowaniem. Zazwyczaj dla centrów danych są to inżynierowie centrum danych, a dla biura - help-desk.
Jeśli takie jednostki są przewidziane w Twojej firmie, kwestia prowadzenia rejestru fizycznej komunikacji nie jest Twoim zadaniem i możesz ograniczyć się tylko do opisu na interfejsie oraz administracyjnego wyłączenia nieużywanych portów.
Schematy sieci
Nie ma uniwersalnego podejścia do rysowania schematów.
Najważniejsze jest to, że schematy powinny dawać zrozumienie, jak będzie przebiegał ruch, przez jakie elementy logiczne i fizyczne będzie przechodzić sieć.
Przez elementy fizyczne rozumiemy
- sprzęt aktywny
- interfejsy/porty sprzętu aktywnego
Przez elementy logiczne rozumiemy —
- urządzenia logiczne (N7K VDC, Palo Alto VSYS, …)
- VRF
- VLAN-y
- podinterfejsy
- tunel
- strefy
- …
Również, jeśli twoja sieć nie jest zupełnie podstawowa, będzie się składać z różnych segmentów.
Na przykład
- centrum danych
- internet
- WAN
- zdalny dostęp
- biurowa LAN
- DMZ
- …
Rozsądnie będzie mieć kilka schematów, które przedstawiają zarówno ogólny obraz (jak ruch przepływa między wszystkimi tymi segmentami), jak i szczegółowe wyjaśnienie każdego pojedynczego segmentu.
Ponieważ w nowoczesnych sieciach może być wiele poziomów logicznych, dobrym (ale nieobowiązkowym) podejściem może być tworzenie różnych schematów dla różnych poziomów, na przykład w przypadku podejścia owerlayowego mogą to być następujące schematy:
- overlay
- L1/L2 underlay
- L3 underlay
Oczywiście najważniejszym schematem, bez którego nie można zrozumieć idei twojego projektu, jest schemat routingu.
Schemat routingu
Przynajmniej na tym schemacie powinno być odzwierciedlone
- jakie protokoły routingu są używane i gdzie
- podstawowe informacje o ustawieniach protokołów routingu (area/AS number/router-id/…)
- na jakich urządzeniach odbywa się redystrybucja
- gdzie odbywa się filtrowanie i agregacja tras
- informacja o domyślnej trasie
Często użyteczny jest również schemat L2 (OSI).
Schemat L2 (OSI)
Na tym schemacie mogą być odzwierciedlone następujące informacje:
- jakie VLAN-y
- jakie porty są trunk portami
- jakie porty są agregowane w ether-channel (port channel), virtual port channel
- jakie protokoły STP i na jakich urządzeniach są używane
- podstawowe ustawienia STP: root/root backup, STP cost, port priority
- dodatkowe ustawienia STP: BPDU guard/filter, root guard…
Charakterystyczne błędy w projektowaniu
Przykład złego podejścia do budowy sieci.
Zróbmy prosty przykład budowy prostej biurowej sieci lokalnej.
Mając doświadczenie w nauczaniu telekomunikacji studentów, mogę powiedzieć, że praktycznie każdy student w połowie drugiego semestru posiada niezbędną wiedzę (w ramach kursu, który prowadziłem), aby skonfigurować prostą biurową LAN.
Co może być trudnego w podłączeniu do siebie przełączników, skonfigurowaniu VLAN, interfejsów SVI (w przypadku przełączników L3) i wpisaniu statycznego routingu?
Wszystko będzie działać.
Jednak pozostają na boku pytania związane z
- bezpieczeństwem
- rezerwacją
- skalowaniem sieci
- wydajnością
- przepustowością
- niezawodnością
- …
Czasami słyszę stwierdzenie, że LAN w biurze to coś bardzo prostego, i słyszę to zazwyczaj od inżynierów (i menedżerów), którzy zajmują się wszystkim, tylko nie sieciami, i mówią to z taką pewnością, że nie zdziwcie się, jeśli LAN zostanie skonstruowane przez ludzi z niedostateczną praktyką i wiedzą oraz będzie zawierało przybliżone błędy, które opiszę poniżej.
Typowe błędy projektowania poziomu L1 (OSI)
- Jeśli jednak odpowiadasz także za SCS, to jednym z najbardziej nieprzyjemnych dziedzictw, które możesz otrzymać, jest niechlujna i nieprzemyślana komutacja.
Również do typu L1 zaliczyłbym błędy związane z zasobami używanego sprzętu, na przykład,
- niewystarczająca przepustowość
- niewystarczający TCAM w urządzeniach (lub jego nieskuteczne wykorzystanie)
- niewystarczająca wydajność (często odnosi się do zapór ogniowych)
Typowe błędy projektowania poziomu L2 (OSI)
Często, gdy nie ma dobrego zrozumienia, jak działa STP, jakie potencjalne problemy ze sobą niesie, przełączniki są podłączane chaotycznie, z ustawieniami domyślnymi, bez dodatkowego dostrajania STP.
W rezultacie często mamy następujące sytuacje:
- duża średnica STP sieci, co może prowadzić do burz rozgłoszeniowych
- korzeń STP zostanie określony losowo (na podstawie adresu MAC) i ścieżka ruchu będzie nieoptymalna
- porty podłączane do hostów nie będą skonfigurowane jako krawędź (portfast), co spowoduje przeliczenie STP przy włączaniu/wyłączaniu stacji końcowych
- sieć nie będzie segmentowana na poziomie L1/L2, w wyniku czego problemy z dowolnym przełącznikiem (na przykład przeciążenie zasilania) będą prowadzić do przeliczenia topologii STP i zatrzymania ruchu we wszystkich VLAN na wszystkich przełącznikach (w tym w krytycznym z punktu widzenia ciągłości usług segmentem)
Przykłady błędów w projektowaniu L3 (OSI)
Kilka typowych błędów początkujących sieciowców:
- częste używanie (lub używanie tylko) statycznego routingu
- użycie nieoptymalnych protokołów trasowania dla danego projektu
- nieoptymalna segmentacja logiczna sieci
- nieoptymalne wykorzystanie przestrzeni adresowej, co uniemożliwia agregację tras
- brak tras zapasowych
- brak rezerwacji dla domyślnej bramy
- asymetryczne trasowanie podczas przestawiania tras (może być krytyczne w przypadku NAT/PAT, zapór stanowych)
- problemy z MTU
- podczas przestawiania tras ruch przechodzi przez inne strefy bezpieczeństwa lub nawet inne zapory, co prowadzi do ich odrzucania
- słaba skalowalność topologii
Kryteria oceny jakości projektu
Kiedy mówimy o optymalności/nieoptymalności, musimy zrozumieć, z jakich kryteriów możemy to ocenić. Z mojego punktu widzenia najważniejsze (ale nie jedyne) kryteria (i ich interpretacja w odniesieniu do protokołów trasowania):
- skalowalność (scalability)
Na przykład, jeśli postanowiliście dodać kolejne centrum danych. Jak łatwo możecie to zrobić? - łatwość zarządzania (manageability)
Jak łatwe i bezpieczne są operacyjne zmiany, na przykład ogłaszanie nowej puli adresowej lub filtrowanie tras - dostępność (availability)
Jaki procent czasu wasz system zapewnia wymagany poziom usług - bezpieczeństwo (security)
Jak bezpieczne są przesyłane dane - cena
Zmiany
Podstawowa zasada na tym etapie można wyrazić formułą 'nie szkodzić'.
Dlatego nawet jeśli nie zgadzacie się całkowicie z projektem i wybraną realizacją (konfiguracją), nie zawsze jest sens wprowadzać zmiany. Rozsądne podejście to uporządkowanie wszystkich zidentyfikowanych problemów według dwóch parametrów:
- jak łatwo można rozwiązać ten problem
- jak duże niesie ryzyko
Przede wszystkim należy usunąć to, co w tej chwili obniża poziom świadczonej usługi poniżej dopuszczalnego, na przykład problemy prowadzące do utraty pakietów. Następnie usuńcie to, co jest najłatwiejsze i najbezpieczniejsze do usunięcia w porządku od największego ryzyka do mniejszego.
Perfekcjonizm na tym etapie może być szkodliwy. Doprowadźcie projekt do satysfakcjonującego stanu i synchronizujcie konfigurację sieci zgodnie z nim.
Źródło: habr.com
