CCNP TSHOOT Chapter 9 Lab 9-2: Trouble-Ticket Scenarios and Troubleshooting Practice

What the Chapter 9 troubleshooting practice covers

CCNP TSHOOT Chapter 9 Lab 9-2 is titled “In Synch (Version 7).” The lab is organized around three independent trouble-ticket tasks that introduce problems on one or more devices. Its purpose is to practice diagnosing and resolving routing and switching problems while documenting the troubleshooting process and results.

The detailed lab covers connectivity issues related to AAA, LLDP, port security, FHRP interface tracking, FHRP IP SLA object tracking, MST, VTP, ACLs, route authentication, VRF, and BGP. The lab also notes that the trouble tickets may involve technologies from any ROUTE or SWITCH lab.

Trouble ticket	Main verification and troubleshooting scope
TT-A	VRF, BGP, MST, and VTP version 3
TT-B	ACLs, HSRP interface tracking, and IPv4 and IPv6 EIGRP summarization
TT-C	HSRP SLA object tracking, LLDP, and port security

For each task, the learner loads the applicable device configurations, diagnoses the introduced problems, makes configuration changes where necessary, and records the process and results. The lab instructions also provide space for troubleshooting approach notes, command and action logs, and debrief notes.

Lab objectives and troubleshooting record

The lab objectives require the learner to load the trouble-ticket device configuration files, diagnose and resolve the introduced problems, and document troubleshooting progress, configuration changes, and problem resolution.

The supplied procedure asks the learner to outline a troubleshooting approach, record commands and actions, document configuration changes and observed results, and write debrief notes about problems encountered, solutions applied, useful commands, alternate methods, and procedure or communication improvements.

The lab lists several approaches that may be selected for a task: follow-the-path, perform-comparison, bottom-up, top-down, divide-and-conquer, shoot-from-the-hip, and swap-components, also called move-the-problem. It also describes a generic process consisting of defining the problem, gathering information, analyzing the information, eliminating possible causes, formulating and testing a hypothesis, and solving the problem.

Trouble Ticket TT-A: Verify VRF, BGP, MST, and VTPv3

TT-A asks the learner to verify a VRF-BGP implementation against stated specifications and troubleshoot missing routes required by the VRF-BGP implementation tests. The scenario uses R2 to simulate ISP routers in AS 65502 and AS 65503, with R1 and R3 acting as edge routers in a multihomed BGP environment.

The scenario also requires verification of MST and VTP version 3 in the LAN. The switching checks cover VLAN availability, EtherChannel trunk VLAN allowances, VTP domain and version, MST mode, VTP database modes, MST region settings, MST instance mappings, and root assignments.

VRF and BGP verification scope

The stated BGP design uses R1 and R3 as iBGP peers through their loopback interfaces, with R1 and R3 as the only BGP speakers in AS 65501. The serial interfaces of R1, R2, and R3 are used for eBGP peering.

AS 65501 is configured as a transit AS, with BGP synchronization configured as a sanity check. BGP MD5 authentication with the password “cisco” is specified for all BGP neighborships. IPv4 is used as the BGP transport for both IPv4 and IPv6 routes.

The specification calls for AS 65502 loopback IPv4 and IPv6 routes to be propagated through BGP to AS 65501, and for AS 65503 loopback IPv4 and IPv6 routes to be propagated through BGP to AS 65501. R1 and R3 are also specified to advertise 10.1.0.0/16 and their connected serial IPv6 networks through BGP.

The VRF-BGP implementation tests include a successful IPv4 source traceroute from Lo1 on R2 through AS 65501 to Lo1 on R2, using traceroute vrf VPN_A 192.168.2.2 source lo1 on R2. They also include a successful IPv6 traceroute from S0/0/0 on R2 through AS 65501 to Lo1 on R2, using traceroute vrf VPN_A ipv6 2001:db8:cafe:222::2 on R2.

The lab specifically identifies a missing-route check: the VRF VPN_A IPv4 routing table should contain a BGP-learned route for Lo1 on R2. The learner is asked to verify the implementation against the stated specifications and make configuration changes where necessary.

MST and VTPv3 verification scope

The switching specification requires VLANs 99, 100, 110, 120, 200, 300, 666, and 999 to be configured on all switches. VLAN 300 is designated as the E-PEER VLAN and is intended to be the sole VLAN for EIGRP peering between DLS1 and DLS2.

EtherChannel trunks are specified to allow VLANs 99, 100, 110, 120, 200, and 300. The VTP domain is changed to TSHOOT on all switches, VTP version 3 is enabled, and the spanning-tree mode is changed to MST.

The MST database VTP mode is set to transparent on all switches. The switches are configured with the MST region name TSHOOT and configuration revision number 25. MST instance 1 maps to VLANs 99, 110, and 120.

The specification then changes both VLAN and MST database VTP modes to server. DLS1 is configured as the primary server for the VLAN VTP feature, while DLS2 is configured as the primary server for the MST VTP feature.

An MD5 VTP password of “cisco” is specified for all switches using the hidden keyword. The lab states that this causes the password to be entered each time there is a change in the primary server for the VLAN VTP feature or the MST VTP feature.

DLS1 is specified as the MST root for instance 1. MST instance 2 is configured on DLS2 to map to VLANs 100, 200, and 300, and the instance should propagate to the other switches. DLS2 is specified as the MST root for instance 2.

The source notes that completing TT-A may require revisiting the techniques used to load the configurations. Possible follow-up actions include manually adding missing VLANs, changing VLAN or MST VTP modes to transparent, configuring the MST region name or revision number, configuring an MST instance, restoring the specified VTP modes, setting MST instance priorities, and bringing opposite ends of trunks down and back up so MST can reconverge.

TT-A preparation and documentation

The TT-A device configuration table lists files for ALS1, DLS1, DLS2, R1, R2, and R3. SRV1 uses a static IPv4 address of 10.1.100.1/24 and a static IPv6 address of 2001:DB8:CAFE:100::1/64, with IPv4 and IPv6 default gateways specified in the lab. PC-B and PC-C are configured as DHCPv4 and DHCPv6 clients.

After loading the TT-A device configuration files, the procedure asks the learner to configure SRV1, start the syslog and TFTP servers, and release and renew the DHCP leases on PC-B and PC-C.

The troubleshooting record should identify the selected approach and validation steps, list commands used to gather information, record suspected causes and corrective actions, and preserve device actions and results.

Trouble Ticket TT-B: Secure iBGP and verify redundancy

TT-B introduces an implementation plan for securing iBGP traffic, implementing HSRP interface tracking, and configuring EIGRP summarization in the development lab.

The reported problems are a down iBGP connection, HSRP interface tracking that is not working properly, and missing summary routes for DLS1 loopbacks on R3.

ACL and HSRP checks

The planned ACL changes add ACLs on DLS1 and DLS2 to restrict traffic between the loopbacks of R1 and R3. The scenario states that the ACLs cannot be applied on R1 and R3 because packets sourced by a router are not filtered by an ACL on that same router.

The ACL plan includes an ACE for all UDP traffic used for network management, an ACE for EIGRP messaging, and an ACE to enable ICMP testing.

The HSRP plan is intended to change standby and active behavior when an uplink fails. On DLS1, HSRP interface tracking should cause DLS2 to become standby for all VLANs when the DLS1 uplink is down. Conversely, DLS1 should become standby for all VLANs when the DLS2 uplink is down.

EIGRP summarization checks

The scenario asks the learner to create loopbacks on DLS1 and implement IPv4 and IPv6 EIGRP summarization on the uplink from DLS2 so that DLS1 loopback routes are summarized before propagation.

The IPv4 and IPv6 summary addresses are required to be as economical as possible. The verification target is whether R3 receives the expected summary routes for the DLS1 loopbacks and whether the summaries meet the stated addressing requirement.

TT-B preparation and documentation

The TT-B device configuration table lists configuration files for ALS1, DLS1, DLS2, R1, R2, and R3. SRV1 uses the same static IPv4 and IPv6 addressing specified for TT-A, while PC-B and PC-C use DHCPv4 and DHCPv6.

The procedure asks the learner to verify that the configuration files are present, load the proper files, configure SRV1 and start the syslog and TFTP servers, and release and renew the DHCP leases on PC-B and PC-C.

The troubleshooting log should capture the selected approach, validation steps, information-gathering commands, suspected causes, corrective actions, device actions, and observed results. The TT-B procedure also includes a step for configuring DHCP redundancy for IPv4 and IPv6.

Trouble Ticket TT-C: Test SLA tracking, LLDP, and port security

TT-C focuses on SLA object tracking for HSRP, LLDP, and port security. The scenario introduces SLA object tracking and LLDP into the topology and describes initial attempts to scale the port-security configuration.

SLA-based HSRP validation

The implementation plan removes HSRP interface tracking from DLS1 and DLS2 and replaces it with HSRP SLA object tracking.

On DLS1, the plan creates an SLA based on TCP connectivity to port 22 for the IPv6 address of interface S0/0/0 on R1. If the TCP session between DLS1 and R1 S0/0/0 fails, DLS2 should become the active router for VLANs 99, 110, and 120.

The scenario states that IPv4 networks for the serial links are not advertised through EIGRP to the LAN, while the IPv6 networks are advertised. It also states that TCP Connect is used because of a known issue with the IPv6 ICMP echo SLA.

The described design expects the SLA state to be down when either the DLS1-R1 uplink is down or the R1-R2 serial link is down. The reason given is that when the F0/5 line protocol on DLS1 is down, the IPv6 route for R1 S0/0/0 is not in DLS1’s routing table because inter-VRF routing is not configured on R2.

On DLS2, the plan creates a parallel HSRP SLA object tracking solution based on TCP connectivity to port 22 for the IPv6 address of interface S0/0/1 on R3.

Because the SLA objects use TCP Connect with port 22, the scenario also asks the learner to ensure that SSH access to R1 and R2 remains possible.

LLDP and port-security validation

The plan requires LLDP to be enabled globally on all network devices with lldp run. The learner must ensure that the network devices can see their neighbors through LLDP.

Port security is removed from the ALS1 ports associated with OFFICE VLAN 120. It is then added to the two ALS1 port-channel interfaces, with up to 10 sticky secure MAC addresses allowed on each interface.

The reported TT-C issues include HSRP failover behavior during uplink or serial-link failures, SSH access to an edge router, missing LLDP neighbors on the VRF router, and an underestimated port-security MAC-address count that can place interfaces in the err-disabled state.

TT-C preparation and documentation

The TT-C device configuration table lists configuration files for ALS1, DLS1, DLS2, R1, R2, and R3. SRV1 uses the specified static IPv4 and IPv6 addresses, and PC-B and PC-C are DHCPv4 and DHCPv6 clients.

The procedure asks the learner to load the TT-C configurations, configure SRV1 and start the syslog and TFTP servers, and release and renew the DHCP leases on PC-B and PC-C.

The troubleshooting record should preserve the approach, commands, device actions, configuration changes, observed results, and final problem resolution.

How to document and validate each troubleshooting task

Use the following sequence for each active trouble ticket:

1. Verify that the required configuration files are present in flash and load the files listed for the devices in the applicable configuration table.
2. Prepare SRV1 and start the syslog and TFTP servers as specified for the task.
3. Configure PC-B and PC-C as the required DHCP clients, then release and renew their leases after the device configurations are loaded.
4. Select and record a troubleshooting approach and define the validation steps that will show whether the reported problem is resolved.
5. Define the problem, gather information, analyze the information, eliminate possible causes, formulate a hypothesis, test the hypothesis, and apply the solution.
6. Record the commands used to gather information, the device actions taken, the configuration changes made, and the observed results.
7. Complete debrief notes covering problems encountered, solutions applied, useful commands, alternate solutions or methods, and procedure or communication improvements.

Validation evidence to capture

Capture the routing, switching, neighbor-discovery, redundancy, access-control, and port-security results relevant to the active trouble ticket.

Use the implementation specifications and stated tests as the comparison point for deciding whether the problem is resolved. For TT-A, this includes the VRF traceroute tests, the expected BGP-learned route in the VPN_A IPv4 routing table, and the specified MST and VTPv3 settings. For TT-B, it includes iBGP connectivity, HSRP tracking behavior, and the IPv4 and IPv6 EIGRP summary routes toward R3. For TT-C, it includes SLA state during the described link failures, SSH reachability, LLDP neighbors, and the port-security configuration on the ALS1 port-channel interfaces.

Scope of this walkthrough

This walkthrough covers the supplied Lab 9-2 “In Synch (Version 7)” trouble-ticket scenarios, their stated verification areas, the required preparation steps, and the documentation workflow. The supplied material does not provide a complete answer key for every trouble ticket or configuration corrections beyond the described specifications, so resolving a task still requires working through the lab and recording the observed results.