📬 ISN 187: Sieciowy DevOps w Praktyce, Sztuczki z MAC Adresami i Lekcje z IPv6!

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

Fatalne sposoby wdrażania IPv6

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?

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.
Syndrom „IPv4 thinking”: Przyzwyczajenie do adresacji prywatnej i NAT przenoszone żywcem do architektury IPv6.
Mylące publikacje i dokumentacja: Wciąż można znaleźć poradniki sugerujące, że ULA to właściwa alternatywa dla RFC1918.

MCP dla NetOps

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

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.

Zapisz się na webinar

Zbieraj adresy MAC jak PRO

Developing a custom solution for mac address collection and storage using Nornir, Nautobot and InfluxDB v.2.x

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

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:

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:

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):

- 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ń.