Netmiko kontra Ansible
Jeśli konfigurujesz urządzenia sieciowe przez Ansible i zastanawiasz się, czy warto przesiąść się na coś szybszego - odpowiedź brzmi: zdecydowanie tak. Autor netlab przeprowadził test porównawczy, który pokazuje skalę różnicy.
Scenariusz testowy obejmował pełną konfigurację laba EVPN - normalizację konfiguracji, VLAN-y, OSPF, BGP, VRF-y i VXLAN. Do konfiguracji przełączników Arista EOS użyto trzech metod: skryptów bash, Netmiko oraz Ansible. Wyniki (czas rzeczywisty):
- Skrypty bash: 4,3 s
- Netmiko: 6,2 s
- Ansible: 33,1 s
Ansible potrzebował niemal 5,5 raza więcej czasu niż Netmiko i ponad 7 razy więcej czasu CPU (9,8 s vs 0,9 s). Dla porównania - samo uruchomienie laba (start kontenerów i VM-ek) zajęło 23,5 sekundy, czyli mniej niż konfiguracja przez Ansible.
Netmiko robi jedną rzecz: zarządza sesjami SSH i wgrywa konfiguracje. Ansible to szwajcarski scyzoryk - orkiestracja, idempotencja, moduły do wszystkiego. Porównywanie ich wprost to jak zestawianie piły łańcuchowej z scyzorykiem.
Ale w kontekście netlab liczy się tylko jedno zadanie: szybkie wgranie konfiguracji do urządzenia. A w tym zadaniu Netmiko miażdży Ansible - mniejszy narzut, brak dodatkowej warstwy abstrakcji, brak "szumu" w konsoli podczas wykonywania playbooka.
Netlab planuje uczynić Netmiko domyślną metodą konfiguracji dla Arista EOS, Cisco IOS, Cisco Nexus OS, Cisco IOS XR oraz maszyn wirtualnych FRRouting w najbliższych miesiącach. Różnica czasowa może wydawać się mało istotna przy wolno startujących VM-kach, ale przy kontenerach i większej liczbie urządzeń w labie potrafi realnie wydłużyć cykl testowy.
Dodatkowy plus: Netmiko działa przez standardowe SSH, bez potrzeby uciekania się do hacków typu skrypty FastCLI dla kontenerów Arista EOS. Ta sama metoda sprawdza się zarówno dla VM-ek, jak i kontenerów - mniej wyjątków w kodzie, mniej miejsc do debugowania.
Od skryptów Python do MCP
KWAME ASAMOAH FRIMPONG
Automatyzacja sieci przeszła długą drogę: od Pythona i Netmiko, przez Ansible i AWX, po API i orkiestratory jak Cisco NSO. Teraz na horyzoncie pojawia się kolejna warstwa – serwery Model Context Protocol (MCP). Warto zrozumieć, czym to realnie jest, zanim zaleje nas kolejna fala hype'u wokół AI.
MCP nie zastępuje Pythona, Ansible czy CI/CD – to warstwa integracyjna, która pozwala aplikacjom AI odkrywać narzędzia, pobierać dane i uczestniczyć w kontrolowanych workflow. Specyfikacja opiera się na trzech prymitywach: tools (operacje wykonywalne), resources (dane infrastrukturalne) i prompts (reużywalne workflow).
W praktyce oznacza to serwer MCP dla np. Cisco IOS XE/XR, FortiGate czy Juniper Junos, który udostępnia modelowi AI ustrukturyzowany dostęp do urządzeń – zamiast polegać na pamięci modelu czy surowym CLI.
Najważniejsza lekcja z budowy wielu takich integracji (Cisco, FortiGate, Palo Alto, MikroTik, NetBox, Zabbix) to powtarzalny wzorzec inżynierski, niezależny od vendora:
- Domyślny tryb tylko do odczytu, zapis wymaga jawnej autoryzacji
- Wymagane potwierdzenie i uzasadnienie dla zmian konfiguracji
- Backup konfiguracji i workflow transakcyjne przed mutacją
- Audyt log bez przechowywania sekretów
- Weryfikacja stanu po zmianie – sukces komendy ≠ sukces operacji
To właśnie granica wokół narzędzia – co może zobaczyć, co może zmienić, co musi odrzucić – stanowi realną wartość inżynierską, nie samo podłączenie modelu do urządzenia.
Zamiast polecenia „wykonaj te pięć komend na routerze”, MCP otwiera drogę do: „zbadaj problem z usługą, sprawdź dokumentację, porównaj stan docelowy z rzeczywistym, zaproponuj bezpieczną zmianę i zweryfikuj wynik po zatwierdzeniu”. To przesunięcie z wykonywania komend na kontekstowe, kontrolowane politykami inżynierstwo infrastruktury.
Tester protokołów sieciowych
BNG Blaster to otwartoźródłowe narzędzie do testowania sieci, obsługujące zarówno protokoły dostępowe, jak i routingu. Umożliwia symulowanie milionów abonentów PPPoE i IPoE, testowanie IPTV, L2TP, BGP, OSPF, IS-IS, LDP oraz EVPN, a także sprawdzanie przekazywania ruchu, jakości usług i czasu konwergencji.
Mucha w labie
NetworkFly to interaktywna demonstracja sieci Cisco Modeling Labs, w której widoczna mucha odwiedza urządzenia, wykonuje rzeczywiste polecenia i prezentuje zweryfikowane wyniki. Możesz wybrać tryb Learning Lab, gdzie model neuronowy uczy się reagować na usterki routerów na podstawie informacji z urządzeń i otrzymywanych nagród, albo Classic CRUD, który realizuje wcześniej zaprogramowane zadania, takie jak odczyt konfiguracji, tworzenie loopbacków czy testowanie łączności. Platforma zawiera także trójwymiarowy podgląd modelu connectome oraz zapisane wyniki eksperymentów, dzięki czemu można sprawdzić, jak system działa w praktyce.
Jak operatorzy dostarczają IPTV milionom abonentów
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