Sieci Kampusowe: Przewodnik Admina – #2 Porządek i dokumentacja sieci

We wstępie obiecałem, że ta seria będzie o praktyce. Dlatego zaczynamy od tematu, który często nie błyszczy na slajdach. Porządek w konfiguracji i dokumentacja sieci to fundament, na którym stoi cała reszta. STP, 802.1X, backup, monitoring czy redundancja przyjdą później. Najpierw musisz wiedzieć, co właściwie masz w sieci.

Sobota, 6:40, pierwszy samodzielny dyżur

Poznaj Kacpra. Kacper jest postacią zmyśloną, ale pewnie znasz kogoś takiego. Możliwe też, że sam nim kiedyś byłeś, a może kiedyś nim będziesz.

Kacper od dwóch miesięcy pracuje jako admin sieci w firmie produkcyjnej. Wdrażał go Marek, senior z dziesięcioletnim stażem. Marek pokazał mu serwerownię, przełączniki, routery i firewall. Opowiedział, jak to wszystko działa. Problem w tym, że opowiadał przez dwa tygodnie, a sieć budował przez dziesięć lat. Części rzeczy nie zdążył powiedzieć, część zapomniał. Inne powiedział, ale nikt nie zapamięta wszystkiego za pierwszym razem.

Sobota, 6:40. Kacper ma pierwszy samodzielny dyżur. Dzwoni kierownik zmiany: na drugim piętrze nie działają terminale do rejestracji czasu pracy. Zmiana zaczyna się o 7:00, a ludzie już stoją przy bramkach.

Kacper loguje się na przełącznik w rdzeniu sieci. Widzi kilkadziesiąt interfejsów, ale opis ma może co piąty. Reszta to gołe Gi1/0/12, Gi1/0/23 czy Te1/1/2. Sąsiedzi w CDP nazywają się SW-2, SW2-NOWY i Switch. Który z nich obsługuje drugie piętro?

Na udziale sieciowym leży plik „siec_schemat_final_v2.vsdx” z 2021 roku. Brakuje na nim przełącznika, który dołożono rok temu. Plan adresacji jest w Excelu. A właściwie w dwóch, bo obok leży jeszcze „adresacja_NOWA.xlsx”. Oczywiście wartości w nich się różnią.

Godzina szukania

Zostaje ręczne śledzenie. Najpierw show cdp neighbors, potem przeskok na kolejny przełącznik i tak w kółko. W końcu Kacper trafia na przełącznik z uptime’em sześciu godzin. W nocy była przerwa w zasilaniu, a ten switch nie miał UPS-a. Zabbix oczywiście jest i restart odnotował. Tylko kto miał to zauważyć, skoro na dashboardzie stale wisi 250 alertów, w tym 100 krytycznych?

Terminal podłączony do tego przełącznika żyje. Port jest w stanie up, a na interfejsie widać nawet adres MAC terminala. Tyle że w VLAN-ie 1, a nie w VLAN-ie terminali. Po restarcie switch wczytał starą konfigurację startową. Pół roku temu Marek przenosił terminale do nowego VLAN-u i najwyraźniej nie zrobił write memory. Z konfiguracji zniknął więc VLAN terminali, zarówno na portach dostepowych, jak i na trunku. Przywrócenie VLAN-u i zapis konfiguracji zajęły pięć minut. Szukanie zajęło godzinę.W poniedziałek Kacper usłyszał pytanie, dlaczego to tak długo trwało.

Kacper nie zawalił. Zawiodła sieć, która żyła tylko w głowie Marka. A Marek był akurat w górach, bez zasięgu.

Dlaczego porządek w sieci się opłaca

Porządek brzmi jak coś „miłego, ale opcjonalnego”. W praktyce przekłada się na czas, pieniądze i nerwy. Oto najważniejsze powody.

Czytelność na co dzień

W uporządkowanej sieci nie zgadujesz, co siedzi na Gi1/0/23. Po prostu to czytasz. Brzmi banalnie, ale znam sieci, w których codzienna praca to ciągłe przeglądanie tablic ARP i MAC. Admin szuka w nich, co jest gdzie podłączone.

Klasyk wygląda tak. Admin serwerowy prosi o adres IP dla nowej maszyny. Sieciowiec loguje się na firewall i sprawdza w tablicy ARP, czy adres jest wolny. Na wszelki wypadek go pinguje. Tydzień później okazuje się, że adres należał do testowej VMki, która akurat była wyłączona.

Szybszy troubleshooting

Awaria to najgorszy moment na naukę własnej sieci. Kiedy wszystko jest opisane, od razu wiesz, gdzie szukać. W efekcie czas przestoju liczysz w minutach, a nie w godzinach. Porządek to inwestycja, która zwraca się dokładnie wtedy, gdy jest najbardziej potrzebna.

Sieć nie może żyć w jednej głowie

Urlop, L4, zmiana pracy, nowa osoba w zespole. Prędzej czy później ktoś inny musi przejąć Twoją sieć. Jeśli cała wiedza siedzi w głowie jednej osoby, firma ma pojedynczy punkt awarii. Tyle że tym razem nie jest nim przełącznik, ale człowiek.

Robota, którą chcesz pokazać

Jest też argument mniej techniczny. Uporządkowana konfiguracja to po prostu dobrze wykonana robota. Nie wstydzisz się jej, gdy zagląda audytor, integrator albo kolega z innego zespołu. Wręcz przeciwnie, chcesz ją pokazać.

Porządek zmienia też to, jak się pracuje. W chaosie każdy dzień to gaszenie pożarów i nerwowe szukanie, kto co kiedyś wpiął. W uporządkowanej sieci zostaje czas na rzeczy, które naprawdę coś zmieniają. Kończysz dzień z poczuciem, że coś zbudowałeś, a nie tylko przetrwałeś. Taka praca bywa po prostu satysfakcjonująca, a to przekłada się na przyjemność z roboty. Nawet dyżury przestają straszyć, kiedy wiesz, że sieć nie kryje niespodzianek. Polecam zasadę: zostaw konfigurację w lepszym stanie, niż ją zastałeś. Dopisz brakujący opis, usuń martwy obiekt, popraw nazwę. Małe kroki po kilku miesiącach dają zaskakująco duży efekt.

Compliance, czyli porządek na papierze

Do tego dochodzi compliance. Dokumentacja sieci coraz częściej nie jest dobrą praktyką, tylko obowiązkiem. Narzucają ją regulacje i standardy, takie jak ISO/IEC 27001, CIS Controls czy NIST CSF. W Polsce dochodzi nowelizacja ustawy o KSC, która wdraża NIS2 i obowiązuje od 3 kwietnia 2026 roku. Dyrektywa NIS2 wprost wymienia zarządzanie aktywami. CIS Controls każą z kolei utrzymywać diagramy architektury sieci i aktualizować je co najmniej raz w roku. Audytor zapyta, co masz w sieci, a bez dokumentacji nie odpowiesz.

Porządek w konfiguracji

Porządek zaczyna się w samych urządzeniach. Konfiguracja to pierwsza dokumentacja, jaką masz. Co więcej, to jedyna dokumentacja, która zawsze jest aktualna. Przykłady pokazuję na Cisco IOS-XE, ale zasady są takie same u każdego producenta.

Konwencja nazw

Zacznij od nazw urządzeń. Przykładowa konwencja to LOKALIZACJA-BUDYNEK-ROLA-TYP z numerem:

  • WAW-B1-CORE-SW01 – Warszawa, budynek B1, rdzeń, przełącznik nr 1
  • WAW-B1-DIS-SW01 – ten sam budynek, warstwa dystrybucji
  • WAW-B1-ACC-SW03 – warstwa dostępowa, trzeci przełącznik
  • WAW-B1-EDGE-FW01 – firewall brzegowy
  • KRK-B2-ACC-SW11 – Kraków, budynek B2

Nie musi to być akurat taki format. Ważne, żeby konwencja była jedna, spisana i stosowana wszędzie. Bez wyjątków w stylu „SW-test” albo „nowy-switch-Marka”.

To samo dotyczy VLAN-ów. Numer mówi niewiele, a nazwa może powiedzieć wszystko:

vlan 110
 name B1-USERS
vlan 120
 name B1-VOICE
vlan 130
 name B1-TERMINALE_CZASU_PRACY

Spójne nazwy procentują później w automatyzacji. Chcesz coś zrobić na wszystkich przełącznikach dostępowych w budynku B1? Wystarczy filtr na wyrażenie regularne ^WAW-B1-ACC-. W Ansible wzorzec hostów z tyldą na początku to właśnie regex:

- name: Backup konfiguracji przełączników dostępowych w B1
  hosts: "~^WAW-B1-ACC-"
  gather_facts: false
  tasks:
    - name: Pobierz running-config
      cisco.ios.ios_config:
        backup: true

Ten sam trik zadziała w regułach grup w systemie monitoringu. Dzięki temu łatwo zróżnicujesz powiadomienia. Niedostępny przełącznik czy firewall od razu wyśle SMS. Padnięty punkt dostępowy pojawi się za to tylko na dashboardzie i poczeka do rana. Przy chaosie w nazwach musisz za to ręcznie utrzymywać listy urządzeń.

Opisy interfejsów

Opis portu to najtańsza dokumentacja, jaka istnieje. Kosztuje kilka sekund, a oszczędza godziny. Przykładowa konwencja to TYP:URZĄDZENIE-PO-DRUGIEJ-STRONIE:PORT.

interface TenGigabitEthernet1/1/1
 description UPL:WAW-B1-DIS-SW01:Te1/0/5
!
interface TenGigabitEthernet1/1/2
 description UPL:WAW-B1-DIS-SW02:Te1/0/5
!
interface GigabitEthernet1/0/23
 description AP:WAW-B1-2P-AP07
!
interface GigabitEthernet1/0/24
 description PRN:WAW-B1-2P-PRN02 (gniazdo 2P-114)

Prefiks od razu mówi, z czym masz do czynienia:

  • UPL – uplink w stronę rdzenia lub dystrybucji
  • DWN – downlink do przełącznika niżej
  • AP – punkt dostępowy Wi-Fi
  • PRN, CAM, PHN – drukarka, kamera, telefon
  • SRV, MGMT – serwer, interfejs zarządzający

Teraz show interfaces description daje Ci mapę przełącznika w jednym widoku. Kacper z naszej historii znalazłby właściwy port w minutę

ACL i polityki firewalla

Najwięcej bałaganu zwykle siedzi w listach ACL i politykach firewalla. Po kilku latach typowa lista to kilkadziesiąt reguł z gołymi adresami IP. Nie mają komentarzy ani widocznej logiki. Stoją w kolejności, w jakiej ktoś je kiedyś dopisywał.

Wtedy pojawiają się pytania, na które nikt nie zna odpowiedzi. Co to jest 10.10.20.15? Po co komuś RDP z jednego hosta do całego świata? Czy ktoś jeszcze używa tej podsieci? Skoro nikt nie wie, nikt tego nie rusza. Lista z każdym rokiem rośnie.

Kilka prostych zasad mocno poprawia sytuację:

  • Obiekty i grupy zamiast gołych adresów. Reguła „użytkownicy B1 do intranetu po HTTPS” czyta się jak zdanie. Zmieniasz adres serwera w jednym obiekcie, a nie w dziesięciu regułach.
  • Spójne nazewnictwo obiektów. Na przykład prefiksy N_, H_ i G_ dla sieci, hostów i grup. Od razu widać, z czym masz do czynienia.
  • Komentarze z numerem zgłoszenia. Komentarz w regule mówi, kto ją dodał i po co. Numer zgłoszenia prowadzi do pełnej historii.
  • Sekcje. Grupuj reguły według przeznaczenia: usługi infrastrukturalne, aplikacje biznesowe, dostęp administracyjny. Na końcu stoi domyślna blokada

Więcej o firewallach FortiGate znajdziesz w naszej serii Akademia Fortinet. Na pewno poruszymy tam też dobre praktyki planowania reguł.

Sprzątanie

Porządek to nie jednorazowa akcja. Konfiguracja obrasta jak strych. Zostają obiekty po wycofanych serwerach, VLAN-y po zamkniętych projektach i reguły „tymczasowe” sprzed kilku lat.

Dlatego raz na jakiś czas zrób przegląd. Zanim jednak cokolwiek usuniesz, sprawdź liczniki trafień i zapytaj właściciela usługi. Pamiętaj, że „nie wiem, po co to jest” wcale nie znaczy „to jest niepotrzebne”.

Wiadomo, czasem zabytkowej reguły nie da się zweryfikować. Autor dawno odszedł z firmy, a w zgłoszeniach cisza. Wtedy zostaje metoda znana jako scream test: wyłączasz regułę i czekasz, kto pierwszy zadzwoni. Zamiast usuwać, najpierw wyłącz, bo przywrócenie zajmie wtedy sekundę. I rób to w godzinach pracy, a nie w piątek o 15:00. Nie jest to porada w rozumieniu ustawy.

Szablon bazowy

Każdy przełącznik dostępowy powinien mieć tę samą bazę konfiguracji. Chodzi o NTP, syslog, AAA, SNMP, baner i domyślne ustawienia portów. Taki wzorzec często nazywa się golden config. Dzięki niemu nie zgadujesz, czemu jeden switch zachowuje się inaczej niż reszta. Szablon to też pierwszy krok do automatyzacji.

Zgodność ze wzorcem da się sprawdzać automatycznie. Narzędzia do audytu konfiguracji przechodzą po urządzeniach i pilnują reguł typu „każdy switch ma wpisany serwer syslog”. Ta praktyka to compliance konfiguracji, czyli wykrywanie dryfu konfiguracji (configuration drift).

Przy okazji: konfiguracja, której nie masz w kopii zapasowej, w praktyce nie istnieje. Pamiętasz brakujący write memory z historii Kacpra? Backupom konfiguracji poświęcimy osobny wpis w tej serii.

Dokumentacja sieci: po co, skoro wszystko jest w konfigu?

Konfiguracja mówi, jak urządzenie jest ustawione. Nie mówi jednak, dlaczego. Nie pokaże też całości, bo każdy przełącznik zna tylko swoich sąsiadów. Tę lukę wypełnia dokumentacja sieci.

Robisz ją dla siebie

Za pół roku nie będziesz pamiętał, dlaczego VLAN 140 idzie trunkiem tylko do dwóch przełączników. Dokumentacja to notatka od Ciebie z przeszłości dla Ciebie z przyszłości. Co ciekawe, pisząc ją, porządkujesz też wiedzę we własnej głowie. Często dopiero wtedy wychodzi, czego sam nie rozumiesz.

Schemat pokazuje błędy, których nie widać w CLI

Rysowanie sieci działa jak code review topologii. Siedzisz nad konfiguracjami i wszystko się zgadza. Potem rysujesz schemat i nagle widzisz problem. Na przykład:

Switch na piętrze ma dwa uplinki spięte w port-channel, LACP działa i wszystko świeci na zielono. Dopiero na schemacie widać, że oba kable wpięto w ten sam switch w ramach stacka w rdzeniu. Nikt nie zrobił tego celowo. Kabel trafił do Te1/0/2 zamiast do Te2/0/1. Wystarczy restart jednego przełącznika i piętro leży.

Zwykły czeski błąd, cyfry 1 i 2 zamieniły się miejscami podczas pisania konfiguracji, a następnie kable zostały połączone, a jakże, zgodnie zaplanowaną konfiguracją. Takiego błędu czasami nie zauważysz czytając konfigurację urządzenia. Za to na schemacie widać go od razu.

Skoro tak, to może warto odwrócić kolejność? Najpierw narysuj, potem konfiguruj. Błąd na rysunku poprawiasz jednym kliknięciem, a w produkcji okienkiem serwisowym. Przy odziedziczonej sieci nie zawsze się da, ale przy każdej nowej zmianie już tak. Nie bez powodu w projektach najpierw powstają HLD i LLD, a dopiero potem konfiguracja.

Troubleshooting i prośba o pomoc

Przy awarii schemat to mapa. Wiesz, którędy płynie ruch, więc wiesz, gdzie szukać. Bez mapy robisz to samo co Kacper, czyli skaczesz od przełącznika do przełącznika.

Schemat jest też obowiązkowy, gdy prosisz kogoś o pomoc. Kolega z zespołu, forum, Discord Packet Hunters czy TAC producenta – każdy zacznie od pytania o topologię. Bez schematu rozmowa zaczyna się od dwudziestu pytań. Ze schematem od razu przechodzi do rzeczy. W ten sposób szanujesz też czas osoby, która Ci pomaga.

Jak robić dokumentację sieci?

Nie ma jednej słusznej drogi

Nie istnieje jeden wzór, który pasuje do każdej sieci. Najważniejsza zasada brzmi: najważniejsza jest czytelność. Dokumentacja, której nikt nie rozumie, jest tak samo bezużyteczna jak jej brak.

Na pytanie „jak to zrobić?” musisz odpowiedzieć sobie sam. W końcu tworzysz dokumentację przede wszystkim dla siebie i swojego zespołu. Inaczej wygląda ona w biurze na jednym piętrze, a inaczej w szpitalu z pięcioma budynkami.

Minimum na start

Nie musisz od razu budować encyklopedii. Spróbuj zacząć od trzech rzeczy:

  • schemat sieci – co jest z czym połączone
  • adresacja i VLAN-y – jakie masz podsieci, do czego służą i gdzie są bramy
  • inwentarz – jakie masz urządzenia i gdzie fizycznie stoją

Reszta przychodzi z czasem. Część rzeczy zresztą pewnie już masz, bo narzuca je organizacja. Rejestr zmian czy zgłoszenia zwykle żyją w Jirze albo ServiceNow. Nie musisz budować własnego. Wystarczy, że w dokumentacji i komentarzach odwołujesz się do numerów zgłoszeń.

Gdzie trzymać dokumentację?

Szczerze? Prawie obojętnie gdzie. SharePoint, udział na firmowym NAS, Confluence czy repozytorium git – każde z tych miejsc się sprawdzi. Dobrze, jeśli narzędzie ma historię zmian i obowiązkowo backup. Ważne, żeby dokumentacja była dostępna dla tych, którzy jej potrzebują. I tylko dla nich, bo dobry schemat sieci to także gotowa mapa dla atakującego.

Jest jednak jeden warunek: dokumentacja musi być dostępna w trakcie awarii. Jeśli leży na macierzy za siecią, która właśnie padła, to jej nie masz. SharePoint w chmurze otworzysz z telefonu przez LTE, ale udział w serwerowni już niekoniecznie. Dlatego trzymaj aktualny eksport najważniejszych schematów offline, na przykład PDF na laptopie.

I jeszcze jedno: hasła nigdy nie trafiają do dokumentacji. Od tego jest menedżer haseł.

Aktualność

Nieaktualna dokumentacja bywa gorsza niż żadna, bo daje fałszywą pewność. Przyjmij więc prostą zasadę: zmiana bez aktualizacji dokumentacji to zmiana niedokończona.

Czasem warto pójść dalej i odwrócić kolejność. Najpierw nanosisz zmianę na schemat, a dopiero potem konfigurujesz i przepinasz zgodnie z rysunkiem. Schemat staje się wtedy planem prac, który może wykonać nawet technik na miejscu. A po robocie nie ma czego aktualizować, bo dokumentacja była gotowa przed zmianą. Jeśli zmianę trzeba wycofać, pamiętaj tylko, żeby cofnąć też rysunek.

Schematy sieci: HLD, LLD i narzędzia

HLD i LLD

W projektach sieciowych często spotkasz dwa skróty: HLD (High-Level Design) i LLD (Low-Level Design). Nie ma jednej normy, która mówi, co dokładnie trafia do którego dokumentu. Możesz spotkać różne szkoły.

W pierwszej HLD to architektura i koncepcja. Pokazuje lokalizacje, warstwy sieci, strefy bezpieczeństwa i wybrane technologie. LLD schodzi do konkretów: numerów VLAN-ów, adresacji, portów i parametrów protokołów. Przykład? HLD mówi, że każde piętro ma osobne sieci dla użytkowników, telefonów i terminali, z bramą na dystrybucji. LLD dopowiada, że użytkownicy B1 to VLAN 110 i podsieć 10.11.110.0/24 z bramą VRRP 10.11.110.1.

Przykład schematu LLD
Przykład schematu HLD

W drugiej szkole cała logika, łącznie z adresacją IP i routingiem, trafia do HLD. LLD to wtedy wyłącznie fizyka: szafy, porty, krosownice, kable i zasilanie. Przykład? HLD zawiera już VLAN 110 i podsieć 10.11.110.0/24. LLD mówi z kolei, że ACC-SW03 stoi w szafie na drugim piętrze w U40. Jego uplink idzie światłowodem OM4 przez krosownicę PP-02, port 5, do DIS-SW01.

Która szkoła jest lepsza? Żadna. Ważne, żeby w zespole wszyscy rozumieli te skróty tak samo. W swojej sieci nie musisz trzymać się sztywnego formatu. Warto jednak mieć oba poziomy: widok z lotu ptaka i szczegóły, z których da się zbudować albo odtworzyć sieć.

Wskazówki dobrego schematu

  • Spójne ikony w całej dokumentacji
  • Legenda – co oznacza kolor, grubość i rodzaj linii.
  • Data i wersja w rogu rysunku
  • Jeden rysunek, jedna historia – nie upychaj wszystkiego na jednej planszy

Narzędzia

draw.io (znany też jako diagrams.net) jest darmowy. Działa w przeglądarce i jako aplikacja desktopowa, bez zakładania konta. Ma wbudowane biblioteki kształtów sieciowych.

Microsoft Visio to standard w wielu korporacjach. Jak też przystało na narzędzie do zastosowań korporacyjnych, jest płatny.

Przykład diagramu sieci w drawio
źródło: https://ihaveapc.com/2019/06/quickly-create-diagrams-and-drawings-online-for-free-with-draw-io/

PowerPoint? Tak, serio. Jeśli masz go pod ręką, a schemat wychodzi czytelny, nie ma się nad czym zastanawiać. Liczy się efekt, a nie narzędzie.

Przykład diagramu sieci w programie Power Point
źródło: https://www.conceptdraw.com/helpdesk/how-to-create-wireless-network-diagram-in-powerpoint

Producenci udostępniają też oficjalne ikony. Cisco ma pakiet Network Topology Icons. W środku są symbole do Visio, biblioteka do PowerPointa oraz pliki EPS i JPG. Warunek jest jeden: ikon wolno używać, ale nie wolno ich modyfikować. Fortinet ma własną Icon Library, podobnie jak inni producenci. Pobierasz, wklejasz i masz schemat, który wygląda profesjonalnie.

Ciekawostka na koniec: diagramy jako kod. W narzędziach takich jak Mermaid czy D2 opisujesz schemat tekstem, a program go rysuje. Taki plik świetnie żyje w gicie. Przy dużych sieciach automatyczny układ potrafi się jednak rozjechać.

IPAM, czyli porządek w adresacji

Adresacja to też dokumentacja sieci, i to jedna z najważniejszych. IPAM (IP Address Management) odpowiada na proste pytania. Jakie mam podsieci? Do czego służą? Który adres jest wolny?

Plan adresacji z logiką

Dobry plan adresacji da się czytać bez ściągawki. Przykładowy schemat to

10.LOKALIZACJA.VLAN.0/24

Wtedy 10.11.110.0/24 oznacza lokalizację 11 (WAW-B1) i VLAN 110, czyli użytkowników. Widzisz adres w logach i od razu wiesz, skąd przyszedł.

Taki schemat ma też wady. Marnuje przestrzeń adresową, bo każdy VLAN dostaje /24. Nie zmieścisz w nim też VLAN-u o numerze powyżej 255. W kampusie z prywatną „dziesiątką” to jednak zwykle rozsądna cena za czytelność.

Ustal też jedną konwencję bramy domyślnej. Pierwszy adres (.1) albo ostatni (.254) – wybierz jeden wariant (jedynke!) i trzymaj się go wszędzie.

Excel jako IPAM

Uczciwie: w małej sieci Excel wystarczy. Kilka podsieci, jeden admin i wszystko jest jasne. Problemy zaczynają się, gdy sieć rośnie.

Excel nie pilnuje, czy podsieci się nie nakładają. Nie powstrzyma też dwóch osób, które edytują plik naraz. W końcu powstaje „adresacja_NOWA.xlsx” i nikt już nie wie, która wersja jest prawdziwa.

Wtedy wracają patologie z początku tekstu. Sprawdzanie wolnego adresu w tablicy ARP i pingowanie „na wszelki wypadek” to znak, że czas na prawdziwe narzędzie.

NetBox: IPAM i dużo więcej

Narzędzi do IPAM jest sporo, od prostych po rozbudowane platformy. Jako przykład weźmy NetBoxa. To jedno z najpopularniejszych narzędzi open source w tej kategorii. Przy tym potrafi dużo więcej niż samo IPAM.

Czym jest NetBox

NetBox to darmowe narzędzie open source do dokumentowania sieci. Stworzył je Jeremy Stretch, gdy pracował jako inżynier sieci w DigitalOcean. Kod opublikowano w czerwcu 2016 roku. Dziś projekt rozwija firma NetBox Labs razem ze społecznością. Oprócz darmowej wersji Community istnieją płatne NetBox Cloud i NetBox Enterprise.

Od początku warto dobrze zrozumieć, czym NetBox jest. To nie jest system monitoringu ani skaner sieci. NetBox opisuje stan zamierzony, czyli to, jak Twoja sieć powinna wyglądać. Dokumentacja projektu mówi o tym wprost. To, jak sieć wygląda naprawdę, pokazuje monitoring. Do tej różnicy jeszcze wrócimy.

IPAM w NetBoxie

Moduł IPAM to serce NetBoxa i zwykle pierwszy powód, dla którego ktoś go wdraża. Zaczynasz od góry, czyli od agregatów, na przykład prywatnej „dziesiątki”. Pod nimi definiujesz prefiksy, a NetBox sam układa je w hierarchię na podstawie zawierania się adresów. Wpisujesz 10.11.110.0/24 i NetBox sam wie, że należy do 10.11.0.0/16. Niczego nie musisz ręcznie przypinać.

Każdy prefiks to coś więcej niż adres z maską. Ma status (aktywny, zarezerwowany, wycofany albo kontener), rolę, VLAN, VRF i lokalizację. Od razu widać więc, że 10.11.110.0/24 to użytkownicy budynku B1 w VLAN-ie 110. Pasek zajętości pokazuje, ile adresów już wykorzystano. Dzięki temu wiesz, że podsieć się kończy, zanim DHCP zacznie odmawiać dzierżaw.

Niżej są pojedyncze adresy IP. Każdy możesz przypisać do interfejsu konkretnego urządzenia i oznaczyć rolą, na przykład VRRP. Do tego dochodzi nazwa DNS i opis, kto i po co używa adresu. Pule DHCP opisujesz jako zakresy. Od razu widać, które adresy należą do puli i nie nadają się do ręcznego przydziału.

NetBox obsługuje też VRF-y, więc nakładające się adresacje, np. po przejęciu innej firmy, nie wchodzą sobie w drogę. W obrębie VRF możesz też wymusić unikalność adresów. Duplikat wyjdzie wtedy przy wpisywaniu, a nie w trakcie awarii.

Przykładowy widok IPAM w NetBox
źródło: https://www.youtube.com/watch?v=zjNftvwbJ3M

IPAM w praktyce

Na co dzień NetBox to po prostu dokumentacja. Pełni tę samą rolę co Excel z adresacją, tylko robi to dużo lepiej. Każda podsieć, każdy zarezerwowany adres i każda zmiana trafiają do jednej bazy. Wszyscy w zespole patrzą na te same dane. Koniec z dwiema wersjami pliku adresacji.

Weźmy typową sytuację. Admin serwerowy prosi o adres IP dla nowej maszyny. Otwierasz w NetBoxie prefiks serwerowni i widzisz, które adresy są zajęte, a które wolne. Wybierasz wolny adres, wpisujesz, do czego służy i kto za niego odpowiada. Zapisujesz i gotowe. Bez logowania na firewall, bez przeglądania tablicy ARP i bez pingowania „na wszelki wypadek”.

NetBox sam prowadzi też historię zmian. Widać w niej, kto i kiedy dodał, zmienił albo usunął dany wpis. Gdy za rok ktoś zapyta, skąd wziął się jakiś adres, odpowiedź będzie czekała w historii.

DCIM, czyli fizyczna strona sieci

Druga duża część to DCIM (Data Center Infrastructure Management). Nazwa sugeruje serwerownię, ale w kampusie przydaje się tak samo. To po prostu fizyczna strona sieci: budynki, pomieszczenia, szafy, urządzenia, kable i zasilanie.

Widok DCIM w NetBox
źródło: https://www.youtube.com/watch?v=hAfCbB-4cyk

Najlepiej widać to na przykładzie szafy. Otwierasz w NetBoxie szafę na drugim piętrze i widzisz jej rysunek, z przodu i z tyłu. Każde urządzenie stoi na nim na swoim miejscu: krosownica w U42, przełącznik w U40, UPS na samym dole. Od razu widać też wolne U. Rysunek jest interaktywny. Klikasz w przełącznik i przechodzisz do jego karty z modelem, numerem seryjnym, interfejsami i adresami IP.

Z zasilaniem jest podobnie. Opisujesz panele zasilające, obwody i listwy PDU, a przy urządzeniach podajesz ich pobór mocy. NetBox podlicza wtedy obciążenie każdego obwodu. Zanim wstawisz do szafy kolejny przełącznik PoE, sprawdzasz, czy obwód go udźwignie.

Najważniejsze jest to, że wszystko masz w jednym miejscu. Planujesz nowe urządzenie? W kilka minut sprawdzasz wolne U, zapas mocy i wolne porty na krosownicy. Możesz nawet zarezerwować miejsce w szafie pod sprzęt, który dopiero jedzie od dostawcy.

Modeli urządzeń nie musisz definiować ręcznie. Społeczność utrzymuje bibliotekę devicetype-library z gotowymi definicjami bardzo wielu modeli. Część z nich ma nawet obrazki frontu i tyłu, które pojawiają się potem na rysunku szafy.

Najciekawiej robi się, gdy połączysz IPAM z DCIM. Adres IP jest przypisany do interfejsu, interfejs do urządzenia, a urządzenie do szafy i pomieszczenia. NetBox modeluje też krosownice, więc kabel prześledzisz od portu przełącznika aż do gniazdka w ścianie. Kacper od razu sprawdziłby, gdzie wpięto terminal na drugim piętrze, zamiast przeskakiwać po przełącznikach.

Od dokumentacji do źródła prawdy

Wszystko, co opisałem wyżej, to wciąż dokumentacja. Bardzo dobra, ale tylko dokumentacja. NetBoxa można jednak rozbudować w prawdziwe źródło prawdy o sieci, czyli SSoT (Single Source of Truth). Chodzi tu o dwie rzeczy.

Po pierwsze, NetBox może pilnować poprawności i aktualności dokumentacji. Pamiętasz różnicę między stanem zamierzonym a rzeczywistym? Skrypt albo NetBox Discovery porównuje jedno z drugim. Każda rozbieżność oznacza, że poprawki wymaga dokumentacja albo sama sieć.

Po drugie, NetBox może być miejscem, w którym wprowadzasz zmiany. Najpierw dodajesz VLAN albo opis portu w NetBoxie, a konfigurację generuje i wdraża ta słynna „automatyzacja”. To ta sama zasada co przy schematach: najpierw dokumentacja, potem zmiana. Tyle że resztę robi automat, więc dokumentacja nie ma kiedy się zestarzeć.

To wyższa szkoła jazdy, ale nawet częściowe wdrożenie tej idei mocno ogranicza rozjazd między dokumentacją a rzeczywistością.

Wady, o których trzeba powiedzieć

NetBox nie jest magiczny. Sam z siebie nie przeskanuje sieci (a przynajmniej nie w 100%). Ktoś musi wprowadzić dane i pilnować, żeby były aktualne. Automatyzacja opisana wyżej też nie zbuduje się sama.

Do tego dochodzi próg wejścia. Model danych jest rozbudowany, a samo wprowadzenie istniejącej sieci potrafi zająć tygodnie. NetBoxa trzeba też utrzymać, czyli aktualizować go, robić kopie bazy i pilnować zgodności pluginów.

Najważniejsza jest jednak dyscyplina zespołu. Jeśli połowa zmian omija NetBoxa, po roku masz kolejny nieaktualny Excel. Tyle że droższy w utrzymaniu.

Alternatywy

Jeśli NetBox wydaje Ci się za duży, spójrz na phpIPAM. To prostsze narzędzie, skupione na samej adresacji. Z kolei Nautobot to fork NetBoxa z 2021 roku. Rozwija go firma Network to Code, z naciskiem na automatyzację.

To dopiero wierzchołek góry lodowej

Na NetBoxa można by poświęcić osobną serię poradników. Tutaj ledwo liznęliśmy temat: nie było instalacji, pluginów, uprawnień ani integracji z automatyzacją. Jeśli Cię zaciekawił, poszukaj materiałów w sieci. Jest ich naprawdę dużo, bo NetBox to narzędzie, którego faktycznie się używa.

Punktem startowym może być oficjalna dokumentacja i kurs NetBox Zero to Hero. To 12 modułów wideo, w których krok po kroku budujesz w NetBoxie sieć oddziału fikcyjnej firmy. Społeczność prowadzi też listę awesome-netbox z pluginami, narzędziami i poradnikami. Gdy utkniesz, pytaj w GitHub Discussions albo na Slacku społeczności NetDev, gdzie NetBox ma swoje kanały. Spora szansa, że ktoś miał już ten sam problem. Możesz też wpaść na nasz Discord. Chętnie pomożemy albo przynajmniej podpowiemy, gdzie szukać dalej.

Narzędzie do dokumentacji, które samo ma porządną dokumentację? W naszej branży to rzadkość, więc warto z tego skorzystać.

DDI, czyli IPAM, który rządzi DNS i DHCP

Na deser coś z wyższej półki. DDI to skrót od DNS, DHCP i IPAM. Chodzi o jedną platformę, która zarządza wszystkimi trzema usługami naraz.

W DDI to IPAM jest źródłem, z którego DNS i DHCP biorą konfigurację. Rezerwujesz adres i od razu powstaje rekord DNS. Widzisz też dzierżawy DHCP na bieżąco. Dokumentacja nie rozjedzie się z rzeczywistością, bo to ta sama baza danych.

Brzmi znajomo? Słusznie, bo w podobną stronę da się rozbudować NetBoxa. Istnieją pluginy i integracje, które łączą go z serwerami DNS i DHCP. Dołóż do tego API, webhooki i trochę automatyzacji, a dostaniesz coś na kształt DDI.

Różnica polega na tym, że takie rozwiązanie składasz i utrzymujesz sam. Komercyjne DDI dostajesz jako gotową, zintegrowaną platformę. Ma własne serwery DNS i DHCP, wysoką dostępność i wsparcie producenta.

Przykład? BlueCat Integrity. Jego sercem jest BlueCat Address Manager, który zarządza adresacją. Usługi DNS i DHCP dostarczają appliance’y BlueCat DNS/DHCP Server. Całość ma REST API, więc łatwo spiąć ją z automatyzacją. Na tym rynku działają też między innymi Infoblox i EfficientIP.

Dla kogo to jest? Głównie dla dużych organizacji z wieloma lokalizacjami. Trzeba też uczciwie powiedzieć o kosztach, bo licencje DDI kosztują sporo. Wybór sprowadza się więc do pytania, co jest tańsze: licencja czy czas zespołu na budowę i utrzymanie własnego rozwiązania.

Sobota Kacpra – wersja alternatywna

Na koniec trochę pogdybajmy. Jak mogłaby wyglądać ta sama sobota?

Kacper ma dyżur, więc jest pod telefonem, ale nie siedzi przy biurku. Zabbix w nocy go nie obudził, bo przełączniki dostępowe zgodnie z regułami alarmują tylko na dashboardzie. Równie dobrze można by je ustawić tak, żeby wysyłały SMS. To kwestia decyzji, ile nocnych pobudek zespół uzna za rozsądne. Telefon od kierownika zmiany przychodzi więc tak samo, o 6:40. Kacper odpala laptopa i otwiera Zabbixa. Zamiast 250 alertów widzi tylko kilka, bo monitoring jest posprzątany. Dwa z nich od razu rzucają się w oczy. O 1:12 przełącznik WAW-B1-ACC-SW02 przestał odpowiadać, a godzinę później wrócił z uptime’em poniżej 10 minut.

Kacper od razu wie, gdzie szukać. Nazwa urządzenia mówi mu, że to przełącznik dostępowy na drugim piętrze budynku B1. Opisy portów prowadzą prosto do uplinku i do terminali. A skoro switch się zrestartował, pierwsze podejrzenie pada na niezapisaną konfigurację.

Dalej też idzie gładko. Oxidized albo płatna alternatywa, np. BackBox, regularnie pobiera konfigurację i pokazuje różnice między wersjami. Diff z ostatniego backupu potwierdza, że po restarcie zniknął VLAN terminali na portach i trunku. Kacper nie zgaduje, tylko przywraca brakujące linie z poprzedniej wersji. Całość trwa kwadrans, a zmiana zaczyna pracę o czasie. Narzędziom do backupu konfiguracji przyjrzymy się bliżej w kolejnej części serii.

Co jeszcze mogłoby pomóc?

Można też pójść krok dalej. Część z tych pomysłów zapobiegłaby awarii, a reszta jeszcze bardziej skróciłaby szukanie:

  • Alert o niezapisanej konfiguracji. Narzędzie do backupu albo prosty skrypt porównuje running-config ze startup-config. Niezapisana zmiana Marka wyszłaby na jaw pół roku wcześniej.
  • Automatyczny write memory. Niektórzy każą narzędziu do backupu przy okazji zapisywać konfigurację. To jednak broń obosieczna, bo utrwala też przypadkowe zmiany.
  • Kontrola zgodności z szablonem konfiguracji. Narzędzie co noc porównuje konfigurację każdego przełącznika z szablonem bazowym (golden config). Szablon może też określać, jakie VLAN-y mają być na trunkach w danym budynku. Brakujący VLAN terminali wyskoczyłby w nocnym raporcie.
  • UPS dla przełączników dostępowych. Albo przynajmniej monitoring zasilania. Najtańsza awaria to ta, do której nie doszło.
  • Aktualny schemat i NetBox. Nawet bez alertu Kacper szybko znalazłby przełącznik obsługujący drugie piętro.

Na rynku nie brakuje płatnych narzędzi, które zrobią dużo z tego za Ciebie. BackBox, platformy DDI czy komercyjne systemy monitoringu są naprawdę dobre i często warte swojej ceny. W tej serii stawiamy jednak głównie na rozwiązania darmowe albo tanie. Zabbix, Oxidized i NetBox w wersji Community nie kosztują nic za licencję. Płacisz za nie czasem i dyscypliną. A porządku i tak żadne narzędzie za Ciebie nie zrobi.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *