📬 ISN 255: Sieć dla Klastra AI, Modbus TCP w Praktyce i Kontrola Zmian w NetBox!

255. numer newslettera obejmuje projektowanie sieci DC, podstawy Modbus TCP, testowanie BGP i kontrolę zmian w NetBox. Sprawdź też, jak zaprojektować sieć dla klastra AI on-prem!
📬 ISN 255: Sieć dla Klastra AI, Modbus TCP w Praktyce i Kontrola Zmian w NetBox!

Projektowanie sieci DC

Większość dyskusji o architekturze data center zaczyna się od wyboru protokołu routingu lub topologii. To błąd, który kosztuje – i to drogo.

Sieć istnieje dla aplikacji, nie odwrotnie

Sieć nie generuje przychodu. Generuje koszty. Jej jedyną rolą jest transport danych aplikacji w sposób spełniający wymagania biznesowe. Zanim wybierzesz EBGP vs OSPF w underlay, odpowiedz na pytania: jakie aplikacje będą działać na tej infrastrukturze, jakie są ich wzorce ruchu i jakie masz priorytety w przypadku konfliktów wymagań?

Typ data center radykalnie zmienia odpowiedzi. Enterprise DC, HPC, AI cluster i hyperscaler to cztery zupełnie różne bestie – każda wymaga innych kompromisów.

RFC 7938 (BGP w large-scale DC) to dobry przykład dokumentu, który warto znać. Ale jego pierwsze zdanie brzmi: "Some network operators build and operate data centers that support over 100,000 servers." To 2500 rackow i 2500 leaf switchy przy standardowym ToR design.

Jeśli twój fabric ma 100 leafów – to nie twoja skala, nie twoje problemy do rozwiązania. Dobry dokument referencyjny zawsze określa skalę i listę problemów, które rozwiązuje. Jeśli widzisz tylko slogan "best practice" bez uzasadnienia – szukaj dalej.

Projektowanie DC to jednoczesne żonglowanie trzema domenami:

Fizyczna warstwa: radix spine'ów (fixed vs modular), współczynnik oversubscription, algorytm ECMP, rozmiar buforów, kablowanie i optyka, zużycie energii.

Control plane: underlay (IPv4/IPv6, OSPF/IS-IS/EBGP), overlay (EVPN z VXLAN/Geneve/MPLS), rozmieszczenie route reflectorów przy IBGP, timery BFD, granulacja failure domain – jeden duży fabric czy pody?

Operacje i biznes: monitoring i telemetria, strategia upgradów, automatyzacja (jakie API eksponują switche), integracja z hypervisorami, vendor lock-in, CapEx i OpEx.

Żadna z tych warstw nie jest ważniejsza od pozostałych. Ignorowanie którejkolwiek na etapie designu oznacza problemy w produkcji.

Wymagania często są ze sobą sprzeczne. Zaawansowane feature'y security od jednego vendora = głęboki lock-in. Dual ToR per rack = wyższe koszty i mniejsza gęstość serwerów. Nie istnieje design, który maksymalizuje wszystko jednocześnie.

Praktyczna zasada: zidentyfikuj wymagania krytyczne dla sieci i sprawdź, które z pozostałych można przenieść do innej domeny. HA można oddelegować na poziom aplikacji. Security można przesunąć na hypervisor lub host. To zwalnia zasoby network layer na to, co faktycznie musi być tam obsługiwane.


Podstawy modbus tcp

Modbus Fundamentals | Weberblog.net

Modbus to protokół z lat 70., który wciąż dominuje w sieciach przemysłowych. Jeśli pracujesz z segmentami OT/ICS, wcześniej czy później trafisz na ten ruch w Wiresharku — i lepiej wiedzieć, co widzisz.

Modbus/TCP to klasyczny Modbus/RTU z dwoma modyfikacjami: usunięto pole CRC (integralność zapewnia TCP) i dodano nagłówek MBAP. Nagłówek niesie Transaction ID, Protocol ID, długość danych oraz Unit ID.

Unit ID to pozostałość po architekturze master/slave z magistral szeregowych. W czystym Modbus/TCP jest zazwyczaj ignorowany, ale nabiera znaczenia przy bramkach TCP↔RTU lub w implementacjach vendorskich — nie pomijaj go przy debugowaniu.

Cztery typy danych i ich pułapki

Modbus adresuje cztery bloki danych:

  • Coils — wyjścia binarne (R/W), np. przekaźniki
  • Discrete Inputs — wejścia binarne (R/O), np. alarmy
  • Input Registers — rejestry 2-bajtowe (R/O), np. pomiary
  • Holding Registers — rejestry 2-bajtowe (R/W), np. setpointy

Kluczowa pułapka adresowania: ten sam adres fizyczny (np. 44) w zależności od użytego function code'a wskazuje na różny blok danych. FC3 czyta Holding Registers, FC4 czyta Input Registers z tego samego adresu — i mogą zwrócić różne wartości. Dokumentacja vendora z prefiksami (0xxxxx, 1xxxxx, 3xxxxx, 4xxxxx) i notacją 6-cyfrową eliminuje tę niejednoznaczność.

Modbus nie przekazuje żadnej informacji o typie danych. Rejestr to zawsze 2 bajty (jeden word). Jeśli wartość jest float32, zajmuje dwa kolejne rejestry — i musisz wiedzieć o tym z dokumentacji, nie z pakietu.

Wireshark pozwala przełączać reprezentację danych w dissectorze Modbus (INT16, UINT32, FLOAT32 itd.), co przy analizie ruchu OT oszczędza sporo czasu. Warto znać ten feature.

Dodatkowy aspekt: kolejność bajtów i word order przy wartościach wielorejestrowych nie jest ustandaryzowana. Big-endian, little-endian, swapped words — każdy vendor może zrobić to inaczej.

Jeśli chcesz przećwiczyć analizę na realnych pakietach — autor artykułu udostępnia publiczny plik PCAP z przykładami Modbus/TCP w ramach projektu "Ultimate PCAP".


Testowanie BGP

David Leonard / gobgp-blaster · GitLab
A GoBGP-driven BGP testing suite for lab and platform validation.

INFO: GoBGP Blaster to narzędzie do testowania sieci BGP w laboratorium. Pozwala generować i odtwarzać trasy, dodawać atrybuty, których standardowy GoBGP nie obsługuje — m.in. RFC 8669 Label-Index i Originator SRGB — oraz mierzyć czas zbieżności, opóźnienia i straty pakietów. Obsługuje rzeczywiste tablice routingu z RouteViews i RIPE RIS, testy na dużą skalę, scenariusze YAML z progami dla CI oraz interfejs CLI i panel webowy. Narzędzie współpracuje ze standardowym gobgpd, oferuje gotowe laboratoria Containerlab dla Nokia SR Linux i Cisco IOS-XR, a także mechanizmy bezpieczeństwa, takie jak ograniczenie adresów, tryb podglądu i dziennik operacji. To propozycja dla osób, które chcą sprawdzać zachowanie routerów i platform sieciowych bez instalowania dodatkowego oprogramowania na testowanym urządzeniu.


Kontrola zmian w Netbox

Home - NetBox Change Control
Policy-driven change control and mandatory review for NetBox branches.

Wtyczka do NetBoxa wprowadza kontrolę zmian opartą na politykach i obowiązkowych przeglądach. Pozwala pracować na branchach, otwierać pull requesti przypisywać wymaganych recenzentów oraz blokować scalanie do czasu uzyskania odpowiedniej liczby akceptacji. Niezależnie działają kontrole przed scaleniem, które mogą odmówić połączenia zmian nawet wtedy, gdy wszyscy wymagani reviewerzy je zatwierdzili. Wtyczka umożliwia też dodawanie własnych kontroli i integrację z zewnętrznymi systemami. Jest darmowa, dostępna na licencji MIT i przeznaczona dla NetBoxa 4.7; wersja dla NetBoxa 4.6 znajduje się w osobnej linii wydań. Projekt nie jest jeszcze stabilny, nie ma oficjalnego wsparcia NetBox Labs.


Sieć dla klastra AI on-prem

Świetnie! Udało ci się pomyślnie zarejestrować.
Witaj z powrotem! Zalogowałeś się pomyślnie.
Pomyślnie subskrybowałeś Inna Sieć.
Twój link wygasł.
Sukces! Sprawdź swoją skrzynkę e-mailową, aby uzyskać magiczny link do logowania.
Sukces! Twoje informacje rozliczeniowe zostały zaktualizowane.
Twoje informacje rozliczeniowe nie zostały zaktualizowane.