Sponsorem tego wydania jest Sycope — firma rozwijająca rozwiązania do analizy ruchu sieciowego i monitorowania bezpieczeństwa IT.
Podczas bezpłatnego, technicznego webinaru dowiesz się, jak rozszerzyć monitoring w Zabbixie o analizę ruchu sieciowego — bez zastępowania dotychczasowych narzędzi i bez przebudowy istniejącego workflow.
Webinar: „From alerts to answers: extending Zabbix with network flow data”
Termin: 29 września 2026, godz. 10:00 CEST
Język: angielski
Udział: bezpłatny
Dlaczego Ethernet ma działać jak InfiniBand
Taha Yusuf
Rozproszone workloady AI (Tensor Parallelism, Expert Parallelism, Pipeline Parallelism) wymagają ciągłej wymiany danych między GPU na różnych serwerach fizycznych. To generuje ruch east-west w skali, do której Ethernet nie był projektowany. GPU to drogi zasób - a każde opóźnienie sieciowe oznacza GPU czekające zamiast liczące.
RDMA (Remote Direct Memory Access) rozwiązuje to, transferując dane bezpośrednio między pamięcią GPU z pominięciem CPU i stosu sieciowego OS. InfiniBand ma RDMA natywnie wbudowane w architekturę. RoCEv2 próbuje to samo osiągnąć na zwykłym Ethernecie - transportując RDMA po UDP/IP w topologii Spine-Leaf.
Haczyk: RoCEv2 sam z siebie nie czyni Ethernetu lossless. To wciąż best-effort forwarding, który przy przeciążeniu zwyczajnie zrzuca pakiety.
Tu wchodzi mechanizm złożony z trzech warstw:
- ECN - switch monitoruje zajętość kolejki i po przekroczeniu progu oznacza pakiety jako "Congestion Experienced" (CE), wciąż je przekazując
- CNP - odbiorczy RNIC widzi znacznik CE i wysyła Congestion Notification Packet z powrotem do nadawcy
- DCQCN - na podstawie CNP nadawca redukuje tempo transmisji, zanim dojdzie do utraty pakietów
- PFC - jeśli powyższe nie zdąży zadziałać, a kolejka zbliża się do przepełnienia, switch wysyła PFC XOFF hop-by-hop, wstrzymując konkretną priorytetową klasę ruchu (nie cały link, jak klasyczny Ethernet PAUSE)
Kluczowe rozróżnienie: ECN+CNP to kontrola przeciążenia (reakcja zanim dojdzie do straty), PFC to mechanizm ochronny ostatniej szansy. Zdrowy design fabric powinien polegać głównie na ECN - jeśli sieć ciągle uderza w progi PFC, to sygnał źle dobranych parametrów QoS, a nie normalna praca systemu.
Budowa fabric pod RoCEv2 to nie włączenie jednej funkcji na switchu brzegowym. To spójna konfiguracja QoS, progów ECN i PFC na każdym hopie w ścieżce - bo PFC działa lokalnie, więc jeden źle skonfigurowany switch w środku może zepsuć cały mechanizm end-to-end.
Martwa strefa w Twoim stosie bezpieczeństwa
Pawel Zwierzynski
HTTP/3 rośnie w adopcji z kwartału na kwartał. Większość stosów bezpieczeństwa nadal nie potrafi zajrzeć do środka tego ruchu.
W przypadku HTTPS over TCP firewall terminuje sesję TLS klienta, otwiera własną sesję do serwera i deszyfruje ruch w środku. Działa to, bo TCP i TLS to dwie oddzielne, dobrze udokumentowane warstwy.
QUIC zrywa z tym modelem. Działa na UDP i nie "siedzi nad" TLS — handshake TLS 1.3 jest wbudowany bezpośrednio w protokół transportowy. Po pierwszym pakiecie praktycznie wszystko jest zaszyfrowane: numery pakietów, większość pól nagłówka, dane. W czystym tekście zostają connection ID i kilka flag. Wiesz, że połączenie istnieje. Nie wiesz, co w nim leci.
Budowa transparentnego proxy dla QUIC wymaga reimplementacji pełnego stosu QUIC po obu stronach. Cisco eksperymentuje z tym w Secure Firewall, ale to na razie wyjątek, nie reguła.
Palo Alto, Fortinet i praktycznie wszyscy pozostali gracze w tym segmencie stosują to samo podejście — blokują QUIC i wymuszają fallback na TLS over TCP. Tam istniejąca polityka deszyfrowania działa normalnie.
Brzmi prosto, ale jest jeden haczyk. Przeglądarka cache'uje preferencję HTTP/3 na określony czas zamiast sprawdzać ją przy każdym żądaniu. Gdy QUIC zawiedzie, zazwyczaj przeglądarka cicho przełącza się na TCP. Jednak w praktyce — szczególnie widoczne w Edge — przeglądarka potrafi przez pewien czas dalej próbować QUIC na domenie, która właśnie nie odpowiedziała, zamiast przełączyć się na TLS. Efekt od strony użytkownika: zakładka się wiesza, serwis "nie działa". Klasyczny ticket do supportu.
Martwa strefa nie jest teoretyczna. Frameworki C2 już od jakiegoś czasu dodają obsługę QUIC. Kaspersky udokumentował RAT-a używającego HTTP/3 do komunikacji z serwerem C2. Jeśli nie blokujesz QUIC, ten ruch przechodzi przez Twój firewall bez żadnej inspekcji.
Warto też wiedzieć, że istnieje przestrzeń między "pełna deszyfracja" a "całkowita ślepota". Pakiety Initial mają klucze możliwe do wyprowadzenia z publicznie dostępnych danych (RFC 9001 §5.2, §5.4), co pozwala na odczyt SNI. Możliwy jest też fingerprinting stosu klienta. To nie zastępuje inspekcji payloadu dla DLP czy IPS, ale daje pewien poziom widoczności przy pasywnym monitoringu.
Action item: Sprawdź dziś, czy Twoja polityka blokuje UDP 443 dla nieznanych lub niezaufanych destynacji. Jeśli używasz proxy, zweryfikuj, czy ruch QUIC w ogóle do niego trafia — część implementacji go omija.
TLS 1.3 też był kiedyś problemem dla narzędzi inspekcji. Przemysł się dostosował. QUIC przejdzie tę samą drogę. Pytanie, ile ruchu C2 przepłynie przez Twoją sieć zanim to nastąpi.
Jak daleko można zajść z monitoringiem sieci za 0 zł?
Sycope zaprasza na techniczny webinar pokazujący, jak rozszerzyć monitoring w Zabbixie o dane NetFlow/IPFIX/sFlow. Nie chodzi o zastępowanie Zabbixa kolejnym systemem, ale o dodanie do metryk kontekstu rzeczywistej komunikacji sieciowej.Na konkretnych przykładach zobaczycie m.in. jak:
- wykorzystać hosty i grupy z Zabbixa do analizy ruchu,
- przejść z konkretnego obiektu w Zabbixie bezpośrednio do jego komunikacji w Sycope,
- wprowadzić dane i alerty z analizy ruchu z powrotem do Zabbixa,
- sprawdzić aktywne usługi na podstawie obserwowanego ruchu,
- połączyć monitoring infrastruktury z analizą NetFlow/IPFIX/sFlow bez przebudowy istniejącego workflow.
Uwaga: Zabbix i Sycope mają wersje bezpłatne, więc to także praktyczny przykład tego, jak daleko można rozszerzyć monitoring bez dokładania kolejnego kosztu licencyjnego.
Termin: 29 września 2026, 10:00 CEST
Język: angielski
Udział: bezpłatny
Kolektor BMP klasy hyperscaler
FastNetMon
INFO: Netom to modułowy i programowalny silnik BGP/BMP przeznaczony do zbierania, przetwarzania i przekazywania dużych ilości danych o routingu. Możesz używać go do otwierania sesji BGP i BMP, gromadzenia tras w pamięciowej bazie RIB, importowania danych z plików MRT oraz filtrowania informacji za pomocą języka Roto. Netom obsługuje między innymi restreaming BMP, eksport pełnych tablic routingu, ochronę przed wolnymi odbiorcami, TLS, kontrolę dostępu i uwierzytelnianie TCP MD5. Stan danych można sprawdzać przez API HTTP/JSON, a wyniki przekazywać do logów lub strumienia MQTT. Projekt jest rozwijanym forkiem Rotondy od NLnet Labs, dostosowanym przede wszystkim do wdrożeń produkcyjnych i monitoringu sieci na dużą skalę. Warto pamiętać, że wersje 0.x mogą wprowadzać zmiany w API, konfiguracji i składni języka Roto.
Integracja Netbox z Cisco Catalyst Center
sieteunoseis
Wtyczka integruje NetBox z Cisco Catalyst Center (dawniej DNA Center), pozwalając wyświetlać w NetBox szczegóły urządzeń sieciowych i klientów bezprzewodowych. Umożliwia także jednokierunkowy import urządzeń, interfejsów i informacji PoE, obsługuje stosy przełączników jako Virtual Chassis oraz oferuje pamięć podręczną odpowiedzi API. Jest przeznaczona dla NetBox 4.x, Cisco Catalyst Center 2.x lub nowszego i wymaga konfiguracji mapowania urządzeń oraz konta API w Catalyst Center.
Troubleshooting ACI
Przeczytaj całą historię
Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.
Subskrybuj