Cisco 350-401: Automatyzacja, programowalność i APIs — Przewodnik do nauki

By Laurynas Brazys · 15 August 2026 · #cisco #350-401 #certification #exam-prep #study-guide

Część Cisco CCNP Enterprise 350-401 ENCOR — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Cisco, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Sieci korporacyjne przechodzą od konfiguracji urządzenie po urządzeniu w kierunku operacji opartych na kontrolerach, sterowanych intencjami (intent-driven) i z automatyzacją w pętli zamkniętej. Programowalność udostępnia stan i kontrolę sieci poprzez API i modele danych, podczas gdy narzędzia takie jak Python, Ansible i Git umożliwiają powtarzalne i testowalne przepływy pracy (workflows). Celem jest deklaratywne wyrażanie pożądanych rezultatów, aby kontrolery tłumaczyły intencje na polityki i konfiguracje, mierzyły wyniki za pomocą telemetrii i systemów zapewniania jakości (assurance) oraz naprawiały odchylenia automatycznie lub po zatwierdzeniu przez człowieka. Osiągnięcie tego wymaga zrozumienia ról kontrolerów, API i protokołów (REST, NETCONF/RESTCONF z YANG), formatów danych (JSON, XML, YAML), platform automatyzacji (Cisco DNA Center) oraz dyscyplin operacyjnych (idempotentność, kontrola wersji, testowanie, zarządzanie ryzykiem i wycofywanie zmian).

Kontrolery, intencje i operacje w pętli zamkniętej

• Sieci oparte na kontrolerach i role:
  • Cisco SD-WAN rozdziela płaszczyzny: vManage zapewnia pojedynczą płaszczyznę zarządzania; vSmart zarządza płaszczyzną sterowania i dystrybuuje polityki, które kierują przesyłaniem danych w całej strukturze (fabric); vBond orkiestruje proces dołączania (onboarding) i może działać jako serwer STUN do przechodzenia przez NAT. Routery brzegowe SD‑WAN używają OMP jako protokołu płaszczyzny sterowania do komunikacji z vSmart.
  • Cisco SD‑Access tworzy sieć nakładkową (overlay), która zapewnia logiczną separację w warstwie 2 i 3. Węzeł płaszczyzny sterowania struktury (fabric control-plane node) utrzymuje globalną bazę danych mapującą punkty końcowe na lokalizacje, podczas gdy węzeł brzegowy struktury (fabric border node) łączy strukturę z sieciami zewnętrznymi. W sieciach bezprzewodowych Radio Resource Management działa na kontrolerze bezprzewodowym.
• Intencje i konfiguracja deklaratywna:
  • Intencja opisuje pożądany rezultat, a nie sposób jego wdrożenia na każdym urządzeniu. Systemy deklaratywne (na przykład „segmentuj gości wszędzie z dostępem tylko do Internetu”) pozwalają kontrolerom kompilować polityki na konfiguracje specyficzne dla urządzeń.
  • Wady i zalety: Modele deklaratywne upraszczają operacje i redukują dryf konfiguracyjny, ale mogą ukrywać szczegóły implementacji. Operatorzy potrzebują transparentnych narzędzi do porównywania zmian (diff/preview) i wycofywania (rollback), aby utrzymać zaufanie.
• Operacje w pętli zamkniętej:
  • Mierz: Zbieraj stan za pomocą telemetrii strumieniowej i systemów zapewniania jakości (assurance) kontrolera.
  • Analizuj: Wykrywaj odchylenia od intencji (np. naruszenia segmentacji, spadki SLA).
  • Działaj: Naprawiaj poprzez aktualizacje polityk, zmiany konfiguracji lub inżynierię ruchu.
  • Tryby awarii: Burze zdarzeń lub zaszumiona telemetria mogą wywoływać fałszywe alarmy (false positives); pętle naprawcze mogą wpadać w oscylacje. Zabezpieczenia (ograniczenia szybkości, histereza, zatwierdzenia przez człowieka) i solidna korelacja zapobiegają niestabilności (thrashing).

API, modele danych i protokoły

• API REST:
  • Metody: GET (odczyt), POST (utworzenie/akcja), PUT (zastąpienie), PATCH (częściowa aktualizacja), DELETE (usunięcie), HEAD/OPTIONS (metadane).
  • Kody statusu: 2xx sukces (200 OK, 201 Created), 3xx przekierowania, 4xx błędy klienta (400 bad input, 401 unauthorized, 403 forbidden, 404 not found, 409 conflict, 429 rate limit), 5xx błędy serwera (500, 503).
  • Uwierzytelnianie: Basic (przez TLS), schematy oparte na tokenach/bearer oraz OAuth 2.0. Zawsze używaj TLS; unikaj osadzania poświadczeń w URI. Obsługuj odświeżanie i wygasanie tokenów.
  • Ograniczenia szybkości (Rate limits): Serwery mogą dławić ruch (throttle) za pomocą kodu 429 i nagłówka Retry-After. Implementuj w klientach wykładnicze ponawianie (exponential backoff), jitter oraz śledzenie budżetu żądań.
• Formaty danych i walidacja:
  • JSON jest powszechny dla REST; XML pozostaje popularny w NETCONF; YAML jest używany do plików tworzonych przez człowieka (inwentarze, playbooki, zestawy zmiennych). W razie potrzeby konwertuj wewnętrznie YAML na JSON.
  • Walidacja schematu: Używaj JSON Schema dla danych JSON; XML Schema dla XML; YANG dla zarządzania opartego na modelach (typy, ograniczenia, instrukcje must/when). Waliduj po stronie klienta przed wysłaniem, aby wcześnie wykrywać błędy.
• NETCONF, RESTCONF, YANG, RPC i magazyny danych (datastores):
  • Modele YANG definiują struktury danych i operacje dla konfiguracji i stanu.
  • NETCONF używa XML przez SSH, operacje takie jak , , , , , . Magazyny danych (datastores) zazwyczaj obejmują running i candidate; candidate umożliwia przygotowanie i zatwierdzenie zmian (prepare-and-commit) z zachowaniem atomowości.
  • RESTCONF mapuje zasoby modelowane w YANG na interfejs RESTful przez HTTP(S), używając JSON lub XML ze standardowymi typami mediów. Metody mapują się na semantykę NETCONF (PATCH/PUT do edycji).
  • Tryby awarii i projektowanie:
    • Rywalizacja o blokady (Lock contention): Koordynuj użycie , aby unikać zakleszczeń (deadlocks); używaj wąskiego zakresu i limitów czasowych.
    • Częściowe awarie: Preferuj magazyn danych candidate + dla transakcyjnych zmian. Jeśli dostępny jest tylko running, używaj ustrukturyzowanych grup zmian i punktów kontrolnych (checkpoints).
    • Dryf modeli: Urządzenia mogą obsługiwać różne wersje modułów YANG; negocjuj możliwości i testuj podczas CI.
• Zwięzłe przykłady:
  • Częściowa aktualizacja RESTCONF (wymiana HTTP): PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1 Content-Type: application/yang-data+json { “ietf-interfaces:interface”: { “name”: “GigabitEthernet1”, “description”: “Uplink”, “enabled”: true } }
  • NETCONF z Pythonem (ncclient): from ncclient import manager cfg = """ GigabitEthernet1 Uplink true """ with manager.connect(host=“r1”, port=830, username=“netops”, password="***", hostkey_verify=False) as m: m.edit_config(target=“candidate”, config=cfg) m.commit()

Narzędzia i przepływy pracy: Python, Ansible, Git i pipeline’y

• Automatyzacja w Cisco DNA Center:
  • Interfejsy REST API typu Northbound zapewniają dostęp do inwentarza, szablonów, provisioningu i funkcji assurance. Interfejsy Southbound łączą kontroler z urządzeniami (CLI, SNMP, NETCONF/RESTCONF) w celu wdrożenia intencji.
  • Procesy wykrywania (discovery) mogą używać CDP, LLDP i zakresów adresów IP. Stosuj kontrolę dostępu opartą na rolach, szablony projektowe i zmienne per lokalizacja. Funkcja Assurance koreluje dane telemetryczne, przekształcając je w problemy, wskaźniki kondycji i sugerowane działania naprawcze — kluczowe dane wejściowe dla automatyzacji w pętli zamkniętej.
• Podstawy języka Python w automatyzacji sieci:
  • Rdzeń języka: typy, funkcje, moduły, środowiska wirtualne i logowanie.
  • Biblioteki: requests/httpx (REST), ncclient (NETCONF), jinja2 (szablony), pyyaml, json, pandas (przetwarzanie danych), rich/logging dla obserwowalności.
  • Dobre praktyki: walidacja danych wejściowych, ponawianie prób z mechanizmem backoff, ustrukturyzowane wyjątki, timeouty i testy jednostkowe. Oddzielaj logikę biznesową od operacji I/O, aby uprościć testy.
• Ansible:
  • Inwentarz (inventory) definiuje hosty i grupy; przechowuj host_vars/group_vars w formacie YAML.
  • Playbooki deklarują pożądany stan; moduły takie jak ios_config, ios_facts, iosxe_config, restconf_config i uri wykonują akcje. Używaj ról (roles) do hermetyzacji logiki wielokrotnego użytku.
  • Idempotentność: Moduły zapewniają, że wielokrotne uruchomienia prowadzą do tego samego stanu bez niezamierzonych zmian. Użyj check_mode i diff, aby zobaczyć podgląd zmian; powiadamiaj handlery, aby zapisały zmiany tylko wtedy, gdy wystąpiły.
  • Przykład:
    • hosts: edge connection: network_cli gather_facts: no tasks:
      • ios_config: parents: interface GigabitEthernet1 lines: - description Uplink notify: save handlers:
      • name: save ios_config: save_when: changed
  • Kontrola zmian: używaj okien serwisowych, strategii szeregowej lub wsadowej oraz ograniczania wdrożeń (throttling) per lokalizacja, aby ograniczyć promień rażenia (blast radius). Automatycznie wykonuj sprawdzenia przed i po wdrożeniu.
• Git, wersjonowanie, testowanie i pipeline’y:
  • Przechowuj intencje sieciowe (zmienne YAML, szablony Jinja, playbooki), wygenerowane konfiguracje i testy w Git. Używaj gałęzi (branches), pull requestów i przeglądu kodu (code review). Semantyczne commity i tagi pozwalają powiązać wersje z wdrożeniami.
  • Testowanie: lintuj pliki YAML i playbooki, waliduj schematy YANG/JSON, uruchamiaj testy jednostkowe i testy scenariuszowe Ansible Molecule. Integruj syntetyczne testy wstępne (np. sprawdzanie osiągalności) w ramach CI.
  • Pipeline’y: Dev → środowisko przejściowe/laboratoryjne (staging/lab) → wdrożenie typu canary na produkcji → wdrożenie etapowe. Bramki (gates) obejmują analizę statyczną, uruchomienia na sucho (dry-runs) na symulatorach, zatwierdzenia i automatyczne wycofanie zmian (rollback) w przypadku pogorszenia kondycji systemu.

Telemetria, automatyzacja sterowana zdarzeniami i zarządzanie ryzykiem

• Strumieniowanie telemetrii:
  • Telemetria sterowana modelem (IOS XE, NX-OS) publikuje stan modelowany w YANG w zdefiniowanych odstępach czasu przez gRPC/gNMI lub NETCONF, z subskrypcjami typu dial-in lub dial-out. Zalety obejmują niskie opóźnienia i ustrukturyzowane dane, co przewyższa okresowe odpytywanie CLI (scraping) lub SNMP.
  • Przykład (IOS XE, zwięzły):

undefined

• Wskazówki projektowe: Dostosuj częstotliwość próbkowania do przypadku użycia; zapewnij odpowiednią pojemność magistrali komunikatów (message bus); zaprojektuj potoki do downsamplingu/agregacji; zabezpiecz się przed utratą danych telemetrycznych za pomocą buforowania i potwierdzeń.
• Automatyzacja sterowana zdarzeniami:
  • Wyzwalaj akcje w odpowiedzi na webhooki, komunikaty syslog, pułapki SNMP, zdarzenia z DNA Center lub tematy w Kafka. Używaj korelacji i ograniczania szybkości (rate limiting), aby unikać niestabilności (flaps) wywołanej przez burze zdarzeń. Utrzymuj idempotentne procedury obsługi (handlery), które można bezpiecznie uruchamiać wielokrotnie.
  • Pętla zwrotna (closed-loop): Kontroler wykrywa naruszenie polityki, weryfikuje je za pomocą dodatkowych sygnałów, otwiera zgłoszenie zmiany lub uruchamia ograniczoną akcję naprawczą, a następnie ponownie mierzy i finalizuje proces.
• Zarządzanie ryzykiem, wycofywanie zmian i poświadczenia:
  • Zabezpieczenia (guardrails): Wdrożenia etapowe (staged rollouts), limity współbieżności, kontrola zasięgu oddziaływania (blast radius), dynamiczne wycofywanie (backoff) przy odpowiedziach 429/5xx oraz limity czasowe (timeouts). Używaj transakcji tam, gdzie są dostępne (NETCONF candidate + commit), lub punktów kontrolnych (checkpointów) urządzeń i polecenia configure replace.
  • Wycofanie zmian (rollback): Utrzymuj złote konfiguracje (golden configs), różnice (diffs) i punkty kontrolne dla każdego urządzenia. Preferuj semantykę commit-confirmed tam, gdzie jest wspierana; w przeciwnym razie zaimplementuj automatyczne wycofywanie przy użyciu timerów i sprawdzania osiągalności.
  • Ochrona poświadczeń: Wymuszaj RBAC, używaj tokenów o krótkim czasie życia i sekretów typu just-in-time dla poszczególnych zadań. Używaj magazynów sekretów (np. Ansible Vault lub zewnętrznego sejfu), nigdy nie osadzaj sekretów w playbookach ani w Git. Rotuj poświadczenia zgodnie z harmonogramem i po zmianach personalnych. Zabezpiecz poświadczenia na linii kontroler-urządzenie i audytuj dostęp.

Praktyczny scenariusz problemowy

Firma Aurelius Logistics planuje standaryzację konfiguracji w kampusie i oddziałach, wdrożenie spójnej segmentacji oraz implementację zapewnienia jakości w pętli zwrotnej (closed-loop assurance) przy użyciu Cisco DNA Center, jednocześnie umożliwiając bezpieczne wprowadzanie zmian za pomocą Ansible i Git.

1. Stworzenie stanu bazowego i odkrycie sieci

• Uzasadnienie: Odkrywanie sieci w DNA Center przy użyciu zakresów IP oraz protokołów CDP/LLDP pozwala na zidentyfikowanie urządzeń i topologii, tworząc autorytatywny inwentarz. Umożliwia to określenie zakresu intencji i dziedziczenie zmiennych według lokalizacji. Zbieranie danych z modułu Assurance tworzy bazowy obraz stanu sieci przed zmianą, służący do porównań i jako wyzwalacz dla procedur rollback.

2. Modelowanie intencji i szablonów w DNA Center

• Uzasadnienie: Deklaratywne definiowanie polityk segmentacji (np. pracownicy, IoT, goście) i QoS. Użycie sparametryzowanych szablonów ze zmiennymi dla lokalizacji (site variables) do konfiguracji interfejsów, routingu i list ACL. Polityka deklaratywna pozwala kontrolerowi kompilować konfiguracje specyficzne dla urządzeń, redukując błędy ludzkie i dryf konfiguracyjny.

3. Implementacja zarządzania konfiguracją w oparciu o Git

• Uzasadnienie: Przechowywanie szablonów, zmiennych dla lokalizacji (w formacie YAML) i testów walidacyjnych w Git. Gałęzie funkcyjne (feature branches) i pull requesty wymuszają wzajemną weryfikację (peer review). Tagi powiązują wdrożenia z wersjami, umożliwiając precyzyjny rollback. Zapewnia to audytowalną historię zmian i wspiera automatyczne wyzwalacze dla potoków CI/CD.

4. Zbudowanie potoku CI/CD z bramkami walidacyjnymi

• Uzasadnienie: Etapy potoku sprawdzają poprawność składni YAML (linting), walidują dane w formacie JSON/YANG, testują jednostkowo renderowanie szablonów Jinja i symulują wywołania API w środowisku testowym (sandbox). Uruchomienia na sucho (dry run) w DNA Center oraz tryby check_mode/diff w Ansible walidują zmiany bez ich wprowadzania. Dopiero po przejściu wszystkich bramek potok pozwala na zatwierdzenie wdrożenia przez operatora.

5. Wdrażanie przyrostowe z użyciem Ansible i API DNA Center

• Uzasadnienie: Użycie northbound API DNA Center do wdrożenia szablonów najpierw w lokalizacji testowej (canary site), a następnie seryjne wdrażanie w kolejnych lokalizacjach z ograniczeniem wielkości partii. Dla urządzeń wspierających NETCONF/RESTCONF, moduły Ansible wykonują celowane, idempotentne aktualizacje. To podwójne podejście wykorzystuje kontroler do zadań związanych z politykami, a bezpośrednią automatyzację urządzeń do precyzyjnych zmian, minimalizując jednocześnie zasięg oddziaływania (blast radius).

6. Aktywacja telemetrii strumieniowej i weryfikacji opartej na module Assurance

• Uzasadnienie: Skonfigurowanie telemetrii sterowanej modelem na urządzeniach brzegowych w celu zasilania modułu DNA Center Assurance oraz firmowego stosu obserwowalności. Zdefiniowanie celów poziomu usług (SLO), np. wskaźnik sukcesu onboardingu, opóźnienia, oraz subskrypcji zdarzeń, które generują alerty w przypadku pogorszenia metryk po wprowadzeniu zmiany. Umożliwia to natychmiastowe wykrywanie negatywnych skutków.

7. Uruchomienie kontrolowanej naprawy w pętli zwrotnej

• Uzasadnienie: Dla dobrze zrozumiałych odchyleń (np. wyłączenie interfejsu ze znanym obejściem), pozwól potokowi na uruchomienie ograniczonego playbooka w celu wycofania ostatniej zmiany lub zastosowania szybkiej poprawki (hotfix). Wymagaj zgody człowieka dla szerszych akcji naprawczych. Zaimplementuj mechanizmy exponential backoff i cooldown, aby zapobiec oscylacjom.

8. Przygotowanie i testowanie ścieżek wycofania zmian

• Uzasadnienie: Przed każdą zmianą twórz punkty kontrolne (checkpointy) na urządzeniach lub używaj NETCONF candidate + commit-confirmed, jeśli jest dostępne. Archiwizuj konfiguracje sprzed zmiany i oznaczaj repozytorium Git odpowiednim tagiem. Jeśli wskaźniki kondycji spadną lub telemetria wykaże naruszenie SLA, potok wykonuje configure replace lub NETCONF discard/rollback, szybko przywracając poprzedni stan.

9. Ochrona poświadczeń i egzekwowanie kontroli dostępu

• Uzasadnienie: Przechowuj poświadczenia do urządzeń/kontrolera w sejfie (vault); wstrzykuj do zadań tokeny o krótkim czasie życia. Używaj RBAC w DNA Center do ograniczania zakresów API. Nigdy nie loguj sekretów; czyść dane wyjściowe w potokach CI. Regularnie rotuj poświadczenia i tokeny, a także po zmianach personalnych, aby zredukować ryzyko.

10. Wdrożenie operacyjne z dokumentacją i runbookami

• Uzasadnienie: Dokumentuj definicje intencji, schematy zmiennych, tryby awarii (np. limity zapytań, błędy API, niedopasowanie modeli) oraz kroki odzyskiwania. Przeszkol zespół NOC w interpretacji sygnałów z modułu Assurance i statusów potoku, aby zapewnić spójne i szybkie reagowanie na incydenty.

Takie podejście tworzy bezpieczną, testowalną ścieżkę od intencji do implementacji, wykorzystuje kontrolery do dystrybucji polityk (z vManage/vSmart w SD‑WAN i DNA Center w kampusie), używa idempotentnych narzędzi do osiągnięcia zbieżności oraz zamyka pętlę za pomocą walidacji opartej na telemetrii i kontrolowanych akcji naprawczych.

← Bezpieczeństwo korporacyjne i usługi tożsamości · Wszystkie domeny · Zapewnienie działania sieci →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →