Cisco 350-401: IP Services, Multicast and Quality of Service — Study Guide

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

Part of the Cisco CCNP Enterprise 350-401 ENCOR — Study Guide. Practice with verified answers in the Cisco exam hub, or take timed practice tests on ExamRoll.io.

Overview

IP services, multicast, and QoS form the operational core of an enterprise network. Foundational services like DHCP, DNS, NTP, and management telemetry enable endpoints and operators; NAT enforces addressing and security boundaries; QoS preserves user experience for real-time applications; multicast scales one-to-many distribution; and active monitoring with IP SLA and object tracking closes the loop for resiliency. This section explains the design and operational reasoning for each, highlighting failure modes and trade-offs.

Foundational IP Services and Telemetry

DHCP: Provide addresses and options centrally while ensuring relay scale and correctness.

• Relay and option handling: Use ip helper-address on the first-hop interface to unicast client broadcasts to the DHCP server. Include only required UDP helpers (e.g., 67/68 DHCP, 53 DNS, 69 TFTP, 161 SNMP) to limit noise. Option 43 supplies CAPWAP APs with WLC addresses; Option 82 (relay information) adds circuit identifiers for per-port policy and reservations. Trust or strip Option 82 thoughtfully—access-layer switches typically insert and upstream devices should not overwrite.
• Allocation models: Dynamic pool with reservations for infrastructure MACs or client IDs, static bindings for critical infrastructure, and short leases for highly mobile or VPN pools. Consider subnet utilization and split-scope or DHCP failover for resilience.
• Troubleshooting: Validate L2 reachability and VLANs first, then relay reachability and giaddr population. On Cisco IOS, use show ip dhcp binding, show ip dhcp server statistics, and debug ip dhcp server events with caution. Common failures include missing helper addresses on SVI, Option 82 dropped by a firewall, or an exhausted pool.

DNS: Deploy redundant, anycast-capable resolvers near users. Enforce split-horizon records for internal services. Cache close to clients to reduce latency. Secure with DNSSEC validation and restrict recursion to internal subnets.

NTP: Time consistency protects logs, Kerberos, and certificates. NTPv4 adds security extensions and uses site-local IPv6 multicast for discovery on LANs. Design with at least two upstream sources (public or enterprise stratum-1/2) and distribute via internal stratum-3 servers. Prefer authentication (symmetric keys or NTS) and avoid device-to-Internet NTP from every node; point infrastructure to local NTP servers.

Management plane and telemetry:

• SNMP: Prefer SNMPv3 for auth/privacy; minimize polling intervals; group OIDs by role. Limit SNMP with ACLs and Control Plane Policing (CoPP) to protect from overload and abuse. Traps/informs should be rate-limited.
• Syslog: Use reliable transport where supported and send to at least two collectors. Normalize severity (0–7) and time-stamp via NTP. Implement parsing for key events (link flaps, route changes, security).
• NetFlow/IPFIX: Export only needed fields; use sampling on high-throughput links. Ensure collector capacity and privacy controls. Prefer IPFIX for vendor-neutral extensibility.
• Model-driven telemetry: Stream YANG-modeled data (gNMI/NETCONF dial-in/out) at fixed intervals; it’s lower latency and more efficient than bulk SNMP. Align collection with SLI/SLOs (e.g., drops, queue depth, CPU, memory, route churn).

NAT: Static, Dynamic, PAT, and Validation

NAT enforces address independence, policy, and overlapping-IP migration. Choose the simplest construct that meets the requirement.

• Static NAT: One-to-one, deterministic. Use for inbound services, VoIP gateways, and IPsec peers that require stable identity. Trade-off: consumes public IPs.
• Dynamic NAT (pool): Many-to-fewer mapping with ephemeral selection from a pool for outbound-only clients. Return routing must target the NAT device; asymmetry breaks sessions.
• PAT (overload): Many-to-one mapping using unique TCP/UDP ports on a single IP (or few IPs). Extremely efficient but can exhaust ports under heavy connection concurrency; distribute PAT across multiple addresses on high-scale edges.
• Hairpin and twice NAT: Required when internal hosts must reach internal services via the public address or need to re-map both source and destination. Validate policy and route matching carefully.
• Order of operations and VRFs: Ensure NAT occurs at the correct stage relative to ACLs, ZBFW, and PBR. For VRF designs, apply per-VRF NAT rules and confirm route-leaking for return traffic.
• High availability: Stateful NAT is mandatory for seamless failover; otherwise, use deterministic static NAT on both peers with first-hop redundancy and accept session loss for dynamic/PAT flows.
• Validation and troubleshooting: show ip nat translations and statistics, confirm hit counters on ACLs, verify routes to/from the NAT outside. Debug sparingly; packet captures are often safer. Watch for port exhaustion, overlapping pools, and asymmetric routing.

Short example: ip access-list standard NAT_INSIDE permit 10.10.0.0 0.0.255.255 ip nat pool PUBLIC 198.51.100.10 198.51.100.14 netmask 255.255.255.248 ip nat inside source list NAT_INSIDE pool PUBLIC overload interface Gig0/0 ip nat inside interface Gig0/1 ip nat outside

QoS: Classification, Marking, Queues, and Congestion Management

End-to-end QoS preserves performance under contention; design the trust boundary and forwarding behavior consistently across access, distribution, WAN, and data center.

• Classification and marking: Classify at the edge; trust only capable devices. Typical trust boundary is the access switch port to an IP phone (trust CoS/DSCP from the phone, not the attached PC) and to infrastructure devices. Use NBAR or ACLs to classify when markings are missing. Re-mark noncompliant traffic at the edge.
• DSCP and CoS: DSCP EF (46) for voice bearer, CS3 for call signaling, AF41 for interactive video, AF31/AF32 for critical data, CS1 for scavenger. Map DSCP to per-hop behaviors and to L2 CoS for trunks.
• Queues and scheduling: Use LLQ for strict-priority traffic (EF) with a policed bandwidth cap to prevent starvation. CBWFQ for assured classes with minimum bandwidth guarantees. Validate hardware queue-to-DSCP mappings per platform.
• Shaping and policing: Shape at egress to a contracted CIR to smooth bursts (especially toward WAN). Police at ingress to enforce tenant or class limits; understand policing adds loss and potential reordering if not mindful.
• Congestion avoidance: WRED drops early based on average queue depth and DSCP, protecting interactive flows at the expense of elastic bulk. Do not enable WRED on strict-priority queues. Tail-drop remains for classes where WRED has no benefit or hardware does not support it.
• Voice/video SLAs: One-way latency ≤150 ms, jitter ≤30 ms, loss ≤1% for voice; interactive video is slightly more tolerant to loss but similarly sensitive to delay variation. Engineer EF bandwidth from codec rates plus headers, VAD, and growth margin; constrain LLQ to protect other classes. For TelePresence/interactive video, allocate AF41 with appropriate minimum bandwidth and shaping on low-speed links.
• Verification: show policy-map interface to confirm class counters, drops, and shaping compliance. Monitor interface queue depth and drop reasons; adjust bandwidth and thresholds based on measured utilization, not peak link rate claims.

Short LLQ example: class-map match-any VOICE match dscp ef class-map match-any VIDEO match dscp af41 policy-map WAN-QOS class VOICE priority percent 10 police rate percent 10 conform-action transmit exceed-action drop class VIDEO bandwidth percent 20 random-detect dscp-based class class-default fair-queue random-detect interface Serial0/0/0 service-policy output WAN-QOS

Multicast: Forwarding, PIM, RPs, and Design Across Campus and WAN

Multicast scales one-to-many traffic efficiently and requires tight coupling with unicast routing for Reverse Path Forwarding (RPF) checks.

• IGMP: Hosts join/leave groups via IGMP (v2 widely deployed, v3 adds source filtering for SSM). Enable IGMP snooping on switches; ensure an IGMP querier exists per VLAN to maintain group state even without a multicast router on the segment.
• PIM modes:
  • PIM Sparse Mode (PIM-SM): Pull model; only sends traffic to interested receivers. An RP is the tree root for the shared tree (*,G). By default, the RP is needed only to start new sessions; receivers may switch to the source tree (S,G) for optimal paths once traffic flows.
  • PIM Source-Specific Multicast (SSM): No RP; receivers specify (S,G) via IGMPv3. Simplifies control plane and mitigates many-to-many risks. Ideal for IPTV and tightly controlled sources.
  • PIM Bidirectional: Efficient for many-to-many with low state and no source registration (e.g., financial market data), but no shortest-path switch-over; design accordingly.
• RP strategies:
  • Static RP for small domains.
  • BSR/Auto-RP for dynamic discovery.
  • Anycast-RP with MSDP to share source registration between multiple RPs using a single anycast address, improving resilience and locality.
• RPF and SPT switch-over: RPF failures stem from unicast route asymmetry or filtered prefixes; verify with show ip rpf and show ip mroute. SPT thresholds govern when to move from the shared tree to the source tree; set them based on traffic volume and core path symmetry.
• Campus design: Use PIM-SM in the routed core, IGMP snooping with queriers at the access edge, and Anycast-RP across aligned core nodes. Prefer SSM where hosts support IGMPv3; otherwise, deploy SSM mapping at the first-hop router.
• WAN design: Over MPLS, use provider mVPN if available; otherwise, run PIM across the WAN VRF or encapsulate with GRE/DMVPN and enable PIM inside tunnels. Ensure RP reachability across domains and confirm provider acceptance of multicast or plan overlays. For Internet-based distribution, prefer SSM with GRE/IPsec to avoid RP dependencies across untrusted domains.

Short PIM/RP example: ip pim rp-address 10.10.10.10 ip pim ssm range 232.0.0.0/8 interface Vlan30 ip pim sparse-mode ip igmp version 3

Active Monitoring, Automated Failover, and Troubleshooting

IP SLA and tracking automate corrective action and validate SLAs in real time.

• IP SLA: ICMP-echo for reachability, UDP jitter for voice/video quality, HTTP/TCP connect for app availability. For multicast, UDP jitter operations can test group delivery to a specific (S,G) or (*,G).
• Object tracking and triggers: Track IP SLA results, interface states, or routes. Tie tracking to HSRP/VRRP, static routes, or PBR. Use EEM applets for complex sequences (log, reconfigure, notify).
• Example: ip sla 10 udp jitter 239.1.1.1 5000 source-ip 10.1.1.10 frequency 30 ip sla schedule 10 life forever start-time now track 10 rtr 10 reachability ip route 0.0.0.0 0.0.0.0 198.51.100.1 10 track 10 ip route 0.0.0.0 0.0.0.0 203.0.113.1 200
• Service availability monitoring: Combine SNMP counters (drops, errors), QoS queue stats, NetFlow/IPFIX for class utilization, and syslog for anomaly correlation. Time synchronization must be strict or multi-source correlation fails.
• Common failure modes and trade-offs:
  • DHCP: Option 82 stripped by firewalls; split-scope overlap; rogue DHCP servers—enable DHCP snooping.
  • DNS: Asymmetric policy or blocked EDNS0; anycast failure without withdrawal leads to blackholes—monitor BGP health if using anycast.
  • NTP: Peering loops and false tickers; unauthenticated time shifts cause cert failures—enforce authentication and sanity thresholds.
  • NAT: Asymmetric routing across redundant edges breaks sessions; PAT port exhaustion—scale out pools or use per-flow hashing with ECMP aware of stateful devices.
  • QoS: Over-provisioned LLQ starves other classes; mis-mapped DSCP on a platform leads to unexpected queues—validate platform-specific QoS maps.
  • Multicast: RPF failures from route filters; RP reachability loss stalls new joins; IGMP snooping without a querier ages out memberships—enable a querier or PIM router presence on the VLAN.
  • Control plane overload: Excess polling or trap storms destabilize routing—apply CoPP and telemetry rate limits.

Practical Problem Scenario

Acme BioTech must support site-to-site multicast video training, VoIP, and cloud Internet access from two redundant data centers connected via MPLS with an Internet VPN backup. Users report intermittent video freezes during trainings and occasional call quality degradation during failover events.

Approach:

1. Normalize and secure time across the estate.

• Configure NTPv4 on all network devices to local stratum-2 servers with authentication. Rationale: Consistent time ensures valid QoS analytics, correlates syslog/NetFlow, and prevents certificate anomalies that could break management APIs during failover.

2. Stabilize DHCP and DNS for infrastructure endpoints and phones.

• Ensure ip helper-address on access SVIs, enable Option 82 insertion at access and trust at distribution, and provide Option 150 for phone TFTP where applicable. Validate DNS resolvers are reachable from all VLANs. Rationale: Stable addressing and name resolution eliminate spurious phone re-registers and AP/controller discovery failures that can cascade into QoS issues.

3. Implement QoS with a clear trust boundary and WAN shaping.

• Trust markings from IP phones and TelePresence endpoints; remark PCs to default. Apply LLQ for EF at 10% with a policer, AF41 for interactive video at 20% with WRED, and shape egress to the MPLS CIR on WAN edges. Rationale: Preserves voice and interactive video under contention and prevents provider policing drops by matching the contracted rate.

4. Optimize multicast for campus and WAN.

• Deploy PIM-SM in the core with Anycast-RP across the two data centers using MSDP, enable IGMP v3 on access VLANs, and prefer SSM (232/8) for training streams where sources are known. Rationale: Anycast-RP maintains session starts across data centers; SSM removes RP dependency for primary training streams and simplifies WAN traversal.

5. Validate NAT and path symmetry at the Internet edge.

• Use stateful NAT on the HA pair for outbound PAT, deterministic static NAT for inbound services, and ensure HSRP aligns with the active stateful peer. Rationale: Prevents session loss and asymmetry during failover that could impact softphone media to cloud services.

6. Deploy IP SLA with object tracking to automate Internet backup failover.

• Configure IP SLA UDP jitter probes toward the cloud SBC and ICMP toward the MPLS PE; track results to adjust static routes or influence BGP local preference. Rationale: Measures real service quality, not just reachability; triggers controlled failover before users notice degradation.

7. Instrument telemetry and protect the control plane.

• Stream queue-depth and drop counters via model-driven telemetry to collectors, enable NetFlow/IPFIX on WAN edges, and restrict SNMP to NMS IPs with SNMPv3. Apply CoPP with explicit class for management traffic. Rationale: Provides actionable visibility while ensuring the control plane remains stable under monitoring load.

8. Test, observe, and tune.

• Run a scheduled multicast training with synthetic VoIP calls while capturing show policy-map interface, show ip mroute, and queue drops. Adjust LLQ and AF41 bandwidths based on measured utilization and provider behavior. Rationale: Empirical tuning aligns QoS allocations with real traffic patterns and provider policing characteristics.

This sequence addresses clock stability, foundational services, queuing and rate control, correct multicast control-plane behavior, NAT symmetry, automated failover, and observability—together yielding consistent voice and video performance across MPLS and Internet paths.

← Unicast Routing and Route Control · All domains · Wireless Infrastructure and Mobility →

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