2 czerwca 2026 · 7 min czytania

MikroTik przez SNMP zwraca ifSpeed = 0 na portach 10G, przez co WanGuard nie policzy wykorzystania łącza. Przyczyna, OID-y i obejście krok po kroku.

Krótka odpowiedź: jeśli masz router MikroTik z portami 10 Gbps, a w systemie WanGuard wykresy wykorzystania łącza są płaskie, wyzerowane albo pokazują bzdury — winny jest błąd RouterOS. Przez SNMP interfejs raportuje ifSpeed = 0 zamiast wartości wymaganej przez RFC 2863. WanGuard dzieli wolumen ruchu przez prędkość interfejsu, więc przy zerze wynik jest niepoliczalny. Obejście zajmuje dwie minuty i nie wymaga żadnych zmian na routerze: prędkość interfejsu wpisuje się ręcznie w konfiguracji sensora.

Objaw jest charakterystyczny: sensor zbiera dane, liczniki pakietów rosną (widać realne 9–10 tys. pps), a mimo to kolumna Speed OUT pokazuje 0 Mbps i wykresy procentowego wykorzystania łącza nic nie pokazują. To nie jest błąd instalacji WanGuarda ani problem z NetFlow — to niezgodność RouterOS ze standardem SNMP.

Na czym dokładnie polega błąd ifSpeed = 0?

RFC 2863 opisuje to jednoznacznie: dla interfejsów szybszych niż ok. 4,3 Gbps licznik ifSpeed (32-bitowy, więc fizycznie niezdolny do wyrażenia 10 Gbps) ma zwracać wartość wartownika 4294967295, a rzeczywistą prędkość podaje się w ifHighSpeed, wyrażoną w Mbps.

RouterOS zamiast wartownika wysyła zero:

# SNMP walk on a 10G MikroTik interface
IF-MIB::ifSpeed.1      = Gauge32: 0          # <- WRONG - should be 4294967295
IF-MIB::ifHighSpeed.1  = Gauge32: 10000      # <- correct (Mbps)

Zwróć uwagę, że ifHighSpeed jest poprawny. Problem dotyczy wyłącznie starego, 32-bitowego OID-u. Każda platforma monitorująca, która odczytuje prędkość interfejsu przez standardowe OID-y SNMP — a robi tak również WanGuard — zobaczy interfejs o prędkości zerowej i nie policzy procentowego wykorzystania. Sprawa jest zgłoszona na forum społeczności MikroTik i według stanu na połowę 2026 roku nie doczekała się poprawki po stronie producenta.

Warto od razu odróżnić dwie rzeczy, bo administratorzy często je mylą przy diagnozie: samo zbieranie danych o ruchu działa poprawnie (NetFlow/IPFIX z MikroTika dociera do sensora bez zarzutu), psuje się natomiast normalizacja tych danych do prędkości portu — bo brakuje mianownika.

Dlaczego WanGuard się na tym wykłada?

WanGuard używa prędkości interfejsu jako mianownika przy obliczaniu procentowego wykorzystania łącza na podstawie datagramów NetFlow, IPFIX lub sFlow. Wzór jest banalny:

utilisation % = traffic bytes / interface speed * 100

Przy mianowniku równym zero działanie jest po prostu nieokreślone. Efekt sięga dalej niż same wykresy — progi wyrażone procentowo (np. „alarm przy 80% wykorzystania uplinku") również przestają działać, bo nie ma od czego liczyć procentu. Progi bezwzględne (bps, pps) działają dalej, co utrudnia zauważenie problemu: alarmy przychodzą, więc system wygląda na sprawny.

Porównanie stanu przed i po poprawce:

ParametrSNMP Auto (zepsute)Po ręcznej poprawce
Źródło prędkościRouterOS SNMPkonfiguracja WanGuard
Speed IN10 000 Mbps (z ifHighSpeed)10 000 Mbps
Speed OUT0 Mbps10 000 Mbps
Wykresy wykorzystanianiepoprawne / pustepoprawne
Statystyki NetFlow / IPFIXzniekształconedokładne
Zgodność z RFC 2863brakpominięta (obejście)

Charakterystyczna asymetria — Speed IN wykryty poprawnie, Speed OUT zerowy — bierze się stąd, że autodetekcja pobiera te dwie wartości z różnych pól MIB. Jeśli w panelu Manage Interfaces widzisz właśnie taki obraz, masz potwierdzoną diagnozę.

Jak wygląda konfiguracja, w której to występuje?

Typowy układ: flow sensor odbiera datagramy NetFlow / IPFIX z routera MikroTik, a SNMP jest włączony i ustawiony na Auto. To właśnie tryb automatyczny jest źródłem kłopotu — WanGuard odpytuje SNMP przy starcie sensora, żeby wypełnić prędkości interfejsów, i pobiera przy okazji zepsutą wartość.

Objaw jest widoczny wyłącznie na portach 10G. Na interfejsach 1G błąd nie występuje, bo tam ifSpeed mieści się w 32 bitach i RouterOS podaje poprawną wartość. Dlatego problem pojawia się zwykle dopiero po modernizacji sieci — wykresy działały latami, a przestały tego samego dnia, w którym wpięto porty 10G. Jeśli dopiero uruchamiasz system, przejrzyj instrukcję instalacji WanGuard: kolejność jest istotna, bo prędkości interfejsów pobierane są przy pierwszym starcie sensora.

Jak to naprawić w WanGuard krok po kroku?

Żadnych zmian na routerze. Nadpisujesz zepsute wartości SNMP bezpośrednio w konfiguracji interfejsów w WanGuard.

  1. Otwórz WanGuard Console → Flow Sensors i kliknij swój sensor MikroTika.
  2. W dolnej części okna Flow Sensor Configuration kliknij Manage Interfaces.
  3. Zaznacz wszystkie interfejsy 10G (możesz użyć Select All).
  4. Kliknij Set Traffic Direction → Set Stats Engine i ustaw zarówno Speed IN, jak i Speed OUT na 10000 (Mbps).
  5. Kliknij Save. Od tej chwili WanGuard używa poprawnej prędkości odniesienia we wszystkich obliczeniach.
# Czego WanGuard użyje po poprawce:
Speed IN  = 10000 Mbps   # ustawione ręcznie
Speed OUT = 10000 Mbps   # ustawione ręcznie - nadpisuje zepsute ifSpeed=0

Wartość podaje się w Mbps: dla portu 10G wpisujesz 10000, dla 40G — 40000. Jeśli port jest ograniczony kontraktowo do niższej przepustowości, wpisz prędkość, względem której faktycznie chcesz mierzyć wykorzystanie — to ona będzie mianownikiem w procentach i punktem odniesienia dla progów.

Na co uważać po zastosowaniu obejścia?

Najważniejsza pułapka: ustawienie nie jest trwałe wobec ponownej autodetekcji. Jeśli uruchomisz ponownie SNMP discovery albo zresetujesz ustawienia interfejsów w WanGuard, zepsute wartości zostaną znów pobrane z RouterOS i trzeba będzie powtórzyć ręczne nadpisanie.

Praktyczne wnioski:

  • Po każdej większej zmianie w sensorze sprawdź kolumnę Speed OUT w Manage Interfaces, zanim uznasz sprawę za zamkniętą.
  • Zapisz prędkości portów w dokumentacji sieci. Przy odtwarzaniu konfiguracji z backupu albo migracji sensora to jedna z tych wartości, o których wszyscy zapominają.
  • Okres sprzed poprawki pozostanie zniekształcony — WanGuard nie przelicza wstecz tego, czego nie dało się policzyć.

Opisane zachowanie potwierdzono na RouterOS 7.x i WanGuard 8.x. Logika obliczania wykorzystania łącza nie zmieniła się w nowszych wydaniach, więc obejście pozostaje aktualne — zmienić się może jedynie rozmieszczenie opcji w konsoli.

Jeśli po ustawieniu prędkości wykresy nadal wyglądają podejrzanie, problem leży gdzie indziej — najczęściej w sampling rate NetFlow albo w kierunku ruchu przypisanym do interfejsu. Więcej o architekturze systemu znajdziesz w tekście czym jest WanGuard, a jeśli utknąłeś na konkretnym wdrożeniu — napisz do naszego wsparcia.

Najczęstsze pytania

Czy da się naprawić ifSpeed po stronie MikroTika?

Nie w sposób, na którym można polegać. To niezgodność implementacji SNMP w RouterOS z RFC 2863, a nie ustawienie konfiguracyjne — nie ma parametru, który kazałby routerowi zwrócić 4294967295 zamiast zera. Do czasu poprawki producenta jedyną sensowną drogą jest nadpisanie prędkości po stronie systemu monitorującego.

Czy ten błąd wpływa na wykrywanie ataków DDoS?

Pośrednio i tylko w części przypadków. Progi wyrażone w bps i pps działają normalnie, bo nie wymagają znajomości prędkości portu. Przestają natomiast działać progi procentowe (typu „x% wykorzystania uplinku"), a raporty o wykorzystaniu łącza są bezużyteczne do planowania pojemności.

Dlaczego Speed IN wykrył się poprawnie, a Speed OUT pokazuje 0?

Bo obie wartości pobierane są z różnych pól MIB. Jedna trafia z poprawnego ifHighSpeed, druga z zepsutego ifSpeed. Ta asymetria jest w praktyce najlepszym potwierdzeniem, że masz do czynienia właśnie z tym błędem, a nie z problemem sieciowym.

Czy muszę powtórzyć poprawkę po aktualizacji WanGuard?

Sama aktualizacja nie kasuje ręcznie ustawionych prędkości. Kasuje je natomiast ponowne uruchomienie SNMP discovery albo reset ustawień interfejsów — a to zdarza się przy odtwarzaniu konfiguracji z backupu lub przenoszeniu sensora na nowy serwer.