Ten artykuł jest drugim z serii artykułów „Jak przejąć kontrolę nad infrastrukturą sieciową”. Można znaleźć treść wszystkich artykułów z serii oraz linki .
Naszym celem na tym etapie jest uporządkowanie dokumentacji i konfiguracji.
Na koniec tego procesu powinieneś posiadać niezbędny komplet dokumentów i zgodnie z nimi skonfigurowaną sieć.
Nie będziemy już rozmawiać o audytach bezpieczeństwa – będzie to temat trzeciej części.
Trudność wykonania zadania postawionego na tym etapie jest oczywiście bardzo zróżnicowana w zależności od firmy.
Idealna sytuacja to kiedy
- Twoja sieć została utworzona zgodnie z projektem i posiadasz komplet dokumentów
- został wdrożony w Twojej firmie dla sieci
- zgodnie z tym procesem dysponujesz dokumentami (w tym wszystkimi niezbędnymi schematami), które dostarczają pełnej informacji o bieżącym stanie rzeczy
W tym przypadku Twoje zadanie jest dość proste. Powinieneś przestudiować dokumenty i przejrzeć wszystkie wprowadzone zmiany.
W najgorszym przypadku będziesz mieć
- sieć tworzona bez projektu, bez planu, bez zatwierdzenia, przez inżynierów, którzy nie posiadają wystarczającego poziomu kwalifikacji,
- z chaotycznymi, nieudokumentowanymi zmianami, z dużą ilością „śmieci” i nieoptymalnych rozwiązań
Jasne jest, że Twoja sytuacja jest gdzieś pośrodku, ale niestety na tej skali od lepszego do gorszego istnieje duże prawdopodobieństwo, że będziesz bliżej najgorszego końca.
W tym przypadku przydać się będzie także umiejętność czytania w myślach, bo trzeba będzie nauczyć się rozumieć, co chcieli zrobić „projektanci”, przywrócić im logikę, dokończyć to, co nie zostało dokończone i usunąć „śmieci”.
I oczywiście będziesz musiał poprawić swoje błędy, zmienić (na tym etapie tak minimalnie, jak to możliwe) projekt i zmienić lub odtworzyć schematy.
Artykuł ten w żaden sposób nie twierdzi, że jest kompletny. Tutaj opiszę jedynie ogólne zasady i skupię się na kilku typowych problemach, które należy rozwiązać.
Zestaw dokumentów
Zacznijmy od przykładu.
Poniżej znajdują się niektóre dokumenty, które są zwykle tworzone w Cisco Systems podczas projektowania.
CR – Wymagania Klienta, wymagania Klienta (specyfikacje techniczne).
Tworzony jest wspólnie z klientem i określa wymagania sieciowe.DWS – Projekt wysokiego poziomu, projekt wysokiego poziomu oparty na wymaganiach sieciowych (CR). Dokument wyjaśnia i uzasadnia podjęte decyzje architektoniczne (topologia, protokoły, wybór sprzętu,...). HLD nie zawiera szczegółów projektu, takich jak użyte interfejsy i adresy IP. Nie omawia się tutaj także konkretnej konfiguracji sprzętowej. Celem tego dokumentu jest raczej wyjaśnienie kluczowych koncepcji projektowych kierownictwu technicznemu klienta.
LLD – Projekt niskiego poziomu, projekt niskiego poziomu oparty na projekcie wysokiego poziomu (HLD).
Powinien zawierać wszystkie szczegóły niezbędne do realizacji projektu, takie jak informacje dotyczące sposobu podłączenia i konfiguracji sprzętu. Jest to kompletny przewodnik po wdrażaniu projektu. Dokument ten powinien dostarczać wystarczających informacji do jego wdrożenia nawet przez mniej wykwalifikowany personel.Coś, na przykład adresy IP, numery AS, schemat fizycznego przełączania (okablowanie), można „umieścić” w oddzielnych dokumentach, takich jak SKAKAĆ (Plan wdrożenia sieci).
Budowa sieci rozpoczyna się po stworzeniu tych dokumentów i przebiega według nich ściśle według nich, a następnie jest sprawdzana przez Klienta (testy) pod kątem zgodności z projektem.
Oczywiście różni integratorzy, różni klienci i różne kraje mogą mieć różne wymagania dotyczące dokumentacji projektowej. Chciałbym jednak uniknąć formalności i rozważyć sprawę merytorycznie. Na tym etapie nie chodzi o projektowanie, ale o uporządkowanie, a do realizacji naszych zadań potrzebujemy odpowiedniego zestawu dokumentów (schematy, tabele, opisy...).
A moim zdaniem jest pewne absolutne minimum, bez którego nie da się skutecznie sterować siecią.
Są to następujące dokumenty:
- schemat (log) fizycznego przełączania (okablowania)
- schemat lub diagramy sieciowe z niezbędnymi informacjami L2/L3
Fizyczny schemat przełączania
W niektórych małych firmach prace związane z instalacją sprzętu i fizycznym przełączaniem (okablowaniem) są w gestii inżynierów sieci.
W tym przypadku problem można częściowo rozwiązać, stosując następujące podejście.
- użyj opisu na interfejsie, aby opisać, co jest z nim połączone
- administracyjnie zamknij wszystkie niepołączone porty sprzętu sieciowego
Dzięki temu będziesz miał możliwość, nawet w przypadku problemu z łączem (kiedy na tym interfejsie nie działa cdp lub lldp), szybko określić co jest podłączone do tego portu.
Można także łatwo sprawdzić, które porty są zajęte, a które wolne, co jest niezbędne przy planowaniu podłączeń nowych urządzeń sieciowych, serwerów czy stacji roboczych.
Ale jasne jest, że jeśli stracisz dostęp do sprzętu, stracisz także dostęp do tych informacji. Dodatkowo w ten sposób nie uda się zapisać tak ważnych informacji jak jaki sprzęt, jaki pobór prądu, ile portów, w jakim racku się znajduje, jakie patch panele się znajdują i gdzie (w jakim racku/patch panelu ) są połączone . Dlatego dodatkowa dokumentacja (nie tylko opisy sprzętu) jest nadal bardzo przydatna.
Idealną opcją jest skorzystanie z aplikacji przeznaczonych do pracy z tego typu informacjami. Możesz jednak ograniczyć się do prostych tabel (na przykład w Excelu) lub wyświetlić informacje, które uznasz za niezbędne, na diagramach L1/L2.
Ważne!
Inżynier sieciowy oczywiście może całkiem dobrze znać zawiłości i standardy SCS, rodzaje stojaków, rodzaje zasilaczy awaryjnych, czym jest zimne i gorące przejście, jak wykonać właściwe uziemienie... tak samo w zasadzie może znasz fizykę cząstek elementarnych lub C++. Ale trzeba jeszcze zrozumieć, że to wszystko nie jest jego obszarem wiedzy.
Dlatego dobrą praktyką jest posiadanie wyspecjalizowanych działów lub wyspecjalizowanych osób do rozwiązywania problemów związanych z instalacją, podłączaniem, konserwacją sprzętu, a także fizycznym przełączaniem. Zwykle w przypadku centrów danych są to inżynierowie centrum danych, a w przypadku biura jest to pomoc techniczna.
Jeśli w Twojej firmie są takie podziały, to kwestie logowania fizycznego przełączania nie są Twoim zadaniem, a możesz ograniczyć się jedynie do opisu interfejsu i wyłączenia administracyjnego nieużywanych portów.
Schematy sieciowe
Nie ma uniwersalnego podejścia do rysowania diagramów.
Najważniejsze jest, aby diagramy zapewniały zrozumienie, w jaki sposób będzie przepływał ruch, przez które logiczne i fizyczne elementy Twojej sieci.
Przez elementy fizyczne mamy na myśli
- sprzęt aktywny
- interfejsy/porty sprzętu aktywnego
Pod logiką -
- urządzenia logiczne (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- podinterfejsy
- tunele
- strefa
- ...
Ponadto, jeśli Twoja sieć nie jest całkowicie elementarna, będzie składać się z różnych segmentów.
na przykład
- Centrum danych
- Internet
- WAN
- zdalny dostęp
- biurowa sieć LAN
- DMZ
- ...
Rozsądnie jest mieć kilka diagramów, które dają zarówno ogólny obraz (przepływ ruchu pomiędzy wszystkimi segmentami), jak i szczegółowe wyjaśnienie każdego pojedynczego segmentu.
Ponieważ we współczesnych sieciach może być wiele warstw logicznych, być może dobrym (ale nie koniecznym) rozwiązaniem jest utworzenie różnych obwodów dla różnych warstw, na przykład w przypadku podejścia nakładkowego mogą to być następujące obwody:
- narzuta
- Podkład L1/L2
- Podkład L3
Oczywiście najważniejszym diagramem, bez którego nie sposób zrozumieć idei swojego projektu, jest diagram routingu.
Schemat routingu
Ten diagram powinien przynajmniej odzwierciedlać
- jakie protokoły routingu są używane i gdzie
- podstawowe informacje o ustawieniach protokołu routingu (obszar/numer AS/id-routera/…)
- na jakich urządzeniach następuje redystrybucja?
- gdzie następuje filtrowanie i agregacja tras
- domyślne informacje o trasie
Często przydatny jest także schemat L2 (OSI).
Schemat L2 (OSI)
Ten diagram może przedstawiać następujące informacje:
- jakie sieci VLAN
- które porty są portami trunk
- które porty są agregowane w kanał eterowy (kanał portu), kanał portu wirtualnego
- jakie protokoły STP są używane i na jakich urządzeniach
- podstawowe ustawienia STP: kopia zapasowa root/root, koszt STP, priorytet portu
- dodatkowe ustawienia STP: osłona/filtr BPDU, osłona korzeni…
Typowe błędy projektowe
Przykład złego podejścia do budowy sieci.
Weźmy prosty przykład budowy prostej biurowej sieci LAN.
Mając doświadczenie w nauczaniu studentów telekomunikacji, mogę powiedzieć, że praktycznie każdy student już w połowie drugiego semestru posiada niezbędną wiedzę (w ramach zajęć, które prowadziłem), aby skonfigurować prostą biurową sieć LAN.
Co jest takiego trudnego w łączeniu ze sobą przełączników, konfigurowaniu sieci VLAN, interfejsów SVI (w przypadku przełączników L3) i konfigurowaniu routingu statycznego?
Wszystko będzie działać.
Ale jednocześnie pytania związane z
- bezpieczeństwo
- rezerwacja
- skalowanie sieci
- występ
- wydajność
- niezawodność
- ...
Od czasu do czasu słyszę stwierdzenie, że biurowa sieć LAN to coś bardzo prostego i zwykle słyszę to od inżynierów (i menedżerów), którzy zajmują się wszystkim oprócz sieci, i mówią to z taką pewnością siebie, że nie zdziwię się, jeśli sieć LAN będzie popełniane przez osoby z niewystarczającą praktyką i wiedzą i będą popełniane z mniej więcej tymi samymi błędami, które opiszę poniżej.
Typowe błędy projektowe L1 (OSI).
- Jeśli jednak jesteś również odpowiedzialny za SCS, to jedną z najbardziej nieprzyjemnych konsekwencji, jakie możesz otrzymać, jest nieostrożna i nieprzemyślana zmiana.
Do typu L1 zaliczyłbym także błędy związane z zasobami wykorzystywanego sprzętu, np.
- niewystarczająca przepustowość
- niewystarczająca ilość TCAM na sprzęcie (lub jego nieefektywne wykorzystanie)
- niewystarczająca wydajność (często związana z zaporami sieciowymi)
Typowe błędy projektowe L2 (OSI).
Często, gdy nie ma dobrego zrozumienia, jak działa STP i jakie potencjalne problemy ze sobą niesie, przełączniki są łączone chaotycznie, z ustawieniami domyślnymi, bez dodatkowego strojenia STP.
W rezultacie często mamy następujące
- duża średnica sieci STP, co może prowadzić do burz rozgłoszeniowych
- Katalog główny STP zostanie określony losowo (na podstawie adresu MAC), a ścieżka ruchu będzie nieoptymalna
- porty podłączone do hostów nie zostaną skonfigurowane jako brzegowe (portfast), co spowoduje przeliczenie STP przy włączaniu/wyłączaniu stacji końcowych
- sieć nie będzie segmentowana na poziomie L1/L2, w efekcie problemy z którymkolwiek przełącznikiem (np. przeciążenie zasilania) spowodują przeliczenie topologii STP i zatrzymanie ruchu we wszystkich sieciach VLAN na wszystkich przełącznikach (w tym na jeden krytyczny z punktu widzenia segmentu usług ciągłości)
Przykłady błędów w projektowaniu L3 (OSI).
Kilka typowych błędów początkujących networkerów:
- Częste używanie (lub tylko używanie) routingu statycznego
- wykorzystanie nieoptymalnych protokołów routingu dla danego projektu
- nieoptymalna segmentacja sieci logicznej
- nieoptymalne wykorzystanie przestrzeni adresowej, które nie pozwala na agregację tras
- brak tras zapasowych
- brak rezerwacji dla bramy domyślnej
- routing asymetryczny przy przebudowie tras (może być krytyczny w przypadku NAT/PAT, firewalli stanowych)
- problemy z MTU
- kiedy trasy są odbudowywane, ruch przechodzi przez inne strefy bezpieczeństwa lub nawet inne zapory sieciowe, co prowadzi do utraty tego ruchu
- słaba skalowalność topologii
Kryteria oceny jakości projektów
Kiedy mówimy o optymalności/nieoptymalności, musimy zrozumieć, z punktu widzenia jakich kryteriów możemy to ocenić. Oto, z mojego punktu widzenia, najważniejsze (ale nie wszystkie) kryteria (i wyjaśnienia w odniesieniu do protokołów routingu):
- skalowalność
Na przykład decydujesz się na dodanie kolejnego centrum danych. Jak łatwo możesz to zrobić? - łatwość obsługi (zarządzanie)
Jak łatwe i bezpieczne są zmiany operacyjne, takie jak ogłoszenie nowej siatki lub filtrowanie tras? - dostępność
W jakim procencie czasu Twój system zapewnia wymagany poziom usług? - bezpieczeństwo
Jak bezpieczne są przesyłane dane? - cena
Zmiany
Podstawową zasadę na tym etapie można wyrazić formułą „nie szkodzić”.
Dlatego nawet jeśli nie do końca zgadzasz się z projektem i wybraną realizacją (konfiguracją), nie zawsze wskazane jest wprowadzanie zmian. Rozsądnym podejściem jest uszeregowanie wszystkich zidentyfikowanych problemów według dwóch parametrów:
- jak łatwo można rozwiązać ten problem
- jak duże ryzyko ona ponosi?
Przede wszystkim należy wyeliminować to, co obecnie obniża poziom świadczonych usług poniżej akceptowalnego poziomu, np. problemy prowadzące do utraty pakietów. Następnie napraw to, co jest najłatwiejsze i najbezpieczniejsze do naprawienia, w kolejności malejącej wagi ryzyka (od problemów z projektem lub konfiguracją wysokiego ryzyka do problemów niskiego ryzyka).
Perfekcjonizm na tym etapie może być szkodliwy. Doprowadź projekt do zadowalającego stanu i odpowiednio zsynchronizuj konfigurację sieci.
Źródło: www.habr.com