Sponsorem tego wydania jest Sycope — polska platforma do monitoringu i analizy ruchu sieciowego. Wypróbuj darmową wersję i sprawdź, kto obciąża Twoją sieć — bez kosztów i zobowiązań.
Z darmową wersję Sycope w kilka minut:
- zobaczysz, które aplikacje i urządzenia zużywają najwięcej pasma,
- wykryjesz anomalie i potencjalne zagrożenia w czasie rzeczywistym,
- skorzystasz z gotowych, personalizowanych dashboardów i raportów,
- odzyskasz kontrolę nad infrastrukturą, zanim pojawi się problem.
Korzystaj z darmowej wersji Sycope w swoim środowisku aż do 31 sierpnia 2026 r.!
Awaria DynamoDB w AWS
19 października 2025 roku region us-east-1 AWS przeżył 14-godzinną awarię, która sparaliżowała dziesiątki usług. Źródło? Race condition w systemie zarządzania DNS DynamoDB, który opróżnił rekord DNS głównego endpointu. To doskonała lekcja z architektury rozproszonych systemów – i pokazuje, jak jeden błąd może wywołać efekt domina w całej infrastrukturze.
DynamoDB zarządza setkami tysięcy rekordów DNS przez dwa niezależne komponenty: DNS Planner (planuje) i DNS Enactor (wdraża zmiany). System działał w trzech AZ z optymistyczną blokadą w Route53. Problem rozpoczął się, gdy jeden Enactor utknął, podczas gdy drugi szybko zastosował nowszy plan. Kluczowy błąd: stary Enactor nadpisał świeży plan swoim przestarzałym, a proces clean-up usunął wszystkie IP z rekordu dynamodb.us-east-1.amazonaws.com.
Co gorsza – system wpadł w niespójny stan uniemożliwiający automatyczne naprawy. Przez 2,5 godziny żaden klient nie mógł połączyć się z DynamoDB przez publiczny endpoint. Global tables działały w innych regionach, ale z ogromnym lagiem replikacji.
EC2 wykorzystuje DynamoDB do zarządzania "dropletami" (fizycznymi serwerami). Gdy lease'y timeout'owały, DWFM wpadł w congestive collapse – próbował odnowić tak wiele lease'ów jednocześnie, że timeout'owały przed zakończeniem. Nowe instancje zwracały "insufficient capacity" przez godziny.
Lambda stracił możliwość tworzenia funkcji i przetwarzania eventów z SQS/Kinesis. NLB zaczął usuwać zdrowe nody z powodu błędnych health checków – system sprawdzał instancje, których konfiguracja sieciowa jeszcze nie wdrożona. Redshift blokował query'e IAM userów globalnie, bo używał API IAM w us-east-1 do rozwiązania grup.
Nawet po naprawie DynamoDB (2:25 AM) problemy trwały do 14:00. Dlaczego? Network Manager miał ogromny backlog propagacji stanu sieciowego – nowe instancje startowały, ale bez connectivity. DWFM potrzebował ręcznych restartów. NLB musiał wyłączyć automatic failover, bo alternating health checks degradowały system.
W systemach rozproszonych czas recovery jednego komponentu nie równa się czasowi recovery całego stosu. Zależności tworzą kolejki, backlog'i i deadlock'i, które wymagają ręcznej interwencji.
AWS wyłączył automatykę DNS DynamoDB globalnie i dodaje velocity controls dla NLB (limit ile capacity można usunąć podczas failover). Dla nas kluczowe wnioski:
Multi-region to must-have – klienci z global tables w innych regionach działali. Dependency na DNS to single point of failure – rozważ account-specific endpoints jako fallback. Health checks mogą kłamać – dodaj grace period dla nowej infrastruktury. Congestive collapse wymaga rate limitingu – EC2 dodaje throttling bazowany na wielkości kolejki.
Najbardziej niepokojące? To nie był atak ani hardware failure – tylko race condition w dobrze zaprojektowanym systemie. W architekturze rozproszonej "rzadkie" zdarzenia są nieuniknione przy skali AWS. Pytanie brzmi: czy Twoja architektura przetrwa, gdy Twój provider tego nie zrobi?
Laboratorium sieciowe za grosze
Suresh Vinasiththamby
: mini PC zamiast serwera
Najczęściej zadawane pytanie na packetswitch.co.uk brzmi: "Jakie specs polecasz do domowego labu sieciowego?" Odpowiedź, która zaskakuje większość osób: używany mini PC za ~1000zł.
Suresh dd roku pracuję na Dell OptiPlex 7060 (i5-8500T, 32GB RAM, 1TB SSD) kupionym za £120. Mały, cichy, niskie zużycie prądu. Jednocześnie odpala 15+ routerów Cisco IOL z OSPF i BGP bez przegrzania systemu.
Co potrzebujesz?
Hardware: Używany mini PC (Lenovo/Dell/HP) z i5 8. generacji, 16-32GB RAM, SSD. eBay roi się od takich ofert w zakresie 750-1250zł. To wystarczy do nauki OSPF, BGP, MPLS, EVPN czy automatyzacji z Ansible.
Software stack:
- Proxmox jako hypervisor (snapshoty ratują życie przy eksperymentach)
- Ubuntu VM z Containerlab/Netlab - definiujesz topologię w YAML, za chwilę masz działający lab
- EVE-NG lub CML - jeśli wolisz GUI i nie chcesz uczyć się Linuksa
Obrazy: Arista cEOS (darmowy do pobrania, znana składnia podobna do Cisco), Cisco IOL (lekki, ale trudny do zdobycia), Nokia SR Linux (darmowy, ale nowa składnia).
Test: 15 routerów Cisco IOL z OSPF i BGP na Ubuntu VM (4 CPU, 16GB RAM). Zużycie zasobów? Ledwo 50%. Spokojnie da radę 30+ nodów na tym samym sprzęcie.
Dla porównania - Cisco CML w wersji darmowej pozwala na... 5 nodów. Płatna licencja za $199/rok daje 20 nodów. To nie jest lab, to żart.
Skaner MCP od Cisco
cisco-ai-defense
MCP Scanner to narzędzie w Pythonie do skanowania serwerów i narzędzi MCP (Model Context Protocol) pod kątem problemów bezpieczeństwa. Możesz go używać jako samodzielnego CLI albo uruchomić jako serwer REST API. Wykorzystuje trzy silniki skanowania: YARA (reguły sygnaturowe), LLM-as-a-judge (ocena przez model) oraz Cisco AI Defense (API inspekcji). Silniki można stosować razem lub oddzielnie — zależnie od potrzeb.
Wypróbuj bezpłatnie Sycope: w kilka minut zobaczysz, co zużywa Twoje pasmo, zidentyfikujesz podejrzane zachowania w czasie rzeczywistym i skorzystasz z gotowych dashboardów — oferta bez kosztów i zobowiązań do 31 sierpnia 2026 r.
Testowanie Serwerów Tras
pierky
ARouteServer to narzędzie w Pythonie do automatycznego tworzenia i testowania zaawansowanych konfiguracji dla BGP route serverów. Możesz go użyć, gdy chcesz wygenerować bezpieczną, spójną i testowaną konfigurację (BIRD, BIRD v2, BIRD v3 w testach oraz OpenBGPD) dla IX i route serverów, zintegrowaną z danymi z zewnętrznych źródeł.
Dlaczego rozciąganie L2 to katastrofa?
Daniel Dib
Wszyscy wiedzą, że rozciąganie domen L2 to zły pomysł, jednak większość nie umie wyjaśnić dlaczego. A to kluczowe, bo bez zrozumienia mechanizmów awarii będziesz budować kruche architektury, które wcześniej czy później się rozpadną.
Brak TTL = wieczna pętla
Fundamentalna różnica między L2 i L3: co się dzieje, gdy nie wiesz, co zrobić z pakietem?
Na warstwie 3: pakiet trafia do /dev/null (chyba że masz default route). Nawet jeśli powstanie pętla routingu, TTL w końcu spadnie do zera i problem się sam rozwiąże.
Na warstwie 2: broadcast, unknown unicast i multicast są floodowane wszędzie. Bez TTL. Ramka może krążyć w nieskończoność. A wystarczy jeden zepsuty link (unidirectional failure), żeby Twoja sieć legła.
Failure domain i fate sharing
Dwa pojęcia, które każdy inżynier powinien rozumieć:
Failure domain to obszar, gdzie awaria się rozprzestrzenia. W domenie L2 to każdy link z danym VLAN-em. Jeden broadcast storm = cała domena pada.
Fate sharing oznacza urządzenia dzielące los przy awarii. Wszystkie VLAN-y na tych samych linkach dzielą wspólny los. Problem z jednym VLAN-em zabije resztę.
Efekt? Awaria eskaluje lawinowo. Nie izolujesz problemu - musisz gasić pożar w całej domenie.
STP nie jest problemem
Spanning Tree dostaje niesłusznie bat. Protokół działa dokładnie tak, jak zaprojektowano. Problem tkwi w projektantach, którzy go nie rozumieją.
Większość inżynierów zna IP lepiej niż Ethernet. To prowadzi do projektów, gdzie:
- Root bridge jest przypadkowy
- BPDU Guard nie istnieje
- Loop prevention? "STP to załatwi"
A potem winią protokół, gdy 10-sekundowa konwergencja powoduje outage.
Co z tym zrobić?
Jeśli musisz rozciągać L2 (migracje, legacy apps etc.):
- Izoluj na brzegu - trzymaj tunele blisko warstwy dostępowej, nie ciągnij do core
- Dedykowane urządzenia - osobny sprzęt dla L2 stretch, żeby awaria nie zalała produkcji
- Monitoruj unidirectional failures - wdrożenie UDLD
- Miej plan wyjścia - L2 stretch to stan przejściowy, nie docelowy
Najważniejsze: rozumiej fundamenty. Nie kopiuj best practices ślepo. Wiedz, DLACZEGO coś jest dobre lub złe w Twoim konkretnym scenariuszu. Bo gdy o 3 w nocy coś padnie, checklista Ci nie pomoże - pomoże zrozumienie, co się faktycznie dzieje pod maską.