LogoفارسیFA

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

Integrated BGP DMVPN QoS TroubleshootingRoute Reflector Client OmissionNHRP Registration Failure Diagnosis

~4 min read · Updated Sep 27, 2026

Lab Objective

Diagnose and resolve three independently introduced faults across the combined BGP-over-DMVPN-with-QoS topology built across recent labs — a spoke omitted from the hub's route-reflector-client configuration, a spoke with a broken NHRP registration preventing tunnel formation, and a QoS policy marking traffic with the wrong DSCP value — using the systematic troubleshooting approach established throughout this entire series.

Lab Purpose

This capstone lab combines faults across BGP route reflection, DMVPN tunnel establishment, and QoS marking — three of the most advanced topics covered across this extended series — demonstrating that the same bottom-up, evidence-based diagnostic discipline applied to the very first Layer 1 troubleshooting lab scales without modification to the most sophisticated multi-technology environments an engineer is likely to encounter.

Lab Topology

Hub (route reflector, DMVPN hub, QoS
     marking point) ---- DMVPN ---- Spoke1
Hub ---- DMVPN ---- Spoke2

Voice traffic from Spoke1's LAN should be
marked EF and prioritized outbound from
the hub toward the WAN

Three faults have been deliberately
introduced across these three systems

Task 1: Confirm the Reported Symptoms

Spoke2 cannot see Spoke1's routes via BGP, Spoke2's tunnel appears to never have fully formed, and voice quality from Spoke1 is poor. Confirm all three symptoms.

Task 2: Diagnose and Resolve the BGP Route Reflector Fault

Examine the hub's BGP configuration to identify why one spoke's routes are not being reflected.

Task 3: Diagnose and Resolve the NHRP Registration Fault

Examine Spoke2's tunnel configuration to identify why its NHRP registration with the hub never completed.

Task 4: Diagnose and Resolve the QoS Marking Fault

Examine the QoS policy applied at the hub to identify why voice traffic is not receiving the correct treatment.

Task 5: Verify All Symptoms Are Resolved

Confirm BGP route reflection works for both spokes, Spoke2's tunnel is fully registered, and voice traffic is correctly marked and prioritized.

Solution and Verification

-- Fault 1: Missing route-reflector-client

Hub# show running-config | section router bgp

router bgp 65100
 neighbor 172.16.200.2 remote-as 65100
 neighbor 172.16.200.2 route-reflector-client
 neighbor 172.16.200.3 remote-as 65100
-- Spoke2 (172.16.200.3) has a neighbor
-- statement but is MISSING the
-- route-reflector-client keyword -- FAULT 1
-- IDENTIFIED: without this, the hub treats
-- Spoke2 as a normal iBGP peer subject to
-- the split-horizon rule, never reflecting
-- Spoke1's routes to it

Hub(config)# router bgp 65100
Hub(config-router)# neighbor 172.16.200.3 route-reflector-client
-- Corrected

-- Fault 2: NHRP registration failure

Spoke2# show running-config interface tunnel0

interface Tunnel0
 ip address 172.16.200.3 255.255.255.0
 tunnel source gigabitethernet0/1
 tunnel mode gre multipoint
 ip nhrp network-id 1
 ip nhrp nhs 172.16.200.1 nbma 203.0.113.99
-- The nbma address (203.0.113.99) does not
-- match the hub's actual WAN address --
-- FAULT 2 IDENTIFIED: wrong NBMA address
-- prevents Spoke2 from ever reaching the
-- hub to register

Hub# show ip interface brief | include GigabitEthernet0/1
GigabitEthernet0/1   203.0.113.50   YES manual up  up
-- Confirms the hub's actual address

Spoke2(config)# interface tunnel0
Spoke2(config-if)# no ip nhrp nhs 172.16.200.1 nbma 203.0.113.99
Spoke2(config-if)# ip nhrp nhs 172.16.200.1 nbma 203.0.113.50
-- Corrected

-- Fault 3: QoS marking mismatch

Hub# show policy-map MARK-VOICE

  Class-map: VOICE-TRAFFIC (match-all)
    Match protocol rtp
  QoS Set
    dscp af31
-- Voice traffic is being marked AF31
-- instead of EF -- FAULT 3 IDENTIFIED:
-- the priority queue elsewhere in the
-- policy matches specifically on EF, so
-- this mismarked traffic never receives
-- priority treatment at all

Hub(config)# policy-map MARK-VOICE
Hub(config-pmap)# class VOICE-TRAFFIC
Hub(config-pmap-c)# set dscp ef
-- Corrected

Spoke2# show ip bgp

   Network             Next Hop        Path
*>i 192.168.11.0/24    172.16.200.2    i
-- Spoke2 now correctly learns Spoke1's LAN

Hub# show ip nhrp | include 172.16.200.3
172.16.200.3/32 via 172.16.200.3, Tunnel0 created
  NBMA address: 203.0.113.51
-- Spoke2 successfully registered

Hub# show policy-map interface gigabitethernet0/2
    Class-map: VOICE-TRAFFIC
      Strict Priority
      (total drops) 0
-- Voice traffic now correctly marked EF
-- and receiving priority treatment,
-- confirmed by zero drops

Key Takeaway

Across BGP, DMVPN, and QoS — three entirely different technologies spanning the most advanced material in this series — each fault still produced the same kind of specific, checkable discrepancy this series has emphasized from its very first troubleshooting lab: a missing keyword, a mistyped address, a mismatched value between two related configuration points. No amount of technological sophistication changes the fundamental discipline of comparing what is actually configured against what the design intended, one verifiable layer at a time.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

Continue

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

Continue

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

Continue

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

Continue

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

Continue

Hands-On Lab: Configuring Cisco DNA Center Assurance-Style Health Scoring (Simulated via IP SLA and EEM)

This hands-on lab combines IP SLA monitoring with an EEM applet to simulate a simplified assurance-style health check, automatically classifying a link's health based on measured performance thresholds and logging a clear status change when the link degrades.

Continue
Previous Article