Cisco 200-301: IP Services, NAT and Quality of Service — Study Guide

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

Part of the Cisco CCNA 200-301 — Study Guide. Practice with verified answers in the Cisco exam hub, or take timed practice tests on ExamRoll.io.

Overview

IP services glue networks together and keep them observable, reachable, and predictable under load. This section covers core service delivery (DHCP, DNS, NTP), visibility and signaling (SNMP, syslog, NetFlow, telemetry), address translation (NAT), and traffic handling (QoS), then ties them to first-hop redundancy and operational validation. Design choices emphasize deterministic behavior, least privilege, and graceful degradation during failures.

Core IP Services: DHCP, DNS, and NTP

DHCP

• Components and flow: A client uses DORA (Discover, Offer, Request, Acknowledgment). Server pools (scopes) define address ranges, masks, gateways (Option 3), DNS (Option 6), timers, and vendor options (for example, Option 150 for TFTP for IP phones).
• Relay: When the server is not on the client subnet, a Layer 3 interface relays broadcasts using ip helper-address to unicast the request to the server. DHCP snooping inserts Option 82 (circuit-id/remote-id) so the server can make location-aware decisions.
• Scopes and exclusions: Build pools just large enough for expected clients plus growth. Reserve static addresses either by MAC reservations or exclude them from dynamic allocation with ip dhcp excluded-address.
• Leases: Balance churn vs. address reuse; shorter leases accelerate reclamation but increase DHCP traffic.
• Common failure modes:
  • Relay missing/wrong helper address, or ACLs blocking UDP 67/68.
  • No matching scope, exhausted pool, or overlapping subnets.
  • Incorrect default gateway option causing reachability failures post-boot.
  • DHCP snooping trust misconfiguration dropping server replies.
• Useful commands:
  • show ip dhcp binding, show ip dhcp pool, show ip dhcp conflict
  • debug ip dhcp server events
• Minimal relay example:
  • interface Vlan10 ip address 10.10.10.1 255.255.255.0 ip helper-address 192.0.2.10

DNS

• Resolution flow: A stub resolver checks the host cache and hosts file, then queries a recursive resolver. The recursive server iteratively queries root, TLD, and authoritative servers, caches responses by TTL, and returns an answer. Failures can be NXDOMAIN (name does not exist) or SERVFAIL (problem resolving).
• Design guidance: Use redundant recursive resolvers; prefer anycast for locality and availability; tune TTLs to balance agility and cache efficiency. Enforce DNS allowlists for sensitive segments.
• Common failure modes:
  • Blocked or asymmetric UDP/TCP 53, broken EDNS handling, or MTU/fragmentation issues.
  • Misconfigured search domains causing wrong FQDN resolution.
  • Stale/poisoned cache; DNSSEC validation failure.
• Device configuration basics: ip domain-lookup, ip name-server 198.51.100.53, show hosts.

NTP

• Time synchronization enables correlation (logs, flows, security) and accurate delay/jitter measurement. Hierarchy uses stratum values (1 is directly attached to a reference clock; 16 is unsynchronized).
• Clients, servers, and peers form a stable time tree; authenticate NTP with keys to prevent spoofing.
• IP SLA and jitter: Accurate time synchronization (for example with NTP) is required when measuring one-way delay and to ensure valid jitter calculations across nodes.
• Common failure modes: Unreachable servers, asymmetric paths/skew, daylight/timezone confusion, or unauthenticated servers accepted inadvertently.
• Useful commands:
  • ntp authenticate; ntp authentication-key 1 md5 ; ntp trusted-key 1; ntp server 192.0.2.20 key 1
  • show ntp status, show ntp associations

Visibility and Control: SNMP, Syslog, NetFlow, and Telemetry

SNMP

• Versions: v2c (community-based) vs v3 (auth/privacy). Prefer v3 with authPriv for integrity and confidentiality.
• Polling vs traps/informs: Poll for regular metrics; sends traps/informs on state changes. Informs include reliability via acknowledgment.
• Security and scale: Restrict managers by ACLs; rate-limit traps; minimize expensive OIDs; avoid public/community defaults.

Syslog

• Levels: 0 emergency, 1 alert, 2 critical, 3 error, 4 warning, 5 notice, 6 informational, 7 debugging.
• Enable timestamping and sequence numbers; send to redundant collectors; set facility/level per feature to avoid noise.
• Example:
  • service timestamps log datetime msec
  • logging host 192.0.2.30
  • logging trap informational

NetFlow

• Captures conversation metadata (5-tuple, counters, timestamps). v5 is fixed; v9/IPFIX are template-based and extensible.
• Design: Export to at least two collectors; sample as needed to reduce CPU; ensure time sync (NTP) for accurate analytics.
• Classic example:
  • ip flow-export destination 192.0.2.40 2055
  • ip flow-export version 9
  • interface GigabitEthernet0/0 ip flow ingress

Model-driven telemetry

• Push-based streaming of selected YANG-modeled data over efficient transports (for example, gRPC). Benefits: lower latency, predictable CPU, and better scale than periodic SNMP polling.
• Trade-offs: Requires collectors that understand models; transport security and QoS for the stream itself.

Common failure modes and mitigations

• Excessive logging or polling causing CPU spikes: tune levels, batch, or sample.
• Time drift: Fix NTP to prevent misordered events and bad flow stitching.
• Firewall/ACLs blocking management plane: dedicate OOB management or VRF, and control plane policing.

NAT and Address Translation

Concepts

• Terminology:
  • Inside local: Original private address.
  • Inside global: Translated address visible externally.
  • Outside local/global: External host’s address as seen inside/outside.
• Types:
  • Static NAT: One-to-one fixed mapping; stable inbound reachability.
  • Dynamic NAT: Many-to-many via a pool; outbound only until a translation is allocated.
  • PAT (overload): Many-to-one or many-to-few using TCP/UDP ports; most common for Internet egress.

Design reasoning and trade-offs

• Static NAT for servers needing inbound access; PAT for clients to conserve public IPs.
• NAT breaks end-to-end transparency; some protocols require ALGs (FTP, SIP). Prefer application-awareness at borders or use protocols tolerant to translation.
• High availability: FHRP moves the default gateway, but NAT state is per device; without stateful NAT, failover resets flows. Place NAT on HA firewalls/routers that support state replication or steer egress deterministically.

Configuration examples

• PAT using the WAN interface:
  • 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
• Static NAT for a server:
  • ip nat inside source static 10.10.10.50 203.0.113.50

Verification and troubleshooting

• show ip nat translations, show ip nat statistics
• clear ip nat translation *
• Common issues: Missing inside/outside on interfaces, no route to pool, overlapping pools, ACL mismatch, port exhaustion on PAT, asymmetric routing across multiple exits, or hairpinning needs not addressed.

QoS Fundamentals: Classification, Marking, Queuing, and Congestion Handling

Classification and marking

• Classify by ACLs, IP precedence/DSCP, CoS, or NBAR. Mark at the edge; preserve markings where trusted.
• DSCP and CoS:
  • DSCP EF (46) for voice bearer; CS3/AF31–AF33 for signaling; AF41–AF43/CS4 for interactive video.
  • CoS values on 802.1Q trunks require mapping to DSCP at L3 boundaries.
• Trust boundaries:
  • Trust only devices that can be held accountable (for example, a Cisco IP phone). On an access port with a phone, use device-based trust and preserve downstream priorities:
    • mls qos
    • interface Fa0/1 mls qos trust device cisco-phone mls qos trust cos switchport priority extend trust

Queuing and congestion management

• CBWFQ: Weighted scheduling by bandwidth guarantees.
• LLQ: Adds strict-priority queue to CBWFQ for latency-sensitive classes (voice, interactive video).
• PQ: Pure strict-priority; can starve other traffic if not policed. LLQ is preferred because it polices priority traffic by design.
• WRED: Early random drop to avoid TCP global synchronization; do not apply to priority queues.

Policing and shaping

• Policing: Enforces a rate by dropping/remarking excess; low delay but increases loss and jitter.
• Shaping: Buffers bursts to fit a specified rate; adds delay but reduces downstream drops. Apply shaping on slower egress links before hierarchical policies.
• Example 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

Voice and video targets

• Voice: One-way delay <150 ms, jitter <30 ms, loss <1%. Use LLQ for bearers, protect signaling separately.
• Video: Interactive video needs bandwidth and jitter control; streaming is more loss-tolerant but bandwidth-heavy. Consider separate queues and admission control.

Validation and measurement

• Use IP SLA to generate synthetic RTP/UDP and measure delay, jitter, loss; ensure NTP for time accuracy.
• show policy-map interface to verify counters and drops per class.

Resilience: FHRP Impact and Operational Validation

FHRP

• HSRP/VRRP provide a virtual default gateway to survive first-hop failures; GLBP adds gateway load balancing.
• Design: Tune timers for convergence vs stability; use object tracking to fail over on upstream/WAN loss, not just interface down.
• Service impact: During failover, ARP refresh and rehashing can cause brief loss; real-time flows without path symmetry or replicated NAT state may reset. Keep the egress path consistent for priority traffic.

Operational validation and troubleshooting

• DHCP: Confirm helper addresses and pool utilization; packet-capture to see DORA; check DHCP snooping tables.
• DNS: Validate with nslookup/dig; check resolver redundancy; inspect firewall rules and MTU/EDNS behavior.
• NAT: Verify translations during active flows; ensure routes to inside local and pool; test inbound static NAT from the outside.
• NTP: Ensure synchronized stratum and low offset; require authentication.
• QoS: Validate trust; check service-policy counters under realistic load; run IP SLA voice tests; watch for policer drops in priority traffic.
• Visibility: Confirm SNMPv3 working and traps delivered; syslog timestamps correct; NetFlow exporters aligned with collectors; telemetry streams steady.

Practical Problem Scenario

Acme Manufacturing experiences intermittent IP phone choppiness and sporadic DHCP failures at a branch after adding a second ISP and enabling PAT on a new router.

1. Stabilize routing and gateway availability with FHRP

• Configure HSRP on the branch VLAN SVI across the two routers, set preempt and priorities, and track the WAN uplinks.
• Rationale: A virtual default gateway hides router failover from endpoints; object tracking moves the gateway away from a router that lost upstream reachability.

2. Normalize NAT behavior and prevent asymmetric egress

• Place PAT on the HSRP active router only; ensure the standby does not advertise a default route unless active, or implement PBR to pin voice VLAN egress to a single router.
• Rationale: Asymmetric egress breaks stateful PAT and ALGs for SIP/RTP; consistent egress maintains translations and call stability.

3. Fix DHCP relay reliability

• On both SVI gateways, configure ip helper-address to the central DHCP servers; verify DHCP snooping trust toward the uplink and untrust toward access ports; exclude static IP ranges.
• Rationale: Proper relay ensures DORA reaches the servers; snooping prevents rogue servers while allowing server replies; exclusions avoid conflicts.

4. Establish accurate time and enable measurement

• Configure NTP clients on both routers with authenticated servers, verify stratum, and then configure IP SLA udp-jitter operations toward the HQ call manager.
• Rationale: Accurate time underpins one-way delay and jitter calculations; IP SLA validates that QoS can support voice.

5. Implement a QoS edge-to-WAN policy with trust boundaries

• Trust CoS on access ports only when a Cisco IP phone is detected; remark DSCP for voice to EF and signaling to CS3; apply LLQ with 10% for voice, bandwidth for video, and fair-queue default. Shape to the provider CIR before applying the policy if the physical interface is faster than the contracted rate.
• Rationale: Proper trust prevents hosts from inflating priority; LLQ guarantees low latency; shaping avoids downstream drops at the provider edge.

6. Enhance visibility and tighten management plane security

• Enable SNMPv3 to the NMS, syslog to redundant collectors with timestamps, and NetFlow v9 exporters to analytics; add control-plane policing for SNMP and logging.
• Rationale: Observability confirms improvements and spots regressions; secured management reduces attack surface while maintaining telemetry.

7. Validate, then simulate failure

• Use show policy-map interface to confirm priority traffic counters increment during test calls; observe IP SLA jitter baselines; run traceroute and test failover by forcing HSRP state change.
• Rationale: Operational validation under load verifies design intent; controlled failover proves resilience and reveals any NAT or convergence edge cases.

← Dynamic Routing and IP Connectivity · All domains · Wireless LAN Design and Operations →

Practice these questions → · Timed practice on ExamRoll.io →