Nowa stara topologia w Data Center
Zamiast tradycyjnych switchy spine, AWS łączy switche leaf bezpośrednio przez pasywne urządzenie zwane ShuffleBox. Topologia wygląda jak losowa sieć połączeń – stąd marketingowe hasło "random graph theory". W rzeczywistości to zoptymalizowany quasi-losowy graf, gdzie uplinki 400GE są dzielone na osobne pasy 100GE, a ShuffleBox to prewired patch panel realizujący określoną macierz połączeń.
To nie jest nowy pomysł. Firma Plexxi próbowała dokładnie tego samego ponad dekadę temu – najpierw z CWDM, potem z prewired middlebox. Skończyła na przejęciu przez HP.
Skąd biorą się liczby: 33% lepszy throughput, 40% mniej energii?
Oszczędności energii są wiarygodne – ShuffleBox to element pasywny, bez zasilania i chłodzenia. Tu nie ma czego kwestionować.
Natomiast wyższy throughput wymaga kontekstu. Rozwiązanie zakłada 3:1 oversubscription w warstwie łączącej switche ToR w porównywanej topologii fat-tree. Innymi słowy: baseline jest celowo ograniczony.
W porównaniu jabłko do jabłka – leaf-and-spine bez oversubscription w core – fizycznie nie możesz uzyskać wyższego throughput w partial mesh. Ruch między dowolnymi dwoma endpointami w L&S pokonuje dokładnie dwa uplinki leaf. W topologii AWS może pokonywać ich więcej, gdy leaf switch pełni rolę węzła tranzytowego.
Lepszy load balancing w rozwiązaniu AWS wynika prawdopodobnie z większej liczby ścieżek alternatywnych oraz algorytmu routingu uwzględniającego obciążenie linków (tzw. spraypoint routing – dwa VRF-y zamiast tuneli, co jest faktycznie eleganckim rozwiązaniem bez narzutu enkapsulacji).
Jeśli budujesz fabric z dziesiątkami tysięcy switchy, ten paper jest wart uważnej lektury. Mniejsza liczba aktywnych urządzeń to realne oszczędności CAPEX i OPEX w tej skali.
Jeśli zarządzasz typowym enterprise datacenter, możesz spokojnie zignorować hype. Kilka praktycznych punktów odniesienia:
- Cztery switche leaf połączone w full mesh zamiast dedykowanej warstwy spine – klasyczna, sprawdzona optymalizacja dla małych fabriców
- Problemy z load balancingiem w L&S rozwiązuje się przez packet spraying lub adaptive routing, zanim sięgnie się po całkowicie nową topologię
- Złożoność operacyjna przy dodawaniu/usuwaniu węzłów w quasi-random graph może niwelować zyski
AI jako wirtualne laboratorium sieciowe
Sergio A.
Przygotowanie do CCIE zawsze wymagało sprzętu. Stary serwer z eBaya, licencje, konfiguracja EVE-NG — zanim zacząłeś ćwiczyć, traciłeś dni. Istnieje szybsza droga.
Idea jest prosta: skonstruuj prompt, który każe modelowi językowemu wcielić się w urządzenie sieciowe i odpowiadać jak jego CLI. Nie jako chatbot omawiający konfigurację — ale jako interaktywny terminal.
Przykład działającego podejścia dla Cisco ASR9K:
"Act as a terminal server with two Cisco ASR9K routers connected via Te0/0/0/1 and Te0/0/0/2. Respond only with CLI output. No explanations."
ChatGPT i Gemini poprawnie odwzorowują składnię IOS-XR, zwracają output show interfaces, akceptują komendy konfiguracyjne i utrzymują stan sesji w obrębie konwersacji.
Największy zysk pojawia się przy technologiach, do których brak obrazów qcow2 lub dostęp do sandboxa jest ograniczony. Nvidia Spectrum-X to dobry przykład — brak publicznie dostępnego emulatora, a środowisko Nvidii jest niedostępne bez kontraktu.
Prompt z topologią clos (2 leaf, 1 spine) na Spectrum-X generuje działające wyjścia CLI zgodne z NVOS. Podobnie działa z SONiC — model zna składnię sonic-cli i potrafi odwzorować typowe workflow konfiguracyjne.
Praktyczne przypadki użycia:
- Szybka weryfikacja składni przed wdrożeniem na produkcji
- Nauka nowych platform bez dostępu do sprzętu
- Prototypowanie topologii MPLS/SR przed laboratorium fizycznym
- Odświeżenie wiedzy z legacy systemów (Cisco PIX, starsze IOS)
To nie jest zamiennik prawdziwego emulatora. Model nie utrzymuje pełnego stanu między sesjami, nie symuluje zachowania protokołów w czasie rzeczywistym i może halucynować nieistniejące komendy — szczególnie przy niszowych platformach lub edge case'ach konfiguracyjnych.
Traktuj to jako narzędzie do nauki składni i eksploracji funkcjonalności, nie do walidacji zachowania protokołów pod obciążeniem.
Gotowe prompty są dostępne w otwartym repozytorium: prompts.chat (GitHub: f/prompts.chat). Znajdziesz tam bazę wyjściową dla network router emulator — wystarczy dostosować platformę i topologię do swoich potrzeb.
Jeśli chcesz zbudować własny prompt: kluczowe jest jawne określenie platformy, wersji systemu operacyjnego oraz instrukcja, by model odpowiadał wyłącznie outputem CLI — bez komentarzy i wyjaśnień. To eliminuje większość problemów z niespójnością odpowiedzi.
Lekki kolektor NetFlow
Michaelbecze
FlowMaster to lekki kolektor NetFlow v5 oraz pulpit nawigacyjny do analizy w czasie rzeczywistym, przeznaczony dla domowych i małych biur. Odbiera dane z przełączników Cisco IOS i pfSense, przechowuje je w SQLite, a następnie wyświetla interaktywny dashboard w przeglądarce z aktualizacjami co 5 sekund. Dzięki temu łatwo monitorujesz ruch sieciowy, widzisz podział protokołów, aplikacji, głównych nadawców oraz mapę przepływów między źródłami i celami.
Awesome Fortinet
yuriskinfo
Strona zawiera bogatą kolekcję zasobów i narzędzi związanych z Fortinet – od oficjalnego wsparcia technicznego i forów społecznościowych, przez aktualności o zagrożeniach i nowych wersjach oprogramowania, po blogi, wideotutoriale oraz skrypty automatyzujące zarządzanie urządzeniami. Znajdziesz tu także rekomendacje szkoleń, dostęp do materiałów demo oraz liczne linki do repozytoriów z przykładami i narzędziami.
Egzamin, który zmienia sposób myślenia o projektowaniu sieci
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