Cisco 350-401: Automatisierung, Programmierbarkeit und APIs — Lernleitfaden

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

Teil des Cisco CCNP Enterprise 350-401 ENCOR — Lernleitfaden. Üben Sie mit verifizierten Antworten im Cisco-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Unternehmensnetzwerke bewegen sich von der gerätebasierten Konfiguration hin zu Controller-basierten, absichtsgesteuerten Abläufen mit geschlossener Regelkreisautomatisierung. Programmierbarkeit legt den Netzwerkzustand und die Steuerung über APIs und Datenmodelle offen, während Tools wie Python, Ansible und Git wiederholbare, testbare Workflows ermöglichen. Das Ziel ist, gewünschte Ergebnisse deklarativ auszudrücken, Controller die Absicht in Richtlinien und Konfigurationen übersetzen zu lassen, die Ergebnisse durch Telemetrie und Assurance zu messen und Abweichungen automatisch oder mit menschlicher Genehmigung zu beheben. Um dies zu erreichen, ist ein Verständnis der Controller-Rollen, APIs und Protokolle (REST, NETCONF/RESTCONF mit YANG), Datenformate (JSON, XML, YAML), Automatisierungsplattformen (Cisco DNA Center) und operativen Disziplinen (Idempotenz, Versionskontrolle, Tests, Risikomanagement und Rollback) erforderlich.

Controller, Absicht und Closed-Loop-Betrieb

• Controller-basiertes Networking und Rollen:
  • Cisco SD-WAN trennt die Ebenen: vManage stellt die zentrale Management-Ebene bereit; vSmart verwaltet die Kontrollebene und verteilt Richtlinien, die die Datenweiterleitung über die Fabric steuern; vBond orchestriert das Onboarding und kann als STUN-Server fungieren, um NAT zu durchqueren. SD-WAN Edge Router verwenden OMP als Protokoll der Kontrollebene, um mit vSmart zu kommunizieren.
  • Cisco SD-Access erstellt ein Overlay-Netzwerk, das eine logische Trennung auf Layer 2 und Layer 3 bietet. Ein Fabric Control-Plane Node unterhält eine globale Endpunkt-zu-Standort-Datenbank, während ein Fabric Border Node die Fabric mit externen Netzwerken verbindet. Im Wireless-Bereich läuft das Radio Resource Management auf dem Wireless Controller.
• Absicht und deklarative Konfiguration:
  • Die Absicht beschreibt das gewünschte Ergebnis, nicht wie es auf jedem einzelnen Gerät umgesetzt wird. Deklarative Systeme (z. B. „Gäste überall mit reinem Internetzugang segmentieren“) ermöglichen es Controllern, Richtlinien in gerätespezifische Konfigurationen zu kompilieren.
  • Kompromisse: Deklarative Modelle vereinfachen den Betrieb und reduzieren Drift, können aber Implementierungsdetails verbergen. Betreiber benötigen transparente Werkzeuge für Diff/Vorschau und Rollback, um das Vertrauen aufrechtzuerhalten.
• Closed-Loop-Betrieb:
  • Messen: Zustand über Streaming-Telemetrie und Controller-Assurance erfassen.
  • Analysieren: Abweichungen von der Absicht erkennen (z. B. Segmentierungsverletzungen, SLA-Einbrüche).
  • Handeln: Behebung durch Richtlinien-Updates, Konfigurationsänderungen oder Traffic Engineering.
  • Fehlermodi: Ereignisstürme oder verrauschte Telemetriedaten können Fehlalarme auslösen; Behebungsschleifen können oszillieren. Leitplanken (Ratenbegrenzungen, Hysterese, Genehmigungen durch Menschen) und eine robuste Korrelation verhindern Thrashing.

APIs, Datenmodelle und Protokolle

• REST APIs:
  • Methoden: GET (lesen), POST (erstellen/Aktion), PUT (ersetzen), PATCH (teilweise aktualisieren), DELETE (entfernen), HEAD/OPTIONS (Metadaten).
  • Statuscodes: 2xx Erfolg (200 OK, 201 Created), 3xx Weiterleitungen, 4xx Client-Fehler (400 Bad Input, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 429 Rate Limit), 5xx Server-Fehler (500, 503).
  • Authentifizierung: Basic (über TLS), Token/Bearer-Schemata und OAuth 2.0. Verwenden Sie immer TLS; vermeiden Sie das Einbetten von Anmeldeinformationen in URIs. Behandeln Sie die Token-Erneuerung und den Ablauf.
  • Ratenbegrenzungen: Server können mit 429 und Retry-After drosseln. Implementieren Sie exponentielles Backoff, Jitter und die Verfolgung des Anfragebudgets in Clients.
• Datenformate und Validierung:
  • JSON ist für REST üblich; XML bleibt in NETCONF weit verbreitet; YAML wird für von Menschen erstellte Dateien (Inventare, Playbooks, Variablensätze) verwendet. Konvertieren Sie YAML bei Bedarf intern in JSON.
  • Schema-Validierung: Verwenden Sie JSON Schema für JSON-Payloads; XML Schema für XML; YANG für modellbasiertes Management (Typen, Constraints, must/when-Anweisungen). Validieren Sie clientseitig vor dem Senden, um Fehler frühzeitig zu erkennen.
• NETCONF, RESTCONF, YANG, RPCs und Datastores:
  • YANG-Modelle definieren Datenstrukturen und Operationen für Konfiguration und Zustand.
  • NETCONF verwendet XML über SSH, mit Operationen wie , , , , , . Datastores umfassen typischerweise running und candidate; candidate ermöglicht ein Prepare-and-Commit mit Atomarität.
  • RESTCONF bildet YANG-modellierte Ressourcen auf eine RESTful-Schnittstelle über HTTP(S) ab und verwendet dabei JSON oder XML mit standardisierten Medientypen. Methoden werden auf die NETCONF-Semantik abgebildet (PATCH/PUT für Bearbeitungen).
  • Fehlermodi und Design:
    • Lock-Konflikte: Koordinieren Sie , um Deadlocks zu vermeiden; verwenden Sie einen engen Geltungsbereich und Timeouts.
    • Teilausfälle: Bevorzugen Sie den candidate-Datastore + für transaktionale Änderungen. Wenn nur running verfügbar ist, verwenden Sie strukturierte Änderungsgruppen und Checkpoints.
    • Modell-Drift: Geräte unterstützen möglicherweise unterschiedliche Revisionen von YANG-Modulen; handeln Sie Fähigkeiten aus und testen Sie während der CI.
• Kurzbeispiele:
  • Partielles RESTCONF-Update (HTTP-Austausch): PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1 Content-Type: application/yang-data+json { “ietf-interfaces:interface”: { “name”: “GigabitEthernet1”, “description”: “Uplink”, “enabled”: true } }
  • NETCONF mit Python (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()

Tooling und Workflows: Python, Ansible, Git und Pipelines

• Automatisierung mit Cisco DNA Center:
  • Northbound-REST-APIs bieten Zugriff auf Inventar, Vorlagen, Provisionierung und Assurance. Southbound-Schnittstellen verbinden den Controller mit den Geräten (CLI, SNMP, NETCONF/RESTCONF), um den Intent umzusetzen.
  • Discovery-Workflows können CDP, LLDP und IP-Bereiche nutzen. Verwenden Sie rollenbasierte Zugriffskontrolle, projektbasierte Vorlagen und standortspezifische Variablen. Assurance korreliert Telemetriedaten zu Problemen, Health Scores (Zustandsbewertungen) und vorgeschlagenen Behebungsmaßnahmen – wichtige Eingaben für die Closed-Loop-Automatisierung.
• Python-Grundlagen für die Netzwerkautomatisierung:
  • Grundlagen der Sprache: Typen, Funktionen, Module, virtuelle Umgebungen und Logging.
  • Bibliotheken: requests/httpx (REST), ncclient (NETCONF), jinja2 (Templating), pyyaml, json, pandas (Datenaufbereitung), rich/logging für Observability.
  • Praktiken: Eingabevalidierung, Wiederholungsversuche mit Backoff, strukturierte Exceptions, Timeouts und Unit-Tests. Trennen Sie die Geschäftslogik von I/O-Operationen, um Tests zu vereinfachen.
• Ansible:
  • Das Inventory definiert Hosts und Gruppen; halten Sie host_vars/group_vars in YAML.
  • Playbooks deklarieren den Soll-Zustand; Module wie ios_config, ios_facts, iosxe_config, restconf_config und uri führen Aktionen aus. Verwenden Sie Roles, um wiederverwendbare Logik zu kapseln.
  • Idempotenz: Module stellen sicher, dass wiederholte Ausführungen ohne unbeabsichtigte Änderungen zum selben Ergebnis konvergieren. Verwenden Sie check_mode und diff für eine Vorschau; benachrichtigen Sie Handler (notify), um nur bei Änderungen zu speichern.
  • Beispiel:
    • 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
  • Change Control: Nutzen Sie Wartungsfenster, eine serielle oder Batch-Strategie und standortspezifisches Throttling, um den „Blast Radius“ (Auswirkungsbereich) zu begrenzen. Erfassen Sie Pre- und Post-Checks automatisch.
• Git, Versionierung, Testing und Pipelines:
  • Speichern Sie den Network Intent (YAML-Variablen, Jinja-Templates, Playbooks), generierte Konfigurationen und Tests in Git. Verwenden Sie Branches, Pull Requests und Code-Reviews. Semantische Commits und Tags gleichen Versionen mit Deployments ab.
  • Testing: Linting von YAML und Playbooks, Validierung von YANG/JSON-Schemata, Ausführung von Unit-Tests und Ansible Molecule-Szenariotests. Integrieren Sie synthetische Vorabprüfungen (z. B. Erreichbarkeit) in die CI.
  • Pipelines: Dev → Staging/Labor → Canary in der Produktion → schrittweiser Rollout. Gates umfassen statische Analyse, Dry-Runs gegen Simulatoren, Genehmigungen und automatischen Rollback bei einer Verschlechterung des Systemzustands (Health Regression).

Telemetrie, ereignisgesteuerte Automatisierung und Risikomanagement

• Telemetrie-Streaming:
  • Modellgetriebene Telemetrie (IOS XE, NX-OS) veröffentlicht YANG-modellierte Zustandsdaten in definierten Intervallen über gRPC/gNMI oder NETCONF, mit Dial-in- oder Dial-out-Abonnements. Zu den Vorteilen gehören geringe Latenz und strukturierte Daten, was die Leistung gegenüber periodischem CLI-Scraping oder SNMP-Polling übertrifft.
  • Beispiel (IOS XE, verkürzt):

undefined

• Design-Tipps: Passen Sie die Abtastfrequenz an den Anwendungsfall an; stellen Sie die Kapazität des Message Bus sicher; entwerfen Sie Downsampling-/Aggregations-Pipelines; schützen Sie sich vor Telemetrieverlust durch Pufferung und Bestätigungen (Acknowledgements).
• Ereignisgesteuerte Automatisierung:
  • Lösen Sie Aktionen bei Webhooks, Syslog, SNMP-Traps, DNA Center-Ereignissen oder Kafka-Topics aus. Verwenden Sie Korrelation und Ratenbegrenzung (Rate Limiting), um durch Storms verursachte Flaps zu vermeiden. Pflegen Sie idempotente Handler, die sicher erneut ausgeführt werden können.
  • Closed-Loop (geschlossener Regelkreis): Ein Controller erkennt eine Richtlinienverletzung, validiert diese mit sekundären Signalen, öffnet ein Change-Ticket oder löst eine begrenzte Behebungsmaßnahme aus, misst dann erneut und schließt den Vorgang ab.
• Risikomanagement, Rollback und Anmeldeinformationen:
  • Leitplanken (Guardrails): gestaffelte Rollouts, Parallelitätsgrenzen (Concurrency Limits), Kontrollen des Explosionsradius (Blast Radius), dynamisches Backoff bei 429/5xx-Antworten und Timeouts. Verwenden Sie Transaktionen, wo verfügbar (NETCONF candidate + commit), oder Geräte-Checkpoints und configure replace.
  • Rollback: Pflegen Sie Golden Configs, Diffs und gerätespezifische Checkpoints. Bevorzugen Sie commit-confirmed-Semantik, wo unterstützt; andernfalls implementieren Sie ein automatisiertes Fallback mit Timern und Erreichbarkeitsprüfungen.
  • Schutz von Anmeldeinformationen: Erzwingen Sie RBAC, kurzlebige Token und auftragsbezogene Just-in-Time-Secrets. Verwenden Sie Secret Stores (z. B. Ansible Vault oder einen externen Vault), betten Sie niemals Secrets in Playbooks oder Git ein. Rotieren Sie Anmeldeinformationen nach Zeitplan und nach Personalwechseln. Sichern Sie die Anmeldeinformationen von Controller zu Gerät und auditieren Sie den Zugriff.

Praktisches Problemszenario

Aurelius Logistics plant, die Konfigurationen für Campus und Zweigstellen zu standardisieren, eine konsistente Segmentierung durchzusetzen und eine Closed-Loop-Assurance mit Cisco DNA Center zu implementieren, während sichere Änderungen über Ansible und Git ermöglicht werden.

1. Baseline und Erkennung des Netzwerks

• Begründung: Die Erkennung (Discovery) im DNA Center mittels IP-Bereichen sowie CDP/LLDP erfasst Geräte und Topologie und schafft so ein maßgebliches Inventar. Dies ermöglicht die Festlegung des Intent-Umfangs und die Vererbung von Variablen nach Standort. Das Sammeln von Assurance-Daten etabliert Zustands-Baselines vor der Änderung für Vergleiche und Rollback-Trigger.

2. Modellierung von Intent und Vorlagen im DNA Center

• Begründung: Drücken Sie Segmentierungs- (z. B. Mitarbeiter, IoT, Gast) und QoS-Richtlinien deklarativ aus. Verwenden Sie parametrisierte Vorlagen mit standortspezifischen Variablen für Schnittstellen, Routing und ACLs. Deklarative Richtlinien ermöglichen es dem Controller, gerätespezifische Konfigurationen zu kompilieren, was menschliche Fehler und Abweichungen (Drift) reduziert.

3. Implementierung eines Git-gesteuerten Konfigurationsmanagements

• Begründung: Speichern Sie Vorlagen, standortspezifische Variablen (YAML) und Validierungstests in Git. Feature-Branches und Pull-Requests erzwingen Peer-Reviews. Tags gleichen Deployments mit Versionen ab und ermöglichen präzise Rollbacks. Dies bietet eine auditierbare Änderungshistorie und unterstützt automatisierte Pipeline-Trigger.

4. Aufbau einer CI/CD-Pipeline mit Validierungs-Gates

• Begründung: Pipeline-Stufen führen Linting für YAML durch, validieren JSON/YANG-Payloads, führen Unit-Tests für das Jinja-Rendering durch und simulieren API-Aufrufe in einer Sandbox. DNA Center Dry-Runs und Ansible check_mode/diff validieren Änderungen ohne Auswirkungen. Nur wenn alle Gates bestanden sind, erlaubt die Pipeline die Freigabe durch einen Operator zur Fortsetzung.

5. Inkrementelles Deployment mit Ansible und DNA Center APIs

• Begründung: Verwenden Sie die Northbound-APIs des DNA Center, um Vorlagen zuerst an einen Canary-Standort zu pushen und dann seriell nach Standort mit begrenzter Batch-Größe auszurollen. Für Geräte, die NETCONF/RESTCONF unterstützen, führen Ansible-Module gezielte, idempotente Updates durch. Dieser duale Ansatz nutzt den Controller für richtlinienintensive Aufgaben und die direkte Geräteautomatisierung für feingranulare Änderungen, während der Explosionsradius minimiert wird.

6. Aktivierung von Streaming-Telemetrie und Assurance-gesteuerten Prüfungen

• Begründung: Konfigurieren Sie modellgetriebene Telemetrie auf Edge-Geräten, um DNA Center Assurance und den Observability-Stack des Unternehmens zu versorgen. Definieren Sie SLOs (z. B. Erfolgsrate beim Onboarding, Latenz) und Ereignis-Abonnements, die Alarme auslösen, wenn sich die Metriken nach der Änderung verschlechtern. Dies ermöglicht die sofortige Erkennung negativer Auswirkungen.

7. Aktivierung kontrollierter Closed-Loop-Korrekturmaßnahmen

• Begründung: Bei gut verstandenen Abweichungen (z. B. eine ausgefallene Schnittstelle mit bekanntem Workaround) erlauben Sie der Pipeline, ein eingeschränktes Playbook auszulösen, um die letzte Änderung rückgängig zu machen oder einen Hotfix anzuwenden. Fordern Sie für umfassendere Korrekturmaßnahmen eine menschliche Genehmigung an. Implementieren Sie exponentielles Backoff und Cooldown, um Oszillationen zu verhindern.

8. Vorbereitung und Testen von Rollback-Pfaden

• Begründung: Erstellen Sie vor jeder Änderung Geräte-Checkpoints oder verwenden Sie NETCONF candidate + commit-confirmed, falls verfügbar. Archivieren Sie die Konfigurationen vor der Änderung und taggen Sie das Git-Repository. Wenn die Health-Scores sinken oder die Telemetrie SLA-Verletzungen anzeigt, führt die Pipeline configure replace oder NETCONF discard/rollback aus und stellt den vorherigen Zustand schnell wieder her.

9. Schutz von Anmeldeinformationen und Durchsetzung der Zugriffskontrolle

• Begründung: Speichern Sie Geräte-/Controller-Anmeldeinformationen in einem Vault; injizieren Sie kurzlebige Token in Jobs. Verwenden Sie DNA Center RBAC, um API-Scopes einzuschränken. Protokollieren Sie niemals Secrets; bereinigen Sie Ausgaben in der CI. Rotieren Sie Anmeldeinformationen und Token regelmäßig und nach Personalwechseln, um das Risiko zu reduzieren.

10. Operationalisierung mit Dokumentation und Runbooks

• Begründung: Dokumentieren Sie Intent-Definitionen, Variablenschemata, Fehlermodi (Rate Limits, API-Fehler, Modell-Inkonsistenzen) und Wiederherstellungsschritte. Schulen Sie das NOC, um Assurance-Signale und Pipeline-Status zu interpretieren und so konsistente, schnelle Reaktionen auf Vorfälle zu gewährleisten.

Dieser Ansatz schafft einen sicheren, testbaren Pfad vom Intent zur Implementierung, nutzt Controller für die Richtlinienverteilung (mit vManage/vSmart in SD‑WAN und DNA Center im Campus), verwendet idempotente Werkzeuge zur Konvergenz und schließt den Regelkreis mit telemetriegestützter Validierung und kontrollierter Fehlerbehebung.

← Unternehmenssicherheit und Identitätsdienste · Alle Domänen · Netzwerk-Assurance →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →