Cisco 200-301: IP-Dienste, NAT und Quality of Service — Lernleitfaden

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Teil des Cisco CCNA 200-301 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Cisco-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

IP-Dienste verbinden Netzwerke miteinander und sorgen dafür, dass sie unter Last beobachtbar, erreichbar und vorhersagbar bleiben. Dieser Abschnitt behandelt zentrale Dienste (DHCP, DNS, NTP), Sichtbarkeit und Signalisierung (SNMP, Syslog, NetFlow, Telemetrie), Adressübersetzung (NAT) und Verkehrssteuerung (QoS) und verknüpft diese mit First-Hop-Redundanz und betrieblicher Validierung. Designentscheidungen betonen deterministisches Verhalten, das Prinzip der geringsten Rechte (Least Privilege) und eine kontrollierte Leistungsreduzierung (Graceful Degradation) bei Ausfällen.

Zentrale IP-Dienste: DHCP, DNS und NTP

DHCP

• Komponenten und Ablauf: Ein Client verwendet DORA (Discover, Offer, Request, Acknowledgment). Server-Pools (Scopes) definieren Adressbereiche, Masken, Gateways (Option 3), DNS (Option 6), Timer und Herstelleroptionen (z. B. Option 150 für TFTP für IP-Telefone).
• Relay: Wenn sich der Server nicht im Subnetz des Clients befindet, leitet eine Layer-3-Schnittstelle Broadcasts mittels ip helper-address als Unicast-Anfrage an den Server weiter. DHCP-Snooping fügt Option 82 (Circuit-ID/Remote-ID) ein, damit der Server standortbezogene Entscheidungen treffen kann.
• Scopes und Ausschlüsse: Erstellen Sie Pools, die gerade groß genug für die erwarteten Clients plus Wachstum sind. Reservieren Sie statische Adressen entweder durch MAC-Reservierungen oder schließen Sie sie mit ip dhcp excluded-address von der dynamischen Zuweisung aus.
• Leases: Wägen Sie Fluktuation gegen Adresswiederverwendung ab; kürzere Leases beschleunigen die Rückgewinnung, erhöhen aber den DHCP-Verkehr.
• Häufige Fehlerursachen:
  • Fehlende/falsche Helper-Adresse beim Relay oder ACLs, die UDP 67/68 blockieren.
  • Kein passender Scope, erschöpfter Pool oder überlappende Subnetze.
  • Falsche Default-Gateway-Option, die nach dem Booten zu Erreichbarkeitsproblemen führt.
  • Fehlkonfiguration des Vertrauensstatus beim DHCP-Snooping, die Serverantworten verwirft.

• Nützliche Befehle:

undefined

undefined

• Minimales Relay-Beispiel:

undefined

undefined

undefined

DNS

• Ablauf der Auflösung: Ein Stub-Resolver prüft den Host-Cache und die Hosts-Datei und fragt dann einen rekursiven Resolver ab. Der rekursive Server fragt iterativ Root-, TLD- und autoritative Server ab, speichert die Antworten gemäß ihrer TTL im Cache und gibt eine Antwort zurück. Fehler können NXDOMAIN (Name existiert nicht) oder SERVFAIL (Problem bei der Auflösung) sein.
• Design-Richtlinien: Verwenden Sie redundante rekursive Resolver; bevorzugen Sie Anycast für Lokalität und Verfügbarkeit; passen Sie TTLs an, um Agilität und Cache-Effizienz auszugleichen. Setzen Sie DNS-Allowlists für sensible Segmente durch.
• Häufige Fehlerursachen:
  • Blockiertes oder asymmetrisches UDP/TCP 53, fehlerhaftes EDNS-Handling oder MTU-/Fragmentierungsprobleme.
  • Falsch konfigurierte Suchdomänen, die zu einer falschen FQDN-Auflösung führen.
  • Veralteter/vergifteter Cache; Fehler bei der DNSSEC-Validierung.
• Grundlagen der Gerätekonfiguration:

undefined

.

NTP

• Zeitsynchronisation ermöglicht die Korrelation (Logs, Flows, Sicherheit) und eine genaue Messung von Verzögerung/Jitter. Die Hierarchie verwendet Stratum-Werte (1 ist direkt mit einer Referenzuhr verbunden; 16 ist nicht synchronisiert).
• Clients, Server und Peers bilden einen stabilen Zeit-Baum; authentifizieren Sie NTP mit Schlüsseln, um Spoofing zu verhindern.
• IP SLA und Jitter: Eine genaue Zeitsynchronisation (z. B. mit NTP) ist erforderlich, um die unidirektionale Verzögerung (One-Way Delay) zu messen und gültige Jitter-Berechnungen über Knoten hinweg sicherzustellen.
• Häufige Fehlerursachen: Nicht erreichbare Server, asymmetrische Pfade/Zeitversatz, Verwechslung von Sommer-/Zeitzonen oder unbeabsichtigt akzeptierte, nicht authentifizierte Server.

• Nützliche Befehle:

undefined

undefined

Sichtbarkeit und Steuerung: SNMP, Syslog, NetFlow und Telemetrie

SNMP

• Versionen: v2c (Community-basiert) vs. v3 (Authentifizierung/Datenschutz). Bevorzugen Sie v3 mit authPriv für Integrität und Vertraulichkeit.
• Polling vs. Traps/Informs: Pollen Sie für regelmäßige Metriken; senden Sie Traps/Informs bei Zustandsänderungen. Informs bieten Zuverlässigkeit durch eine Bestätigung.
• Sicherheit und Skalierung: Beschränken Sie Manager durch ACLs; begrenzen Sie die Rate von Traps; minimieren Sie aufwendige OIDs; vermeiden Sie Standard-Communitys wie „public“.

Syslog

• Stufen: 0 Emergency, 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice, 6 Informational, 7 Debugging.
• Aktivieren Sie Zeitstempel und Sequenznummern; senden Sie an redundante Kollektoren; legen Sie Facility/Level pro Feature fest, um Rauschen zu vermeiden.

• Beispiel:

undefined

undefined

undefined

NetFlow

• Erfasst Metadaten von Konversationen (5-Tupel, Zähler, Zeitstempel). v5 ist fest definiert; v9/IPFIX sind vorlagenbasiert und erweiterbar.
• Design: Exportieren Sie an mindestens zwei Kollektoren; verwenden Sie bei Bedarf Sampling, um die CPU-Last zu reduzieren; stellen Sie die Zeitsynchronisation (NTP) für genaue Analysen sicher.

• Klassisches Beispiel:

undefined

undefined

undefined

undefined

Modellgetriebene Telemetrie

• Push-basiertes Streaming ausgewählter, in YANG modellierter Daten über effiziente Transporte (z. B. gRPC). Vorteile: geringere Latenz, vorhersagbare CPU-Auslastung und bessere Skalierbarkeit als periodisches SNMP-Polling.
• Nachteile: Erfordert Kollektoren, die die Modelle verstehen; Transportsicherheit und QoS für den Stream selbst.

Häufige Fehlerursachen und Gegenmaßnahmen

• Übermäßiges Logging oder Polling, das CPU-Spitzen verursacht: Passen Sie Stufen an, nutzen Sie Batch-Verarbeitung oder Sampling.
• Zeitabweichung: Korrigieren Sie NTP, um falsch geordnete Ereignisse und fehlerhaftes Zusammensetzen von Flows zu verhindern.
• Firewall/ACLs, die die Management-Ebene blockieren: dediziertes Out-of-Band-Management oder VRF und Control Plane Policing verwenden.

NAT und Adressübersetzung

Konzepte

• Terminologie:
  • Inside Local: Ursprüngliche private Adresse.
  • Inside Global: Übersetzte, extern sichtbare Adresse.
  • Outside Local/Global: Adresse des externen Hosts, wie sie intern/extern gesehen wird.
• Typen:
  • Statisches NAT: Feste Eins-zu-eins-Zuordnung; stabile Erreichbarkeit für eingehenden Verkehr.
  • Dynamisches NAT: Viele-zu-viele über einen Pool; nur für ausgehenden Verkehr, bis eine Übersetzung zugewiesen wird.
  • PAT (Overload): Viele-zu-eins oder Viele-zu-wenige unter Verwendung von TCP/UDP-Ports; am häufigsten für den Internet-Egress.

Designüberlegungen und Kompromisse

• Statisches NAT für Server, die eingehenden Zugriff benötigen; PAT für Clients, um öffentliche IPs zu sparen.
• NAT bricht die Ende-zu-Ende-Transparenz; einige Protokolle erfordern ALGs (FTP, SIP). Bevorzugen Sie anwendungsspezifische Erkennung (Application Awareness) an den Netzwerkgrenzen oder verwenden Sie Protokolle, die tolerant gegenüber Übersetzungen sind.
• Hochverfügbarkeit: FHRP verschiebt das Standard-Gateway, aber der NAT-Status ist gerätespezifisch; ohne Stateful NAT setzt ein Failover die Flows zurück. Platzieren Sie NAT auf HA-Firewalls/Routern, die Zustandsreplikation (State Replication) unterstützen, oder steuern Sie den Egress-Verkehr deterministisch.

Konfigurationsbeispiele

• PAT unter Verwendung des WAN-Interfaces:
  • access-list 1 permit 10.10.10.0 0.0.0.255
  • interface Gi0/0 ip address 203.0.113.2 255.255.255.252 ip nat outside
  • interface Gi0/1 ip address 10.10.10.1 255.255.255.0 ip nat inside
  • ip nat inside source list 1 interface Gi0/0 overload
• Statisches NAT für einen Server:
  • ip nat inside source static 10.10.10.50 203.0.113.50

Überprüfung und Fehlerbehebung

• show ip nat translations, show ip nat statistics
• clear ip nat translation *
• Häufige Probleme: Fehlende inside/outside-Konfiguration auf Interfaces, keine Route zum Pool, überlappende Pools, nicht übereinstimmende ACL, Port-Erschöpfung bei PAT, asymmetrisches Routing über mehrere Ausgänge oder nicht berücksichtigte Hairpinning-Anforderungen.

QoS-Grundlagen: Klassifizierung, Markierung, Queuing und Staumanagement

Klassifizierung und Markierung

• Klassifizieren durch ACLs, IP Precedence/DSCP, CoS oder NBAR. An der Netzwerkgrenze (Edge) markieren; Markierungen beibehalten, wo sie vertrauenswürdig sind.
• DSCP und CoS:
  • DSCP EF (46) für Voice-Bearer-Traffic; CS3/AF31–AF33 für Signalisierung; AF41–AF43/CS4 für interaktives Video.
  • CoS-Werte auf 802.1Q-Trunks erfordern an L3-Grenzen eine Zuordnung zu DSCP.
• Vertrauensgrenzen (Trust Boundaries):
  • Vertrauen Sie nur Geräten, die zur Verantwortung gezogen werden können (z. B. ein Cisco IP-Telefon). An einem Access-Port mit einem Telefon verwenden Sie gerätebasiertes Vertrauen und erhalten die nachgelagerten Prioritäten:
    • mls qos
    • interface Fa0/1 mls qos trust device cisco-phone mls qos trust cos switchport priority extend trust

Queuing und Staumanagement

• CBWFQ: Gewichtetes Scheduling durch Bandbreitengarantien.
• LLQ: Fügt CBWFQ eine Strict-Priority-Warteschlange für latenzempfindliche Klassen (Sprache, interaktives Video) hinzu.
• PQ: Reine Strict-Priority; kann anderen Verkehr aushungern, wenn er nicht durch Policing reguliert wird. LLQ wird bevorzugt, da es priorisierten Verkehr designbedingt reguliert (policing).
• WRED: Frühes, zufälliges Verwerfen (Early Random Drop), um globale TCP-Synchronisation zu vermeiden; nicht auf Prioritätswarteschlangen anwenden.

Policing und Shaping

• Policing: Erzwingt eine Rate durch Verwerfen/Neumarkieren von überschüssigem Verkehr; geringe Verzögerung, aber erhöht Verlust und Jitter.
• Shaping: Puffert Bursts, um sie an eine bestimmte Rate anzupassen; fügt Verzögerung hinzu, reduziert aber nachgelagerte Paketverluste (Drops). Wenden Sie Shaping auf langsameren Egress-Links vor hierarchischen Policies an.
• Beispiel für eine LLQ-Policy:
  • class-map match-any VOICE match dscp ef
  • class-map match-any VIDEO match dscp af41 af42 af43 cs4
  • policy-map WAN-OUT class VOICE priority percent 10 class VIDEO bandwidth percent 20 class class-default fair-queue
  • interface Serial0/0/0 service-policy output WAN-OUT

Zielwerte für Sprache und Video

• Sprache: Einweg-Verzögerung <150 ms, Jitter <30 ms, Verlust <1 %. Verwenden Sie LLQ für den Bearer-Traffic, schützen Sie die Signalisierung separat.
• Video: Interaktives Video benötigt Bandbreiten- und Jitter-Kontrolle; Streaming ist toleranter gegenüber Verlusten, aber bandbreitenintensiv. Ziehen Sie separate Warteschlangen und Admission Control in Betracht.

Validierung und Messung

• Verwenden Sie IP SLA, um synthetischen RTP/UDP-Verkehr zu erzeugen und Verzögerung, Jitter und Verlust zu messen; stellen Sie NTP für Zeitgenauigkeit sicher.
• show policy-map interface, um Zähler und Drops pro Klasse zu überprüfen.

Resilienz: Auswirkungen von FHRP und operative Validierung

FHRP

• HSRP/VRRP stellen ein virtuelles Standard-Gateway bereit, um First-Hop-Ausfälle zu überstehen; GLBP fügt Gateway-Lastverteilung hinzu.
• Design: Timer für Konvergenz vs. Stabilität anpassen; Object Tracking verwenden, um bei einem Upstream-/WAN-Verlust umzuschalten, nicht nur bei einem Schnittstellenausfall.
• Auswirkungen auf den Dienst: Während des Failovers können ARP-Aktualisierung und Rehashing zu kurzen Ausfällen führen; Echtzeit-Flows ohne Pfadsymmetrie oder replizierten NAT-Status können zurückgesetzt werden. Halten Sie den Egress-Pfad für priorisierten Datenverkehr konsistent.

Operative Validierung und Fehlerbehebung

• DHCP: Helper-Adressen und Pool-Auslastung bestätigen; Paketmitschnitt, um DORA zu sehen; DHCP-Snooping-Tabellen überprüfen.
• DNS: Mit nslookup/dig validieren; Resolver-Redundanz prüfen; Firewall-Regeln und MTU/EDNS-Verhalten inspizieren.
• NAT: Übersetzungen während aktiver Flows überprüfen; Routen zu Inside Local und zum Pool sicherstellen; eingehendes statisches NAT von außen testen.
• NTP: Synchronisiertes Stratum und geringen Offset sicherstellen; Authentifizierung erfordern.
• QoS: Trust-Status validieren; Service-Policy-Zähler unter realistischer Last prüfen; IP-SLA-Sprachtests durchführen; auf Policer-Drops bei priorisiertem Datenverkehr achten.
• Sichtbarkeit: Bestätigen, dass SNMPv3 funktioniert und Traps zugestellt werden; Syslog-Zeitstempel korrekt sind; NetFlow-Exporter auf die Kollektoren abgestimmt sind; Telemetrie-Streams stabil sind.

Praktisches Problemszenario

Bei Acme Manufacturing kommt es in einer Niederlassung zu zeitweise abgehackten IP-Telefongesprächen und sporadischen DHCP-Fehlern, nachdem ein zweiter ISP hinzugefügt und PAT auf einem neuen Router aktiviert wurde.

1. Routing und Gateway-Verfügbarkeit mit FHRP stabilisieren

• HSRP auf dem VLAN-SVI der Niederlassung über die beiden Router hinweg konfigurieren, Preempt und Prioritäten festlegen und die WAN-Uplinks überwachen.
• Begründung: Ein virtuelles Standard-Gateway verbirgt den Router-Failover vor den Endgeräten; Object Tracking verschiebt das Gateway von einem Router weg, der die Upstream-Erreichbarkeit verloren hat.

2. NAT-Verhalten normalisieren und asymmetrischen Egress verhindern

• PAT nur auf dem aktiven HSRP-Router platzieren; sicherstellen, dass der Standby-Router keine Standardroute ankündigt, es sei denn, er ist aktiv, oder PBR implementieren, um den Egress des Voice-VLANs an einen einzigen Router zu binden.
• Begründung: Asymmetrischer Egress unterbricht stateful PAT und ALGs für SIP/RTP; ein konsistenter Egress erhält die Übersetzungen und die Anrufstabilität aufrecht.

3. Zuverlässigkeit des DHCP-Relays beheben

• Auf beiden SVI-Gateways ip helper-address zu den zentralen DHCP-Servern konfigurieren; DHCP-Snooping-Trust in Richtung Uplink und Untrust in Richtung Access-Ports überprüfen; statische IP-Bereiche ausschließen.
• Begründung: Ein korrektes Relay stellt sicher, dass DORA die Server erreicht; Snooping verhindert nicht autorisierte Server (Rogue Servers), während Server-Antworten zugelassen werden; Ausschlüsse vermeiden Konflikte.

4. Genaue Zeit etablieren und Messungen aktivieren

• NTP-Clients auf beiden Routern mit authentifizierten Servern konfigurieren, das Stratum überprüfen und dann IP-SLA-Operationen vom Typ udp-jitter in Richtung des HQ-Call-Managers konfigurieren.
• Begründung: Genaue Zeit ist die Grundlage für die Berechnung von One-Way Delay und Jitter; IP SLA validiert, dass QoS Sprache (Voice) unterstützen kann.

5. Eine QoS-Richtlinie vom Edge zum WAN mit Trust Boundaries implementieren

• CoS an Access-Ports nur dann vertrauen (trust), wenn ein Cisco IP-Telefon erkannt wird; DSCP für Sprache (Voice) auf EF und für Signalisierung auf CS3 ummarkieren; LLQ mit 10 % für Sprache, Bandbreite für Video und Fair-Queue als Standard anwenden. Traffic auf die CIR des Providers shapen, bevor die Richtlinie angewendet wird, falls die physische Schnittstelle schneller als die vertraglich vereinbarte Rate ist.
• Begründung: Ein korrekter Trust-Status verhindert, dass Hosts die Priorität künstlich erhöhen; LLQ garantiert niedrige Latenz; Shaping vermeidet Paketverluste (Drops) auf der Downstream-Seite am Provider-Edge.

6. Sichtbarkeit verbessern und die Sicherheit der Management-Ebene erhöhen

• SNMPv3 zum NMS, Syslog zu redundanten Kollektoren mit Zeitstempeln und NetFlow v9 Exporter zur Analyseplattform aktivieren; Control-Plane-Policing für SNMP und Logging hinzufügen.
• Begründung: Beobachtbarkeit (Observability) bestätigt Verbesserungen und deckt Regressionen auf; ein gesichertes Management reduziert die Angriffsfläche bei gleichbleibender Telemetrie.

7. Validieren, dann Ausfall simulieren

• show policy-map interface verwenden, um zu bestätigen, dass die Zähler für priorisierten Verkehr während Testanrufen ansteigen; IP-SLA-Jitter-Baselines beobachten; traceroute ausführen und Failover testen, indem eine HSRP-Statusänderung erzwungen wird.
• Begründung: Die operative Validierung unter Last überprüft die Designabsicht; ein kontrollierter Failover beweist die Ausfallsicherheit und deckt etwaige Grenzfälle bei NAT oder Konvergenz auf.

← Dynamisches Routing und IP-Konnektivität · Alle Domänen · Wireless-LAN-Design und Betrieb →

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