Hands-On Lab: Advanced Multi-Layer Troubleshooting Challenge (BGP, VXLAN, and QoS)

This hands-on lab presents a complex failure spanning BGP path selection, a VXLAN VNI mismatch, and a QoS policy misapplication simultaneously, requiring the systematic layer-by-layer troubleshooting approach used throughout this series to isolate and resolve all three faults.

Advanced Multi-Fault TroubleshootingBGP Path Selection DiagnosisVXLAN VNI Verification

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

Lab Objective

Diagnose and resolve three independently introduced faults across a topology combining BGP, VXLAN, and QoS — an incorrect local preference causing suboptimal path selection, a VNI mismatch breaking Layer 2 extension between two VTEPs, and a QoS policy applied in the wrong direction — using the systematic troubleshooting discipline established throughout this series.

Lab Purpose

This capstone lab combines faults across three of the more advanced technologies covered in this series, reinforcing that the same bottom-up, layer-by-layer methodology used for basic connectivity problems scales to sophisticated multi-technology environments — each fault here produces a distinct, identifiable signature once the right verification command is used, exactly as with every troubleshooting lab throughout this series.

Lab Topology

Site-A (R1, VTEP1) ---- BGP/VXLAN/QoS ---- Site-B (R2, VTEP2)

Expected working state:
- Traffic from Site-A to Site-B's network
  should prefer the primary path (higher
  local preference)
- HostA (Site-A, VNI 10100) should reach
  HostB (Site-B, same VLAN, should be VNI 10100)
- Voice traffic should be marked and
  prioritized outbound from R1 toward the WAN

Three faults have been deliberately introduced

Task 1: Confirm the Reported Symptoms

Traffic is taking the backup path unexpectedly, HostA cannot reach HostB, and voice quality is poor. Confirm all three symptoms.

Task 2: Diagnose and Resolve the BGP Path Selection Fault

Examine the BGP table for the affected route and identify why the expected path is not preferred.

Task 3: Diagnose and Resolve the VXLAN Fault

Examine the VNI configuration on both VTEPs and identify the mismatch preventing Layer 2 reachability.

Task 4: Diagnose and Resolve the QoS Fault

Examine the policy-map application on R1's interfaces and identify why voice traffic is not being prioritized.

Task 5: Verify All Symptoms Are Resolved

Confirm the primary BGP path is now preferred, HostA reaches HostB, and voice traffic is properly marked and queued.

Solution and Verification

-- Fault 1: BGP path selection

R1# show ip bgp 192.168.80.0

   Network              Next Hop        LocPrf  Path
*  192.168.80.0/24     [via primary]     80      65200 i
*> 192.168.80.0/24     [via backup]      100     65200 i
-- The backup path shows a HIGHER local
-- preference (100) than the intended
-- primary path (80) -- exactly backwards
-- from the design intent -- FAULT 1
-- IDENTIFIED

R1(config)# route-map SET-PRIMARY-LOCALPREF permit 10
R1(config-route-map)# set local-preference 200
R1(config)# router bgp 65100
R1(config-router)# neighbor [primary-peer] route-map SET-PRIMARY-LOCALPREF in
R1# clear ip bgp [primary-peer] soft in
-- Corrected: primary path now has the
-- highest local preference

-- Fault 2: VXLAN VNI mismatch

VTEP1# show nve vni

Interface  VNI     VLAN  State
nve1       10100   100   Up

VTEP2# show nve vni

Interface  VNI     VLAN  State
nve1       10200   100   Up
-- Both map VLAN 100 locally, but to
-- DIFFERENT VNIs (10100 vs 10200) -- they
-- are extending two completely separate
-- Layer 2 segments that never intersect --
-- FAULT 2 IDENTIFIED

VTEP2(config)# interface nve1
VTEP2(config-if)# no member vni 10200 vlan-mapping 100
VTEP2(config-if)# member vni 10100 vlan-mapping 100
-- Corrected: both VTEPs now use VNI 10100
-- for VLAN 100

-- Fault 3: QoS policy direction

R1# show policy-map interface gigabitethernet0/1

  Service-policy input: QUEUE-POLICY
-- The queuing policy is applied INBOUND
-- on the WAN interface -- queuing only
-- makes sense on egress, where congestion
-- and buffering actually occur -- FAULT 3
-- IDENTIFIED

R1(config)# interface gigabitethernet0/1
R1(config-if)# no service-policy input QUEUE-POLICY
R1(config-if)# service-policy output QUEUE-POLICY
-- Corrected: applied outbound instead

R1# show ip bgp 192.168.80.0
*> 192.168.80.0/24     [via primary]     200     65200 i
-- Primary path now preferred

HostA> ping HostB
!!!!!
Success rate is 100 percent (5/5)
-- VXLAN connectivity restored

R1# show policy-map interface gigabitethernet0/1
  Service-policy output: QUEUE-POLICY
    Class-map: VOICE-TRAFFIC
      Strict Priority
      (total drops) 0
-- Voice traffic now correctly prioritized
-- outbound, drops at zero

Key Takeaway

Even across three unrelated advanced technologies, each fault revealed itself through the same pattern established throughout this series: examine the specific attribute or state relevant to the symptom (local preference in the BGP table, VNI mapping in the NVE configuration, policy direction in the interface's service-policy output) rather than guessing broadly — this attribute-level, evidence-based diagnosis scales from the simplest Layer 1 cabling issue in an early lab to this multi-technology capstone scenario without requiring a fundamentally different troubleshooting approach.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

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.

ادامه

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.

ادامه

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.

ادامه

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.

ادامه

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.

ادامه

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.

ادامه