> ## Content Index > Fetch the complete content index at: https://innasiec.pl/llms.txt > Use this file to discover other available public pages before exploring further. # 📬 ISN 187: Sieciowy DevOps w Praktyce, Sztuczki z MAC Adresami i Lekcje z IPv6! - URL: https://innasiec.pl/isn-187-sieciowy-devops-w-praktyce-sztuczki-z-mac-adresami-i-lekcje-z-ipv6/ - Published: 2025-05-19T08:00:57.000Z - Updated: 2025-05-19T08:00:57.000Z - Description: W numerze 187 poznasz fatalne błędy we wdrażaniu IPv6, MCP dla NetOps, drogę od inżyniera do architekta, sekret zbierania adresów MAC oraz praktyczne zastosowanie sieciowego DevOps. Nie przegap! - Author: Rafał Rudewicz - Tags: #newsletter, #toc SPONSORED Sponsorem tego wydania jest ****Sycope**, firma specjalizująca się w monitorowaniu ruchu sieciowego oraz bezpieczeństwie IT. Oferuje zaawansowane rozwiązania do nadzoru nad infrastrukturą sieciową, wykrywania i analizy zagrożeń bezpieczeństwa oraz optymalizacji wydajności sieci i aplikacji. W najbliższy wtorek, ****20 maja** o godzinie ****10:00** odbędzie się darmowy webinar pt.: ****"Kontrolowanie sieci hybrydowych poprzez automatyczną inwentaryzację zasobów, aplikacji i ich połączeń**" [Zapisz się na webinar ](https://webinar.sycope.com/?utm%5Fsource=Inna-siec&utm%5Fmedium=mail&utm%5Fcampaign=Webinar-asset) ## Fatalne sposoby wdrażania IPv6 [Bad IPv6 Approaches | Weberblog.net![](https://innasiec.pl/content/images/icon/cropped-webernetz-logo-4-icon-2000x2000-1-180x180-6.png)Weberblog.netJohannes Weber![](https://innasiec.pl/content/images/thumbnail/Bad-IPv6-Approaches-featured-image-604x270.jpg)](https://weberblog.net/bad-ipv6-approaches/?ref=innasiec.pl) Zastanawiałeś się, ile złych praktyk wokół IPv6 wciąż jest wdrażanych przez firmy? Te błędy mogą kosztować czas, niezawodność i bezpieczeństwo. **1\. Pozostanie przy IPv4 w LAN i NATowanie ruchu do IPv6 (NAT46)** Pierwszy pomysł — trzymanie wyłącznie adresacji IPv4 w sieci lokalnej i zastosowanie mechanizmu NAT46 na brzegu przy wyjściu do Internetu przez IPv6. **Dlaczego to zły pomysł?** - NAT46 tworzy zbyteczną złożoność. Konfiguracja i diagnostyka stają się trudniejsze. - Możliwość translacji NAT46 nie zawsze jest dostępna na typowych urządzeniach. - Klienci nie korzystają z natywnego IPv6 – tracisz automatyczne end-to-end, wydajność i uproszczone zarządzanie trasami. - NAT zwiększa opóźnienia, obciążenie urządzeń i ryzyko „tajemniczych” błędów. **Podejście poprawne:** Uruchomić IPv6 w sieci LAN i umożliwić hostom natywną komunikację do Internetu poprzez IPv6. **2\. Zastosowanie NAT66 zamiast NPTv6** Kolejny pomysł — administratorzy chcieli używać wewnętrznego zakresu IPv6, a na brzegu NATować adresacje do ISP. Wybrali NAT66\. To poważny błąd. **Dlaczego NAT66 to ślepa uliczka?** - NAT66 tłumaczy cały (128-bitowy) adres. Często stosuje się wtedy także PAT, co nie ma sensu przy ogromnej puli IPv6. - NAT66 jest „zastępcą” NAT44 z IPv4\. W świecie IPv6 nie istnieje problem braku adresów. - Skomplikowanie ruchu i utrudnienie rozwiązywania problemów. - NAT nie dodaje bezpieczeństwa! Skupienie się na filtracji ruchu i segmentacji jest skuteczniejsze. **Właściwe rozwiązanie:** Jeśli musisz przetłumaczyć prefiks (na przykład dla failover między ISP), zastosuj NPTv6\. Translacja dotyczy tylko części sieciowej, adres hosta i numery portów pozostają bez zmian. Jest to bezstanowe i szybkie. **3\. Wykorzystywanie ULA jako „prywatnych” adresów IPv6** Wielu szuka odpowiednika RFC1918 dla IPv6 i ląduje przy Unique Local Addresses (ULA). To kolejny duży błąd w typowych wdrożeniach. **Główne wady ULA:** - **Brak routowalności:** ULA nie mogą być routowane poza sieć lokalną. Translacja ich do Internetu jest niezalecana i problematyczna. - **Preferencje w dual-stack:** Zgodnie z RFC6724, hosty preferują IPv4 nad ULA, jeśli oba są dostępne. IPv6 w tej postaci przestaje praktycznie działać. - **Ryzyko kolizji:** Nawet przy 40-bitowym random Global ID, niepoprawna generacja prowadzi do konfliktów przy fuzjach, VPN-ach czy peeringu. - **Złożoność routingowa:** Mieszanie ULA i GUA komplikuje trasowanie i diagnostykę. - **Brak dodatkowego bezpieczeństwa:** ULA nie są mechanizmem ochronnym. Jeśli ruch opuści sieć i nie ma firewalla, są podatne na ataki. **Rekomendacja:** ULA stosuj tylko w szczególnych przypadkach (np. odseparowane segmenty lub laboratoria). W środowisku produkcyjnym korzystaj zawsze z odpowiedniej, bezpiecznej adresacji GUA. **Lepsze scenariusze adresacji IPv6** - Wybierz jeden prefiks GUA od ISP jako główny. W razie awarii przełącz translację (NPTv6) do drugiego ISP. - Idealnie? Uzyskaj własny prefiks (np. przez sponsoring LIR). Zachowasz pełną niezależność od operatorów, uprościsz zarządzanie i uprościsz polityki routingu. **Skąd te złe pomysły?** 1. **Produkty klasy UTM:** Przykład FortiGate, gdzie domyślnie promowane jest użycie NAT także dla IPv6\. Może to wprowadzać w błąd niewyedukowanych administratorów. 2. **Syndrom „IPv4 thinking”:** Przyzwyczajenie do adresacji prywatnej i NAT przenoszone żywcem do architektury IPv6. 3. **Mylące publikacje i dokumentacja:** Wciąż można znaleźć poradniki sugerujące, że ULA to właściwa alternatywa dla RFC1918. --- ## MCP dla NetOps [MCP for DevOps, NetOps, and SecOps: Real-World Use Cases and Future InsightsMCP for DevOps, NetOps, and SecOps: Real-World Use Cases and Future Insights In the previous post on MCP for DevOps: Architecture and Components, we![](https://innasiec.pl/content/images/icon/cropped-Cisco-logo-thumb-sky-blue-300x300-1.jpg)Cisco BlogsShannon McFarland![](https://innasiec.pl/content/images/thumbnail/mcp-usecases-abstract.png)](https://blogs.cisco.com/developer/mcp-usecases?ref=innasiec.pl) Czy wyobrażasz sobie AI, które automatycznie zarządza Twoją siecią, automatyzuje procesy DevOps i błyskawicznie reaguje na incydenty bezpieczeństwa? Poznaj Model Context Protocol (MCP) – technologię, która umożliwia takie scenariusze. **Model Context Protocol (MCP) to protokół komunikacyjny zaprojektowany z myślą o agentach i aplikacjach AI**. MCP umożliwia im skuteczne i jednolite integrowanie się z narzędziami, API, bazami danych czy systemami plików. Najważniejsze cechy MCP: - Jest lekki, prosty i przewidywalny – oparty na architekturze klient-serwer. - Łączy agentów AI z narzędziami i danymi w ekosystemie IT. - Działa jako „spoiwo” między AI a infrastrukturą operacyjną. Czym MCP nie jest? - Nie jest protokołem komunikacji agent–agent. - Nie jest LLM-em, bazą danych ani agentem AI. - Nie zastępuje istniejących API czy platform integracyjnych. Zastosowania MCP są bardzo szerokie, szczególnie gdy wykorzystujemy go razem z SDK po stronie klienta AI i dedykowanym serwerem MCP, który pośredniczy między agentem a narzędziami lub systemami. **MCP działa jak centralny hub dla aplikacji AI, umożliwiając im współpracę z:** - Systemami obserwacyjnymi (np. Splunk). - Orkiestratorami (np. Cisco NSO). - Platformami bezpieczeństwa AI (np. Cisco AI Defense). Aplikacje AI integrujące MCP mogą pobierać dane z różnych źródeł, co pozwala na: - Szybsze i dokładniejsze analizy. - Błyskawiczne podejmowanie decyzji na podstawie pełnego obrazu sytuacji. **Wykorzystanie MCP w praktyce** **Przykładowe użycia:** - Pełna automatyzacja pipeline’ów CI/CD. AI samo buduje, testuje, wdraża i powiadamia (np. przez Cisco Webex). - Zarządzanie kodem – AI obsługuje branche, pull requesty, triage błędów i skanuje podatności w GitHub. - Automatyczne zarządzanie infrastrukturą dzięki integracji z Terraform/Ansible. - Automatyczne reagowanie na incydenty i powiadamianie zespołów. - Zarządzanie konfiguracjami sieciowymi za pomocą poleceń w języku naturalnym. AI wykorzystuje API Cisco lub narzędzia IaC. - Monitorowanie wydajności sieci i automatyczne reagowanie na anomalie (np. Cisco ThousandEyes, Meraki Dashboard). - Zarządzanie infrastrukturą chmurową, w tym integracja z Kubernetes i kontrolerami sieciowymi Cisco. MCP jest dynamicznie rozwijanym rozwiązaniem z rosnącym ekosystemem. Pozwala wdrażać coraz bardziej inteligentne i zautomatyzowane usługi, lecz wymaga uważności. --- ## Od inżyniera do Architekta [GitHub - chronot1995/Engineer2Architect: This is the repo used for the KC NUG Keynote ProjectThis is the repo used for the KC NUG Keynote Project - chronot1995/Engineer2Architect![](https://innasiec.pl/content/images/icon/pinned-octocat-093da3e6fa40-15.svg)GitHubchronot1995![](https://innasiec.pl/content/images/thumbnail/Engineer2Architect)](https://github.com/chronot1995/Engineer2Architect/tree/main?ref=innasiec.pl) Projekt Engineer2Architect pokazuje, jak przejść z Network Engineera do Network Architecta. Składa się z prezentacji i 5 laboratoriów technicznych, uczących praktycznych umiejętności z użyciem Arista EOS, FRR i Linuxa w Containerlab z Ansible. --- SPONSORED Sponsorem tego wydania jest ****Sycope**, firma specjalizująca się w monitorowaniu ruchu sieciowego oraz bezpieczeństwie IT. Oferuje zaawansowane rozwiązania do nadzoru nad infrastrukturą sieciową, wykrywania i analizy zagrożeń bezpieczeństwa oraz optymalizacji wydajności sieci i aplikacji. W najbliższy wtorek, ****20 maja** o godzinie ****10:00** odbędzie się darmowy webinar pt.: ****"Kontrolowanie sieci hybrydowych poprzez automatyczną inwentaryzację zasobów, aplikacji i ich połączeń**" [Zapisz się na webinar ](https://webinar.sycope.com/?utm%5Fsource=Inna-siec&utm%5Fmedium=mail&utm%5Fcampaign=Webinar-asset) --- ## Zbieraj adresy MAC jak PRO > [Developing a custom solution for mac address collection and storage using Nornir, Nautobot and InfluxDB v.2.x](https://www.mythryll.com/?p=1630&ref=innasiec.pl) Projekt opisuje stworzenie autorskiego systemu do zbierania i przechowywania historii adresów MAC w sieci firmowej. Wykorzystuje do tego InfluxDB v.2.x jako bazę danych typu Time Series, Python z frameworkiem Nornir do zbierania danych z przełączników oraz Nautobot jako źródło inwentarza sieciowego. Całość działa w kontenerach Docker z automatycznym zapisem danych o adresach MAC, portach, IP i hostach, co ułatwia analizę i zarządzanie infrastrukturą sieciową, np. przy migracjach. --- ## Sieciowy DevOps w praktyce [https://medium.com/@netopschic/network-automation-series-7-configuring-static-routing-on-nokia-sr-linux-via-ansible-and-ef85edc52462](https://medium.com/@netopschic/network-automation-series-7-configuring-static-routing-on-nokia-sr-linux-via-ansible-and-ef85edc52462?ref=innasiec.pl) Czy kiedykolwiek marzyłeś, by wdrożenie i automatyzacja sieciowych labów była szybka, powtarzalna i bliska podejściu “infra as code”? Jeśli twoja odpowiedź brzmi “tak”, Containerlab może stać się twoim nowym najlepszym przyjacielem. Po latach spędzonych z GNS3 czy Packet Tracer można poczuć, że tradycyjne narzędzia nie nadążają za nowoczesnymi procesami DevOps w NetOps. **Containerlab to open-source’owe narzędzie CLI umożliwiające definiowanie i uruchamianie złożonych topologii w pliku YAML.** Wspiera podejście lab-as-code: - łatwo podlega wersjonowaniu, - idealnie nadaje się do CI/CD, - gwarantuje powtarzalność środowisk. Wyjątkowym atutem jest błyskawiczne wdrożenie – pełna topologia czterech węzłów SR Linux wystartuje w kilka chwil na twoim laptopie. **Przykładowa topologia – cztery węzły w Containerlab** W tej demonstracji budujemy układ czterech routerów SR Linux, gdzie każdy ma relacje sąsiedzkie zgodnie ze schematem: ``` node1──node2 │ │ node4──node3 ``` Konfiguracja YAML dla Containerlab prezentuje się następująco: ```yaml name: srl-square topology: kinds: nokia_srlinux: image: ghcr.io/nokia/srlinux nodes: node1: kind: nokia_srlinux type: ixrd2l node2: kind: nokia_srlinux type: ixrd2l node3: kind: nokia_srlinux type: ixrd2l node4: kind: nokia_srlinux type: ixrd2l links: - endpoints: ["node1:e1-1", "node2:e1-1"] - endpoints: ["node2:e1-2", "node3:e1-1"] - endpoints: ["node3:e1-2", "node4:e1-1"] - endpoints: ["node4:e1-2", "node1:e1-2"] ``` Uruchamiasz wszystko jednym poleceniem: ``` containerlab deploy -t nokia.clab.yaml ``` Dodatek Containerlab do VSCode generuje graficzny podgląd topologii i pozwala na szybkie połączenie z konsolami urządzeń. **Automatycznie generowany inwentarz Ansible** Po wdrożeniu labu, Containerlab automatycznie utworzy inventory Ansible z danymi dostępowymi do każdego węzła. Przykładowy fragment: ```yaml clab-srl-square-node1: ansible_host: 172.20.20.5 ansible_user: admin ansible_password: NokiaSrl1! ansible_network_os: nokia.srlinux.srlinux ansible_connection: ansible.netcommon.httpapi ``` To ogromne ułatwienie – nie tracisz czasu na przygotowywanie ręcznych plików inventory. **Ansible: wyzwania i wzorzec konfiguracji** Konfigurowanie interfejsów i tras statycznych na SR Linux przez Ansible nie jest jeszcze tak intuicyjne, jak w przypadku Cisco IOS czy Aristy EOS. Kolekcja `nokia.srlinux` jest młoda, a oficjalna dokumentacja YANG potrafi być nieczytelna. Najważniejsze elementy playbooka dla każdego węzła to: - Włączanie interfejsów i subinterfejsów, - Nadawanie adresacji IPv4, - Przypisywanie subinterfejsów do VRF (network-instance), - Definicja grup next-hop, - Konfiguracja tras statycznych, - Commit zmian na urządzeniu. Struktura zadania w playbooku wygląda następująco (fragment przykład z node1): ```yaml - name: Apply Node1 subinterfaces, NHGs & routes nokia.srlinux.config: datastore: candidate save_when: changed update: - path: /interface[name=ethernet-1/1]/admin-state value: enable - path: /interface[name=ethernet-1/1]/subinterface[index=0]/ipv4/address[ip-prefix=10.1.1.1/24] value: {} # (... dalej konfiguracje interfejsów ...) - path: /network-instance[name=default]/static-routes/route[prefix=30.1.1.0/24]/next-hop-group value: nhg1 # (... dalsze trasy ...) ``` Każdy node dostaje analogiczne zadania dostosowane do swojej roli w topologii. **Porównanie z innymi platformami** - **Cisco i Arista** mają bardziej dojrzałe kolekcje Ansible oraz dużo przystępniejsze modele YANG/CLI. - **Nokia SR Linux** oferuje olbrzymią elastyczność (YANG na sterydach) – to atut, ale jednocześnie tworzy strome wejście dla prostych automatyzacji. - Containerlab rozwiązuje problem integracji, generując gotowe inventory oraz automatyzując dostęp do urządzeń.