Strona główna 1: Wprowadzenie 2: Protokół SNMP 3: SNMP w praktyce 4: Systemy NMS 5: Kontenery i wdrożenie 6: Logowanie i bezpieczeństwo
Slajd 1/55
SNMP w praktyce – operacje, MIB i OID
Cel slajdu: Przejście od architektury teoretycznej do warsztatowej praktyki odpytywania urządzeń sieciowych, analizy metryk i skryptowania.

Strona tytułowa i wprowadzenie do modułu

Praktyczne wykorzystanie protokołu SNMP wymaga biegłości w operowaniu narzędziami konsolowymi, rozumienia struktury zwracanych odpowiedzi oraz umiejętności automatyzacji zapytań.

  • Zakres tematyczny: Operacje GET, GETNEXT, GETBULK, SET, obsługa pułapek (traps) i powiadomień Inform per RFC 3416
  • Praktyka inżynierska: Odpytywanie routerów Cisco, MikroTik RouterOS, przełączników zarządzalnych, serwerów Linux, drukarek (RFC 3805) i zasilaczy UPS (RFC 1628)
  • Skrypty i automatyzacja: Tworzenie własnych skryptów diagnostycznych w powłoce Bash oraz z użyciem języka Python (biblioteka pysnmp)
  • Analiza i optymalizacja: Wyliczanie pasma, rozwiązywanie problemu counter wrap oraz inspekcja pakietów w Wireshark
Warsztat inżyniera: Biegłość w posługiwaniu się narzędziami net-snmp pozwala na błyskawiczne zweryfikowanie parametrów urządzenia bez konieczności logowania się na konsolę czy interfejs graficzny.
Wprowadzenie do praktyki SNMP SNMP w praktyce – operacje, MIB i OID Część 3: Operacje GET/SET/BULK, trapy, odpytywanie urządzeń, skrypty ⚡ Praktyczne PDU GETBULK, snmpwalk 🛠 Sprzęt w sieci Cisco, MikroTik, Linux 🐍 Automatyzacja Bash, Python pysnmp Warsztat inżynierski diagnostyki i telemetrii sieciowej
Slajd 2/55
Spis treści prezentacji 3
Cel slajdu: Przedstawienie struktury dydaktycznej wykładu warsztatowego: od podstawowych operacji protokołu i odpytywania heterogenicznego sprzętu po zaawansowaną automatyzację i skrypty.

Struktura i harmonogram wykładu

Prezentacja prowadzi studenta przez 55 zagadnień warsztatowych, kładąc nacisk na bezpośrednią pracę z konsolą CLI, analizę składni zapytań i automatyzację.

  • Blok I: Operacje protokołu i heterogeniczny sprzęt (Slajdy 1-18): Mechanizmy GET/GETBULK/SET, kody błędów, inspekcja portów IF-MIB, routerów MikroTik, przełączników, drukarek i zasilaczy UPS
  • Blok II: Skrypty automatyzacji i telemetria systemowa (Slajdy 19-36): Rozwiązywanie przepełnienia liczników, skrypty Bash i Python pysnmp, nadzór nad CPU, RAM, dyskami, tablicami ARP i routingiem
  • Blok III: Narzędzia wizualizacji, zaawansowane studia przypadków i laboratoria (Slajdy 37-55): MRTG, Cacti, skrypty detekcji nasycenia WAN, audyt podatności, kompilacja MIB oraz 3 ćwiczenia warsztatowe
Metodyka laboratoryjna: Każdy slajd w niniejszym module zawiera listingi gotowych poleceń terminala, które student może bezpośrednio przetestować na maszynach laboratoryjnych (Linux, MikroTik RouterOS).
Plan zagadnień prezentacji 3 Plan warsztatowy prezentacji 3 Część I: Operacje • Get, GetNext, GetBulk • Zdalny SET i błędy • snmpwalk i flagi -O • Tablica ifTable • MikroTik RouterOS • Przełączniki L2/L3 • Drukarki i UPS-MIB • snmpd extend / MIB Część II: Skrypty • Counter Wrap i 64-bit • Skrypty w Bash • Python i pysnmp • Monitoring CPU / RAM • Dyski i sensory temp. • Tablica ARP i routing • VLAN i Wi-Fi RSSI • snmptrapd i zdarzenia Część III: Warsztat • Skalowalność NMS • Wykresy MRTG i Cacti • Studium routera BGP • Skrypt alarmowy pasma • Audyt bezpieczeństwa • RESTCONF vs gNMI • Zadania laboratoryjne • Test sprawdzający
Slajd 3/55
Operacja GET – pobieranie wartości konkretnego obiektu
Cel slajdu: Przedstawienie mechaniki operacji GetRequest/GetResponse, zasady adresowania instancji skalarnych (.0) oraz łączenia zmiennych w liście VarBinds.

Podstawowe operacje protokołu

Operacja GET (GetRequest per RFC 3416) jest najbardziej podstawowym atomem komunikacyjnym w protokole SNMP, służącym do pobrania wartości dokładnie wskazanego węzła.

  • Jednoznaczność adresacji: Operacja GET wymaga podania pełnego, dokładnego OID wraz z indeksem instancji; w przypadku zmiennych skalarnych obowiązkowy jest sufiks `.0` (np. `sysName.0`)
  • Łączenie zapytań (Multi-VarBind): Pojedynczy pakiet GetRequest może zawierać listę wielu numerów OID (np. sysName.0, sysUpTime.0, sysLocation.0), co drastycznie redukuje liczbę pakietów w sieci
  • Format wartości w żądaniu: W pakiecie GetRequest wysyłanym przez menedżera pole wartości każdej zmiennej ma typ ASN.1 NULL; agent wypełnia je rzeczywistą wartością w odpowiedzi Response
  • Obsługa błędu noSuchInstance: Jeśli zapytamy o OID bez sufiksu instancji (np. samo `sysDescr`), agent zwróci informację `No Such Instance currently exists at this OID`
Praktyka optymalizacyjna: Gdy system NMS odpytuje router o parametry bazowe, zawsze wysyła jedno zapytanie GET z listą 5–10 identyfikatorów z grupy system w jednym pakiecie PDU, zamiast generować 10 oddzielnych transakcji round-trip.
Operacja SNMP GET Operacja GET – mechanizm żądanie-odpowiedź Manager (NMS) Klient SNMP GetRequest: [ OID: sysDescr.0, Val: Null ] GetResponse: [ OID: sysDescr.0, Val: "Linux..." ] Agent (Router) Demon snmpd:161 Przykłady wywołania snmpget w terminalu: $ snmpget -v2c -c public 192.168.53.84 sysUpTime.0 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (842910) 2:20:29.10 # Odpytanie wielu zmiennych jednocześnie w jednym PDU: $ snmpget -v2c -c public 192.168.53.84 sysName.0 sysLocation.0
Slajd 4/55
Operacja GETNEXT – sekwencyjne przechodzenie drzewa
Cel slajdu: Przedstawienie mechanizmu wyznaczania leksykograficznego następnika w operacji GetNextRequest oraz zasady działania pętli snmpwalk.

Podstawowe operacje protokołu

Operacja GETNEXT (RFC 3416) pozwala na eksplorację drzewa MIB bez uprzedniej znajomości dokładnych numerów instancji ani rozmiaru tabel.

  • Leksykograficzny następnik: W odpowiedzi na zapytanie o OID X, agent zwraca pierwszy istniejący w jego bazie obiekt o identyfikatorze leksykograficznie większym od X
  • Fundament pętli snmpwalk: Narzędzie `snmpwalk` to w rzeczywistości sekwencja automatycznych zapytań GetNext wykonywanych w pętli dopóki zwracany OID mieści się w zadanym poddrzewie
  • Wykrywanie końca drzewa (endOfMibView): W momencie gdy GetNext osiągnie koniec poddrzewa lub koniec całej bazy agenta, w SNMPv2c zwracany jest wyjątek `endOfMibView`
  • Odporność na brak wiedzy o indeksach: Umożliwia pobranie całej tabeli interfejsów nawet wtedy, gdy nie wiemy, czy porty mają numery 1, 2, 3 czy 1001, 1002
Porządek leksykograficzny OID: OID A jest mniejszy od OID B, jeśli na pierwszej pozycji, na której się różnią, podliczba w A jest mniejsza niż w B, lub jeśli A jest prefiksem B. Przykładowo: 1.3.6.1.2.1.1.1 < 1.3.6.1.2.1.1.1.0 < 1.3.6.1.2.1.1.2.0.
Operacja SNMP GETNEXT Operacja GETNEXT – nawigacja leksykograficzna Zasada działania leksykograficznego następnika: Zapytanie: GetNextRequest ( .1.3.6.1.2.1.1.1 ) [sysDescr] Odpowiedź: GetResponse ( .1.3.6.1.2.1.1.1.0 = "Linux srv01..." ) Kolejne: GetNextRequest ( .1.3.6.1.2.1.1.1.0 ) -> Zwraca sysObjectID.0 Demonstracja snmpgetnext w terminalu: $ snmpgetnext -v2c -c public localhost sysDescr SNMPv2-MIB::sysDescr.0 = STRING: Linux proxmox 7.0.14-17-pve ... $ snmpgetnext -v2c -c public localhost sysDescr.0 SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
Slajd 5/55
Operacja GETBULK (SNMPv2c/v3) – optymalizacja masowa
Cel slajdu: Przedstawienie architektury i parametrów operacji GetBulkRequest wprowadzonej w RFC 3416 oraz jej wpływu na wydajność systemów NMS.

Podstawowe operacje protokołu

Operacja GETBULK (RFC 3416) zrewolucjonizowała odpytywanie tabel SNMP, umożliwiając pobranie setek zmiennych w odpowiedzi na pojedynczy pakiet zapytania.

  • Parametr Non-Repeaters: Określa liczbę zmiennych z początku listy VarBind, dla których agent ma zwrócić dokładnie jednego następnika (zastosowanie do zmiennych skalarnych)
  • Parametr Max-Repetitions: Określa maksymalną liczbę kolejnych leksykograficznych następników, jakie agent ma wygenerować dla pozostałych zmiennych tabelarycznych
  • Kompensacja opóźnień RTT: Drastyczne skrócenie czasu odpytywania na łączach rozległych WAN; czas operacji przestaje zależeć od liczby wierszy tabeli
  • Narzędzie snmpbulkwalk: Standardowy odpowiednik snmpwalk wykorzystujący pakiety GetBulk; domyślnie używa parametru max-repetitions równego od 10 do 25
Ryzyko błędu tooBig: Ustawienie zbyt dużej wartości max-repetitions (np. 200) na urządzeniu z ograniczonymi zasobami może spowodować wygenerowanie odpowiedzi przekraczającej bufor agenta lub limit komunikatu menedżera (maxMsgSize / msgMaxSize) i zwrócenie przez agenta błędu tooBig. Bezpieczna wartość produkcyjna wynosi od 20 do 50.
Operacja SNMP GETBULK Operacja GETBULK – masowy transfer danych Non-Repeaters (N) • Zmienne pojedyncze (skalarne) • Pobierane dokładnie 1 raz • Np. sysUpTime.0, sysName.0 Max-Repetitions (M) • Zmienne tabelaryczne • Pobierane kaskadowo M razy • Np. kolejne 20 wierszy ifTable Porównanie wydajnościowe na łączu o opóźnieniu RTT = 20 ms: • snmpwalk (100 wierszy x GetNext): 100 RTT = 2000 ms (2 sekundy!) • snmpbulkwalk (Max-Repetitions=25): 4 RTT = 80 ms (25 razy szybciej!) Wniosek: W sieciach produkcyjnych zawsze używamy GetBulk (SNMPv2c/v3)
Slajd 6/55
Operacja SET – zdalna zmiana konfiguracji urządzenia
Cel slajdu: Przedstawienie mechanizmu operacji SetRequest, typowania wartości przy zapisie oraz analizy zagrożeń związanych z udostępnianiem praw zapisu.

Podstawowe operacje protokołu

Operacja SET (RFC 3416) pozwala stacji zarządzającej na zdalną modyfikację zmiennych w bazie MIB nadzorowanego urządzenia.

  • Format polecenia snmpset: Wymaga wskazania pełnego identyfikatora OID, litery oznaczającej typ danych (np. `s` dla ciągu znaków, `i` dla liczby całkowitej, `x` dla heksadecymalnego) oraz nowej wartości
  • Uprawnienia zapisu w MIB (MAX-ACCESS): Zmianie podlegają wyłącznie zmienne zdefiniowane w plikach MIB z klauzulą `read-write` lub `read-create` (np. sysContact, sysLocation, ifAdminStatus)
  • Zagrożenia operacyjne: Pozostawienie domyślnego hasła zapisu 'private' w SNMPv1/v2c pozwala dowolnej osobie w sieci na zdalną rekonfigurację urządzenia, a nawet wyłączenie interfejsów magistrali
  • Rekomendacja architektoniczna: W systemach monitoringu NMS należy bezwzględnie stosować wyłącznie poświadczenia tylko do odczytu (Read-Only / rocommunity); zmiany konfiguracji powinny być realizowane przez SSH, Ansible lub NETCONF
Kody typów w snmpset:
i = INTEGER, u = unsigned integer, s = OCTET STRING, x = hex string, d = decimal string, n = null, o = OID, t = timeticks, a = ipaddress.
Operacja SNMP SET Operacja SET – modyfikacja parametrów urządzenia Przykłady polecenia snmpset w terminalu: # 1. Zmiana kontaktu administracyjnego (typ s = string): $ snmpset -v2c -c private srv01 sysContact.0 s "admin@bezpieczna-siec.pl" # 2. Administracyjne wyłączenie portu eth1 (typ i = integer, stan down=2): $ snmpset -v2c -c private router01 ifAdminStatus.2 i 2 Ryzyko operacji SET: • Przejęcie community RW • Zdalne wyłączenie portów • Restart urządzenia Dobra praktyka NMS: • Blokada zapisu w NMS • Tylko profil read-only (RO) • Konfiguracja przez SSH/Ansible
Slajd 7/55
Kody błędów protokołu SNMP
Cel slajdu: Przedstawienie standardowych kodów błędów zawartych w polu Error-Status nagłówka PDU oraz zasad ich interpretacji podczas diagnostyki.

Diagnostyka i inspekcja ruchu

W przypadku problemów z realizacją zapytania agent SNMP wypełnia pole `Error-Status` odpowiednim kodem liczbowym, a pole `Error-Index` wskazuje błędną zmienną.

  • noError (kod 0): Operacja wykonana pomyślnie; lista VarBinds zawiera poprawne odczyty lub potwierdzenie zapisu
  • tooBig (kod 1): Wygenerowana odpowiedź przekroczyła dopuszczalny bufor agenta lub limit pakietu UDP; rozwiązaniem jest zmniejszenie parametru `max-repetitions` lub liczby zmiennych
  • Błędy autoryzacji zapisu (readOnly / notWritable): Informacja, że obiekt ma status MAX-ACCESS read-only lub zalogowany użytkownik/wspólnota nie posiada praw zapisu w modelu VACM
  • Nowoczesne wyjątki VarBind (v2c/v3): W wersjach nowożytnych błąd nie unieważnia całego pakietu; zamiast tego w konkretnym VarBind pojawia się wartość specjalna: `noSuchObject`, `noSuchInstance` lub `endOfMibView`
Rola Error-Index: W zapytaniu zawierającym 10 zmiennych wartość Error-Index: 4 oznacza, że błąd wywołała czwarta zmienna z listy. Pozwala to stacji NMS na natychmiastowe usunięcie błędnego OID i ponowienie zapytania dla pozostałych 9 zmiennych.
Kody błędów SNMP Kody błędów jednostki PDU (Error-Status) noError (0) Operacja zakończona pełnym sukcesem tooBig (1) Odpowiedź przekracza bufor agenta lub maxMsgSize noSuchName (2 - v1) Wskazany OID nie istnieje w drzewie agenta badValue (3 - v1) Niepoprawny typ lub zakres wartości w SET readOnly (4 - v1) / notWritable (17) Próba zapisu do zmiennej tylko do odczytu genErr (5) Ogólny błąd wewnętrzny systemu operacyjnego W SNMPv2c/v3 wprowadzono granularne kody błędów RFC 3416 (od 6 do 18).
Slajd 8/55
Narzędzie snmpwalk – automatyczne pobieranie poddrzewa
Cel slajdu: Przedstawienie zaawansowanego wykorzystania narzędzia snmpwalk, interpretacji wyników oraz opcji sterowania formatowaniem wyjścia (-O).

Praktyka laboratoryjna i narzędzia

Program `snmpwalk` to najpopularniejsze narzędzie diagnostyczne w arsenale inżyniera sieciowego, automatyzujące pobieranie całych gałęzi bazy MIB.

  • Zasada pętli GetNext: Narzędzie wysyła kolejne zapytania, dopóki zwracane obiekty należą do odpytywanego poddrzewa; po napotkaniu obiektu spoza zakresu program kończy działanie
  • Format numeryczny (-On): Wymusza wyświetlanie pełnych ścieżek kropkowych (np. `.1.3.6.1.2.1.1.1.0`), co uniezależnia parsowanie wyników w skryptach od obecności lokalnych plików MIB
  • Format skrócony i cichy (-Oq / -Ov): Flaga `-Oq` usuwa znaki równości i typy; flaga `-Ov` wyświetla wyłącznie wartość; połączenie `-Oqv` zwraca surowy ciąg gotowy do podstawienia do zmiennej w Bash
  • Pełne nazwy hierarchiczne (-Of): Wyświetla pełną ścieżkę symboliczną od korzenia, np. `.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0`
Przydatna sztuczka w Bash:
Pobranie nazwy routera bezpośrednio do zmiennej środowiskowej:
ROUTER_NAME=$(snmpget -v2c -c public -Oqv 192.168.53.84 sysName.0)
Zmienna $ROUTER_NAME zawiera od razu czysty ciąg tekstowy bez zbędnych białych znaków.
Narzędzie snmpwalk i flagi -O Narzędzie snmpwalk – automatyzacja zrzutu poddrzewa Przegląd flag formatowania wyjścia snmpwalk (-O) # 1. Domyślne wyjście (z prefiksem modułu MIB): $ snmpwalk -v2c -c public srv01 sysName SNMPv2-MIB::sysName.0 = STRING: srv-proxmox-01 # 2. Flaga -On: Wyjście czysto numeryczne (do skryptów automatyzacji): $ snmpwalk -v2c -c public -On srv01 sysName .1.3.6.1.2.1.1.5.0 = STRING: srv-proxmox-01 # 3. Flagi -Oq -Ov: Tylko czysta wartość bez nazw i typów (Quiet Value): $ snmpwalk -v2c -c public -Oqv srv01 sysName.0 srv-proxmox-01 Flagi: -Of (pełna ścieżka) | -Os (skrócona) | -On (numeryczna) | -Oq (cicha)
Slajd 9/55
Odpytywanie interfejsów sieciowych (IF-MIB)
Cel slajdu: Przedstawienie procedury praktycznego mapowania i odpytywania parametrów interfejsów sieciowych w oparciu o standard IF-MIB RFC 2863.

Odpytywanie heterogenicznego sprzętu

Standard IF-MIB (RFC 2863) jest najczęściej wykorzystywaną bazą telemetryczną, dostarczającą kompletnych informacji o kondycji i obciążeniu portów sieciowych.

  • Powiązanie kolumn kluczem ifIndex: Wszystkie tablice (ifName, ifOperStatus, ifHighSpeed, ifHCInOctets) posiadają ten sam numer indeksu; port o ifIndex=1 ma swoją nazwę pod `ifName.1` i status pod `ifOperStatus.1`
  • Status operacyjny vs administracyjny: Rozróżnienie stanu: `ifAdminStatus=1 (up)` i `ifOperStatus=2 (down)` oznacza brak kabla lub awarię łącza fizycznego; `ifAdminStatus=2 (down)` to celowe wyłączenie portu (shutdown)
  • Pobieranie prędkości negocjowanej (ifHighSpeed): Obiekt `ifHighSpeed` zwraca prędkość portu w megabitach na sekundę (np. wartość 1000 oznacza port Gigabit Ethernet, a 10000 to 10 Gbps SFP+)
  • Liczniki błędów transmisji: Obiekty `ifInErrors` (błędy sumy kontrolnej CRC, uszkodzone kable) oraz `ifInDiscards` (odrzucenia z powodu przepełnienia bufora kolejki egress/ingress)
Kluczowa zasada diagnostyki LAN: Jeśli wykres NMS wskazuje zerowy ruch, a użytkownicy zgłaszają awarię, pierwszym krokiem inżyniera jest sprawdzenie ifInErrors. Rosnący licznik błędów CRC niemal zawsze wskazuje na uszkodzenie wkładki optycznej SFP lub zagięcie światłowodu.
Inspekcja portów IF-MIB Praktyczna inspekcja interfejsów (IF-MIB) Odpytanie portów przełącznika L2/L3 w terminalu # 1. Pobranie czytelnych nazw portów (ifName): $ snmpbulkwalk -v2c -c public 192.168.53.84 ifName IF-MIB::ifName.1 = ether1 | IF-MIB::ifName.2 = ether2 | IF-MIB::ifName.3 = wlan1 # 2. Pobranie statusów operacyjnych (1=up, 2=down): $ snmpbulkwalk -v2c -c public 192.168.53.84 ifOperStatus IF-MIB::ifOperStatus.1 = up(1) | IF-MIB::ifOperStatus.2 = down(2) # 3. Odczyt 64-bitowych liczników bajtów wejściowych: $ snmpbulkwalk -v2c -c public 192.168.53.84 ifHCInOctets IF-MIB::ifHCInOctets.1 = Counter64: 8492049182390 bajtów Wskazówka: Indeks za kropką (.1, .2) to unikalny identyfikator ifIndex
Slajd 10/55
Odpytywanie routera MikroTik RouterOS
Cel slajdu: Przedstawienie praktycznego odpytywania specyficznych sensorów sprzętowych i telemetrycznych w systemie MikroTik RouterOS z wykorzystaniem gałęzi PEN 14988.

Odpytywanie heterogenicznego sprzętu

Routery i przełączniki MikroTik udostępniają bogaty zestaw parametrów diagnostycznych w ramach dedykowanego poddrzewa MIKROTIK-MIB (.1.3.6.1.4.1.14988).

  • Sensory sprzętowe (mtxrHealth): Monitorowanie parametrów fizycznych płyty: napięcie zasilania (mtxrHlVoltage, .1.1.3.8), temperatura płyty (mtxrHlTemperature, .1.1.3.10), temperatura procesora (mtxrHlProcessorTemperature, .1.1.3.11) oraz pobór prądu (mtxrHlCurrent, .1.1.3.13)
  • Telemetria radiowa (mtxrWireless): Precyzyjne statystyki interfejsów bezprzewodowych: poziom sygnału klientów (RSSI w dBm), jakość połączenia CCQ oraz liczba retransmisji ramek
  • Liczniki zasobów RouterOS: Zmienne określające wersję oprogramowania RouterOS, model urządzenia RouterBOARD oraz stan pamięci flash
  • Weryfikacja w terminalu RouterOS: Menu `/system health print` pozwala na bezpośrednie porównanie wartości raportowanych przez SNMP z wewnętrznymi odczytami systemu
Skalowanie jednostek w MIB: Wielu producentów zwraca liczby dziesiętne jako liczby całkowite pomnożone przez 10 lub 1000 (np. napięcie 24.2 V jako integer 242, a temperaturę 48.0 °C jako integer 480). System NMS musi zastosować odpowiedni mnożnik (w tym przypadku 0.1) w celu poprawnej prezentacji na wykresie.
Telemetria MikroTik RouterOS Odpytywanie routera MikroTik RouterOS Prywatne OID MikroTik (.1.3.6.1.4.1.14988) # 1. Odczyt napięcia zasilania płyty (w jednostkach 0.1 V): $ snmpget -v2c -c public 192.168.53.84 .1.3.6.1.4.1.14988.1.1.3.8.0 INTEGER: 242 (co oznacza 24.2 V na wejściu DC) # 2. Odczyt temperatury procesora (w jednostkach 0.1 °C): $ snmpget -v2c -c public 192.168.53.84 .1.3.6.1.4.1.14988.1.1.3.11.0 INTEGER: 480 (co oznacza 48.0 °C po przeskalowaniu ×0.1) # 3. Odczyt mocy sygnału klientów Wi-Fi (RSSI): $ snmpwalk -v2c -c public 192.168.53.84 .1.3.6.1.4.1.14988.1.1.1.2.1.3 mtxrWlRtabStrength = -62 dBm (siła sygnału RSSI) Plik definicji: MIKROTIK-MIB.txt (kod IANA PEN = 14988)
Slajd 11/55
Odpytywanie przełącznika zarządzalnego L2/L3
Cel slajdu: Przedstawienie metodyki odpytywania tablicy przełączania FDB w standardzie BRIDGE-MIB RFC 4188 oraz monitorowania zasilania PoE per RFC 3621.

Odpytywanie heterogenicznego sprzętu

Przełączniki zarządzalne warstwy L2/L3 dostarczają kluczowych danych o topologii sieci lokalnej, w tym tablicy skojarzeń adresów MAC z portami fizycznymi.

  • Tablica FDB (RFC 4188): Standard BRIDGE-MIB (dot1dTpFdbTable); pozwala stacji NMS na automatyczne zlokalizowanie, do którego portu przełącznika podłączony jest dany komputer lub drukarka
  • Indeksowanie adresem MAC: Klucz wiersza tabeli składa się z 6 bajtów adresu fizycznego (w zapisie dziesiętnym), a wartością jest numer portu mostu (dot1dBasePort)
  • Monitorowanie Power over Ethernet (RFC 3621): Standard POWER-ETHERNET-MIB udostępnia pobór mocy w watach dla każdego portu oraz bilans zasilacza przełącznika (zapobieganie przeciążeniom PoE budget)
  • Topologia Spanning Tree (STP/RSTP): Nadzór nad stanami portów STP (blocking, forwarding) oraz rejestrowanie pułapek zmian topologii `newRoot` i `topologyChange`
Funkcja Mac-Tracking w NMS: Systemy klasy LibreNMS cyklicznie pobierają tablicę dot1dTpFdbTable ze wszystkich przełączników w firmie. Umożliwia to administratorowi wpisanie w wyszukiwarkę adresu MAC szukanego laptopa i natychmiastowe wskazanie szafy RACK, przełącznika oraz numeru gniazdka na ścianie.
Odpytywanie przełącznika L2/L3 Odpytywanie przełącznika zarządzalnego L2/L3 Tablica FDB (Adresy MAC) • BRIDGE-MIB (RFC 4188) • dot1dTpFdbTable Mapowanie MAC -> Port fizyczny Lokalizacja urządzeń w LAN Zasilanie PoE (POWER-ETHERNET) • RFC 3621 (POWER-ETHERNET-MIB) • pethPsePortDetectionStatus Status PoE portu (brak mocy w [W]) pethMainPsePower [W] - bilans mocy Odczyt tablicy MAC przełącznika w terminalu: $ snmpbulkwalk -v2c -c public sw-core dot1dTpFdbPort dot1dTpFdbPort.0.26.184.22.41.90 = INTEGER: 24 Interpretacja: Adres MAC 00:1a:b8:16:29:5a znajduje się na porcie 24
Slajd 12/55
Odpytywanie drukarki sieciowej (Printer-MIB)
Cel slajdu: Przedstawienie standardu Printer-MIB RFC 3805 służącego do monitorowania materiałów eksploatacyjnych, stanu podajników oraz liczników stron w drukarkach sieciowych.

Odpytywanie heterogenicznego sprzętu

Standard Printer-MIB (RFC 3805) definiuje uniwersalny model nadzoru nad urządzeniami drukującymi i wielofunkcyjnymi (MFP) w przedsiębiorstwie.

  • Poziomy tonerów i tuszy (prtMarkerSuppliesTable): Tabela zawierająca opisy materiałów, ich maksymalną pojemność (MaxCapacity) oraz bieżący poziom (Level) wyrażony w procentach lub liczbie stron
  • Status podajników papieru (prtInputTable): Rejestrowanie dostępności formatów papieru (A4, A3), poziomu zapełnienia kaset oraz sygnalizowanie braku papieru
  • Licznik wydrukowanych stron (prtMarkerLifeCount): Niezawieralny licznik całkowitej liczby wydrukowanych stron od momentu wyprodukowania urządzenia (podstawa rozliczeń kontraktów MPS)
  • Alerty operacyjne (prtAlertTable): Aktywna tabela incydentów: zacięcie papieru (Paper Jam), otwarta pokrywa, zapełniony pojemnik na zużyty toner (Waste Toner Box)
Automatyzacja Managed Print Services (MPS): Integracja systemu NMS z bazą Printer-MIB pozwala na całkowicie automatyczne wysyłanie zgłoszeń do dostawcy materiałów biurowych, gdy poziom czarnego tonera spadnie poniżej 10%, eliminując przestoje w pracy biura.
Standard Printer-MIB Telemetria drukarek sieciowych (RFC 3805) Materiały eksploatacyjne • prtMarkerSuppliesTable • Toner czarny, Cyan, Magenta Poziom max i poziom bieżący Automatyczne zamówienia Podajniki i statusy • prtInputTable (podajniki) • Stan papieru A4/A3 Zacięcie papieru (Paper Jam) Powiadomienia Helpdesk Przykłady odpytania tonera drukarki biurowej: $ snmpwalk -v2c -c public prn01 prtMarkerSuppliesDescription prtMarkerSuppliesDescription.1.1 = STRING: "Black Toner Cartridge" $ snmpget -v2c -c public prn01 prtMarkerSuppliesLevel.1.1 INTEGER: 15 (% pozostałego tonera)
Slajd 13/55
Odpytywanie zasilacza awaryjnego UPS (UPS-MIB)
Cel slajdu: Przedstawienie standardu UPS-MIB RFC 1628 dedykowanego do ciągłego nadzoru nad parametrami zasilania awaryjnego serwerowni i węzłów dystrybucyjnych.

Odpytywanie heterogenicznego sprzętu

Standard UPS-MIB (RFC 1628) to krytyczny element infrastruktury Data Center, zapewniający wczesne ostrzeganie o awariach zasilania podstawowego.

  • Stan baterii (upsBatteryStatus): Wartości wyliczeniowe: unknown(1), batteryNormal(2), batteryLow(3), batteryDepleted(4); stan `batteryLow` wyzwala procedurę bezpiecznego wyłączania serwerów
  • Szacowany czas podtrzymania (upsEstimatedMinutesRemaining): Liczba minut pracy na baterii wyliczana dynamicznie przez procesor UPS-a na podstawie bieżącego poboru mocy
  • Źródło zasilania wyjściowego (upsOutputSource): Informuje, czy serwery są zasilane z sieci miejskiej (normal=3), z baterii falownika (battery=5) czy z toru obejściowego (bypass=4)
  • Utylizacja mocy (upsOutputPercentLoad): Procentowe obciążenie znamionowe zasilacza UPS; przekroczenie progu 80% oznacza brak redundancji N+1
Automatyczny skrypt wyłączania (Graceful Shutdown): Narzędzie NUT (Network UPS Tools) lub moduł w NMS stale odpytuje upsEstimatedMinutesRemaining.0. Gdy wartość spadnie poniżej 10 minut, system wysyła polecenia bezpiecznego zamykania maszyn wirtualnych i macierzy dyskowych.
Standard UPS-MIB RFC 1628 Nadzór nad zasilaczem UPS (RFC 1628) Bateria i akumulatory • upsBatteryStatus (normal/low) • upsEstimatedMinutesRemaining Szacowany czas pracy [minuty] Klucz do procedury shutdown Parametry zasilania AC • upsInputVoltage (napięcie wej.) • upsOutputPercentLoad (obciążenie %) upsOutputSource (normal/battery) Detekcja zaniku zasilania sieci Odczyt parametrów UPS w terminalu: $ snmpget -v2c -c public ups01 upsEstimatedMinutesRemaining.0 UPS-MIB::upsEstimatedMinutesRemaining.0 = INTEGER: 42 minut $ snmpget -v2c -c public ups01 upsOutputPercentLoad.0 UPS-MIB::upsOutputPercentLoad.0 = INTEGER: 34 % obciążenia mocy
Slajd 14/55
Odpytywanie serwera Linux przez snmpd
Cel slajdu: Przedstawienie metodyki monitorowania serwerów operacyjnych Linux za pomocą demona Net-SNMP, łączącej standard RFC 2790 z rozszerzeniami UCD-SNMP-MIB.

Odpytywanie heterogenicznego sprzętu

Serwery z systemem Linux udostępniają metryki telemetryczne dwutorowo: poprzez oficjalny standard HOST-RESOURCES-MIB (RFC 2790) oraz dedykowaną gałąź UCD-SNMP-MIB (.1.3.6.1.4.1.2021).

  • Metryki obciążenia jądra (laTable): Odczyt parametru Load Average z ostatnich 1, 5 i 15 minut (odpowiednik wyniku polecenia `uptime` lub `top` w powłoce)
  • Surowe liczniki procesora (ssCpuRaw): Liczniki typu Counter zliczające jiffy procesora w stanach: User, Nice, System, Idle, Wait-IO; pozwalają na dokładne wyliczenie procentowego zużycia
  • Zarządzanie pamięcią (memTotalReal / memAvailReal): Precyzyjny podział na pamięć fizyczną całkowitą, wolną, bufory jądra oraz pamięć podręczną stron (Page Cache)
  • Monitorowanie demonów (prTable): Możliwość zdefiniowania w `snmpd.conf` dyrektywy `proc nazwa_procesu min max`, co automatycznie generuje alert przy braku procesu w systemie
Load Average przez SNMP: Gałąź .1.3.6.1.4.1.2021.10.1.3 udostępnia Load Average w postaci czytelnego ciągu znaków DisplayString (np. "0.45"), natomiast gałąź .1.3.6.1.4.1.2021.10.1.5 jako liczbę całkowitą przeskalowaną przez 100 (np. 45).
Telemetria Linux snmpd Telemetria serwera Linux przez demona snmpd Standard RFC 2790 (HOST) • hrProcessorLoad per rdzeń • hrStorageTable (RAM/Dysk) Zgodne z Windows i UNIX Metadane systemowe Gałąź UCD-SNMP (.2021) • laLoad (Load Average 1/5/15) • ssCpuRawUser/System/Idle Dedykowane dla jądra Linux Precyzja pomiaru jądra Odczyt parametrów Load Average i pamięci w terminalu: $ snmpwalk -v2c -c public srv01 .1.3.6.1.4.1.2021.10.1.3 UCD-SNMP-MIB::laLoad.1 = "0.25" | laLoad.2 = "0.18" | laLoad.3 = "0.12" $ snmpget -v2c -c public srv01 UCD-SNMP-MIB::memAvailReal.0 INTEGER: 12582912 kB (dostępna wolna pamięć RAM)
Slajd 15/55
Rozszerzenia agenta snmpd: dyrektywa extend/exec
Cel slajdu: Przedstawienie mechanizmu dynamicznego rozszerzania bazy MIB demona snmpd za pomocą dyrektywy extend, integracji ze skryptami powłoki oraz adresacji OID.

Odpytywanie heterogenicznego sprzętu

Dyrektywa `extend` w pakiecie Net-SNMP pozwala na bezproblemowe przekształcenie wyjścia dowolnego programu lub skryptu w standardowy obiekt protokołu SNMP.

  • Zastąpienie przestarzałego 'exec': Nowoczesna dyrektywa `extend` zastępuje stary mechanizm `exec`, tworząc ustrukturyzowaną tabelę obiektów w standardzie NET-SNMP-EXTEND-MIB
  • Pobieranie wyjścia jedno- i wieloliniowego: Tabela `nsExtendOutput1Line` zwraca pierwszą linijkę tekstu ze standardowego wyjścia; tabela `nsExtendOutputFull` udostępnia pełny wieloliniowy zrzut
  • Kod powrotu procesu (Exit Code): Obiekt `nsExtendResult` udostępnia kod wyjścia skryptu (np. 0 dla sukcesu, 1 lub 2 dla ostrzeżeń i błędów w stylu pluginów Nagios)
  • Dynamiczne indeksowanie nazwą: Indeks wiersza w OID jest kodowany z kolejnych wartości ASCII liter nazwy rozszerzenia (np. 'smart_nvme' tworzy ciąg .10.115.109.97.114.116...)
Wydajność i bezpieczeństwo: Skrypt podpięty pod dyrektywę extend wykonuje się w momencie nadejścia zapytania SNMP GET z uprawnieniami użytkownika demona (snmp). Skrypt musi wykonywać się w czasie poniżej 1 sekundy, aby nie wywołać przekroczenia limitu czasu (timeout) u menedżera.
Dyrektywa extend w snmpd Własne metryki przez dyrektywę extend w snmpd 1. Konfiguracja w /etc/snmp/snmpd.conf: # Definicja polecenia o nazwie 'smart_nvme': extend smart_nvme /usr/local/bin/check_nvme_temp.sh # Skrypt check_nvme_temp.sh wypisuje na stdout: "42" sudo systemctl restart snmpd 2. Odpytanie nowej zmiennej przez NMS: # Odpytanie gałęzi nsExtendOutput1Line w NET-SNMP-EXTEND-MIB: $ snmpget -v2c -c public srv01 'NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."smart_nvme"' NET-SNMP-EXTEND-MIB::nsExtendOutput1Line."smart_nvme" = STRING: 42 Adres numeryczny OID: .1.3.6.1.4.1.8072.1.3.2.3.1.1.10.115.109.97.114.116... = "42"
Slajd 16/55
Narzędzie snmptranslate – translacja nazw i numerów OID
Cel slajdu: Przedstawienie narzędzia snmptranslate, opcji badania semantyki obiektów (-Td), wizualizacji drzewa (-Tp) oraz konwersji notacji.

Praktyka laboratoryjna i narzędzia

Program `snmptranslate` służy do tłumaczenia i analizowania struktur bazy MIB bez konieczności nawiązywania jakiejkolwiek komunikacji sieciowej.

  • Translacja dwukierunkowa: Konwersja nazwy tekstowej na numeryczny OID (`-On`) oraz numerycznego OID na przyjazną nazwę symboliczną (`-Os` lub `-Of`)
  • Szczegółowy opis definicji (-Td): Wyświetlenie pełnego bloku metadanych z pliku MIB: typ danych (SYNTAX), prawa dostępu (MAX-ACCESS), status oraz pełny opis słowny (DESCRIPTION)
  • Wizualizacja poddrzewa (-Tp): Generowanie tekstowego drzewa hierarchicznego prezentującego strukturę węzłów, prawa dostępu (-R-- dla read-only, -RW- dla read-write) oraz typy
  • Weryfikacja składni plików MIB: Narzędzie automatycznie sprawdza poprawność nowo dodanych plików MIB i raportuje błędy składniowe ASN.1
Szybka pomoc w konsoli: Nie pamiętasz, czy zmienna liczy bajty czy bity? Wpisz: snmptranslate -Td ifHCInOctets. W sekcji DESCRIPTION natychmiast przeczytasz: "The total number of octets received on the interface...".
Narzędzie snmptranslate Narzędzie snmptranslate – inspekcja drzewa MIB Zaawansowane użycie snmptranslate w terminalu # 1. Konwersja nazwy symbolicznej na numeryczny OID (-On): $ snmptranslate -On -m IF-MIB ifHCInOctets .1.3.6.1.2.1.31.1.1.1.6 # 2. Pełny opis semantyczny obiektu z pliku MIB (-Td): $ snmptranslate -Td -m SNMPv2-MIB sysUpTime SYNTAX: TimeTicks | MAX-ACCESS: read-only | STATUS: current DESCRIPTION: "The time (in hundredths of a second) since network mgmt..." # 3. Rysowanie drzewa podrzędnego w formacie tekstowym (-Tp): $ snmptranslate -Tp -m SNMPv2-MIB system +--system(1) | +-- -R-- String sysDescr(1) | +-- -R-- ObjID sysObjectID(2)...
Slajd 17/55
Zarządzanie plikami MIB w systemie Linux
Cel slajdu: Przedstawienie zasad zarządzania biblioteką plików MIB w systemie Linux, konfiguracji zmiennych środowiskowych MIBDIRS oraz instalacji modułów producenckich.

Praktyka laboratoryjna i narzędzia

Prawidłowa organizacja plików MIB na serwerze zarządzającym gwarantuje czytelność danych i bezbłędne działanie parserów w systemach monitoringu.

  • Lokalizacja systemowa i użytkownika: Katalog ogólnosystemowy `/usr/share/snmp/mibs` oraz prywatny katalog administratora `~/.snmp/mibs`
  • Zmienna środowiskowa MIBDIRS: Definiowanie niestandardowych ścieżek wyszukiwania, np. `export MIBDIRS=+/opt/custom_mibs` (znak `+` oznacza dopisanie do ścieżki domyślnej)
  • Zmienna środowiskowa MIBS: Określa, które moduły mają zostać automatycznie sparsowane; ustawienie `export MIBS=+ALL` nakazuje załadowanie wszystkich plików z katalogów MIB
  • Struktura nagłówka DEFINITIONS: Nazwa pliku na dysku powinna odpowiadać nazwie modułu zdefiniowanej w klauzuli `NAZWA-MIB DEFINITIONS ::= BEGIN` wewnątrz pliku tekstowego
Konflikty zależności (IMPORTS): Jeśli dodany plik MIB zwraca błędy typu Cannot find module (XYZ), oznacza to, że w sekcji IMPORTS odwołuje się do innego pliku MIB, który nie został jeszcze wgrany do katalogu. Należy pobrać i dograć brakujący moduł bazowy.
Zarządzanie plikami MIB Zarządzanie plikami MIB w systemie Linux Ścieżki systemowe MIB • /usr/share/snmp/mibs • ~/.snmp/mibs (użytkownik) Zmienna MIBDIRS steruje katalogami wyszukiwania Sterowanie modułami • export MIBS=+ALL • Flaga: -m +MIKROTIK-MIB Ładowanie konkretnego pliku Rozwiązywanie nazw MIB Instalacja bazy MIB producenta krok po kroku: $ cp MIKROTIK-MIB.txt ~/.snmp/mibs/ $ snmptranslate -m +MIKROTIK-MIB -On mtxrHealth .1.3.6.1.4.1.14988.1.1.3 Baza została pomyślnie załadowana i zindeksowana przez bibliotekę Net-SNMP
Slajd 18/55
Monitorowanie ruchu sieciowego przez SNMP
Cel slajdu: Przedstawienie zasad pomiaru parametrów ruchu sieciowego w standardzie IF-MIB: rozróżnienia kierunków Inbound/Outbound oraz analizy pakietów i bajtów.

Odpytywanie heterogenicznego sprzętu

Podstawowym zadaniem systemu NMS jest precyzyjny pomiar wolumenu danych przepływających przez interfejsy sieciowe w obu kierunkach transmisyjnych.

  • Perspektywa urządzenia (Device Perspective): Kierunek `Inbound (RX)` oznacza ruch wchodzący do urządzenia z medium fizycznego; `Outbound (TX)` oznacza ruch wychodzący z urządzenia do sieci
  • Bajty a pakiety (Octets vs Packets): Pomiar bajtów (`ifHCOctets`) służy do wyliczania przepustowości pasma (bps); pomiar pakietów (`ifPkts`) pozwala na ocenę wydajności przetwarzania (PPS - Packets Per Second)
  • Pakiety rozgłoszeniowe (Broadcast Storm): Gwałtowny wzrost licznika `ifInBroadcastPkts` przy małym wzroście oktetów świadczy o pętli przełączania L2 lub sztormie pakietów ARP/DHCP
  • Odrzucenia wyjściowe (ifOutDiscards): Kluczowy wskaźnik przeciążenia kolejki wyjściowej (egress buffer drop) występujący przy zjawisku mikroszczytów lub asymetrii prędkości łączy
Zasada symetrii na łączu punkt-punkt: Ruch wychodzący (Outbound) z portu routera R1 podłączonego do routera R2 musi być dokładnie równy ruchowi wejściowemu (Inbound) na porcie routera R2. Różnica w licznikach wskazuje na gubienie pakietów na samym kablu lub w medium transmisyjnym.
Metryki ruchu sieciowego Metryki ruchu sieciowego: Inbound vs Outbound Ruch wejściowy (Inbound / RX) ifHCInOctets (.1.3.6.1.2.1.31.1.1.1.6) Suma odebranych bajtów na porcie ifInUcastPkts (.1.3.6.1.2.1.2.2.1.11) Pakiety Unicast (ruch docelowy) ifInNUcastPkts / ifInBroadcastPkts Pakiety rozgłoszeniowe (Broadcast/Multicast) Punkt widzenia: Urządzenie odbiera Ruch wyjściowy (Outbound / TX) ifHCOutOctets (.1.3.6.1.2.1.31.1.1.1.10) Suma wysłanych bajtów z portu ifOutUcastPkts (.1.3.6.1.2.1.2.2.1.17) Pakiety Unicast wysłane w medium ifOutDiscards (.1.3.6.1.2.1.2.2.1.19) Odrzucenia z powodu braku bufora kolejki Punkt widzenia: Urządzenie nadaje
Slajd 19/55
Problem zawijania liczników 32-bitowych (Counter Wrap)
Cel slajdu: Przedstawienie matematycznej analizy problemu zawijania liczników 32-bitowych w sieciach szerokopasmowych oraz uzasadnienie konieczności stosowania standardu IF-MIB.

Obliczenia inżynierskie

Jednym z najpoważniejszych problemów klasycznego monitoringu jest zjawisko przepełnienia 32-bitowych rejestrów liczników bajtów (Counter Wrap) przy standardowych interwałach odpytywania.

  • Pojemność licznika Counter32: Maksymalna wartość wynosi 2^32 - 1 = 4 294 967 295 bajtów (ok. 4.29 GB); po osiągnięciu tej wartości licznik natychmiast wraca do zera
  • Matematyka zawijania przy 1 Gbps: Łącze 1 Gbps przesyła do 125 000 000 bajtów na sekundę; dzieląc 4.29 GB przez 125 MB/s otrzymujemy czas przepełnienia równy zaledwie 34.36 sekundy
  • Konsekwencje dla systemów NMS: Przy standardowym 5-minutowym (300 s) cyklu odpytywania licznik zawija się niemal 9 razy pomiędzy dwiema próbkami; stacja NMS rejestruje fałszywy, zaniżony ułamek ruchu
  • Standardowe rozwiązanie IF-MIB: Przejście na protokół SNMPv2c/v3 oraz odpytywanie liczników 64-bitowych `ifHCInOctets` i `ifHCOutOctets` zdefiniowanych w dokumencie RFC 2863
Praktyczna reguła wdrożeniowa: Dla każdego interfejsu o przepustowości równej lub większej niż 100 Mbps system NMS musi bezwzględnie korzystać z liczników 64-bitowych. Użycie liczników 32-bitowych jest dopuszczalne wyłącznie na wolnych portach szeregowych lub zabytkowych urządzeniach.
Problem Counter Wrap Zjawisko przepełnienia licznika (Counter Wrap) Prędkość łącza Transfer na sekundę Czas zawinięcia (32-bit) Status NMS 10 Mbps 1.25 MB/s ok. 57 minut Bezpieczny 100 Mbps 12.5 MB/s ok. 5.7 minuty Graniczny (300 s) 1 Gbps 125 MB/s zaledwie 34 sekundy! Błędne wykresy 10 Gbps 1.25 GB/s ok. 3,4 sekundy! Całkowity paraliż Rozwiązanie inżynierskie: Standard IF-MIB (RFC 2863) • Liczniki 64-bitowe: ifHCInOctets / ifHCOutOctets (typ Counter64) • Przy pełnym nasyceniu łącza 10 Gbps licznik 64-bitowy zawinie się po... 468 latach!
Slajd 20/55
SNMP w skryptach powłoki Bash – automatyzacja
Cel slajdu: Przedstawienie metodyki tworzenia skryptów powłoki Bash do automatycznego audytu stanu urządzeń sieciowych z wykorzystaniem narzędzi Net-SNMP.

Skrypty i automatyzacja

Powłoka Bash w połączeniu z narzędziami pakietu Net-SNMP pozwala inżynierom na błyskawiczne tworzenie lekkich skryptów monitorujących bez narzutu ciężkich platform.

  • Integracja potoków uniksowych: Połączenie wyjścia `snmpwalk -Oq` z narzędziami `awk`, `grep` i pętlą `while read` do iteracyjnego przetwarzania kolejnych portów urządzenia
  • Pobieranie atrybutów skojarzonych: Dynamiczne wyciąganie numeru indeksu z nazwy zmiennej i odpytywanie skalarne o nazwę portu (`ifName.$IDX`) oraz opis administracyjny (`ifAlias.$IDX`)
  • Obsługa kodów powrotu ($?): Weryfikacja czy polecenie `snmpget` zakończyło się kodem 0; kod różny od zera natychmiast sygnalizuje brak łączności (timeout węzła)
  • Integracja z powiadomieniami: Skrypt może wysłać wiadomość SMS, webhook do systemu Discord/Slack lub wywołać polecenie pocztowe `mail` w przypadku wykrycia awarii
Praktyka administracyjna: Skrypty tego typu są uruchamiane w harmonogramie cron (np. co 1 minutę) na serwerze pomocniczym, realizując niezależny nadzór nad krytycznymi portami magistrali szkieletowej (Uplinks).
Skrypty powłoki Bash i SNMP Automatyzacja diagnostyki w skrypcie Bash Skrypt Bash: check_ports.sh #!/bin/bash TARGET="192.168.53.84"; COMM="public" # Pobranie listy portów i ich stanów za pomocą snmpwalk: snmpwalk -v2c -c "$COMM" -Oq "$TARGET" ifOperStatus | while read -r line; do IDX=$(echo "$line" | awk -F'.' '{print $2}' | awk '{print $1}') STATUS=$(echo "$line" | awk '{print $2}') NAME=$(snmpget -v2c -c "$COMM" -Oqv "$TARGET" "ifName.$IDX") if [ "$STATUS" = "down" ]; then echo "[ALARM] Port $NAME (indeks $IDX) ma stan DOWN!" fi done
Slajd 21/55
Automatyzacja w języku Python – biblioteka pysnmp
Cel slajdu: Przedstawienie programistycznego odpytywania agentów SNMP za pomocą języka Python i nowoczesnej biblioteki pysnmp z interfejsem asyncio (funkcje get_cmd, next_cmd, bulk_cmd).

Skrypty i automatyzacja

Język Python to wiodące środowisko programowania sieciowego (NetDevOps); biblioteka `pysnmp` dostarcza kompletny stos protokołu SNMP z natywną obsługą asynchroniczności asyncio.

  • Nowoczesny interfejs asynchroniczny: Moduł `pysnmp.hlapi.asyncio` udostępnia natywne funkcje asynchroniczne `get_cmd`, `next_cmd`, `bulk_cmd` oraz `set_cmd` ukrywające skomplikowane operacje ASN.1 BER
  • Konstrukcja ObjectIdentity: Elastyczne definiowanie zmiennych: możliwość podania czystego numeru OID (np. `'1.3.6.1.2.1.1.1.0'`) lub nazwy modułu i zmiennej (`'SNMPv2-MIB', 'sysDescr', 0`)
  • Struktura zwracanych wyników: Czwórka zmiennych: `errorIndication` (błąd sieci/transportu), `errorStatus` (błąd z PDU), `errorIndex` oraz lista krotek `varBinds`
  • Formatowanie czytelne (prettyPrint): Metoda `.prettyPrint()` automatycznie formatuje wartości binarne, ciągi znaków, czasy TimeTicks i adresy IP do czytelnej postaci tekstowej
Instalacja biblioteki: Oficjalny pakiet na PyPI nosi nazwę pysnmp (dawny pakiet przejściowy pysnmp-lextudio został oznaczony jako deprecated):
pip install pysnmp
Współczesna biblioteka pysnmp oparta jest na pętli zdarzeń asyncio, co umożliwia równoległe odpytywanie setek urządzeń bez blokowania wątku głównego.
Automatyzacja Python pysnmp (asyncio) Automatyzacja w języku Python (biblioteka pysnmp) Skrypt asynchroniczny Python: snmp_query.py (pysnmp 7.x) import asyncio from pysnmp.hlapi.asyncio import * async def main(): engine = SnmpEngine() errInd, errStat, errIdx, varBinds = await get_cmd( engine, CommunityData('public', mpModel=1), # 1 = SNMPv2c await UdpTransportTarget.create(('192.168.53.84', 161), timeout=2), ContextData(), ObjectType(ObjectIdentity('SNMPv2-MIB', 'sysDescr', 0)) ) if not errInd and not errStat: for vb in varBinds: print(f"{vb[0].prettyPrint()} = {vb[1].prettyPrint()}") engine.close_dispatcher() asyncio.run(main())
Slajd 22/55
Monitorowanie obciążenia procesora (CPU) przez SNMP
Cel slajdu: Przedstawienie zróżnicowania identyfikatorów OID i metod wyliczania obciążenia procesora u czołowych producentów sprzętu sieciowego oraz serwerów.

Telemetria zasobów systemowych

Pomiar obciążenia procesora (CPU Utilization) jest kluczowym wskaźnikiem zdrowia węzła sieciowego, jednak każdy producent implementuje tę metrykę w inny sposób.

  • Cisco Systems (CISCO-PROCESS-MIB): Dedykowana gałąź `.1.3.6.1.4.1.9.9.109`; udostępnia uśrednione obciążenie CPU z ostatnich 5 sekund (`cpmCPUTotal5sec`), 1 minuty oraz 5 minut (`cpmCPUTotal5minRev`)
  • MikroTik RouterOS i Windows: Stosują standard HOST-RESOURCES-MIB (`.1.3.6.1.2.1.25.3.3.1.2`); zwracają wartość procentową z ostatniej minuty niezależnie dla każdego rdzenia procesora
  • Serwery Linux (UCD-SNMP-MIB): Udostępniają zmienne miernikowe `ssCpuUser`, `ssCpuSystem`, `ssCpuIdle` lub surowe liczniki `ssCpuRawUser/System/Idle` zliczające jiffy procesora od startu
  • Rola uśredniania (Smoothing): Chwilowe piki CPU (100% przez 200 ms) są normalne w trakcie obsługi przerwań; alarm w NMS powinien reagować dopiero na średnią 5-minutową przekraczającą 85%
Cisco Data Corruption Trap: W starszych routerach Cisco używano OID cpmCPUTotal5min (zwracał Integer32). W nowszych modelach z procesorami wielordzeniowymi wprowadzono cpmCPUTotal5minRev (Unsigned32), zapobiegając błędom ujemnych wartości.
Monitorowanie CPU przez SNMP Porównanie OID obciążenia procesora (CPU) Cisco IOS / IOS-XE .1.3.6.1.4.1.9.9.109.1.1.1.1.8.1 (cpmCPUTotal5minRev) MikroTik RouterOS .1.3.6.1.2.1.25.3.3.1.2.1 (hrProcessorLoad per rdzeń) Linux (UCD-SNMP) .1.3.6.1.4.1.2021.11.11.0 (ssCpuIdle - bezczynność %) Windows Server .1.3.6.1.2.1.25.3.3.1.2 (HOST-RESOURCES-MIB) Matematyka utylizacji CPU w systemie Linux: Zużycie CPU [%] = 100 - ssCpuIdle.0 Lepsza metoda: delta liczników ssCpuRawUser, ssCpuRawSystem, ssCpuRawIdle Różnica: Uśrednianie sprzętowe vendorów a surowe jiffy jądra Linuksa
Slajd 23/55
Monitorowanie pamięci RAM i przestrzeni SWAP
Cel slajdu: Przedstawienie procedury monitorowania pamięci fizycznej i wymiany, eliminacji pozornych alarmów związanych z buforami linuksowymi oraz analizy tabeli hrStorage.

Telemetria zasobów systemowych

Prawidłowy pomiar zużycia pamięci RAM wymaga rozróżnienia pamięci rzeczywiście wykorzystywanej przez aplikacje od pamięci buforowej jądra systemu operacyjnego.

  • Uniwersalny standard hrStorageTable: W standardzie RFC 2790 pamięć fizyczna RAM jest reprezentowana jako wpis typu `hrStorageRam`, a przestrzeń wymiany jako `hrStorageVirtualMemory`
  • Problem 'Brakującej pamięci' w Linuksie: Jądro Linuksa wykorzystuje każdą nieużywaną pamięć RAM jako pamięć podręczną dysku (Buffer/Cached); prosty odczyt `memFreeReal` wskaże 2% wolnego RAM-u, generując fałszywy alarm
  • Prawidłowa metryka memAvailReal: Zmienna `.1.3.6.1.4.1.2021.4.6.0` zwraca pamięć rzeczywiście dostępną dla nowych procesów (wolną powiększoną o bezpieczny do zwolnienia cache)
  • Monitorowanie nasycenia SWAP: Wzrost wykorzystania pamięci wymiany (Swap) powyżej 20% w połączeniu z intensywną aktywnością dysku jest czytelnym sygnałem zjawiska thrashingu i wyczerpania RAM
Zjawisko Thrashingu pamięci: Stan przeciążenia serwera, w którym system poświęca większość czasu na ciągłe przenoszenie stron pamięci między RAM a dyskiem SWAP, doprowadzając do niemal całkowitego zamrożenia pracy aplikacji.
Monitorowanie RAM i SWAP Telemetria pamięci RAM i przestrzeni wymiany SWAP HOST-RESOURCES-MIB • hrStorageRam (typ pamięci) • hrStorageSize (rozmiar RAM) • hrStorageUsed (zajęty RAM) Uniwersalny dla wszystkich OS Specyfika jądra Linux • memTotalReal (całkowity RAM) • memBuffer / memCached • memAvailReal (dostępny RAM) Uwzględnienie Page Cache Pułapka interpretacji pamięci w systemie Linux: Błędne wyliczenie: Wolny RAM = memFreeReal (ignoruje bufor i pamięć cache!) Prawidłowe: Realnie Dostępny = memFreeReal + memBuffer + memCached W nowoczesnym Net-SNMP dostępna jest gotowa zmienna memAvailReal (.0)
Slajd 24/55
Monitorowanie pamięci masowej i dysków
Cel slajdu: Przedstawienie procedury odpytywania i kalkulacji zajętości systemów plików oraz partycji dyskowych z wykorzystaniem tabeli hrStorageTable RFC 2790.

Telemetria zasobów systemowych

Przepełnienie dysku systemowego lub partycji bazodanowej prowadzi do natychmiastowego paraliżu usług; protokół SNMP umożliwia ciągły nadzór nad pojemnością magazynów.

  • Jednostka alokacji (hrStorageAllocationUnits): Rozmiar pojedynczego bloku w bajtach (zazwyczaj 4096 bajtów); rzeczywisty rozmiar partycji w bajtach to iloczyn liczby bloków i rozmiaru jednostki
  • Pojemność całkowita i wykorzystana: Zmienne `hrStorageSize` (łączna liczba bloków) oraz `hrStorageUsed` (bloki zajęte przez dane)
  • Niezależność od systemu plików: Metoda działa identycznie dla partycji ext4, XFS, Btrfs, ZFS w systemach Linux oraz wolumenów NTFS i ReFS w Windows Server
  • Weryfikacja alokacji w Net-SNMP (dskTable): Alternatywna gałąź UCD-SNMP `.1.3.6.1.4.1.2021.9` udostępniająca bezpośrednio procent zajętości partycji (`dskPercent`)
Krytyczne partycje systemowe: W serwerach Linux szczególnym nadzorem należy objąć partycję /var/log (ryzyko zalania logami przez atak brute-force) oraz /tmp. Zapełnienie partycji głównej / do 100% uniemożliwia zapis plików sesji i paraliżuje bazy danych.
Monitorowanie dysków hrStorage Telemetria partycji dyskowych (hrStorageTable) Odczyt partycji root (/) w terminalu: $ snmpwalk -v2c -c public srv01 hrStorageDescr hrStorageDescr.31 = STRING: "/" | hrStorageDescr.32 = STRING: "/var" $ snmpget -v2c -c public srv01 hrStorageAllocationUnits.31 hrStorageSize.31 hrStorageUsed.31 Units: 4096 B | Size: 24419020 bloków (100 GB) | Used: 18314265 bloków (75 GB) Obliczanie procentu zajętości: Zajętość [%] = (Used / Size) * 100 W przykładzie: (18.3M / 24.4M) = 75% Stan: Prawidłowy (< 85%) Progi alarmowe NMS: • Ostrzeżenie (Warning): >= 80% • Krytyczny (Critical): >= 90% • Zagrożenie awarią: >= 95%
Slajd 25/55
Monitorowanie temperatur i sensorów sprzętowych
Cel slajdu: Przedstawienie zasad monitorowania sensorów środowiskowych: temperatur procesorów, diagnostyki optycznej SFP DDM oraz prędkości wentylatorów.

Telemetria zasobów systemowych

Utrzymanie prawidłowych warunków termicznych i zasilania w szafach serwerowych jest gwarantem bezawaryjnej pracy urządzeń teleinformatycznych.

  • Standard CISCO-ENVMON-MIB: Modelowa implementacja nadzoru środowiskowego: czujniki temperatury wlotowej (Inlet) i wylotowej (Outlet), sensory prędkości obrotowej wentylatorów oraz statusy redundantnych zasilaczy
  • Diagnostyka optyczna SFP DDM (Digital Diagnostic Monitoring): Odczyt mocy optycznej nadawania (TX Power w dBm) i odbioru (RX Power w dBm); spadek mocy odbiorczej poniżej -20 dBm zwiastuje degradację światłowodu
  • Podsystem LM-SENSORS w Linuksie: Moduł `LM-SENSORS-MIB` (.1.3.6.1.4.1.2021.13.16) integrujący odczyty układów scalonych płyty głównej serwera ze stosem SNMP
  • Histereza progów alarmowych: Konieczność stosowania progów z histerezą (np. alert przy 75 °C, odwołanie alertu dopiero przy spadku poniżej 70 °C), aby zapobiec migotaniu powiadomień (alert flapping)
SFP DDM Telemetry: Ciągłe monitorowanie mocy RX na wkładkach 10G/40G/100G pozwala na wykrycie zabrudzenia czoła złącza światłowodowego lub mikropęknięcia włókna na wiele tygodni przed całkowitym przerwaniem transmisji.
Telemetria sensorów sprzętowych Telemetria sensorów sprzętowych i środowiskowych Czujniki temperatury • Temperatura CPU i płyty • Temperatura wkładek SFP DDM Wykrywanie awarii chłodzenia Ochrona termiczna ASIC Wentylatory i zasilacze • Prędkość obrotowa RPM • Status redundancji PSU (RPS) Zanik zasilania na zasilaczu B Alerty prewencyjne Odczyt temperatury SFP i procesora w Cisco / Linux: $ snmpwalk -v2c -c public sw01 CISCO-ENVMON-MIB::ciscoEnvMonTemperatureStatusValue ciscoEnvMonTemperatureStatusValue.1 = INTEGER: 38 (Inlet Temp: 38 °C) ciscoEnvMonTemperatureStatusValue.2 = INTEGER: 52 (HotSpot Temp: 52 °C)
Slajd 26/55
Monitorowanie czasu pracy (sysUpTime) i restartów
Cel slajdu: Przedstawienie mechaniki zmiennej sysUpTime, wykrywania nieplanowanych restartów oraz zjawiska przepełnienia licznika TimeTicks po 497 dniach.

Telemetria zasobów systemowych

Zmienna `sysUpTime` (.1.3.6.1.2.1.1.3.0) jest jedną z najważniejszych metryk diagnostycznych, określającą stabilność pracy urządzenia od ostatniego uruchomienia.

  • Jednostka centisekund (10 ms): Licznik typu TimeTicks zlicza setne części sekundy od momentu zainicjalizowania stosu sieciowego agenta SNMP
  • Algorytm detekcji restartu: Jeśli wartość sysUpTime(T2) < sysUpTime(T1), system NMS natychmiast rejestruje zdarzenie 'Device Reboot' i wysyła powiadomienie o awarii
  • Pułapka 497 dni (TimeTicks Rollover): Ponieważ TimeTicks to 32-bitowa liczba całkowita bez znaku, maksymalna wartość 4 294 967 295 centisekund odpowiada dokładnie 497 dniom, 2 godzinom, 27 minutom i 52 sekundom pracy; po tym czasie licznik przepełnia się i startuje od zera bez restartu sprzętu
  • Rozróżnienie przyczyn w NMS: Zaawansowane platformy (LibreNMS) weryfikują jednoczesny spadek liczników ifInOctets oraz datę utworzenia procesów, eliminując fałszywe alarmy po 497 dniach uptime
Ciekawostka inżynierska: Wiele przełączników i routerów pracujących bezawaryjnie w serwerowniach po 497 dniach pracy wyzwalało fałszywe alarmy w systemach NOC. Z tego powodu w standardzie SNMPv2 wprowadzono dodatkowe liczniki czasowe w sekundach, np. hrSystemUptime w HOST-RESOURCES-MIB.
Czas pracy sysUpTime Detekcja restartów i specyfika licznika sysUpTime Jednostka TimeTicks • Setne części sekundy (10 ms) • Wartość 100 = dokładnie 1 sekunda • Wartość 8640000 = 1 dzień (24h) Precyzyjny znacznik czasu Problem 497 dni (Rollover) • Rejestr 32-bit TimeTicks • Max: 4 294 967 295 centisekund • Zawinięcie po 497.1 dniach! Fałszywy alert o restarcie Jak NMS odróżnia realny restart od zawinięcia 497 dni? 1. Realny restart: sysUpTime spada do zera ORAZ zerują się liczniki interfejsów 2. Urządzenie wysyła asynchroniczną pułapkę coldStart / warmStart 3. Sprawdzenie hrSystemUptime (RFC 2790) lub sysUpTime w 64-bitach
Slajd 27/55
Odczyt tablicy ARP i mapowanie adresów IP do MAC
Cel slajdu: Przedstawienie procedury pobierania tablicy translacji adresów ARP (ipNetToMediaTable) za pomocą protokołu SNMP oraz jej roli w inwentaryzacji IPAM.

Telemetria sieciowa i routing

Tablica ARP routera pozwala na jednoznaczne powiązanie logicznego adresu warstwy sieciowej (IP) z fizycznym adresem karty sieciowej (MAC).

  • Tabela ipNetToMediaTable (RFC 1213): Standardowa tablica MIB-II odwzorowująca pamięć podręczną ARP urządzenia; klucz indeksu składa się z numeru interfejsu ifIndex oraz adresu IPv4
  • Struktura zwracanego adresu MAC: Wartość zmiennej `ipNetToMediaPhysAddress` ma typ OCTET STRING; w zależności od konfiguracji klienta wyświetlana jest jako ciąg heksadecymalny lub dwukropkowy MAC
  • Nowoczesne rozszerzenie RFC 4293: Tablica `ipNetToPhysicalTable` zastępująca MIB-II, zapewniająca jednolitą obsługę adresów IPv4 i IPv6 oraz wpisów sąsiedztwa NDP (Neighbor Discovery Protocol)
  • Integracja IPAM (IP Address Management): Systemy NMS pobierają tablice ARP z bram domyślnych, budując aktualną bazę wykorzystania podsieci firmowych
Korelacja ARP + FDB w systemie NMS:
1. Router podaje: 192.168.1.50 -> 00:11:22:33:44:55 (z tablicy ARP)
2. Switch podaje: 00:11:22:33:44:55 -> Port 14 (z tablicy FDB)
W efekcie NMS natychmiast wie, do którego fizycznego portu podłączony jest dany adres IP!
Tablica ARP w SNMP Odczyt tablicy ARP przez SNMP (ipNetToMediaTable) Odpytanie tablicy ARP routera w terminalu: $ snmpbulkwalk -v2c -c public 192.168.53.84 ipNetToMediaPhysAddress ipNetToMediaPhysAddress.2.192.168.53.50 = STRING: 00:1a:b8:16:29:5a ipNetToMediaPhysAddress.2.192.168.53.97 = STRING: b8:27:eb:41:88:12 Struktura OID: [ kolumna ] . [ ifIndex ] . [ adres IPv4 ] = [ adres MAC ] Typ wpisu ARP: • ipNetToMediaType: dynamic(3) - z protokołu ARP static(4) - wpis statyczny Zastosowanie NMS: • Inwentaryzacja IP/MAC (IPAM) • Wykrywanie obcych stacji • Lokalizacja urządzeń w sieci
Slajd 28/55
Odczyt tablicy routingu IP przez SNMP
Cel slajdu: Przedstawienie procedury monitorowania tablicy tras routingu IP za pomocą standardu MIB-II oraz nowocześniejszego standardu IP-FORWARD-MIB RFC 4292.

Telemetria sieciowa i routing

Stan tablicy routingu (FIB/RIB) decyduje o kierunku przesyłania pakietów przez węzeł sieciowy; monitorowanie tras przez SNMP pozwala na natychmiastowe wykrycie awarii łączy tranzytowych.

  • Klasyczna tablica ipRouteTable: Standard RFC 1213; kolumny: `ipRouteDest` (sieć docelowa), `ipRouteNextHop` (adres kolejnego skoku), `ipRouteMask` (maska sieciowa), `ipRouteMetric1` (metryka)
  • Detekcja trasy domyślnej: Odpytanie instancji `ipRouteNextHop.0.0.0.0` zwraca bieżący adres IP bramy wyjściowej do sieci Internet; zmiana tego adresu świadczy o zadziałaniu protokołu failover
  • Protokół pochodzenia trasy (ipRouteProto): Wskazuje źródło trasy: local(2), netmgmt(3) (trasy statyczne / zarządcy sieci), icmp(4), ospf(13), bgp(14); pozwala na weryfikację czy sesje protokołów dynamicznych działają poprawnie
  • Nowoczesna tablica inetCidrRouteTable (RFC 4292): Zastępuje starszą tablicę, dodając pełną obsługę notacji bezklasowej CIDR oraz tras protokołu IPv6
Wydajność na routerach BGP: Na routerze brzegowym pobierającym pełną tablicę routingu internetowego (Full BGP Table liczącą ponad 950 000 tras!) wykonanie polecenia snmpwalk ipRouteTable doprowadzi do natychmiastowego przeciążenia procesora i pamięci RAM. W takich węzłach należy monitorować wyłącznie stan sesji w BGP4-MIB!
Tablica routingu w SNMP Odczyt tablicy routingu IP (RFC 1213 / RFC 4292) Odpytanie tablicy routingu (ipRouteTable): $ snmpbulkwalk -v2c -c public router01 ipRouteNextHop ipRouteNextHop.0.0.0.0 = 195.114.20.1 (Brama domyślna Default Gateway) ipRouteNextHop.10.0.0.0 = 10.255.0.2 (Trasa do sieci wewnętrznej) Indeks OID = docelowy adres sieci (ipRouteDest, np. .0.0.0.0) Standardy MIB routingu: • RFC 1213: ipRouteTable • RFC 4292: inetCidrRouteTable Pełna obsługa tras bezklasowych Zastosowanie diagnostyczne: • Weryfikacja obecności łącza backup • Wykrywanie pętli routingu • Badanie metryki tras (ipRouteMetric)
Slajd 29/55
Monitorowanie wirtualnych sieci LAN (VLAN)
Cel slajdu: Przedstawienie standardu Q-BRIDGE-MIB RFC 4363 definiującego reprezentację sieci VLAN IEEE 802.1Q oraz mapowania portów w maskach bitowych.

Telemetria sieciowa i routing

Wirtualne sieci lokalne (VLAN) stanowią podstawę segmentacji bezpieczeństwa w architekturze kampusowej; ich stan jest odzwierciedlony w standardzie Q-BRIDGE-MIB (RFC 4363).

  • Identyfikacja VLAN (dot1qVlanStaticTable): Tabela przechowująca nazwy symboliczne sieci VLAN (`dot1qVlanStaticName`), indeksowana bezpośrednio numerem VLAN ID (od 1 do 4094)
  • Maska portów wyjściowych (EgressPorts): Pole typu OCTET STRING traktowane jako wektor bitowy; każdy bit odpowiada kolejnemu numerowi portu przełącznika; wartość 1 oznacza przynależność portu do VLAN
  • Rozróżnienie portów tagowanych i dostępowych: Porównanie masek `dot1qVlanCurrentEgressPorts` (wszystkie porty) oraz `dot1qVlanCurrentUntaggedPorts` (porty dostępowe Access) pozwala stwierdzić, które porty pracują w trybie Trunk (802.1Q)
  • Wykrywanie niespójności konfiguracji: NMS porównuje konfigurację VLAN na obu końcach łącza trunk, wykrywając błędy typu Native VLAN Mismatch
Cisco Community String Indexing: W przełącznikach Cisco klasyczna tablica BRIDGE-MIB wymaga dodania numeru VLAN do community string (tzw. community@vlan), np. snmpwalk -v2c -c public@10 sw01 dot1dTpFdbPort w celu odpytania tablicy MAC konkretnego VLAN 10!
Monitoring VLAN Q-BRIDGE-MIB Telemetria wirtualnych sieci LAN (Q-BRIDGE-MIB) Standard Q-BRIDGE (RFC 4363) • dot1qVlanCurrentTable • dot1qVlanStaticName Nazwy i identyfikatory VLAN ID IEEE 802.1Q w SNMP Mapowanie portów (Bitmask) • dot1qVlanCurrentEgressPorts • dot1qVlanCurrentUntaggedPorts Maska bitowa portów członkowskich Porty Trunk vs Access Odczyt nazw sieci VLAN na przełączniku: $ snmpbulkwalk -v2c -c public sw01 dot1qVlanStaticName dot1qVlanStaticName.10 = "VLAN_BIURO" | dot1qVlanStaticName.20 = "VLAN_SERWERY" dot1qVlanStaticName.99 = "VLAN_ZARZADZANIE" Indeks OID (.10, .20, .99) odpowiada 12-bitowemu numerowi VLAN ID (VID)
Slajd 30/55
Monitorowanie punktów dostępowych Wi-Fi
Cel slajdu: Przedstawienie metodyki monitorowania sieci bezprzewodowych WLAN, kontrolerów WLC oraz analizy jakości środowiska radiowego (RSSI, SNR, Channel Utilization).

Telemetria sieciowa i routing

Sieci bezprzewodowe Wi-Fi wymagają specyficznego nadzoru łączącego klasyczne metryki przepustowości z parametrami propagacji fal radiowych.

  • Architektura kontrolera (WLC): W nowoczesnych sieciach korporacyjnych SNMP odpytuje centralny kontroler bezprzewodowy (Wireless LAN Controller), który agreguje dane z setek punktów AP
  • Zajętość kanału radiowego (Channel Utilization): Procentowy wskaźnik czasu, w którym kanał radiowy jest zajęty przez transmisje własne lub obce; wartość powyżej 70% oznacza drastyczny spadek prędkości transmisji
  • Jakość sygnału klienta (RSSI i SNR): Received Signal Strength Indicator (wartości typowe od -40 dBm do -85 dBm); stacje ze słabym sygnałem (< -75 dBm) spowalniają całą komórkę radiową
  • Wykrywanie 'lepkich klientów' (Sticky Clients): Sytuacja, w której laptop pracownika pozostaje połączony z odległym punktem dostępowym z miniaturową prędkością zamiast przełączyć się na najbliższy AP
Standard IEEE 802.11 MIB: Oficjalny standard IEEE802dot11-MIB definiuje podstawowe statystyki, jednak czołowi producenci (Cisco AireOS/Catalyst 9800, Aruba, Ruckus, MikroTik) udostępniają znacznie bogatsze metryki w swoich prywatnych bazach MIB.
Telemetria sieci Wi-Fi Telemetria sieci bezprzewodowych Wi-Fi Parametry środowiska radiowego • Poziom szumu tła (Noise Floor) • Wykorzystanie kanału (Channel Load %) Zaszumienie pasma 2.4 GHz i 5 GHz Optymalizacja planu radiowego Metryki stacji klienckich • Liczba klientów per AP / SSID • Poziom sygnału RSSI w dBm Stosunek sygnału do szumu (SNR) Wykrywanie 'Sticky Clients' Przykłady odpytania kontrolera Wi-Fi w terminalu: $ snmpget -v2c -c public wlc01 bsnDot11EssNumberOfActiveClients.1 INTEGER: 28 (aktywnych stacji w sieci SSID "Firma-WiFi") $ snmpget -v2c -c public wlc01 bsnAPOperationStatus.1 INTEGER: operational(1) (punkt dostępowy w pełni operacyjny)
Slajd 31/55
Zdalne zarządzanie przez SNMP SET w praktyce
Cel slajdu: Przedstawienie praktycznych scenariuszy operacji modyfikacji parametrów (SNMP SET), automatyzacji kwarantanny portów oraz rygorystycznych zasad bezpieczeństwa.

Zarządzanie i konfiguracja

Mimo że odczyt dominuje w monitoringu, operacja SET znajduje zastosowanie w systemach kontroli dostępu do sieci (NAC) oraz automatyzacji usuwania awarii.

  • Automatyczna kwarantanna portu (NAC): System bezpieczeństwa (np. SIEM) po wykryciu ataku wysyła zapytanie `snmpset ... ifAdminStatus.X i 2`, natychmiast odcinając zainfekowany komputer od sieci lokalnej
  • Restart zasilania kamery / telefonu (PoE Cycle): Modyfikacja zmiennej `pethPsePortAdminEnable` w celu chwilowego wyłączenia i włączenia zasilania PoE zablokowanej kamery przemysłowej
  • Aktualizacja opisów portów (ifAlias): Synchronizacja dokumentacji systemów NetBox/DCIM z przełącznikami; skrypt automatycznie aktualizuje nazwy portów na podstawie bazy danych
  • Rygorystyczne wymagania bezpieczeństwa: Operacja SET może być uruchomiona wyłącznie w standardzie SNMPv3 authPriv z uwierzytelnianiem SHA-2 i szyfrowaniem AES oraz zawężonym widokiem VACM
Zagrożenie braku audytowalności: Pamiętaj, że protokół SNMP sam w sobie nie zapisuje w logach, który administrator zmodyfikował port. W środowiskach spełniających normę ISO/IEC 27001 operacje rekonfiguracji należy realizować za pośrednictwem systemów z pełnym logowaniem sesji (SSH / TACACS+ / RADIUS).
Praktyka operacji SNMP SET Scenariusze zdalnego zarządzania (SNMP SET) Praktyczne wywołania snmpset w terminalu: # 1. Zmiana opisu portu (ifAlias) na przełączniku: $ snmpset -v3 -u admin -l authPriv -a SHA-256 -A pass1 -x AES -X pass2 \ sw01 ifAlias.12 s "Uplink_Do_Serwera_WWW" # 2. Awaryjny restart urządzenia (reboot OID producenta): $ snmpset -v3 -u admin -l authPriv ... router01 .1.3.6.1.4.1.14988.1.1.7.1.0 i 1 Wymogi bezpieczeństwa: • WYŁĄCZNIE SNMPv3 authPriv • Dedykowane konto z rouser/rwuser • Bezwzględny zakaz w v1/v2c! Zastosowania operacyjne: • Zdalna kwarantanna portu (NAC) • Reset zablokowanego portu PoE • Automatyczna dokumentacja sieci
Slajd 32/55
Powiadomienia asynchroniczne: SNMP TRAP kontra INFORM
Cel slajdu: Przedstawienie architektury powiadomień asynchronicznych (TRAP vs INFORM wg RFC 3416) oraz prawidłowej konfiguracji wysyłki zdarzeń w MikroTik RouterOS.

Raportowanie zdarzeń

W protokole SNMP zdarzenia asynchroniczne mogą być wysyłane jako bezpotwierdzeniowe pułapki (TRAP) lub niezawodne powiadomienia z potwierdzeniem (INFORM).

  • SNMP TRAP (RFC 1157 / RFC 3416): Jednokierunkowy pakiet UDP (port 162). Agent wysyła powiadomienie bez oczekiwania na potwierdzenie; w przypadku awarii sieci lub zatoru bufora NMS pakiet ginie bezpowrotnie
  • SNMP INFORM (RFC 3416): Asynchroniczne powiadomienie niezawodne (InformRequest-PDU). Odbiornik NMS natychmiast odsyła pakiet `Response-PDU`; w razie braku ACK agent ponawia próby wysyłki (retransmisje)
  • Konfiguracja w Net-SNMP: Dyrektywy `trapsink` (v1), `trap2sink` (v2c), `informsink` (v2c/v3 INFORM z oczekiwaniem na ACK) oraz uniwersalna `trapsess` (dla sesji SNMPv3 authPriv)
  • Konfiguracja w MikroTik RouterOS: Aktywacja w menu `/snmp`: parametry `trap-target`, `trap-community`, `trap-generators` oraz `trap-interfaces` (ograniczenie generowania linkUp/linkDown do portów magistralnych)
Testowanie wysyłki zdarzeń w laboratorium:
Na routerze MikroTik przełączenie portu: /interface ethernet disable ether1 i enable ether1 wyzwala pułapki linkDown/linkUp. Z kolei z poziomu Linuksa wysyłkę powiadomienia INFORM z oczekiwaniem na potwierdzenie testuje się poleceniem: snmpinform -v2c -c public 192.168.53.50 0 linkUp ifIndex.1 i 1.
SNMP TRAP vs INFORM i konfiguracja RouterOS Konfiguracja zdarzeń w MikroTik RouterOS i model TRAP/INFORM [admin@MikroTik-GW] > /snmp (Konfiguracja pułapek) # 1. Konfiguracja wysyłki pułapek ze wskazaniem serwera i interfejsów: /snmp set enabled=yes \ trap-target=192.168.53.50 trap-community=v3-mon trap-version=2 \ trap-generators=interfaces,start-trap \ trap-interfaces=ether1,sfp-sfpplus1 # 2. Porównanie mechanizmów powiadamiania (RFC 3416): • SNMP TRAP: Agent -> NMS [UDP 162] (brak potwierdzenia, ryzyko utraty pakietu) • SNMP INFORM: Agent -> NMS [InformRequest] ; NMS -> Agent [Response-PDU / ACK] (w razie braku ACK agent dokonuje retransmisji po upływie czasu timeout) # 3. Testowanie wysyłki INFORM z konsoli Linuksa do odbiornika: $ snmpinform -v2c -c public 192.168.53.50 0 linkUp ifIndex.1 i 1 Weryfikacja w RouterOS: /snmp print (weryfikacja stanu licznika trap-sent)
Slajd 33/55
Odbiór i parsowanie pułapek oraz powiadomień INFORM: demon snmptrapd
Cel slajdu: Przedstawienie procedury wdrożenia demona snmptrapd w systemie Linux, konfiguracji uprawnień authCommunity (v1/v2c) i authUser (v3), formatowania logów oraz skryptów reakcji traphandle.

Raportowanie zdarzeń

Demon `snmptrapd` jest centralnym odbiornikiem zdarzeń SNMP w środowisku Linux, odpowiedzialnym za dekodowanie pakietów UDP 162 (TRAP i INFORM) oraz automatyczne potwierdzanie żądań InformRequest.

  • Uprawnienia wspólnot (authCommunity): Dotyczy wyłącznie SNMPv1/v2c: definiuje dozwolone społeczności i uprawnienia: `log` (zapis w logach), `execute` (wywołanie skryptu traphandle), `net` (przekazywanie dalej)
  • Bezpieczeństwo SNMPv3 (createUser i authUser): Dla SNMPv3 dyrektywa `authCommunity` nie wystarcza – konieczne jest zdefiniowanie użytkownika (`createUser -e ...`) oraz dyrektywy `authUser log,execute priv`
  • Formatowanie logów (format1 i format2): Dyrektywa `format1` formatuje pułapki SNMPv1 (znaczniki specyficzne: `%N` Enterprise OID, `%W` opis, `%q` kod podtypu), natomiast `format2` formatuje zdarzenia SNMPv2c/v3 Trap oraz INFORM (`%v` wersja, `%B` host nadawcy, `%N` OID zdarzenia, `%W` lista VarBinds)
  • Wykonywanie akcji (traphandle): Uruchamianie zewnętrznego programu po dopasowaniu OID zdarzenia (np. `IF-MIB::linkDown` lub `default`); demon przekazuje na standardowe wejście (stdin) hosta, IP oraz wszystkie pary OID-wartość
Automatyczne potwierdzanie INFORM: Gdy demon snmptrapd odbierze pakiet InformRequest-PDU, po zweryfikowaniu uprawnień natychmiast generuje i odsyła do nadawcy pakiet Response-PDU z tym samym request-id, dzięki czemu agent wie, że alert został zarejestrowany.
Konfiguracja demona snmptrapd (TRAP / INFORM) Konfiguracja i przetwarzanie w demonie snmptrapd Konfiguracja /etc/snmp/snmptrapd.conf (v1, v2c, v3 INFORM) # 1. Autoryzacja: authCommunity (v1/v2c) oraz authUser (v3): authCommunity log,execute,net public v3-mon authUser log,execute secUser priv # 2. Definicja skryptu reakcji na spadek łącza (linkDown): traphandle IF-MIB::linkDown /usr/local/bin/handle_linkdown.sh # 3. Formatowanie logów dla SNMPv2c/v3 i INFORM (format2): format2 [%v] Od: %B | Typ: %N | Zmienne: %W # 4. Demon i test odbioru INFORM (automatyczna odpowiedź Response-PDU): sudo systemctl enable --now snmptrapd $ snmpinform -v2c -c public 127.0.0.1 0 linkUp ifIndex.1 i 1 # snmptrapd automatycznie odsyła ACK (Response-PDU); brak retransmisji
Slajd 34/55
Skalowalność zapytań SNMP – odpytywanie setek urządzeń
Cel slajdu: Przedstawienie wyzwań skalowalności systemów NMS, zjawiska opóźnienia cyklu (Poller Lag) oraz architektury wieloprocesowej i rozproszonej.

Zaawansowane architektury i wydajność

Wraz ze wzrostem monitorowanej sieci z kilkunastu do tysięcy węzłów, kluczowym wyzwaniem inżynierskim staje się zmieszczenie całego cyklu odpytywania w zadanym oknie czasowym.

  • Zjawisko opóźnienia pollera (Poller Lag): Sytuacja, w której czas potrzebny na odpytanie wszystkich węzłów przekracza zaplanowany interwał (np. trwa 340 sekund przy oknie 300 sekund); prowadzi to do kumulacji zaległych zadań i dziur w wykresach
  • Architektura wieloprocesowa (Worker Pool): Rozbicie kolejki urządzeń na dziesiątki niezależnych procesów wykonawczych (np. 16 lub 32 procesy poller-service w LibreNMS)
  • Rozproszone pollery (Distributed Pollers): Instalacja lokalnych serwerów zbierających dane w odległych lokalizacjach i przesyłających zagregowane wyniki do centralnej bazy danych
  • Optymalizacja silnika (C vs Python/PHP): Zastosowanie skompilowanych demonów w języku C (np. `spine` w Cacti) drastycznie redukuje zużycie CPU serwera NMS względem skryptów interpretowanych
Poller Lag: Opóźnienie startu kolejnego cyklu próbkowania spowodowane zbyt długim wykonywaniem poprzedniego. Jest to podstawowy wskaźnik przeciążenia stacji NMS wymagający optymalizacji liczby wątków lub dodania drugiego serwera pollerów.
Skalowalność SNMP Poller Lag Architektura skalowalnego odpytywania (Poller Lag) Model jednowątkowy • 500 urządzeń x 1 sekunda • Czas cyklu: 500 sekund • Przekroczenie okna 300 s! Zjawisko Poller Lag Pula wątków (Worker Pool) • 32 równoległe procesy robocze • Kolejka zadań w Redis • Czas cyklu: zaledwie 18 s! Skalowalność do 10 000 węzłów Metody optymalizacji wielkich instalacji NMS: 1. Rozproszone pollery (Distributed Polling) w oddziałach firmy 2. Adaptacyjny timeout: 1 s dla LAN, 3 s dla łączy satelitarnych/WAN 3. Spine Poller (napisany w C) w Cacti zamiast interpretera PHP
Slajd 35/55
Wizualizacja danych SNMP – wprowadzenie do wykresów
Cel slajdu: Przedstawienie zasad przechowywania i wizualizacji danych telemetrycznych za pomocą biblioteki RRDtool oraz mechanizmów konsolidacji czasowej.

Wizualizacja i platformy NMS

Surowe liczby zwracane przez SNMP są trudne w interpretacji; biblioteka RRDtool (Round Robin Database) stanowi fundament generowania wykresów czasowych.

  • Koncepcja bufora kołowego (Round Robin Database): Plik bazy `.rrd` ma stałą, z góry zdefiniowaną wielkość od momentu utworzenia; nowe próbki nadpisują najstarsze, gwarantując brak niekontrolowanego rozrostu bazy na dysku
  • Typy źródeł danych (Data Sources - DS): Obsługa typów `COUNTER` (automatyczne liczenie pochodnej Delta/Delta_Time), `GAUGE` (wartości bieżące, np. temperatura) oraz `DERIVE`
  • Archiwa konsolidacji (Round Robin Archives - RRA): Wraz z upływem czasu szczegółowe próbki 5-minutowe są agregowane w średnie 30-minutowe, 2-godzinne i dobowe
  • Funkcje konsolidacji (CF - Consolidation Functions): `AVERAGE` (wartość średnia dla trendów), `MAX` (rejestrowanie maksymalnych pików pasma) oraz `MIN`
Dlaczego RRDtool a nie baza SQL? Baza relacyjna (MySQL/PostgreSQL) przy milionach próbek telemetrycznych wymagałaby gigabajtów przestrzeni i indeksów dyskowych. Plik RRD ma stałą wagę (np. 300 kB per port) i stały czas zapisu O(1) niezależnie od tego, czy działa od roku, czy od 10 lat.
Architektura RRDtool Architektura baz czasowych RRDtool Bufor kołowy (Round Robin) • Stały rozmiar pliku na dysku • Nowe dane nadpisują najstarsze Brak ryzyka przepełnienia dysku Pliki bazy: *.rrd Konsolidacja danych (RRA) • Dane 5 min: przez 2 dni • Średnia 30 min: przez 2 tygodnie • Średnia 2 h: przez 1 rok Funkcje: AVERAGE, MAX, MIN Zasada działania RRDtool (Round Robin Database Tool): 1. RRDtool przyjmuje próbki liczników Counter64 i sam wylicza bps (Data Source: COUNTER) 2. Automatycznie interpoluje brakujące próbki w przypadku chwilowych opóźnień 3. Generuje gotowe wykresy PNG wykorzystywane w Cacti, LibreNMS i MRTG
Slajd 36/55
Klasyczne narzędzie MRTG (Multi Router Traffic Grapher)
Cel slajdu: Przedstawienie historii, architektury i zasad działania narzędzia MRTG, protoplasty współczesnych systemów wizualizacji ruchu sieciowego.

Wizualizacja i platformy NMS

Stworzony w 1995 roku przez Tobiasa Oetikera program MRTG (Multi Router Traffic Grapher) zdefiniował współczesny standard prezentacji ruchu sieciowego.

  • Architektura działania: Skrypt w języku Perl uruchamiany z harmonogramu `cron` co 5 minut; odpytuje router przez SNMP, wylicza przepustowość i generuje statyczne pliki graficzne PNG
  • Automatyczny generator cfgmaker: Narzędzie sondujące urządzenie sieciowe i automatycznie tworzące plik konfiguracyjny ze wszystkimi wykrytymi interfejsami
  • Kanon kolorystyczny wykresów: Wprowadzenie standardu branżowego: wypełniony kolor zielony oznacza ruch wejściowy (Inbound), a niebieska linia oznacza ruch wyjściowy (Outbound)
  • Cztery horyzonty czasowe: Stały układ czterech wykresów: dobowy (Daily Graph), tygodniowy (Weekly Graph), miesięczny (Monthly Graph) oraz roczny (Yearly Graph)
Opcja growright: W pierwotnej wersji MRTG wykresy rysowały się od prawej do lewej strony. Opcja growright odwróciła ten kierunek, sprawiając, że oś czasu biegnie naturalnie od lewej do prawej, co stało się standardem we wszystkich późniejszych narzędziach.
Klasyczne narzędzie MRTG Klasyczne narzędzie MRTG (Multi Router Traffic Grapher) Konfiguracja generatora cfgmaker w terminalu: # 1. Automatyczne przeskanowanie routera i generowanie mrtg.cfg: cfgmaker --global 'WorkDir: /var/www/html/mrtg' \ --global 'Options[_]: bits,growright' \ public@192.168.53.84 > /etc/mrtg/mrtg.cfg Cztery horyzonty czasowe: • Wykres dobowy (Daily: 5 min) • Wykres tygodniowy (Weekly: 30 min) • Wykres miesięczny (Monthly: 2 h) • Wykres roczny (Yearly: 1 dzień) Kolorystyka standardu MRTG: • Zielony (Green): Ruch wejściowy (In) • Niebieski (Blue): Ruch wyjściowy (Out) Kanon wizualizacji stosowany do dziś we wszystkich panelach NMS
Slajd 37/55
System Cacti – graficzny interfejs dla SNMP i RRDtool
Cel slajdu: Przedstawienie architektury systemu Cacti, hierarchii szablonów telemetrycznych oraz różnic wydajnościowych między pollerem cmd.php a wielowątkowym Spine.

Wizualizacja i platformy NMS

System Cacti stanowi jedno z najbardziej cenionych otwartoźródłowych narzędzi telemetrycznych, integrujące protokół SNMP z silnikiem bazy RRDtool i interfejsem graficznym WWW.

  • Hierarchia szablonów (Templates): Rozdział logiki na szablony urządzeń (Device Templates), źródeł danych (Data Templates) oraz prezentacji graficznej (Graph Templates)
  • Silniki odpytujące (Pollers): Podstawowy skrypt `cmd.php` (sekwencyjny, wolniejszy) vs wielowątkowy demon w języku C `spine` (zdolny do zebrania dziesiątek tysięcy OID w kilkanaście sekund)
  • Drzewo prezentacji (Graph Tree): Elastyczna organizacja wykresów w wielopoziomowe drzewa według lokalizacji fizycznej, oddziałów przedsiębiorstwa lub ról sieciowych
  • Automatyzacja odkrywania: Moduł Network Discovery skanujący zadane podsieci IP, identyfikujący typ sprzętu i automatycznie aplikujący odpowiednie szablony wykresów
Wdrożenie produkcyjne Spine: W środowiskach powyżej 50 monitorowanych urządzeń użycie polleru spine jest koniecznością. Dzięki bezpośredniemu wykorzystaniu bibliotek net-snmp i wielowątkowości POSIX Threads drastycznie redukuje zużycie pamięci i czas cyklu odpytywania.
System Cacti i silnik Spine Architektura systemu Cacti i pollerów telemetrii 1. Konfiguracja • Baza MySQL/MariaDB • Szablony urządzeń • Drzewo Graph Tree 2. Silnik odpytujący • cmd.php (skrypt PHP) • Spine (demon w C) • Wątki POSIX pthreads 3. Składowanie i UI • Pliki baz RRDtool • Generowanie PNG/SVG • Interfejs WWW PHP Porównanie pollerów Cacti: cmd.php vs Spine Cecha architektoniczna cmd.php (Domyślny) Spine (Zalecany produkcyjnie) Język implementacji Skrypt interpretowany PHP Skompilowany kod w C Wielowątkowość Jednowątkowy / procesowy Wielowątkowy (pthreads) Wydajność (10 000 OID) Czas wykonania > 300 s (lag) Czas wykonania < 15 s Spine eliminuje opóźnienia pollerów (poller overrun) w sieciach szkieletowych.
Slajd 38/55
Studium przypadku: Kompletne odpytanie routera brzegowego
Cel slajdu: Przećwiczenie całościowej procedury inspekcji parametrów routera brzegowego (Cisco ASR / MikroTik CCR) za pomocą zapytań SNMP.

Scenariusze wdrożeniowe i diagnostyka

Wprowadzenie nowego routera brzegowego do systemu monitoringu wymaga weryfikacji tożsamości, zasobów sprzętowych, integralności interfejsów transmisyjnych oraz sesji BGP z dostawcami ISP.

  • Identyfikacja i czas pracy: Odczyt `sysDescr.0`, `sysName.0` oraz `sysUpTime.0` w celu potwierdzenia wersji systemu operacyjnego i braku nieplanowanych restartów
  • Obciążenie węzła (CPU i RAM): Odpytanie tablicy `cpmCPUTotalTable` (Cisco) lub `hrProcessorTable` oraz analiza wykorzystania pamięci operacyjnej
  • Interfejsy transmisyjne i DDM: Odczyt liczników 64-bitowych z `ifXTable` oraz parametrów diagnostyki optycznej DDM (moc odbiorcza Rx i nadawcza Tx we wkładkach SFP+)
  • Status protokołu BGP: Weryfikacja tabeli `bgpPeerTable` (RFC 1657 / BGP4-MIB), gdzie wartość `bgpPeerState = 6 (established)` potwierdza pełną łączność
Weryfikacja sesji BGP: Zmienna bgpPeerState (OID 1.3.6.1.2.1.15.3.1.2) przyjmuje wartości od 1 (idle) do 6 (established). Wartość 6 oznacza pełną wymianę tablic routingu z sąsiadem eBGP.
Audyt routera brzegowego Procedura audytu routera brzegowego krok po kroku 1. Identyfikacja sysDescr.0 Wersja OS sysUpTime.0 Czas stabilności SNMPv2-MIB 2. Wydajność CPU 1m / 5m cpmCPUTotal Pamięć RAM hrStorageTable Zasoby węzła 3. Optyka DDM Moc Rx / Tx Wkładki SFP+ Błędy CRC ifInErrors / FCS Warstwa fizyczna 4. Sesje BGP bgpPeerState Stan 6 = Estab Czas sesji bgpEstablished BGP4-MIB # 1. Sprawdzenie stanu sesji BGP do operatora nadrzędnego (ISP) $ snmpwalk -v2c -c secret 195.187.245.1 bgpPeerState BGP4-MIB::bgpPeerState.195.187.245.2 = INTEGER: established(6) # 2. Odczyt mocy optycznej portu uplink 10G SFP+ (RouterOS CCR) $ snmpget -v2c -c secret 195.187.245.1 1.3.6.1.4.1.14988.1.1.19.1.1.10.1 iso.3.6.1.4.1.14988.1.1.19.1.1.10.1 = INTEGER: -4720 # -4.72 dBm (Prawidłowy)
Slajd 39/55
Praktyczny skrypt monitorujący stan interfejsów
Cel slajdu: Implementacja i omówienie działania autonomicznego skryptu Bash wykrywającego awarie portów i wysyłającego powiadomienia Webhook.

Skrypty i automatyzacja

Autonomiczne skrypty w powłoce Bash pozwalają na natychmiastowe wykrywanie nieprawidłowości na przełącznikach bez konieczności wdrażania rozbudowanych systemów centralnych.

  • Pobranie statusów ifOperStatus: Zastosowanie `snmpwalk` z flagami `-Onqe` (numeryczne OID, skrócony format, numeryczne wartości wyliczeniowe) gwarantuje uzyskanie czystych liczb (`1 = up`, `2 = down`)
  • Mapowanie indeksów na nazwy: Wyciąganie czytelnych nazw interfejsów (`ifDescr` lub `ifAlias`) za pomocą `snmpget -Oqv` wyłącznie dla portów wykazujących status błędu
  • Filtracja stanów operacyjnych: Weryfikacja warunku arytmetycznego: status `1 = up`, status `2 = down`, status `6 = notPresent`
  • Powiadomienie Webhook (REST): Automatyczna wysyłka ładunku JSON za pomocą polecenia `curl` do zdefiniowanego adresu `WEBHOOK_URL` w komunikatorze NOC (Mattermost, Slack lub MS Teams)
Flagi formatowania net-snmp: Flagi -Onqe (Numeric OID, Quick print, Numeric Enum) eliminują przedrostki tekstowe i nazwy wyliczeniowe, zwracając pary .1.3.6.1.2.1.2.2.1.8.1 1. Z kolei snmpget -Oqv zwraca samą surową wartość ciągu (np. GigabitEthernet0/1), co pozwala na bezpośrednie przypisanie wyniku do zmiennej powłoki bez użycia awk czy sed.
Skrypt monitorujący interfejsy Architektura skryptu powłoki badającego stany portów 1. Odpytanie SNMP • snmpwalk -Onqe • Czyste pary OID i int 2. Pętla i warunek • while read -r OID STAT • [ "$STATUS" -ne 1 ] 3. Akcja alertowa • snmpget -Oqv ifDescr • cURL POST Webhook #!/bin/bash # check_ports.sh - Weryfikacja stanu portów przełącznika L2 HOST="192.168.1.2"; COMM="public" WEBHOOK_URL="https://hooks.slack.com/services/T00/B00/X00" snmpwalk -v2c -c "$COMM" -Onqe "$HOST" ifOperStatus | while read -r OID STATUS; do IDX=${OID##*.} if [ "$STATUS" -ne 1 ]; then NAME=$(snmpget -v2c -c "$COMM" -Oqv "$HOST" ifDescr."$IDX") curl -s -X POST -H "Content-Type: application/json" \ -d "{\"text\":\"Awaria portu $NAME (idx:$IDX, status:$STATUS)\"}" "$WEBHOOK_URL" fi; done
Slajd 40/55
Praktyczny skrypt monitorujący nasycenie łącza WAN
Cel slajdu: Zaprogramowanie i omówienie skryptu wyliczającego utylizację procentową łącza w czasie rzeczywistym z obsługą progów alarmowych.

Skrypty i automatyzacja

Zabezpieczenie przed saturacją łącza internetowego wymaga wyliczania chwilowej utylizacji pasma na podstawie dwóch próbek 64-bitowych liczników `ifHCInOctets`.

  • Próbkowanie dwupunktowe: Odczyt wartości licznika w chwili t1, odczekanie stałego interwału Δt = 10 s i ponowny odczyt w chwili t2
  • Matematyka przepływności: Ruch w bitach na sekundę: bps = ((Octets₂ - Octets₁) × 8) / Δt
  • Wyliczenie nasycenia procentowego: Wskaźnik obciążenia: Utylizacja (%) = (bps / Przepustowość) × 100%
  • Generowanie alertu: Weryfikacja warunku przekroczenia progu bezpieczeństwa (> 85%) i zapis zdarzenia przez `logger` do podsystemu Syslog
Wybór interwału pomiarowego: Zbyt krótki interwał (np. 1 sekunda) powoduje duże błędy pomiarowe wynikające z fluktuacji opóźnień sieciowych (jitter). Interwał 10 sekund stanowi optymalny kompromis między szybkością detekcji a stabilnością wyniku.
Kalkulacja nasycenia pasma Kalkulacja utylizacji łącza w skrypcie Bash Pomiar w chwilach t1 i t2 t1: Octets1 = 120 500 000 000 Odczekanie interwału: sleep 10 t2: Octets2 = 121 625 000 000 Matematyka przepustowości Delta = 1 125 000 000 bajtów bps = (Delta * 8) / 10 s = 900 Mbps Łącze 1 Gbps -> Nasycenie = 90.0% # Obliczenie utylizacji łącza z użyciem kalkulatora bc IN_1=$(snmpget -v2c -c "$COMM" -Oqv "$IP" ifHCInOctets."$IDX") sleep 10 IN_2=$(snmpget -v2c -c "$COMM" -Oqv "$IP" ifHCInOctets."$IDX") # Przeliczenie bitów na sekundę i porównanie z progiem 85% BPS=$(echo "scale=2; ($IN_2 - $IN_1) * 8 / 10" | bc) SPEED=1000000000; UTIL=$(echo "scale=1; ($BPS / $SPEED) * 100" | bc) [ $(echo "$UTIL > 85.0" | bc) -eq 1 ] && logger -p local0.warn "WAN OVERLOAD: $UTIL%"
Slajd 41/55
Wykrywanie awarii portu w czasie rzeczywistym
Cel slajdu: Połączenie techniki odpytywania cyklicznego z modelem sterowanym zdarzeniami w celu natychmiastowej reakcji na awarie fizyczne L1/L2.

Scenariusze wdrożeniowe i diagnostyka

Poleganie wyłącznie na cyklicznym odpytywaniu (np. co 300 sekund) powoduje nieakceptowalne opóźnienia w detekcji przerw w łączności. Rozwiązaniem jest model hybrydowy z pułapkami SNMP.

  • Pułapka linkDown (RFC 2863): Zdarzenie sprzętowe wyzwalane przez kontroler PHY natychmiast po zaniku nośnej optycznej lub elektrycznej (Loss of Carrier)
  • Zmienne powiązane pułapki: Pakiet pułapki niesie precyzyjne zmienne: `ifIndex`, `ifAdminStatus` oraz `ifOperStatus = down(2)`
  • Weryfikacja dwukierunkowa: Serwer NMS po odebraniu pułapki natychmiast wykonuje celowane zapytanie `snmpget`, eliminując fałszywe alarmy
  • Korelacja z pakietami tranzytowymi: Weryfikacja, czy utrata linku fizycznego zbiega się z natychmiastowym zatrzymaniem przyrostu liczników `ifInUcastPkts`
Standard RFC 2863 (IF-MIB): Zgodnie ze standardem, pułapka linkDown powinna być wysyłana tylko wtedy, gdy stan administracyjny ifAdminStatus interfejsu to up(1), a stan operacyjny ifOperStatus ulega awaryjnemu przejściu do stanu down(2).
Korelacja zdarzeń w czasie rzeczywistym Korelacja pułapek linkDown z odpytywaniem cyklicznym Przełącznik L2/L3 • Port Gi1/0/1 • Utrata nośnej L1 • Wyzwolenie Trapa Zdarzenie hardware Czas: 0.001 s Kanał SNMP (UDP) • Trap: linkDown OID: 1.3.6.1.6.3.1.1.5.3 • ifIndex: 1 • ifOperStatus: down(2) Port UDP 162 Serwer NMS / Korelator 1. Odbiór pułapki 2. Celowane snmpget 3. Badanie ifInErrors 4. Generowanie incydentu P1 Detekcja w < 200 ms! Dlaczego sam Polling (np. co 5 minut) to za mało? • Klasyczny polling zauważa awarię ze średnim opóźnieniem równym połowie interwału (2.5 minuty). • Pułapka linkDown (RFC 2863) informuje o przerwaniu kabla w czasie poniżej 1 sekundy. • Model hybrydowy (Event-Driven Polling) łączy szybkość pułapek z niezawodnością cyklicznego odpytywania.
Slajd 42/55
Optymalizacja parametrów zapytań SNMP
Cel slajdu: Prawidłowy dobór parametrów timeout, retries, non-repeaters oraz max-repetitions w celu eliminacji zatorów i fałszywych alarmów.

Architektura i wydajność

Domyślna konfiguracja narzędzi SNMP rzadko odpowiada wymogom sieci produkcyjnych. Błędny dobór czasów oczekiwania prowadzi do blokowania procesów pollerowych.

  • Czas oczekiwania (Timeout -t): Parametr określający czas oczekiwania na pakiet odpowiedzi; w stabilnej sieci LAN powinien wynosić 1-2 sekundy, na łączach WAN/VPN 3-5 sekund
  • Liczba powtórzeń (Retries -r): Domyślna wartość w Net-SNMP to 5 prób, co przy awarii hosta generuje ogromne opóźnienia; w sieciach korporacyjnych zaleca się 1-2 próby
  • Rozmiar paczki GETBULK (-Cr): Parametr max-repetitions określa ile wierszy agent zwraca w jednej odpowiedzi; zalecana wartość to 20-30 wierszy
  • Zabezpieczenie przed błędem tooBig: Zbyt wysoka wartość max-repetitions (np. 100) powoduje przekroczenie lokalnego bufora agenta lub limitu komunikatu menedżera (maxMsgSize / msgMaxSize), generując błąd `tooBig` lub niepożądaną fragmentację pakietów UDP
Strojenie wiersza poleceń: Dodanie flag -t 1.5 -r 1 do poleceń w skryptach diagnostycznych zapobiega zjawisku zawieszania się konsoli w przypadku niedostępności odpytywanego urządzenia.
Optymalizacja parametrów SNMP Parametry wydajnościowe klienta SNMP i pollerów NMS Timeout (-t) • LAN: 1 - 2 sekundy • WAN/VPN: 3 - 5 sekund • Satelita: 8 - 10 sekund Czas oczekiwania na PDU Retries (-r) • Domyślnie: 5 powtórzeń • Zalecane w LAN: 1 - 2 • Unikanie blokad wątków Liczba retransmisji UDP Max-Repetitions (-Cr) • GETBULK: 20 - 30 wierszy • Zbyt duże (>80): błąd tooBig • Limit bufora / maxMsgSize Wielkość paczki masowej Skutki błędnego doboru parametrów w dużej skali Konfiguracja nieoptymalna (timeout=5s, retries=5; domyślnie 1s/5): Przy awarii 1 hosta klient czeka: 5s + (5 * 5s) = 30 sekund! 100 martwych hostów blokuje poller na 50 minut. Konfiguracja profesjonalna (timeout=1.5s, retries=1): Maksymalny czas oczekiwania na brakujący węzeł: 1.5s + 1.5s = 3 sekundy. Poller natychmiast przechodzi dalej. Właściwe parametry eliminują lawinowe opóźnienia pollerów (poller lag).
Slajd 43/55
Drzewo decyzyjne diagnostyki problemów SNMP
Cel slajdu: Opanowanie metodyki diagnozowania problemów z łącznością SNMP od warstwy L3 przez filtry L4 aż po reguły widoków VACM.

Scenariusze wdrożeniowe i diagnostyka

Komunikat Timeout: No Response from <host> jest najczęstszym problemem w pracy z SNMP. Usystematyzowana procedura pozwala na szybką identyfikację przyczyny awarii.

  • Krok 1: Weryfikacja warstwy sieciowej (L3): Wykonanie testu ICMP ping i badanie routingu powrotnego; brak odpowiedzi ping oznacza problem z kablem, portem lub trasą IP
  • Krok 2: Weryfikacja warstwy transportowej (L4): Sprawdzenie, czy port UDP 161 nie jest blokowany przez zapory sieciowe (firewall, iptables, listy ACL routera)
  • Krok 3: Weryfikacja Community String i USM: Błędna społeczność lub niezgodne hasło autoryzacji w SNMPv3 powoduje ciche odrzucenie pakietu przez agenta bez żadnego komunikatu zwrotnego
  • Krok 4: Weryfikacja uprawnień i widoków VACM: Sprawdzenie, czy żądany OID znajduje się w zdefiniowanym dla danej grupy widoku MIB (`view systemview included ...`)
Zjawisko Silent Drop: Ze względów bezpieczeństwa agenci SNMP nie odsyłają pakietu ICMP Port Unreachable ani odpowiedzi z kodem błędu, jeśli ciąg Community String jest niepoprawny. Zapobiega to ułatwianiu ataków słownikowych napastnikom.
Drzewo diagnostyki problemów Algorytm rozwiązywania błędu: Timeout: No Response Krok 1: L3 ICMP Ping? Routing IP? Krok 2: L4 Port UDP 161? Zapora / ACL? Krok 3: Auth Community OK? USM v3 Auth/Priv? Krok 4: MIB/VACM Widok VACM? OID istnieje? Objawy, przyczyny i polecenia diagnostyczne Brak odpowiedzi na Ping (L3): Problem z trasą IP, interfejs w stanie down. Polecenie: ping -c 3 $IP oraz traceroute $IP. Ping działa, brak odpowiedzi SNMP (L4 / Firewall): Blokada UDP 161 na firewallu lub liście ACL w routerze. Test: nc -z -v -u $IP 161 lub nmap -sU -p 161 $IP. Błędna społeczność (Community String) / Ciche odrzucenie: Agent nie odsyła błędu, lecz po cichu upuszcza pakiet (Silent Drop)! Weryfikacja pliku konfiguracyjnego agenta. Odpowiedź noSuchName / noSuchObject: Agent działa poprawnie, lecz dany OID nie jest zaimplementowany w MIB producenta lub wykluczony w VACM.
Slajd 44/55
SNMP w środowisku heterogenicznym
Cel slajdu: Zrozumienie wyzwań związanych z integracją urządzeń różnych producentów w jednym systemie NMS i rola warstwy abstrakcji.

Architektura i wydajność

W rzeczywistych sieciach korporacyjnych infrastruktura składa się ze sprzętu wielu dostawców, co wymusza radzenie sobie z rozbieżnościami w implementacji baz MIB.

  • Zmienne uniwersalne vs producenckie: Standardowe MIB-II (RFC 1213) oraz IF-MIB (RFC 2863) działają na każdym sprzęcie, lecz metryki sprzętowe są unikalne
  • Cisco Systems: Metryki obciążenia procesora w `CISCO-PROCESS-MIB` (OID `.1.3.6.1.4.1.9.9.109`), sensory temperatur w `CISCO-ENTITY-SENSOR-MIB`
  • MikroTik RouterOS: Struktura prywatna pod OID `.1.3.6.1.4.1.14988`, specyficzne gałęzie dla napięcia zasilania, temperatur i licencji systemowych
  • Serwery Linux (Net-SNMP): Wykorzystanie gałęzi `UCD-SNMP-MIB` (OID `.1.3.6.1.4.1.2021`) oraz standardu `HOST-RESOURCES-MIB` (RFC 2790)
Profile urządzeń w NMS: Nowoczesne platformy telemetryczne (np. LibreNMS) rozwiązują ten problem za pomocą plików definicji YAML. Na podstawie ciągu sysDescr system automatycznie dobiera odpowiedni zestaw OID dla procesora, pamięci i sensorów.
Środowisko heterogeniczne Integracja urządzeń wielu producentów w jednym panelu NMS Cisco Systems • CISCO-PROCESS-MIB • cpmCPUTotal5minRev • ENTITY-SENSOR-MIB OID: .1.3.6.1.4.1.9... MikroTik RouterOS • MIKROTIK-MIB • mtxrHlTemperature • hrProcessorLoad OID: .1.3.6.1.4.1.14988... Linux (Net-SNMP) • UCD-SNMP-MIB • ssCpuIdle / laLoad • HOST-RESOURCES-MIB OID: .1.3.6.1.4.1.2021... Warstwa normalizacji danych w systemie NMS (np. LibreNMS) • Wykrywanie systemu (OS Detection): Analiza ciągu sysDescr.0 przypisuje urządzeniu dedykowany profil. • Standaryzacja jednostek: Przeliczanie dziesiątych części stopnia (0.1 C w MikroTik) na stopnie Celsjusza. • Wspólne zmienne MIB-II: Wszystkie urządzenia współdzielą tablice ifTable, ifXTable oraz ipNetToMediaTable. Dzięki warstwie abstrakcji administrator widzi jednolity wykres CPU niezależnie od producenta sprzętu.
Slajd 45/55
Audyt bezpieczeństwa SNMP w sieci lokalnej
Cel slajdu: Opanowanie technik audytu podatności konfiguracji SNMP z użyciem narzędzi Nmap i onesixtyone oraz formułowanie zaleceń utwardzających.

Bezpieczeństwo i audyt

Pozostawienie domyślnych haseł `public` lub `private` oraz brak filtracji portu UDP 161 stanowi krytyczną podatność umożliwiającą wrogi rekonesans infrastruktury teleinformatycznej.

  • Skanowanie Nmap NSE: Polecenie `nmap -sU -p 161 --script snmp-info,snmp-brute` pozwala na jednoczesną detekcję aktywnych agentów i testowanie słownikowe społeczności
  • Narzędzie onesixtyone: Wysoko wydajny skaner wysyłający zapytania równolegle do setek adresów IP na sekundę z minimalnym narzutem czasowym
  • Zagrożenia Community Write: Wykrycie społeczności `private` z uprawnieniami zapisu (RW) pozwala napastnikowi na zmianę konfiguracji tras, restart urządzenia lub wyłączenie portów
  • Zalecenia utwardzające (Hardening): Wyłączenie SNMPv1/v2c, wdrożenie SNMPv3 (SHA-256 + AES-256), restrykcje ACL oraz odizolowanie zarządzania w dedykowanym Out-of-Band (OOB) VLAN
Wymogi dyrektywy NIS 2: Zgodnie z europejską dyrektywą NIS 2 oraz normą ISO/IEC 27001, stosowanie nieszyfrowanych protokołów zarządzania (takich jak SNMPv1/v2c) w publicznych i krytycznych sieciach produkcyjnych bez separacji sieciowej jest traktowane jako niezgodność audytowa.
Audyt bezpieczeństwa SNMP Metodyka audytu podatności konfiguracji SNMP w LAN 1. Rekonesans Nmap • nmap -sU -p 161 • --script snmp-info • --script snmp-brute Wyszukiwanie agentów 2. Narzędzie onesixtyone • onesixtyone -c dict.txt • Szybki audyt słownikowy • Wykrywanie public/private Setki hostów / sekundę 3. Utwardzanie (Hardening) • Migracja do SNMPv3 • SHA-256 + AES-256 • OOB Management VLAN Standardy ISO 27001 # Skanowanie sieci pod kątem domyślnych społeczności SNMP $ onesixtyone -c /usr/share/doc/onesixtyone/dict.txt 192.168.1.0/24 192.168.1.1 [public] Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M) 192.168.1.50 [private] HP LaserJet 400 M401dne (Zagrożenie modyfikacji!) # Zalecenie naprawcze: całkowite wyłączenie SNMPv1/v2c i blokada ACL (config)# no snmp-server community public (config)# snmp-server community SilneHaslo123# RO 10 # Dostęp tylko z ACL 10
Slajd 46/55
Projektowanie planu adresacji OID dla sieci korporacyjnej
Cel slajdu: Opracowanie spójnej matrycy telemetrycznej określającej zbiór odpytywanych OID oraz częstotliwość ich pobierania.

Architektura i wydajność

Chaotyczne odpytywanie wszystkich dostępnych OID prowadzi do przeciążenia procesorów urządzeń i bazy danych NMS. Niezbędna jest zdefiniowana matryca telemetryczna.

  • Poziom 1: Metryki krytyczne (Interwał 30-60 s): Dostępność L3, statusy portów rdzeniowych `ifOperStatus` oraz liczniki pasma łączy tranzytowych
  • Poziom 2: Zasoby sprzętowe (Interwał 5 min): Obciążenie procesora (CPU), zajętość pamięci RAM, temperatury płyty głównej i prędkości obrotowe wentylatorów
  • Poziom 3: Topologia i tablice L2/L3 (Interwał 1 h): Pobieranie tablic ARP (`ipNetToMedia`), tablic przełączania FDB (`dot1dTpFdbTable`) i powiązań VLAN
  • Poziom 4: Inwentaryzacja i sprzęt (Interwał 24 h): Odczyt numerów seryjnych modułów z `ENTITY-MIB`, wersji systemów operacyjnych oraz dat ważności licencji
Zasada minimalizmu telemetrycznego: Nie odpytuj zmiennych, które nie podlegają monitorowaniu alertowemu ani długoterminowemu planowaniu pojemności (capacity planning). Zmniejsza to obciążenie pollerów i sieci o ponad 70%.
Matryca telemetryczna OID Matryca telemetryczna i planowanie interwałów odpytywania Poziom 1: 30 s Stan łączy (L1/L2) ifOperStatus Ruch rdzeniowy ifHCInOctets Alerty natychmiastowe Poziom 2: 5 min Zasoby węzła CPU 5m, RAM Sensory sprzętu Temperatura, Fan Baza RRDtool Poziom 3: 1 h Topologia L2/L3 Tablice ARP Tablice FDB (MAC) VLAN, Routing Inwentaryzacja Poziom 4: 24 h Asset Tracking Numery seryjne ENTITY-MIB Wersje Firmware Audyt licencji Zasady optymalizacji matrycy telemetrycznej • Hierarchizacja interwałów: Odpytywanie tablicy FDB lub numerów seryjnych co 30 sekund to kardynalny błąd projektowy! • Ochrona procesora agenta: Procesory wbudowane w przełączniki dostępowe mają ograniczoną moc obliczeniową. • Kalkulacja IOPS bazy danych: 1 000 portów odpytywanych co 5 minut generuje stabilne, przewidywalne obciążenie I/O. Wdrożenie matrycy redukuje ruch telemetryczny w sieci szkieletowej o ponad 75%.
Slajd 47/55
SNMP a nowoczesne API urządzeń sieciowych (REST / JSON)
Cel slajdu: Porównanie protokołu SNMP z nowoczesnymi programowalnymi interfejsami API (RESTCONF, RouterOS REST API) opartymi na formacie JSON.

Nowoczesne trendy i alternatywy

Ewolucja w kierunku programowalnych sieci SDN i automatyzacji spowodowała rozwój interfejsów opartych na protokole HTTP/TLS i formacie JSON, stanowiących alternatywę dla SNMP.

  • RESTCONF (RFC 8040): Standard IETF (RFC 8040) mapujący modele danych YANG na operacje HTTP (GET, POST, PUT, PATCH, DELETE) z kodowaniem JSON
  • MikroTik RouterOS REST API: Wprowadzone w RouterOS v7 natywne API HTTPS pozwalające na odczyt i zmianę konfiguracji za pomocą prostych zapytań cURL
  • Struktury danych: OID vs JSON: Numeryczne OID w SNMP (wymagające parsowania MIB) vs czytelne dla człowieka obiekty klucz-wartość JSON
  • Analiza wydajności i narzutu: Lekkie pakiety binarne UDP w SNMP (kilkadziesiąt bajtów) vs narzut sesyjny TCP, negocjacja TLS i tekstowe nagłówki HTTP w REST API
Zapytanie REST API w RouterOS v7:
curl -k -u admin:haslo -X GET https://192.168.1.1/rest/system/resource
Zwraca czytelny obiekt JSON ze zużyciem CPU, pamięci RAM i czasem pracy bez konieczności kompilacji plików MIB.
SNMP vs REST API Porównanie architektoniczne: SNMP vs REST API / JSON Protokół SNMP (v2c / v3) • Transport: UDP port 161 (lekki, bezstanowy) • Format: Binarny ASN.1 BER (mały narzut) • Adresowanie: Numeryczne OID (wymaga MIB) • Zastosowanie: Masowy polling tysięcy portów Zaleta: Minimalny narzut sieciowy i CPU RESTCONF / REST API (JSON) • Transport: HTTPS / TCP 443 (sesyjny TLS) • Format: Tekstowy JSON / XML (czytelny) • Adresowanie: URI (/rest/system/resource) • Zastosowanie: Automatyzacja, Ansible, CI/CD Zaleta: Natywna integracja w Python / REST Porównanie narzutu transmisyjnego dla pojedynczej metryki • SNMP GetResponse: Rozmiar ramki Ethernet: ok. 72 bajty (brak negocjacji TCP/TLS). • REST API over HTTPS: Rozmiar transmisji: handshake TLS (ok. 3-5 KB) + nagłówki HTTP + JSON = > 1 200 bajtów. • Wniosek inżynierski: REST API dominuje w konfiguracji i provisioning, a SNMP w telemetrii masowej. Standardy IETF: RFC 8040 (RESTCONF) oraz RFC 7950 (Język modelowania danych YANG).
Slajd 48/55
Telemetria gNMI vs SNMP w nowoczesnych centrach danych
Cel slajdu: Przedstawienie protokołu gNMI jako następcy SNMP w środowiskach wieloskalowych sieci hyperscale i centrach danych AI/ML.

Nowoczesne trendy i alternatywy

W nowoczesnych centrach danych z łączami 100G/400G/800G model odpytywania okresowego (Pull) protokołu SNMP staje się wąskim gardłem. Zastępuje go strumieniowa telemetria gNMI.

  • Model Pull (SNMP) vs Push (gNMI): W gNMI to urządzenie sieciowe samo nieprzerwanie wypycha dane do kolektora z zadaną częstotliwością, bez czekania na zapytania
  • Protokół gRPC i HTTP/2: Wykorzystanie trwałego połączenia TCP/TLS z multipleksacją wielu strumieni danych telemetrycznych w ramach jednej sesji
  • Serializacja Protocol Buffers: Zastosowanie binarnego kodowania Protobuf, znacznie wydajniejszego obliczeniowo i sieciowo niż ASN.1 BER protokołu SNMP
  • Tryb subskrypcji On-Change: Możliwość zdefiniowania subskrypcji zdarzeniowej, w której router przesyła dane wyłącznie w momencie zmiany stanu interfejsu lub tabeli
OpenConfig i gNMI: Inicjatywa zapoczątkowana przez największych operatorów chmurowych (Google, Microsoft, Meta), mająca na celu stworzenie zunifikowanych, niezależnych od producenta modeli danych YANG dla całej telemetrii sieciowej.
Telemetria gNMI vs SNMP Telemetria strumieniowa gNMI vs SNMP w centrach danych Model Pull: Protokół SNMP • Serwer NMS cyklicznie odpytuje węzeł • Zapytanie GET -> Odpowiedź RESPONSE • Ziarnistość pomiaru: 1 - 5 minut • Brak detekcji mikro-burstów Ograniczenie wydajnościowe CPU przełącznika Model Push: Telemetria gNMI • Przełącznik strumieniuje dane do kolektora • Trwały strumień gRPC over HTTP/2 • Ziarnistość: sub-sekundowa (np. 100 ms) • Subskrypcja On-Change (tylko zmiany) Sprzętowa akceleracja w układach ASIC Kluczowe innowacje technologii gNMI / OpenConfig • Serializacja Protocol Buffers (protobuf): Ekstremalnie kompaktowy, binarny format danych Google. • Subskrypcja On-Change: Brak zbędnych zapytań o porty, na których nic się nie dzieje – przesyłane są tylko zmiany. • Wykrywanie zjawiska microburst: Umożliwia rejestrację przeciążeń buforów kolejkowych trwających milisekundy. Zastosowanie: Sieci szkieletowe Hyperscale, klastry sztucznej inteligencji (AI/ML) i DC 400G/800G.
Slajd 49/55
Kompilacja i instalacja niestandardowych plików MIB
Cel slajdu: Praktyczne opanowanie procedury instalacji, walidacji narzędziem smilint i rozwiązywania zależności w plikach MIB producentów sprzętu.

Administracja i konfiguracja

Urządzenia sieciowe dostarczają dedykowane pliki MIB opisujące ich specyficzne funkcje. Ich prawidłowa instalacja w systemie zarządzającym jest warunkiem poprawnej translacji OID.

  • Lokalizacja plików MIB w Linuksie: Standardowe katalogi systemowe `/usr/share/snmp/mibs` oraz katalog użytkownika `~/.snmp/mibs`; sterowanie zmienną `MIBDIRS`
  • Klauzula IMPORTS w ASN.1: Każdy plik MIB importuje typy bazowe z innych modułów; brak pliku bazowego (np. `SNMPv2-SMI` lub `IF-MIB`) uniemożliwia parsowanie
  • Walidacja składniowa smilint: Wykorzystanie narzędzia `smilint -m -s -l 5 MIB.txt` do weryfikacji zgodności ze standardem SMIv2 i wykrywania błędów syntaktycznych
  • Aktywacja w pliku snmp.conf: Dodanie dyrektywy `mibs +NAZWA-MODULU` w `/etc/snmp/snmp.conf` lub ustawienie zmiennej środowiskowej `export MIBS=+NAZWA`
Pakiet smi-tools: W systemach Debian/Ubuntu narzędzie smilint instalowane jest poleceniem sudo apt-get install smi-tools. Pozwala ono na błyskawiczne wykrycie brakujących zależności MIB przed wdrożeniem do NMS.
Instalacja plików MIB Procedura instalacji i rozwiązywania zależności w plikach MIB 1. Kopiowanie pliku • /usr/share/snmp/mibs • lub ~/.snmp/mibs • export MIBDIRS=+... Ścieżka systemowa 2. Zależności IMPORTS • SNMPv2-SMI • SNMPv2-TC / CONF • Brak pliku = błąd Drzewo dziedziczenia 3. Walidacja smilint • smilint -s -l 5 MIB.txt • Weryfikacja ASN.1 • snmp.conf: mibs +NAZWA Poprawna translacja OID # 1. Pobranie i walidacja pliku MIKROTIK-MIB $ smilint -s -l 4 /usr/share/snmp/mibs/MIKROTIK-MIB.txt 0 errors, 0 warnings (Plik poprawny składniowo) # 2. Test translacji OID przed i po załadowaniu modułu $ snmptranslate -m +MIKROTIK-MIB -On MIKROTIK-MIB::mtxrHlTemperature.0 .1.3.6.1.4.1.14988.1.1.3.10.0 # Trwała aktywacja w /etc/snmp/snmp.conf: dodaj 'mibs +MIKROTIK-MIB'
Slajd 50/55
Praktyczny przegląd narzędzi pakietu Net-SNMP
Cel slajdu: Usystematyzowanie wiedzy o narzędziach konsolowych pakietu Net-SNMP z ich flagami i zastosowaniem w codziennej pracy inżyniera.

Narzędzia i warsztat

Pakiet Net-SNMP stanowi podstawowy zestaw narzędzi diagnostycznych każdego administratora. Biegła znajomość dedykowanych poleceń decyduje o szybkości rozwiązywania awarii.

  • Pobieranie danych: `snmpget` (konkretny węzeł), `snmpgetnext` (następnik), `snmpwalk` (drzewo), `snmpbulkwalk` (zoptymalizowany GETBULK dla v2c/v3)
  • Prezentacja tablic i różnic: `snmptable` (automatyczne formatowanie wierszy i kolumn tabeli MIB), `snmpdelta` (obliczanie przyrostu liczników w czasie)
  • Modyfikacja i translacja: `snmpset` (modyfikacja stanu obiektu), `snmptranslate` (zamiana nazw na numery OID i inspekcja struktury drzewa)
  • Zdarzenia i pułapki: `snmptrap` (nadawanie pułapek testowych), `snmpinform` (nadawanie powiadomień z potwierdzeniem), demon `snmptrapd`
Flaga -Oqv: W skryptach automatyzacji połączenie opcji -Oqv (Quick Value) jest standardem inżynierskim. Zwraca ono wyłącznie surową wartość zmiennej bez przedrostków OID i typów ASN.1.
Narzędzia pakietu Net-SNMP Kompendium poleceń wiersza poleceń pakietu Net-SNMP Odpytywanie i inspekcja snmpget Pojedyncza instancja (skalar) snmpgetnext Następnik leksykograficzny snmpwalk Sekwencyjne całe poddrzewo snmpbulkwalk Zoptymalizowany GETBULK (v2c/v3) Tablice, zmiany i pułapki snmptable Formatowanie tabeli MIB snmpset Zdalna zmiana zmiennej snmptrap Wysyłanie pułapki testowej snmptranslate Translacja OID <-> Nazwa Niezbędnik flag formatowania wyjścia (Output Options -O) • -On : Wyświetl OID w formacie w pełni numerycznym (np. .1.3.6.1.2.1.1.1.0). • -Of : Wyświetl pełną ścieżkę symboliczną (np. .iso.org.dod.internet.mgmt.mib-2...). • -Oq : Tryb cichy (Quick Mode) – usuwa znaki równości i formatowanie ASN.1. • -Ov : Wyświetl wyłącznie wartość zmiennej (idealne do przetwarzania w Bash). Połączenie -Oqv zwraca czysty ciąg znaków gotowy do przypisania w skryptach powłoki.
Slajd 51/55
Ćwiczenie warsztatowe 1: Odpytanie przełącznika sieciowego
Cel slajdu: Samodzielne zrealizowanie procedury lokalizacji stacji roboczej na porcie przełącznika poprzez odpytanie tablicy FDB przez SNMP.

Laboratorium i warsztat praktyczny

Jednym z fundamentalnych zadań inżyniera sieci jest ustalenie, do którego fizycznego portu przełącznika podłączone jest urządzenie o znanym adresie MAC.

  • Krok 1: Reprezentacja adresu MAC: Przeliczenie 6 oktetów adresu szesnastkowego MAC (np. `00:1A:2B:3C:4D:5E`) na format dziesiętny (`0.26.43.60.77.94`)
  • Krok 2: Odpytanie dot1dTpFdbTable: Odczyt zmiennej `dot1dTpFdbPort` (OID 1.3.6.1.2.1.17.4.3.1.2.<MAC>) w celu uzyskania numeru portu mostu (Bridge Port)
  • Krok 3: Mapowanie na ifIndex: Odpytanie tablicy `dot1dBasePortIfIndex` (OID 1.3.6.1.2.1.17.1.4.1.2.<BridgePort>) w celu uzyskania standardowego `ifIndex`
  • Krok 4: Identyfikacja portu fizycznego: Odczyt `ifDescr` lub `ifAlias` dla uzyskanego indeksu (np. port `GigabitEthernet1/0/14`), wskazujący fizyczne gniazdko sieciowe
Indeksowanie Community per VLAN (Cisco): Na przełącznikach Cisco z wieloma sieciami VLAN odpytanie tablicy FDB wymaga podania numeru VLAN w społeczności, np. snmpwalk -v2c -c public@100 192.168.1.2 dot1dTpFdbPort dla VLAN 100.
Lokalizacja hosta w przełączniku Warsztat 1: Lokalizacja hosta po MAC w tablicy FDB Krok 1: Adres MAC • MAC: 00:1A:2B:3C:4D:5E • Konwersja na dziesiętny: .0.26.43.60.77.94 Indeks tabeli FDB Krok 2: dot1dTpFdb • Odpytanie FDB Port: dot1dTpFdbPort.0.26... Wynik: Bridge Port = 14 Numer portu mostu Krok 3: ifDescr • Mapowanie portu: dot1dBasePortIfIndex.14 ifDescr.10114 = Gi1/0/14 Zlokalizowano gniazdo! # Gotowy jednoliniowiec lokalizujący MAC na przełączniku L2 BPORT=$(snmpget -v2c -c public 192.168.1.2 -Oqv 1.3.6.1.2.1.17.4.3.1.2.0.26.43.60.77.94) IFIDX=$(snmpget -v2c -c public 192.168.1.2 -Oqv 1.3.6.1.2.1.17.1.4.1.2.$BPORT) PORTNAME=$(snmpget -v2c -c public 192.168.1.2 -Oqv ifDescr.$IFIDX) echo "Host 00:1A:2B:3C:4D:5E znajduje się na fizycznym porcie: $PORTNAME" # Wynik: Host 00:1A:2B:3C:4D:5E znajduje się na fizycznym porcie: GigabitEthernet1/0/14
Slajd 52/55
Ćwiczenie warsztatowe 2: Własne rozszerzenie snmpd
Cel slajdu: Implementacja i przetestowanie autorskiego sensora telemetrycznego w demonie snmpd z użyciem dyrektywy extend.

Laboratorium i warsztat praktyczny

Standardowe bazy MIB nie obejmują wszystkich specyficznych metryk aplikacji biznesowych. Dyrektywa `extend` pozwala na bezproblemowe wystawienie dowolnego parametru przez SNMP.

  • Przygotowanie skryptu pomiarowego: Utworzenie wykonywalnego skryptu powłoki odczytującego temperaturę procesora z wirtualnego systemu plików Linuksa `/sys/class/thermal/`
  • Konfiguracja demona snmpd: Wpisanie dyrektywy `extend cpu_temp /usr/local/bin/temp.sh` do pliku `/etc/snmp/snmpd.conf` i restart usługi systemowej
  • Struktura drzewa rozszerzeń: Pojawienie się obiektu w gałęzi `NET-SNMP-EXTEND-MIB` pod OID `.1.3.6.1.4.1.8072.1.3.2` (gdzie nazwa rozszerzenia jest indeksem ASCII)
  • Weryfikacja konsolowa: Odczyt parametru za pomocą `snmpget` lub `snmpwalk` z poprawnym sparsowaniem tekstu wyjściowego
Wydajność dyrektywy extend: Każde zapytanie SNMP o dany OID powoduje uruchomienie nowego procesu powłoki (`fork`/`exec`). Jeśli skrypt wykonuje się dłużej niż 1 sekundę lub jest odpytywany bardzo często, należy zastosować buforowanie wyniku w pamięci RAM (`/dev/shm`).
Własne rozszerzenie snmpd Warsztat 2: Własna telemetria w Linuksie z dyrektywą extend 1. Skrypt pomiarowy • /usr/local/bin/temp.sh • Odczyt /sys/class/thermal • chmod +x temp.sh Zwraca liczbę (np. 42) 2. snmpd.conf • extend cpu_temp /usr/local/bin/temp.sh • systemctl restart snmpd Rejestracja obiektu 3. Odpytanie OID • NET-SNMP-EXTEND-MIB • nsExtendOutputFull • Wynik: STRING: "42" Dostępne w NMS! # 1. Zawartość skryptu /usr/local/bin/temp.sh #!/bin/sh; awk '{print int($1/1000)}' /sys/class/thermal/thermal_zone0/temp # 2. Odpytanie rozszerzenia z lokalnej lub zdalnej maszyny $ snmpget -v2c -c public localhost 'NET-SNMP-EXTEND-MIB::nsExtendOutputFull."cpu_temp"' NET-SNMP-EXTEND-MIB::nsExtendOutputFull."cpu_temp" = STRING: 42 # Numeryczny OID: .1.3.6.1.4.1.8072.1.3.2.3.1.2.8.99.112.117.95.116.101.109.112
Slajd 53/55
Ćwiczenie warsztatowe 3: Analiza ruchu SNMP w Wireshark
Cel slajdu: Przechwycenie i deasemblacja pakietów protokołu SNMP w analizatorze Wireshark ze szczególnym uwzględnieniem porównania wersji v2c i v3.

Laboratorium i warsztat praktyczny

Zrozumienie budowy ramek SNMP na poziomie bitów i bajtów wymaga bezpośredniej analizy w analizatorze protokołów Wireshark.

  • Przechwytywanie ruchu: Zastosowanie filtru przechwytywania `port 161 or port 162` w celu odizolowania ruchu SNMP od pozostałych pakietów sieciowych
  • Inspekcja pakietu SNMPv2c: W nagłówku widać jawnie otwartym tekstem: `version: v2c`, ciąg `community` oraz całą listę żądanych OID w strukturze `variable-bindings`
  • Inspekcja pakietu SNMPv3: Nagłówek zawiera flagi `authPriv`, a całe pole `scopedPDU` stanowi ciąg losowych bajtów zaszyfrowanych algorytmem AES
  • Deszyfrowanie SNMPv3 w Wireshark: Wprowadzenie poświadczeń USM w preferencjach protokołu SNMP (`Edit -> Preferences -> Protocols -> SNMP`) pozwala na podgląd zaszyfrowanych danych
Filtr wyświetlania błędów: Filtr snmp.error_status != 0 natychmiast wyodrębnia w Wiresharku wszystkie pakiety zawierające komunikaty o błędach (np. `noSuchName`, `tooBig` lub `readOnly`).
Analiza pakietów w Wireshark Warsztat 3: Dekapsulacja pakietów SNMPv2c vs v3 w Wireshark Pakiet SNMPv2c (Otwarty tekst) • UDP Port: Dst: 161 (snmp) • Community: "public" (Jawne hasło!) • data: get-request (0) • variable-bindings: 1 item 1.3.6.1.2.1.1.1.0 (Widoczne dla sniffera) Pakiet SNMPv3 (AuthPriv: AES) • msgVersion: 3 • msgFlags: 0x03 (authPriv) • msgAuthoritativeEngineID: 80001f88... • encryptedPDU: 48 b9 a1 f3 e2... Całkowita poufność i integralność HMAC Praktyka laboratoryjna w Wireshark • Filtr przechwytywania: port 161 or port 162. • Konfiguracja deszyfrowania SNMPv3: Edit -> Preferences -> Protocols -> SNMP. • Wprowadzenie: Nazwa użytkownika, Hasło Auth (SHA-256), Hasło Priv (AES-256) pozwala Wiresharkowi odszyfrować pakiet. Ćwiczenie demonstruje, dlaczego SNMPv1/v2c nie wolno stosować w niezaufanych sieciach.
Slajd 54/55
Słownik pojęć prezentacji 3
Cel slajdu: Utrwalenie kluczowych terminów, akronimów i protokołów omawianych w module praktycznego działania protokołu SNMP.

Podsumowanie i słownik

Zestawienie fundamentalnych pojęć technicznych wykorzystywanych w analizie działania protokołu SNMP, automatyzacji i wizualizacji parametrów sieciowych.

  • GETBULK (RFC 3416): Operacja protokołu SNMP wprowadzona w wersji v2c/v3 optymalizująca pobieranie dużych fragmentów tabel w pojedynczym pakiecie UDP
  • Counter Wrap: Zjawisko przekroczenia maksymalnej wartości 32-bitowego licznika oktetów (`2^32 - 1`), wymagające stosowania obiektów Counter64 na łączach >= 100 Mbps
  • Spine Poller: Wysokowydajny, wielowątkowy demon w języku C zaimplementowany dla systemu Cacti, eliminujący opóźnienia pollerów w dużych sieciach
  • RRDtool: Otwarty standard silnika bazy danych o stałym rozmiarze (Round Robin Database) przeznaczony do magazynowania i konsolidacji szeregów czasowych
Forwarding Database (FDB): Tablica warstwy łącza danych (L2) przechowująca skojarzenia wykrytych adresów MAC stacji roboczych z fizycznymi numerami portów przełącznika sieciowego.
Słownik pojęć Kluczowe pojęcia i terminy techniczne prezentacji 3 GETBULK (RFC 3416) Operacja masowego pobierania wielu wierszy tabeli. Counter Wrap Przepełnienie licznika oktetów (wymusza Counter64). Spine Poller Wielowątkowy silnik akwizycji w języku C dla Cacti. RRDtool Baza danych o stałym rozmiarze dla szeregów czasowych. Tablica FDB (Forwarding DB) Powiązanie adresów MAC z portami przełącznika L2. DDM (Digital Diagnostic Monitoring) Telemetria optyczna wkładek SFP+ (moc Rx/Tx w dBm). Dyrektywa extend Wystawianie wyników skryptów Bash w drzewie snmpd. gNMI (gRPC Network Mgmt) Strumieniowa telemetria Push oparta na Protobuf.
Slajd 55/55
Pytania kontrolne i zadania końcowe
Cel slajdu: Weryfikacja opanowania materiału prezentacji 3 oraz przygotowanie studentów do egzaminu i ćwiczeń laboratoryjnych.

Podsumowanie i weryfikacja wiedzy

Zestaw czterech zaawansowanych pytań problemowych sprawdzających umiejętność praktycznego wykorzystania protokołu SNMP w analizie sieci LAN.

  • Pytanie 1 (Wydajność liczników): Dlaczego na interfejsach 10 Gbps i szybszych stosowanie liczników 32-bitowych `ifInOctets` prowadzi do błędnych wykresów pasma?
  • Pytanie 2 (Powiadomienia zdarzeniowe): Czym różni się mechanizm SNMP TRAP od SNMP INFORM i dlaczego INFORM zapewnia niezawodność dostarczenia?
  • Pytanie 3 (Nowoczesna telemetria): Jakie kluczowe ograniczenie tradycyjnego odpytywania SNMP eliminuje telemetria strumieniowa gNMI w centrach danych?
  • Pytanie 4 (Diagnostyka przełączników): Wskaż sekwencję zapytań SNMP niezbędną do powiązania adresu MAC stacji roboczej z fizyczną nazwą portu na przełączniku.
Odpowiedzi wzorcowe:
1. Licznik 32-bitowy przepełnia się po 3.4 s przy pełnym wysyceniu 10G, co uniemożliwia wyliczenie poprawnej delty w interwale 300 s (wymagany Counter64).
2. TRAP jest bezpotwierdzeniowy (unacknowledged UDP). INFORM (RFC 3416) wymaga odesłania pakietu Response-PDU; przy braku potwierdzenia agent ponawia wysyłkę (retransmisje po timeout).
3. gNMI eliminuje narzut odpytywania Pull i zjawisko ślepoty na mikro-bursty dzięki streamingowi w czasie rzeczywistym.
4. Kolejno: dot1dTpFdbPort (BRIDGE-MIB) -> dot1dBasePortIfIndex -> ifDescr (IF-MIB).
Pytania kontrolne Pytania kontrolne sprawdzające wiedzę techniczną Pytanie 1: Liczniki Counter Wrap Dlaczego na łączu 10 Gbps liczniki 32-bitowe są bezużyteczne? Odpowiedź: Przepełniają się w 3.4 s, co uniemożliwia wyliczenie delty przy standardowym interwale 300 s. Pytanie 2: SNMP TRAP vs INFORM Czym różni się TRAP od INFORM i jak zapewniona jest niezawodność? Odpowiedź: TRAP to UDP bez ACK. INFORM (RFC 3416) wymaga ACK (Response-PDU) i ponawia próby. Pytanie 3: Przewaga gNMI Jaka jest główna zaleta gNMI nad SNMP w centrach danych? Odpowiedź: Strumieniowanie Push z sub-sekundową ziarnistością i detekcją mikro-burstów przez Protobuf. Pytanie 4: Śledzenie portu po MAC Jakie tablice należy odpytać, aby powiązać MAC z ifDescr? Odpowiedź: dot1dTpFdbTable (MAC -> BridgePort), dot1dBasePortIfIndex (BridgePort -> ifIndex) i ifDescr.
← Poprzednia prezentacja Następna prezentacja →