Jak zostać adminem sieci: od podstaw TCP/IP do pierwszej roli w NOC

Na start: czego nie robić i gdzie najłatwiej się wykoleić

Chęć „zostać adminem sieci” często rozbija się o trzy pułapki: uczenie się teorii bez praktyki, chaos w narzędziach oraz brak podstaw TCP/IP. Bez umiejętności diagnozowania prostych problemów (warstwa 1–3) i czytelnego raportowania w NOC trudno przeskoczyć dalej. Zanim włączysz Wiresharka i odpalisz kurs CCNA, ustaw zasady gry: uczysz się na małych, działających przykładach, zapisujesz wnioski, a każdą nową komendę testujesz w kontrolowanym labie. I jeszcze jedno: nie skacz od razu w BGP i EVPN, jeśli nie umiesz policzyć maski /27 i rozumieć ARP.

Jeśli Twoim celem jest pierwsza rola w Network Operations Center, licz się z pracą zmianową i presją czasu. NOC nie oczekuje, że skonfigurujesz backbone, ale oczekuje, że w 5–10 minut określisz, czy incydent to problem klienta, operatora czy sprzętu, uruchomisz właściwy runbook i poprawnie eskalujesz. To konkretny zestaw nawyków i wiedzy z TCP/IP, a nie „encyklopedia sieci”.

W skrócie: poznaj fundamenty, opanuj narzędzia pierwszej pomocy, zbuduj własny lab, ćwicz diagnozę krok po kroku i przełóż to na czytelną komunikację. To wystarczy, by sensownie wejść w zawód administratora sieci i zacząć w NOC.

Krótki brief: pytania, na które szukasz odpowiedzi

• Od czego zacząć naukę TCP/IP, by nie utonąć w teorii?
• Jakie komendy i narzędzia realnie używa początkujący admin sieci i NOC?
• Jak zbudować tani i skuteczny lab do praktyki?
• Jakie minimum konfiguracji przełączników i routerów trzeba umieć?
• Co robi NOC na co dzień i jak wygląda praca z incydentami?
• Jak przygotować się do rozmów rekrutacyjnych i jak uwiarygodnić umiejętności?
• Jakie błędy najczęściej kosztują czas i nerwy na starcie?

1. Zrozum TCP/IP bez ściemy: absolutne minimum i praktyka

Adresacja IP i maski – trzy ruchy, które musisz mieć w palcu

Bez płynnego liczenia podsieci i rozumienia CIDR ciężko nawet odczytać alert. Skup się na szybkim rozpoznawaniu sieci, broadcastu i zakresu hostów.

• Ćwiczenie: podany adres 10.10.5.77/26 – wyznacz sieć (10.10.5.64), broadcast (10.10.5.127), hosty (10.10.5.65–10.10.5.126).
• Reguła: /24 to 256 adresów, /25 – 128, /26 – 64, /27 – 32, /28 – 16, /29 – 8, /30 – 4 (2 hosty). Zapamiętaj te punkty odniesienia i licz w dół/w górę.
• Checklist: dla każdej podsieci określ gateway, zakres DHCP, adresy statyczne, rezerwacje i monitoring.

W praktyce NOC szybko wykrywa kolizje adresów lub złe maski po symptomach: brak odpowiedzi ping w obrębie sieci lokalnej, ARP nie zwraca właściwego MAC, hosty widzą się tylko przez router. Jeśli na hostach widzisz różne maski w jednej VLAN – masz przyczynę.

Routing kontra switching – gdzie pakiet skręca naprawdę

Switch (warstwa 2) przekazuje ramki na podstawie MAC i tablicy CAM. Router (warstwa 3) przekazuje pakiety na podstawie tablicy routingu. W praktyce:

• Objaw „nie działa”: hosty w tym samym VLAN nie pingują się – szukaj L2 (VLAN, trunk, STP, port down, błędny access port).
• Hosty w różnych VLAN nie pingują się – szukaj L3 (SVI wyłączone, zła trasa domyślna, ACL blokuje ICMP).
• TCP działa wolno, UDP gubi pakiety – analizuj L2/L3 (przepełnione kolejki, błędy interfejsów, ECMP hash, MTU/MSS).

Ćwicz czytanie tablic: „show mac address-table” i „show ip route” (albo „ip neigh” i „ip route” w Linuksie) mówią, gdzie pakiet skręca, a nie gdzie chciałby skręcić.

ARP, DNS, DHCP, NAT – małe protokoły, duże awarie

Te cztery mechanizmy wyjaśniają większość „nagle przestało działać”.

• ARP: brak wpisu lub konflikt MAC – pakiety nie trafiają do gateway. Diagnoza: brak odpowiedzi na ARP probe, tablica ARP pełna lub „incomplete”.
• DNS: zła strefa, przeterminowany rekord, brak rekurencji – aplikacje zgłaszają „timeout”. Zawsze testuj rozwiązywanie nazwy i TTL rekordu.
• DHCP: brak wolnych adresów, brak opcji 3/6 (gateway/DNS), scope na złym VLAN. Diagnostyka: brak DHCP Discover/Offer na zrzucie ruchu.
• NAT: zły kierunek, brak SNAT dla podsieci, terminacja VPN przed/za NAT. Objawy: wychodzące koneksje działają wybiórczo, publikacje nieosiągalne.

IPv6 w pigułce dla przyszłego NOC

Nie unikaj IPv6. Minimum operacyjne:

• Adresy: global unicast (2000::/3), link-local (fe80::/10), ULA (fc00::/7).
• Podsieci: /64 dla LAN to standard. DHCPv6 i SLAAC – rozumiej różnice i role RA.
• Diagnoza: ping6, traceroute6, „ip -6 route”, NDP (odpowiednik ARP). MTU i ICMPv6 są krytyczne – blokowanie ICMPv6 psuje Path MTU Discovery.

2. Narzędzia pierwszej pomocy sieciowej: od ping do Wireshark

Ping, traceroute i mtr – szybka mapa drogi pakietu

Triada, bez której NOC nie rusza. Sekwencja testu:

1. Ping gateway lokalny – upewnij się, że host rozmawia z bramą.
2. Ping ip publiczny (np. 1.1.1.1) – test routingu wychodzącego.
3. Ping nazwę (np. domenę) – test DNS + routing.
4. Traceroute/mtr – gdzie rośnie RTT, gdzie pojawiają się gwiazdki.

tcpdump i Wireshark – kiedy bez echa nie ruszysz

Sniffing ratuje, gdy ping i traceroute już nic nie mówią. Włączaj go z głową: na właściwym interfejsie, z filtrem i na krótko.

• Cel: potwierdź, czy pakiety wychodzą i wracają oraz co je blokuje (ARP/DNS/DHCP/TCP handshake).
• Filtry, które wystarczą na start: „arp or icmp or (tcp and port 443)” oraz „udp port 67 or 68” (DHCP).
• Wzorce awarii: brak ARP reply (gateway nie widzi hosta), SYN bez SYN-ACK (firewall/ACL), TLS handshake reset (SNI/inspekcja).
• Przykład: brak dostępu do portalu – w zrzucie tylko SYN→, brak SYN-ACK, a ICMP „fragmentation needed” – winne MTU/MSS na styku VPN.

dig/nslookup, curl i openssl – szybka diagnoza DNS i HTTPS

DNS i TLS psują aplikacje częściej niż routing. Sprawdź to zanim rozkręcisz incydent.

• DNS: użyj „dig +short host.tld A/AAAA”, „dig @dns-serwer host.tld” i „+trace”, by zobaczyć, gdzie się urywa delegacja.
• HTTP(S): „curl -vkI https://host” – status, certyfikat, SNI, przekierowania. „openssl s_client -connect host:443 -servername host” – łańcuch certów i protokoły.
• Przykład: aplikacja działa z IP, a nie z nazwą – „dig” zwraca stare IP (TTL 2h). Winny lokalny cache lub brak odświeżenia strefy wtórnej.

iperf3, ss/netstat – czy to przepustowość, czy zatory

Gdy jest „wolno”, zmierz, a nie zgaduj.

• iperf3: testy w obie strony, kilka strumieni równoległych, zapis wyniku (–J do JSON). Różnica kierunków = problem kolejki/policera.
• ss -tuna: stan TCP (ESTAB/RETRANS), kolejki send/recv. Dużo RETRANS i rosnące RTO – straty lub shaping.
• Przykład: 1 Gbps w miedzi, a transfer 80 Mbps – iperf3 pokazuje dropy co 10 s; „show int” ujawnia błędy FCS na jednym porcie.

Syslog, SNMP/Telemetry i NetFlow – ślady przed i po awarii

Zanim zadzwonisz do on-calla, miej chociaż trzy fakty z monitoringu.

• Syslog: flapping interfejsu, STP topology change, DHCP pool full – to są „dymiące pistolety”. Szukaj korelacji czasowej z incydentem.
• SNMP/telemetria: CPU, pamięć, temperatura, licznik błędów/CRC, discards – minuty przed awarią powiedzą więcej niż sam moment „down”.
• NetFlow/sFlow/IPFIX: nagły wzrost do jednego hosta/ASN – być może DDoS lub backup poza oknem.

3. Zbuduj lab, który realnie uczy (i nie pali czasu)

Prosty lab to lepszy lab. Trzy warianty, które działają w mieszkaniu i na laptopie.

• Wariant „kontenery + namespace”:
  • Docker/Podman: FRRouting (routing), Bind9 (DNS), dnsmasq (DHCP), iperf, nginx.
  • Linux: „ip netns” do symulacji hostów, veth-pairs i bridge do łączenia segmentów.
  • Ćwiczenie: VLANy wirtualne na bridge, NAT na „routerze” (nftables), DHCP relay do dnsmasq.
• Wariant „EVE-NG/GNS3/containerlab”:
  • Obrazy: VyOS, FRR, Mikrotik CHR, Cumulus VX. Topologie zapisuj w repo (wersjonowanie!).
  • Ćwiczenie: Inter-VLAN routing, OSPF single-area, podstawowy ACL między VLAN „Goście” i „Prod”.
• Wariant „tani switch + stary PC”:
  • Switch L2 z VLAN/802.1Q, PC jako router-on-a-stick (Linux + FRR/pfSense/OPNsense).
  • Ćwiczenie: VLAN10/20, trunk do PC, SVI na Linuxie, DHCP dla obu VLAN, NAT do internetu.

Checklist po każdym ćwiczeniu:

• Host w VLAN ping do gateway i do hosta w tym samym VLAN.
• Inter-VLAN ping i kontrola ACL (czy blokuje to, co ma blokować).
• DNS z poprawnym TTL, DHCP z prawidłowymi opcjami 3/6.
• Wyjście do internetu i poprawne SNAT, log na syslog/flow na dashboardzie.

4. Konfiguracje, które powinieneś umieć od ręki

Bez kodowania, bez „magii”. Po prostu zestawy kroków, które składają się na 80% zadań.

• VLAN i trunk:
  • Utwórz VLANy, opisz porty access, włącz trunk tylko tam, gdzie trzeba; pilnuj native VLAN.
  • Sprawdź: „show vlan”, „show interfaces trunk”, LLDP sąsiadów.
• SVI i routing między VLAN:
  • Adresy bram dla każdego VLAN, trasa domyślna na brzeg, ICMP dostęp z mgmt.
  • Sprawdź: „show ip route”, ARP/NDP dla bram i hostów.
• DHCP i relay:
  • Scope per VLAN, opcje 3/6, rezerwacje dla drukarek/IoT; na L3 dodaj helper do serwera DHCP.
  • Sprawdź: DORA w zrzucie (Discover–Offer–Request–ACK).
• ACL na brzegu i między VLAN:
  • Domyślnie deny, zezwól na niezbędne porty, mgmt tylko z jump-host. Loguj trafienia (rate-limit log).
  • Sprawdź: kolejność reguł, hit-count, czy ICMP kontrolny nie jest zbyt agresywnie blokowany.

5. Brzeg i ciągłość działania: NAT, VPN, QoS, HA

NAT bez niespodzianek

• Cel: przewidywalny SNAT/DNAT, bez pętli hairpin i z wyjątkami dla tuneli.
• Jak ustawić:
  • SNAT dla wszystkich podsieci wychodzących do internetu; wyjątki no-NAT dla ruchu do tuneli VPN i sieci partnerskich.
  • DNAT tylko za WAF/rewers-proxy lub na wydzielonej strefie; loguj trafienia.
  • Hairpin NAT (NAT loopback) włącz tylko, jeśli publikacje muszą działać z sieci LAN po nazwie publicznej.
• Przykład: publikacja https://app.example.com na 10.10.10.10:443
  • DNAT: WAN:443 → 10.10.10.10:443; policy: allow z internetu tylko do tego VIP.
  • Health-check z zewnątrz i z wnętrza (curl -vkI), sprawdź ścieżkę certyfikatu.
• Mikro-checklista:
  • Czy istnieje no-NAT dla podsieci tuneli (crypto/domestic ranges)?
  • Czy DNAT nie omija ACL/WAF? Czy logujesz drop/permit?
  • Czy hairpin nie dubluje reguł i nie psuje ścieżki powrotnej?

VPN: site-to-site, który wstaje i zostaje

• Cel: stabilny IPsec/IKEv2 lub SSL z przewidywalnym routingiem.
• Jak ustawić:
  • Spójne fazy: IKEv2, AES-GCM, PFS, te same lifetimy po obu stronach.
  • Route-based (tunel jako interfejs) – łatwiejsze trasy, lepsze monitorowanie; unikaj policy-based w nowych wdrożeniach.
  • Overlapping podsieci? Dodaj NAT w tunelu (policy NAT) albo przemapuj jedną stronę do zakresu translacyjnego.
• Diagnoza:
  • „show crypto ike/ipsec sa” lub odpowiedniki – czy są SPIs i rosną liczniki?
  • Ping z konkretnym źródłem przez tunel, sprawdź trasę powrotną (asymetria = drop).
• Przykład: ruch 10.1.0.0/16 ↔ 10.1.0.0/16 z partnerem – policy NAT do 172.31.0.0/16 po Twojej stronie i odpowiednie ACL w tunelu.
• Mikro-checklista:
  • Czy Faza1/Faza2 mają ten sam algorytm i DH/PFS?
  • Czy no-NAT obejmuje oba kierunki i zakresy w tunelu?
  • Monitor: SLA track na interfejsie tunelowym i alert w NMS.

QoS: minimalny zestaw, który naprawdę działa

• Cel: ochrona ruchu krytycznego przy ograniczonych łączach.
• Jak ustawić:
  • Klasyfikacja + znakowanie na brzegu (DSCP); egzekucja na wąskim gardle (shaper/policer).
  • Co najmniej trzy klasy: EF (głos), AF (aplikacje krytyczne), BE (reszta). Kolejki z priorytetem tylko dla EF (strzeż starvation).
  • Shaping na 90–95% przepustowości fizycznej, by unikać kolejek u ISP.
• Przykład: Voice VLAN → DSCP EF, kolejka priorytetowa do 10% linku, reszta WRR.
• Weryfikacja: „show policy-map interface”/„qos statistics”, NetFlow po DSCP, test rozmowy podczas backupu – brak jitteru >30 ms.

HA na brzegu: szybki failover bez czarów

• Cel: przełączenie bramy w < 1 s bez utraty sesji krytycznych.
• Jak ustawić:
  • VRRP/HSRP z preempt i track interfejsu WAN; drugi router ma kopię NAT/ACL.
  • Dla L3 do ISP: dwa eBGP z MED/LocalPref i as-path prepend na zapasowej ścieżce.
• Przykład: VRRP na VLAN-ach użytkowników, track spadku BFD do ISP – zmiana priorytetu i GARP po failoverze.
• Mikro-checklista:
  • Czy stan VRRP/HSRP jest stabilny (brak flapów)?
  • Czy sesje po przełączeniu odzyskują drogę (test TCP/UDP, SIP/RTP)?
  • Czy backup configów obu urządzeń jest aktualny (diff = 0)?

6. NOC w praktyce: triage, eskalacja, komunikaty

5-minutowy triage, zanim eskalujesz

• Zakres: kto dotknięty (1 host, segment, region, wszyscy)?
• Warstwa: L1/L2/L3 czy aplikacja? Ustal na podstawie dwóch testów (ping gateway, ping publiczny, DNS przez dig/curl).
• Czas: od kiedy i co się zmieniło (deploy, zmiana, awaria zasilania)?
• Dowody: 3 fakty z monitoringu (syslog, interfejsy, NetFlow) i 1 z hosta.
• Decyzja: rollback/mitigacja czy eskalacja (sieć/ISP/app/security).

Runbook minimum, który ratuje dyżur

• Detekcja: alert → potwierdzenie symptomów (2 niezależne źródła).
• Izolacja: ACL/blackhole, odpięcie wadliwego linku, rate-limit ruchu źródłowego.
• Komunikacja: pierwszy update w 15 min – zakres, objawy, ETA kolejnego statusu.
• Obejście: przełączenie na zapasowe łącze, wymuszenie route przez drugi DC.
• Zapisy: numer incydentu, czas, właściciel, hipotezy, decyzje, dowody (zrzuty/komendy).

Eskalacja bez chaosu

• Kryteria „teraz”: wpływ na klientów zewnętrznych, brak obejścia, naruszenie SLO, podejrzenie bezpieczeństwa.
• Do ISP: traceroute/mtr, adresacja dotknięta, timestamp, przykładowe IP źródło/cel, AS-path (jeśli BGP).
• Do aplikacji: dowód, że L3/DNS działa (curl, s_client), zakres nazw/URI, ostatnie wdrożenia.

Komunikaty statusowe, które nie wprowadzają w błąd

• Szablon: co nie działa, kogo dotyczy, co wiemy, co robimy, ETA następnej aktualizacji.
• Przykład: „Degradacja Wi‑Fi bud. B – problemy z roamingiem. Dotyczy SSID Corp. Awaryjnie wyłączono 802.11k/v. Kolejny update 10:30.”

7. Porządek i automatyzacja: Git, backup, szablony

Backup i wersjonowanie konfiguracji

• Automat: Oxidized/RANCID/Ansible pull → Git. Alert na diff większy niż X linii.
• Tagi: release/rollbacks dla kluczowych wdrożeń (np. nowy QoS, nowy WAN).
• Przykład: diff pokazuje skasowany no-NAT dla VPN – szybki revert z tagu.

Szablony i bezpieczne wdrożenia

• Ansible + Jinja: VLANy, ACL, NTP/SNMP. Najpierw check-mode, potem małe partie.
• Idempotencja: playbook nie może „doklejać” duplikatów. Test w labie + golden config compliance.
• Przykład: szablon ACL z listą dozwolonych usług per VLAN; zmiana w YAML generuje spójne reguły na całej flocie.

Tajne dane i dostęp administracyjny

• Hasła/klucze: Ansible Vault/Pass/HashiCorp Vault; zero haseł w repo wprost.
• AAA: RADIUS/TACACS+, lokalny fallback, role read-only dla NOC; loguj komendy.
• Mgmt-plane: SSH only, disable legacy, ogranicz dostęp źródłowy (mgmt VLAN/jump host), banner z identyfikacją.

Kontrola jakości konfiguracji

• Lint: ciscoconfparse/batfish – sprawdź, czy intenty są spełnione (np. brak not-tracked VRRP, poprawne next-hop’y).
• Health-check: skrypt dzienny – pętle portów down, liczniki błędów, flapy VRRP/BGP, wolne pule DHCP.

Obserwowalność, która naprawdę pomaga

SNMP/telemetria: zbierz dane, które coś mówią

• Cel: widzieć przepływy i błędy zanim zadzwoni użytkownik.
• Jak ustawić:
  • SNMPv3 z auth+priv; minimum OIDs: interfejsy (octety, błędy, discardy), CPU, pamięć, temperatury, zasilanie.
  • Streaming telemetry (jeśli wspierane): interwał 10–30 s dla interfejsów brzegowych, 60 s dla reszty.
• Przykład: skok discardów na uplinku >0,1% koreluje z kolejką BE – korekta QoS lub shaping.
• Mikro-checklista:
  • Czy każdy switch ma profil SNMPv3 i poprawne „location/contact”?
  • Czy posiadasz baseline 24 h/7 dni do porównań?

Syslog z sensem: nie tonąć w szumie

• Cel: szybki wgląd w zdarzenia krytyczne bez tysiąca duplikatów.
• Jak ustawić:
  • Poziomy: na brzegu notice/info, w core warning, a config-change zawsze info.
  • Parser: taguj facility+hostname, normalizuj czasy (NTP!), koreluj z interfejsami i VRRP/BGP.
• Przykład: „%VRRP-5-STATECHANGE” + „link down” na WAN w tej samej sekundzie → automatyczna adnotacja incydentu.
• Szybki test: czy wyłapiesz w 1 min flapa VRRP albo BGP Idle→Established? Jeśli nie – podnieś poziom lub dołóż alert.

Flow i sondy syntetyczne

• Cel: wiedzieć co zjada łącze i czy usługa działa „od nas”.
• Jak ustawić:
  • NetFlow/IPFIX na brzegu i dystrybucji: top talkers, top dst, DSCP, as-path (jeśli BGP).
  • Syntetyki: ping/HTTP/DNS z oddziałów do DC/Internetu, progi SLA (latencja, packet loss, TLS handshake).
• Przykład: nagły wzrost UDP/12345 z jednego VLAN → reguła ACL i izolacja hosta zanim saturuje uplink.

Wi‑Fi bez magii: szybkie wygrane

Plan kanałów i moc

• Cel: pokrycie bez „krzyku” AP na siebie.
• Jak ustawić:
  • 2,4 GHz: tylko 1/6/11, niska moc; 5 GHz: automatyczne z wykluczeniem zatłoczonych DFS przy specyficznych klientach.
  • Obniż moc AP w korytarzach, podnieś w salach, unikaj 40 MHz w 2,4 GHz.
• Test: „Wi‑Fi heatmap” po zmianach, roaming w ruchu – czy nie gubi DHCP/VoIP?

SSID i bezpieczeństwo

• Cel: mniej beaconów, lepsza wydajność.
• Jak ustawić:
  • Max 3–4 SSID per radio. WPA2-Enterprise/WPA3-Enterprise z RADIUS, goście przez portal + izolacja kliencka.
  • 802.11k/v dla lepszego roamingu; 802.11r ostrożnie – test z urządzeniami legacy.
• Przykład: osobny SSID dla skanerów bez wsparcia 802.11r, reszta w korporacyjnym z fast transition.

Bezpieczeństwo operacyjne w LAN: szybkie blokady

Ochrona portów dostępowych

• Cel: odciąć najczęstsze wektory z L2.
• Jak ustawić:
  • DHCP Snooping + IP Source Guard; ARP Inspection tam, gdzie masz wiarygodne bindingi.
  • BPDU Guard na access, Root Guard na granicach; Storm Control na broadcast/multicast.
  • Port-Security: ogranicz MAC per port lub 802.1X z MAB dla urządzeń nieautoryzowanych.
• Przykład: podpięty switch SOHO nie wywróci Ci STP – port w err‑disable, alert w syslog.

Higiena mgmt-plane

• Cel: tylko uprawnieni i tylko z właściwych miejsc.
• Jak ustawić:
  • SSH tylko z mgmt VLAN/jump host; wyłącz HTTP/Telnet, włącz tylko HTTPS z certem z Twojego PKI.
  • AAA z RADIUS/TACACS+, role readonly dla NOC, pełny audit poleceń.
• Mikro-checklista:
  • Czy baner i kontakt są ustawione?
  • Czy konta lokalne mają unikalne hasła i są zablokowane poza awarią AAA?

IPv6 świadomie: dual‑stack bez bólu

Adresacja i dystrybucja

• Cel: proste, przewidywalne prefiksy i DNS działający od dnia 1.
• Jak ustawić:
  • Podział /48→/56 per lokalizacja→/64 per VLAN. RA dla hostów, DHCPv6 dla opcji i rezerwacji serwerów.
  • DNS: A i AAAA równolegle; reverse dla krytycznych podsieci.
• Przykład: mgmt VLAN z statycznymi /128 na urządzeniach, reszta przez SLAAC + DHCPv6 options.

Polityki i filtrowanie

• Cel: nie powielać złudzeń NAT‑=‑ochrona.
• Jak ustawić:
  • ACL v6 domyślnie deny, jawne permit dla usług; ICMPv6 kontrolny przepuszczony (ND, PMTU).
  • RA Guard na access, DHCPv6 Guard, uRPF loose na brzegu.
• Weryfikacja: „ping -6”, „tracepath -6”, czy PMTUD działa (brak fragmentacji na środku).

DNS, NTP i PKI: małe elementy, duży wpływ

DNS lokalny i odporność

• Cel: szybkie i pewne odpowiedzi wewnątrz.
• Jak ustawić:
  • Dwa resolvery na segment, forwarding do upstream z cache. Split‑horizon dla stref wewnętrznych.
  • Monitoring: czas odpowiedzi, SERVFAIL rate, stale rosnące NXDOMAIN → sygnał błędnej konfiguracji.
• Przykład: awaria publicznego DNS nie zabija ruchu do aplikacji wewnętrznych – działa strefa split.

NTP i spójny czas

• Cel: logi i certyfikaty z tym samym zegarem.
• Jak ustawić:
  • Dwa serwery NTP w LAN, urządzenia sieciowe wskazują je jako preferowane; stratum i źródła zewnętrzne z monitorowaniem driftu.
• Szybki test: „ntpq -p” stabilny, offset < 50 ms na infrastrukturze.

PKI w praktyce

• Cel: koniec z self‑signed i ostrzeżeniami w przeglądarce do kontrolerów/WLC.
• Jak ustawić:
  • Własne CA lub korporacyjne: wydaj certyfikaty dla HTTPS/802.1X EAP‑TLS; rotacja przed wygaśnięciem z alertem 30 dni.
• Przykład: WLC z certem z wewnętrznego CA – brak przerw przy captive portal i pewny EAP‑TLS.

Pakiet po pakiecie: szybka diagnostyka TCP/UDP

TCP w trzech ruchach

• Cel: odróżnić sieć od aplikacji w 2–3 minutach.
• Jak sprawdzić:
  • SYN→brak SYN‑ACK: routing/ACL/serwer down. SYN‑ACK→RST: aplikacja zamyka lub port zły.
  • Długo czeka po SYN‑ACK: TLS handshake lub MTU/MSS – sprawdź PMTUD, ustaw MSS clamp w VPN.
• Narzędzia: „tcpdump -ni … port 443”, „curl -vkI”, „openssl s_client -connect host:443”.

UDP i QUIC

• Cel: audio/Video/DoH nie działają? Sprawdź UDP/443 i DSCP.
• Jak sprawdzić:
  • „mtr -u”, „nping –udp”, logi firewall (rate-limit/deny). Wyłącz tymczasowo ALG dla SIP, porównaj ścieżkę.
• Przykład: blokada UDP/443 przez stary filtr → Chrome spada do TCP/443 z gorszym UX.

Droga do pierwszej zmiany w NOC: plan 60–90 dni

Tydzień 1–2: fundamenty i dostęp

• Lista:
  • Dostępy do NMS, syslog, bastion, narzędzia ticketowe.
  • Mapa sieci: core, dystrybucja, brzeg, krytyczne VLAN i trasy do DC/Cloud.
• Cel: umiesz znaleźć dowolny interfejs i zobaczyć jego historię w 60 s.

Tydzień 3–6: runbooki i symulacje

• Ćwiczenia:
  • Symulowany zanik linku WAN – przełącz, komunikat, przywrócenie.
  • Incydent Wi‑Fi – triage L1–L3, decyzja o eskalacji do radiowców.

Tydzień 7–12: pierwsze dyżury i mała automatyzacja

• Wejście w dyżury:
  • Dzień 1–7: shadowing seniora, czytasz i piszesz tickety, robisz „głośno-myślenie”.
  • Dzień 8–14: samodzielne L1 z gotowymi runbookami, eskalacja wg matrycy.
  • Po każdej nocy: 10-min „after action” – 3 wnioski i 1 poprawka do runbooka.
• Mini‑automatyzacje (3 skrypty):
  • „health‑check” interfejsów (admin/up, err-disable, błędy/sek) – JSON/CSV do ticketu.
  • „routing‑pulse” (OSPF/BGP summary: sąsiedzi, flapy, trasy domyślne) – 1 komenda na region.
  • „wifi‑client‑probe” (asocjacje, RSSI, retry) – szybka diagnoza pod zgłoszenia VoIP.
• Komunikaty i szablony:
  • 3 gotowce: zanik WAN, prace planowe, degradacja Wi‑Fi. Zmieniasz tylko lokalizację i czas.
• Przykład: krótkie przycięcie łącza w oddziale – health‑check wskazuje discardy na uplinku, komunikat do biznesu + ticket do WAN‑provider z załączonym wykresem.

Runbook BGP/OSPF: szybkie decyzje

• OSPF – ścieżka decyzyjna:
  • Neighbors: FULL/2WAY/EXSTART? EXSTART/EXCHANGE → zderzenie MTU (sprawdź MTU i „ip ospf mtu-ignore”).
  • Typy obszarów: stub/NSSA – czy filtr nie odcina LSA5? Zobacz sumaryzacje na ABR.
  • „show ip ospf interface/neighbor/database”; korelacja z flappingiem interfejsu w NMS.
  • Przykład: 2WAY na łączu p‑p → błędny „network type broadcast” po jednej stronie. Ustaw „point-to-point”.
• BGP – ścieżka decyzyjna:
  • Stan: Idle/Active → warstwa transportowa (TCP/179, ACL, reachability). Established, ale 0 prefixów → route‑policy.
  • iBGP: brak next‑hop‑self → trasy docierają, lecz next‑hop nieosiągalny.
  • Communities i as‑path: brak „send‑community” → polityki w downstream nie działają.
  • Przykład: Established, brak prefiksów VPNv4 → zapomniane „address-family vpnv4” i „send-community extended”.
• Mikro‑checklista:
  • Clock/NTP zgodny (MD5/key‑chain/TTL security czasem „gryzą”).
  • Interfejs up/up, brak err‑disable, brak policera na control‑plane.
  • ACL/firewall: TCP/179, multicast OSPF, ICMP dla PMTUD.

Backup i wersjonowanie konfiguracji bez filozofii

• Setup:
  • Oxidized/RANCID + Git. Pull co 15 min, tag „last‑known‑good” po każdej udanej zmianie.
  • Maskowanie sekretów (enable/keys) w filtrach. Repo prywatne, dostęp tylko z bastionu.
• Odtwarzanie:
  • Awaria po zmianie? Rollback z ostatniego „good” diffem w ticketcie.
  • Procedura offline (port console) wydrukowana i w runbooku NOC.
• Przykład: błąd w ACL na core – z bastionu wgrywasz poprzednią wersję, ruch wraca w 60 s, post‑mortem z diffem.

Change management, ale po ludzku

• Przed zmianą:
  • Diff i wpływ: co dotkniesz (interfejsy, VRF, policy)? Jak mierzysz sukces (SLO)?
  • MOP: kroki + pre‑check/post‑check + backout ≤ 3 kroki. Okno + freeze na krytyki.
• W trakcie:
  • Canary: 1 lokalizacja/urządzenie → walidacja → dopiero rollout masowy.
  • Komunikacja: jeden kanał (bridge/Teams) i status co 10–15 min.
• Po:
  • Verifikacja: metryki QoS/CPU/errors, brak wzrostu ticketów. Tag „implemented” i link do grafów.
• Przykład: nowa polityka QoS na 200 switchach – 5 canary, 30 min obserwacji, dopiero potem reszta z Ansible w partiach po 20.

Mała automatyzacja: Ansible/CLI + sanity checks

• Start:
  • Inventory z tagami (site/role/vendor). Hasła przez Vault.
  • Playbook „facts‑only” (gather/show) do porównań baseline.
• Bezpieczne wdrożenia:
  • check‑mode + diff przed apply. Pre‑check: reachability/NTP; Post‑check: routing/QoS counters.
  • Idempotencja: ten sam play nie robi ponownie zmiany, gdy stan jest zgodny.
• Przykład: zmiana serwerów NTP na flocie – pre: „ntpq -p”, push, post: offset/stratum i timestampy w syslogu.

VPN i zdalny dostęp: szybki triage

• IPsec site‑to‑site:
  • Phase1/2: czy SA stoją? Jeśli P1 up, P2 down → proxy‑ID/ACL mismatch.
  • NAT‑T: keepalive i port 4500, asymeria w ścieżce psuje PMTUD.
  • Crypto lifetime i zegar – desynchronizacja zjada renegocjację.
• SSL‑VPN/remote:
  • Portal/ACL: split‑tunnel listy i DNS‑suffix. Brak nazw? Sprawdź split‑DNS.
  • Certyfikaty: data, CN/SAN, łańcuch CA. Alert 30 dni przed wygaśnięciem.
• Mikro‑checklista:
  • „show crypto ike/ipsec sa”, zlicz pakiety in/out – czy rosną symetrycznie?
  • Ping przez tunel z DF, test PMTUD i MSS clamp na brzegu.
• Przykład: tunel „up” bez ruchu – nieprzepuszczony UDP/4500 po NAT u dostawcy oddziału. Zmiana profilu na NAT‑T i ruch wraca.

Alerty bez szumu: progi, grupowanie, kontekst

• Progi ze stanami:
  • Warn/Crit z histerezą (np. 70/85% CPU przez ≥5 min). Baseline per pora dnia.
  • Deadman: brak danych z hosta = osobny alert „monitoring blind”.
• Redukcja duplikatów:
  • Dedup window 2–5 min, grupowanie po lokalizacji i zależnościach (core→dist→access).
  • Suppress w oknie zmian (maintenance window tag).