CCNP Enterprise Troubleshooting Hands-On Workshop
Introduction
You are sitting in front of a terminal. A ticket comes in: PC1 cannot reach the public address 203.0.113.1. The network was working yesterday, but someone made changes to interface status, addressing, routing, and Layer 2 connectivity overnight. Where do you start? This is the reality of CCNP troubleshooting — and the ability to systematically diagnose and resolve network issues under pressure is what separates a competent engineer from one who merely passed the exam. In this comprehensive hands-on workshop guide, we walk through a structured troubleshooting lab environment featuring 27 trouble tickets that span the full breadth of the CCNP Enterprise curriculum. These scenario-based challenges mirror the kind of problems you will face in the CCNP Enterprise ENCOR and ENARSI exams and, more importantly, in production networks. Whether you are preparing for certification or sharpening your day-to-day operational skills, this workshop will make you stronger at diagnosing and fixing real network issues.
This article covers the lab topology in detail, breaks down the major troubleshooting domains you will encounter, walks through representative trouble tickets with expected outputs and verification steps, and provides practical strategies you can apply immediately. Every technical detail — IP addresses, VLAN assignments, HSRP configurations, and traceroute outputs — comes directly from the lab environment.
What Does the CCNP Troubleshooting Lab Topology Look Like?
Before diving into individual trouble tickets, understanding the lab topology is essential. The environment is built around a multi-layer campus network with distribution switches, access switches, a core router acting as a DHCP relay agent, a branch router, and an ISP edge — a design that reflects real-world enterprise deployments.
IPv4 Topology (Tickets 1 through 21)
The IPv4 portion of the lab uses the following key devices and addressing:
| Device | Role | Key Interfaces |
|---|---|---|
| DSW1 | Distribution Switch 1 | HSRP Active/Standby per VLAN |
| DSW2 | Distribution Switch 2 | HSRP Active/Standby per VLAN |
| ASW1 | Access Switch | End-user connectivity |
| ASW2 | Access Switch | End-user connectivity |
| CORE | Core Router / DHCP Relay | Relay agent address 2.2.2.2 |
| BRANCH | Branch Router | 172.16.200.0/24, gateway 172.16.200.254 |
| ISP | Internet Edge | 209.165.200.1 |
The public destination address used across nearly every ticket is 203.0.113.1, which sits behind the ISP edge. PCs in the lab are actually IOS router images configured with no ip routing and ip default-gateway, simulating endpoint behavior.
The enable secret password for all devices is: cisco.
VLAN and Subnet Assignments
| VLAN | Subnet | Gateway |
|---|---|---|
| 10 | 10.0.10.0/24 | 10.0.10.254 |
| 20 | 10.0.20.0/24 | 10.0.20.254 |
| 30 | 10.0.30.0/24 | 10.0.30.254 |
| 40 | 10.0.40.0/24 | 10.0.40.254 |
| 99 | 10.0.99.0/24 | Management |
VLAN 99 serves as the management VLAN, with switch management addresses in the 10.0.99.0/24 range. The management IPs for the switches are:
- ASW1: 10.0.99.250
- ASW2: 10.0.99.251
- DSW1: 10.0.99.252
- DSW2: 10.0.99.253
Spanning Tree Configuration
Rapid Spanning Tree Protocol (RSTP) is deployed across the switched infrastructure with carefully assigned root bridge roles:
| VLAN | DSW1 Role | DSW2 Role |
|---|---|---|
| 10 | Root | Backup Root |
| 20 | Root | Backup Root |
| 30 | Backup Root | Root |
| 40 | Backup Root | Root |
| 99 | Root | Backup Root |
This split-root design distributes Layer 2 traffic across both distribution switches, aligning with the HSRP active/standby assignments to ensure traffic follows optimal paths.
HSRPv2 Configuration
Hot Standby Router Protocol version 2 (HSRPv2) provides first-hop redundancy with the following assignments:
| VLAN | DSW1 Role | DSW2 Role | Virtual IP |
|---|---|---|---|
| 10 | Active | Standby | 10.0.10.254 |
| 20 | Active | Standby | 10.0.20.254 |
| 30 | Standby | Active | 10.0.30.254 |
| 40 | Standby | Active | 10.0.40.254 |
| 99 | Active | Standby | 10.0.99.254 |
Notice how the HSRP active roles mirror the STP root bridge assignments. VLANs 10, 20, and 99 are active on DSW1, while VLANs 30 and 40 are active on DSW2. This alignment ensures that Layer 2 forwarding and Layer 3 gateway traffic follow the same path, avoiding suboptimal routing through the backup switch.
Advanced BGP Topology (Tickets 22 through 27)
The final six trouble tickets shift focus to advanced BGP scenarios. These tickets operate on a separate topology segment and test your ability to troubleshoot eBGP and iBGP peering, route advertisement, path selection, and policy application. The BGP tickets represent the most challenging portion of the workshop and align closely with the advanced routing topics covered in the ENARSI exam.
How Does the CCNP Troubleshooting Workflow Operate?
Each of the 27 trouble tickets in this workshop follows a consistent, structured workflow that mirrors real-world incident response:
- Read the scenario — Every ticket describes a network requirement (for example, "all PCs should have access to 203.0.113.1") and a reported symptom (for example, "PC1 cannot ping 203.0.113.1").
- Confirm the issue — Before making any changes, verify that the reported symptom is real. Run the relevant ping or traceroute from the affected PC.
- Troubleshoot systematically — Work through the OSI layers or follow a structured methodology to identify the root cause.
- Apply the fix — Make the minimum configuration change needed to resolve the issue.
- Verify the fix — Confirm that the expected output now matches the requirement.
- Document the solution — Record what was broken and how it was fixed on the answer sheet.
Pro Tip: Always confirm the issue before changing anything. In a lab or exam environment, you may find that the symptom differs from what you expected, which changes your entire troubleshooting approach.
This scenario-based format is similar to what was tested on the legacy CCNP TSHOOT exam and is directly relevant to the ENARSI lab components. The skills transfer directly to production network operations.
CCNP Troubleshooting Domain 1: Layer 2 Switching Issues
A significant number of the 27 trouble tickets involve Layer 2 problems — VLAN misconfigurations, STP issues, trunk link failures, and access port assignments. These are often the trickiest to diagnose because they are invisible to Layer 3 tools like traceroute.
Common Layer 2 Failure Scenarios
In the lab topology, the following Layer 2 elements can be misconfigured to create trouble tickets:
- VLAN assignment errors — A PC's access port placed in the wrong VLAN, preventing it from reaching its default gateway.
- Trunk link misconfigurations — Missing VLANs on trunk allowed lists between ASW and DSW switches, causing traffic to be dropped silently.
- STP root bridge changes — Altering bridge priorities so that the root bridge shifts to the wrong switch, creating suboptimal paths or loops.
- Interface shutdown — Ports administratively disabled after "several changes to interface status," a phrase that appears in every ticket description.
Diagnostic Approach for Layer 2
When a PC cannot reach 203.0.113.1 and you suspect a Layer 2 issue, start from the bottom up:
show interfaces status
show vlan brief
show interfaces trunk
show spanning-tree vlan 10
show spanning-tree root
show mac address-table
These commands let you verify that the PC's port is in the correct VLAN, that the VLAN is allowed on all trunk links between the PC and its gateway, and that STP is not blocking a critical path.
Pro Tip: The
show vlan briefcommand only shows access ports assigned to each VLAN. Trunk ports will not appear in this output even though they carry that VLAN's traffic. Always cross-reference withshow interfaces trunkto get the full picture.
CCNP Troubleshooting Domain 2: First-Hop Redundancy with HSRPv2
HSRPv2 is a critical component of the lab topology and a frequent source of trouble tickets. The lab uses HSRPv2 across all five VLANs with a split active/standby design between DSW1 and DSW2.
Trouble Ticket 8: Intermittent Default Gateway
One of the most instructive tickets in the workshop is Trouble Ticket 8. The scenario states that PC2 should reach 203.0.113.1 via its default gateway DSW2 (since PC2 is in VLAN 30, where DSW2 is the HSRP Active router). However, the reported symptom is that PC2's default gateway alternates intermittently between DSW1 and DSW2.
The broken behavior shows this traceroute output:
PC2# traceroute 203.0.113.1
Type escape sequence to abort.
Tracing the route to 203.0.113.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.30.252 3 msec 8 msec 1 msec
2 192.168.3.1 1 msec 1 msec 1 msec
3 192.168.1.1 1 msec 1 msec 1 msec
4 209.165.200.1 2 msec * 2 msec
Notice the first hop is 10.0.30.252, which is DSW1's real interface IP — not the HSRP virtual IP 10.0.30.254 and not DSW2. This means PC2 is sometimes hitting DSW1 as its gateway, which should not happen if HSRP is working correctly with DSW2 as Active for VLAN 30.
The expected (fixed) output should show:
PC2# traceroute 203.0.113.1
Type escape sequence to abort.
Tracing the route to 203.0.113.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.30.253 4 msec 6 msec 11 msec
2 192.168.4.1 1 msec 1 msec 1 msec
3 192.168.1.1 1 msec 1 msec 1 msec
4 209.165.200.1 1 msec * 2 msec
Here, the first hop is 10.0.30.253 (DSW2), confirming that DSW2 is correctly serving as the HSRP Active router for VLAN 30.
The root cause in this type of scenario typically involves HSRP priority or preempt misconfiguration. To diagnose:
show standby brief
show standby vlan 30
These commands reveal which router is Active, the configured priorities, and whether preempt is enabled. The fix involves ensuring that DSW2 has a higher HSRP priority for VLAN 30 and that preempt is enabled so it can reclaim the Active role.
CCNP Troubleshooting Domain 3: Routing and Path Selection
Routing issues form the backbone of this troubleshooting workshop. With OSPF running between the distribution switches, core router, and branch, plus static or default routes toward the ISP, there are many places where routing can break.
Trouble Ticket 4: Suboptimal Path Detection
Trouble Ticket 4 introduces a subtler problem than a complete connectivity failure. PC1 can reach 203.0.113.1, but it takes a suboptimal path. The ticket requires you to fix the routing so that the traceroute from PC1 follows this specific path:
PC1# traceroute 203.0.113.1
Type escape sequence to abort.
Tracing the route to 203.0.113.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.10.252 3 msec 4 msec 6 msec
2 192.168.3.1 1 msec 1 msec 1 msec
3 192.168.1.1 1 msec 1 msec 1 msec
4 209.165.200.1 2 msec * 2 msec
Breaking down this expected path:
- Hop 1: 10.0.10.252 — This is DSW1, the HSRP Active router for VLAN 10, confirming correct first-hop behavior.
- Hop 2: 192.168.3.1 — This is the core router, reached via the DSW1-to-CORE link (192.168.3.0/24 subnet).
- Hop 3: 192.168.1.1 — This is the ISP-facing interface of the core router (192.168.1.0/24 subnet).
- Hop 4: 209.165.200.1 — This is the ISP router, the final hop before reaching 203.0.113.1.
If the traceroute shows a different path — perhaps going through DSW2 or through the branch router — you need to examine OSPF costs, static route preferences, or administrative distances to understand why the routing table is selecting the wrong next hop.
show ip route 203.0.113.1
show ip ospf interface brief
show ip ospf neighbor
show ip route ospf
Trouble Ticket 5: Multiple PCs Affected
Trouble Ticket 5 escalates the complexity: both PC1 and PC2 cannot reach 203.0.113.1. This means the issue likely sits higher in the topology — on CORE, the ISP link, or a shared routing element — rather than on an individual access or distribution port.
The expected outputs after fixing show both PCs taking their correct paths:
PC1# traceroute 203.0.113.1
Type escape sequence to abort.
Tracing the route to 203.0.113.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.10.252 3 msec 4 msec 6 msec
2 192.168.3.1 1 msec 1 msec 1 msec
3 192.168.1.1 1 msec 1 msec 1 msec
4 209.165.200.1 2 msec * 2 msec
PC2# traceroute 203.0.113.1
Type escape sequence to abort.
Tracing the route to 203.0.113.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.0.30.253 9 msec 1 msec 1 msec
2 192.168.4.1 1 msec 1 msec 1 msec
3 192.168.1.1 1 msec 1 msec 1 msec
4 209.165.200.1 2 msec * 2 msec
Notice that PC1 (VLAN 10) goes through DSW1 (10.0.10.252) via the 192.168.3.0/24 link, while PC2 (VLAN 30) goes through DSW2 (10.0.30.253) via the 192.168.4.0/24 link. This confirms the split HSRP and routing design is working as intended.
CCNP Troubleshooting Domain 4: Network Services — Telnet and TFTP
Not all trouble tickets involve ping failures. Several tickets test your ability to troubleshoot network services such as Telnet and TFTP, which require correct Layer 3 reachability plus properly configured application-layer services.
Trouble Ticket 6: Telnet Connectivity to All Switches
Trouble Ticket 6 requires PC1 to successfully Telnet to all four switches using their management VLAN 99 addresses. The expected output shows successful connections with username/password authentication:
PC1# telnet 10.0.99.251
Trying 10.0.99.251 ... Open
User Access Verification
Username: admin
Password:
ASW2>
PC1# telnet 10.0.99.252
Trying 10.0.99.252 ... Open
User Access Verification
Username: admin
Password:
DSW1>
PC1# telnet 10.0.99.253
Trying 10.0.99.253 .. Open
User Access Verification
Username: admin
Password:
DSW2>
PC1# telnet 10.0.99.250
Trying 10.0.99.250 ... Open
User Access Verification
Username: admin
Password:
ASW2>
When Telnet fails, the issue could reside at multiple layers:
- Layer 3: No route from PC1 to the 10.0.99.0/24 management subnet.
- VTY line configuration: Missing
login local, no username configured, ortransport inputnot allowing Telnet. - Access control lists: An ACL applied to the VTY lines or the SVI blocking Telnet traffic.
- Management VLAN: VLAN 99 not extended to the PC's switch or not allowed on trunks.
show ip route 10.0.99.0
show run | section line vty
show access-lists
show vlan id 99
Trouble Ticket 7: TFTP File Transfer
Trouble Ticket 7 takes services troubleshooting further. PC1 must be able to copy the startup configuration from all four switches using TFTP:
PC1# copy tftp://10.0.99.250/startup-config null:
Accessing tftp://10.0.99.250/startup-config...
Loading startup-config from 10.0.99.250 (via Ethernet0/0): !
[OK - 3494 bytes]
3494 bytes copied in 0.116 secs (30121 bytes/sec)
PC1# copy tftp://10.0.99.252/startup-config null:
Accessing tftp://10.0.99.252/startup-config...
Loading startup-config from 10.0.99.252 (via Ethernet0/0): !
[OK - 4719 bytes]
4719 bytes copied in 0.153 secs (30843 bytes/sec)
TFTP uses UDP port 69 and has unique troubleshooting requirements. Beyond basic reachability, you must verify that the TFTP server service is enabled on the switches and that no ACLs are blocking UDP traffic. The copy command to null: is a useful technique — it copies the file but discards it, confirming that the transfer works without cluttering the local file system.
Pro Tip: When troubleshooting TFTP failures, remember that TFTP uses ephemeral UDP ports for data transfer after the initial connection on port 69. An ACL that permits port 69 but blocks high-numbered UDP ports will cause the initial connection to succeed but the data transfer to fail.
CCNP Troubleshooting Domain 5: DHCP and Relay Agent Configuration
The lab topology uses the CORE router as a DHCP relay agent with the address 2.2.2.2. The DHCP relay forwards broadcast DHCP requests from client VLANs to a centralized DHCP server.
Understanding the DHCP Architecture
| Component | Detail |
|---|---|
| Relay Agent | CORE router |
| Relay Source IP | 2.2.2.2 |
| VLAN 10 Subnet | 10.0.10.0/24, Gateway 10.0.10.254 |
| VLAN 20 Subnet | 10.0.20.0/24, Gateway 10.0.20.254 |
| VLAN 30 Subnet | 10.0.30.0/24, Gateway 10.0.30.254 |
| VLAN 40 Subnet | 10.0.40.0/24, Gateway 10.0.40.254 |
| Branch Subnet | 172.16.200.0/24, Gateway 172.16.200.254 |
When DHCP is involved in a trouble ticket, check the following:
show ip dhcp pool
show ip dhcp binding
show ip helper-address
show ip interface vlan 10
The ip helper-address command on the SVI interfaces of DSW1 and DSW2 must point to the DHCP server. If the relay agent address (2.2.2.2) is not reachable from the distribution switches due to a routing issue, DHCP will fail even though the DHCP server itself is functioning correctly.
Pro Tip: DHCP relay issues often masquerade as "PC cannot get an IP address" problems. Always check whether the relay agent IP (in this case, 2.2.2.2) is reachable from the distribution switch SVIs before investigating the DHCP server configuration itself.
How Should You Approach IPv6 CCNP Troubleshooting?
Trouble Ticket 15 introduces IPv6 into the troubleshooting mix. The scenario states that PC3 should have access to all OSPF IPv6 prefixes but cannot ping them. The target IPv6 address is:
PC3# ping 2001:db8:beef:1::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:BEEF:1::1, timeout is 2 seconds
IPv6 troubleshooting in the CCNP context adds several layers of complexity compared to IPv4:
Key Differences in IPv6 Troubleshooting
| Aspect | IPv4 | IPv6 |
|---|---|---|
| Routing Protocol | OSPFv2 | OSPFv3 |
| Address Assignment | DHCP or Static | SLAAC, DHCPv6, or Static |
| Neighbor Discovery | ARP | NDP (ICMPv6) |
| Link-Local Addresses | Not applicable | Required for routing |
| Multicast Dependency | Optional | Essential for routing |
When troubleshooting IPv6 OSPF connectivity, the diagnostic commands differ from IPv4:
show ipv6 route
show ipv6 ospf neighbor
show ipv6 ospf interface
show ipv6 interface brief
Common IPv6 issues in the lab include:
- OSPFv3 not enabled on an interface — The
ipv6 ospf <process-id> area <area-id>command missing from an interface. - Link-local address issues — IPv6 routing protocols use link-local addresses for next-hop resolution. If the link-local address is missing or misconfigured, OSPF adjacencies will fail.
- IPv6 unicast routing not enabled — The global command
ipv6 unicast-routingmust be present on all routers participating in IPv6 routing. - ACLs blocking ICMPv6 — IPv6 relies heavily on ICMPv6 for Neighbor Discovery. Overly aggressive ACLs can break basic connectivity.
Pro Tip: Trouble Ticket 15 is flagged as one where you should notify the proctor when you begin. This typically indicates it is more complex or time-sensitive than other tickets. Budget your time accordingly and have your IPv6 troubleshooting methodology ready before starting.
What Are the Advanced BGP Troubleshooting Scenarios?
Tickets 22 through 27 focus exclusively on advanced BGP troubleshooting. These six tickets operate on a separate topology segment and represent the most challenging portion of the workshop. BGP is a core topic in both the ENCOR and ENARSI exams, and these tickets test deep understanding of BGP behavior.
BGP Troubleshooting Methodology
BGP issues can be broadly categorized into three areas:
-
Peering failures — The BGP session does not come up. This could be due to incorrect neighbor IP addresses, AS number mismatches, missing
update-sourceconfiguration, or connectivity issues between peers. -
Route advertisement issues — The session is up, but routes are not being advertised or received. This involves network statements, route redistribution, route maps, and prefix lists.
-
Path selection problems — Routes are received but the wrong path is selected. This requires understanding the BGP best path selection algorithm, including attributes like weight, local preference, AS path length, MED, and origin type.
Key diagnostic commands for BGP troubleshooting:
show ip bgp summary
show ip bgp neighbors
show ip bgp
show ip bgp neighbor <ip> advertised-routes
show ip bgp neighbor <ip> received-routes
show ip bgp neighbor <ip> routes
show route-map
show ip prefix-list
Structured BGP Diagnostic Steps
When approaching a BGP trouble ticket:
-
Verify session state — Use
show ip bgp summaryto check if the session is in Established state. If it shows Idle, Active, or Connect, the session is not up. -
Check connectivity — Can you ping the neighbor's IP address? Is there a route to it? For iBGP peers, is
update-source loopbackconfigured and is the loopback reachable? -
Verify configuration — Are the AS numbers correct? Is the neighbor statement present on both sides? For eBGP multihop, is
ebgp-multihopconfigured? -
Check route propagation — Once the session is up, verify what routes are being sent and received. Use the
advertised-routesandreceived-routeskeywords. -
Examine policies — Route maps, prefix lists, and distribute lists can filter routes. Check for inbound and outbound policies on the BGP neighbor.
Understanding the Relationship Between STP and HSRP in CCNP Troubleshooting
One of the most important design principles reinforced throughout this workshop is the alignment between Spanning Tree Protocol root bridge placement and HSRP active router assignment. Misalignment between these two protocols is a common source of suboptimal forwarding that can be difficult to detect without careful analysis.
Why Alignment Matters
Consider what happens when STP and HSRP are not aligned for VLAN 10. If DSW1 is the HSRP Active router (meaning all PCs in VLAN 10 send their traffic to DSW1 as the default gateway), but DSW2 is the STP root bridge for VLAN 10, the following sequence occurs:
- PC1 sends a frame destined for 203.0.113.1 to the HSRP virtual MAC address, which DSW1 owns.
- DSW1 receives the frame and performs a routing lookup. It forwards the packet out its uplink toward CORE.
- However, since DSW2 is the STP root for VLAN 10, the Layer 2 path from access switches to DSW1 may be suboptimal — traffic from ASW1 might need to traverse through DSW2 first before reaching DSW1, because STP has blocked the direct path to DSW1 in favor of the path through the root bridge (DSW2).
This creates unnecessary traffic on the inter-switch link. In the lab topology, the correct alignment is:
- VLANs 10, 20, 99: DSW1 is both the STP Root and HSRP Active
- VLANs 30, 40: DSW2 is both the STP Root and HSRP Active
When a trouble ticket involves suboptimal paths or intermittent gateway behavior, always verify both the STP root placement and the HSRP active assignment for the affected VLAN. A mismatch between the two is often the root cause.
show spanning-tree root
show standby brief
These two commands, run on both distribution switches, give you an immediate picture of whether the design alignment is intact or has been disrupted by configuration changes.
Verifying STP and HSRP Together
A quick verification table you can build during troubleshooting:
| VLAN | STP Root (Expected) | STP Root (Actual) | HSRP Active (Expected) | HSRP Active (Actual) | Aligned? |
|---|---|---|---|---|---|
| 10 | DSW1 | ? | DSW1 | ? | ? |
| 20 | DSW1 | ? | DSW1 | ? | ? |
| 30 | DSW2 | ? | DSW2 | ? | ? |
| 40 | DSW2 | ? | DSW2 | ? | ? |
| 99 | DSW1 | ? | DSW1 | ? | ? |
Fill in the "Actual" columns using the show commands above. Any mismatch is a candidate for the root cause.
Systematic CCNP Troubleshooting Strategies for Exam Success
Beyond the specific tickets, this workshop teaches a systematic troubleshooting methodology that applies to any network problem. Here are the key strategies:
The Bottom-Up Approach
Start at Layer 1 and work your way up:
- Physical/Data Link — Is the interface up/up? Is it in the correct VLAN? Are trunks passing the right VLANs?
- Network — Does the device have a valid IP address? Is there a route to the destination? Is OSPF/BGP adjacency up?
- Transport — Are the right ports open? Is any ACL blocking traffic?
- Application — Is the service (Telnet, TFTP) configured correctly?
The Divide-and-Conquer Approach
For connectivity issues between two endpoints, test from the middle of the path:
- Can the distribution switch ping the destination?
- If yes, the problem is between the PC and the distribution switch (Layer 2, HSRP, VLAN).
- If no, the problem is upstream (routing, ISP link, core router).
Documentation and Verification
Every trouble ticket requires you to document your solution. This discipline is valuable beyond the lab:
- Record the symptom (what was reported)
- Record the root cause (what was actually wrong)
- Record the fix (the exact commands you applied)
- Record the verification (the output that confirms the fix)
Pro Tip: In a timed environment, resist the urge to change multiple things at once. Make one change, verify, and if it does not fix the issue, revert it before trying the next hypothesis. Stacking changes makes it impossible to identify which one resolved the problem — or worse, introduces new issues.
How Many Trouble Tickets Should You Expect and How Are They Structured?
The workshop contains 27 trouble tickets organized into two major groups:
| Ticket Range | Focus Area | Topology |
|---|---|---|
| Tickets 1-21 | Campus switching, HSRP, OSPF, DHCP, services, IPv6 | Full campus + branch + ISP |
| Tickets 22-27 | Advanced BGP | Separate BGP topology |
Ticket Categories Breakdown
Based on the trouble ticket descriptions, the tickets cover these categories:
| Category | Example Tickets | Key Skills Tested |
|---|---|---|
| Basic reachability | 1, 2, 3, 9, 10, 11, 14 | Ping failure — interface, VLAN, routing |
| Suboptimal path | 4 | Traceroute analysis, OSPF cost, HSRP |
| Multi-PC failure | 5, 12, 13 | Upstream issue identification |
| Network services | 6, 7 | Telnet, TFTP, VTY, ACLs |
| HSRP/FHRP | 8 | Gateway intermittency, priority, preempt |
| IPv6 | 15 | OSPFv3, IPv6 reachability |
| Advanced BGP | 22-27 | Peering, route policy, path selection |
Each ticket follows the same structure: a stated network requirement, a description of changes that were made, a reported symptom, and (for many tickets) the expected output after the fix.
Building a CCNP Troubleshooting Checklist for Each Ticket
Having a repeatable checklist accelerates your troubleshooting process and prevents you from overlooking common issues. Based on the patterns seen across all 27 trouble tickets, here is a comprehensive checklist you can follow for each ticket:
Pre-Troubleshooting Checklist
Before making any changes, gather baseline information:
- Read the ticket carefully — Identify the affected PC, the destination, and expected behavior. Note whether the ticket asks for ping, a specific traceroute path, Telnet, or TFTP.
- Verify the symptom — Run the test from the affected PC to confirm the failure.
- Identify the expected path — Based on the VLAN, HSRP, and routing design, determine the correct path. For example, PC1 in VLAN 10 should use DSW1 (10.0.10.252) as its first hop.
Layer-by-Layer Checklist
Work through each layer systematically:
Layer 1 and 2 Checks:
- Is the PC's interface up/up?
- Is the access port in the correct VLAN?
- Are all trunk links between the access switch and distribution switch operational?
- Is the VLAN allowed on trunk links?
- Is STP blocking any critical ports?
Layer 3 Checks:
- Does the PC have the correct IP address and default gateway?
- Is the HSRP virtual IP responding?
- Does the distribution switch have a route to the destination?
- Is the OSPF adjacency up between the distribution switch and CORE?
- Is the default or static route to 203.0.113.0/24 present?
Service-Level Checks (for Telnet/TFTP tickets):
- Is the VTY configuration correct (username, password, transport input)?
- Is the TFTP service enabled?
- Are any ACLs filtering the management traffic?
Post-Fix Verification
After applying your fix, run the exact test specified in the ticket and compare your output to the expected result hop by hop. If the ticket provides a specific traceroute path, verify that every hop matches. Also test that your fix has not broken adjacent functionality — a change to a trunk configuration could affect other VLANs.
Frequently Asked Questions
What certifications does this troubleshooting workshop prepare you for?
This hands-on troubleshooting workshop prepares you directly for the CCNP Enterprise certification exams, specifically the ENCOR (350-401) and ENARSI (300-410) exams. The scenario-based format with trouble tickets is similar to the legacy CCNP TSHOOT exam and covers the same fundamental troubleshooting skills. The topics span switching, routing (OSPF and BGP), first-hop redundancy (HSRPv2), network services (DHCP, Telnet, TFTP), and IPv6 — all of which are exam objectives.
How are the PCs in the lab environment configured?
The PCs in the lab are running IOS router images configured to behave like endpoints. They use no ip routing to disable routing functionality and ip default-gateway to set their default gateway, just like a real PC would use a configured default gateway. The enable secret password on all devices is cisco. This setup allows you to run standard diagnostic commands like ping and traceroute from the PCs.
What is the significance of the 203.0.113.1 address used across the tickets?
The address 203.0.113.1 is from the 203.0.113.0/24 range, an RFC 5737 documentation address block reserved for use in examples. In this lab, it represents a public internet destination behind the ISP router and serves as the consistent target for connectivity tests across most trouble tickets (tickets 1 through 14), verifying end-to-end reachability from campus PCs through the network to the ISP edge at 209.165.200.1.
How should you manage your time across 27 trouble tickets?
Time management is critical with 27 tickets. Start with the tickets you feel most confident about to build momentum and earn points quickly. The campus switching and basic reachability tickets (1-14) tend to be faster to resolve than the advanced BGP tickets (22-27). Ticket 15 (IPv6) is specifically flagged as one where you should notify the proctor before starting, indicating it may be more complex. Save the BGP tickets for when you have a solid block of uninterrupted time, as they require deeper analysis.
What is the role of the CORE router in the lab topology?
The CORE router serves dual purposes. First, it acts as the central routing device connecting the campus distribution switches (DSW1 and DSW2) to the branch and ISP routers through OSPF. Second, it functions as the DHCP relay agent with the address 2.2.2.2, forwarding DHCP requests from client VLANs to the DHCP server. This makes it a critical device — routing issues on the CORE router can simultaneously break both data forwarding and DHCP services.
What is the difference between a complete connectivity failure and a suboptimal path issue?
A complete connectivity failure means the PC cannot reach the destination at all — ping fails with 100% packet loss. These are typically caused by interface shutdowns, missing routes, VLAN misconfigurations, or incorrect IP addressing. A suboptimal path issue, as seen in Trouble Ticket 4, means the PC can reach the destination, but traffic takes an inefficient route — perhaps going through the backup HSRP router instead of the active one, or taking a longer path through the network. Suboptimal path issues require traceroute analysis rather than simple ping tests, and they involve fixing OSPF metrics, HSRP priorities, or STP root bridge assignments.
Conclusion
This CCNP troubleshooting hands-on workshop, with its 27 scenario-based trouble tickets, provides exactly the kind of practical experience that certification exams and production networks demand. From Layer 2 VLAN and STP issues through HSRPv2 gateway problems, OSPF routing failures, network service diagnostics, IPv6 connectivity, and advanced BGP troubleshooting, the workshop covers the full spectrum of enterprise network troubleshooting.
The key takeaways are clear: always confirm the reported issue before making changes, work systematically through the layers, understand how the topology design (split STP roots aligned with HSRP active roles) dictates expected traffic paths, and verify your fix matches the expected output. The structured workflow of confirm, troubleshoot, fix, verify, and document is a discipline that will serve you well beyond any exam.
Whether you are targeting the CCNP Enterprise ENCOR or ENARSI certification or simply want to become a more effective network engineer, hands-on troubleshooting practice is irreplaceable. Theory teaches you how protocols work; troubleshooting teaches you how they break. Explore the CCNP Enterprise training resources at NHPREP to continue building your skills with structured labs that bridge certification study and real-world operations.