CCNP TSHOOT Chapter 9 Lab 9-2, In Synch (Version 7)

Physical Topology

Logical Topology

Objectives

• Load the trouble ticket device configuration files for each trouble ticket.
• Diagnose and resolve problems related to AAA, LLDP, port security, FHRP interface tracking, FHRP IP SLA object tracking, MST, VTP, ACLs, route authentication, VRF, and BGP.
• Document troubleshooting progress, configuration changes, and problem resolution.

Background

This lab covers a range of problems and requires that you make use of the troubleshooting skills acquired throughout this course to resolve the routing and switching problems introduced. These trouble tickets may involve technologies from any ROUTE or SWITCH lab. But the focus is on connectivity issues related to AAA, LLDP, port security, FHRP interface tracking, FHRP IP SLA object tracking, MST, VTP, ACLs, route authentication, VRF, and BGP.

For each task or trouble ticket, the trouble scenario and problem symptom are described. While troubleshooting, you will discover the cause of the problem, correct it, and then document the process and results.

Trouble Tickets and Troubleshooting Logs

This lab includes three tasks. Each task is associated with a trouble ticket (TT) and introduces one or more errors on one or more devices. If time is a consideration, each task or trouble ticket can be performed independently.

Note: This lab uses Cisco ISR G2 routers running Cisco IOS 15.4(3) images with IP Base and Security packages enabled, and Cisco Catalyst 3560 and 2960 switches running Cisco IOS 15.0(2) IP Services and LAN Base images, respectively. The 3560 and 2960 switches are configured with the SDM templates dual-ipv4-and-ipv6 routing and lanbase-routing, respectively. Depending on the router or switch model and Cisco IOS Software version, the commands available and output produced might vary from what is shown in this lab. Any changes made to the baseline configurations or topology (other than errors introduced) are noted in the trouble ticket so that you are aware of them prior to beginning the troubleshooting process.

Required Resources

• 3 routers (Cisco IOS Release 15.4 or comparable)
• 2 multilayer switches and 1 access layer switch (Cisco IOS Release 15.0(2) or comparable with Fast Ethernet interfaces)
• SRV1 (PC with static IP address): Windows 7 with RADIUS, TFTP, and syslog servers, plus an SSH client, SNMP monitor, and WireShark software
• PC-B (DHCP client): Windows 7 with SSH client and WireShark software
• PC-C (DHCP client): Windows 7 with SSH client and WireShark software
• Serial and Ethernet cables, as shown in the topology

Task 1: Trouble Ticket Lab 9-2 TT-A

Step 1: Review trouble ticket Lab 9-2 TT-A.

A LABCO company technology directive is to move toward using virtual routing and forwarding (VRF), in parallel with shifts toward desktop, server, and data virtualization. In an effort to come up to speed with the technologies, the network administrator, Sapna, built a lab environment. Sapna configured VRF on R2 to simulate ISP routers in AS 65502 and AS 65503, to model a multihomed BGP environment, with two ISPs accessed through edge routers R1 and R3. Sapna decided to avoid all NAT configurations and focus on VRF and BGP. To gain BGP expertise, she implemented BGP according to the following specifications:

• R1 and R3 are iBGP peers via their loopback interfaces.
• R1 and R3 are the only BGP speakers in AS 65501.
• The R1, R2, and R3 serial interfaces are used for eBGP peering.
• AS 65501 is a transit AS, with BGP synchronization configured as a sanity check.
• BGP MD5 authentication with password cisco is configured for all BGP neighborships.
• IPv4 is the BGP transport for both IPv4 and IPv6 routes.
• AS 65502 Lo0 IPv4 and IPv6 routes are propagated via BGP from AS 65502 to AS65501.
• AS 65503 Lo1 IPv4 and IPv6 routes are propagated via BGP from AS 65503 to AS65501.
• R1 and R3 advertise 10.1.0.0/16 and their connected serial IPv6 networks via BGP.
• BGP-VRF implementation tests:

1. Successful IPv4 source traceroute from Lo1 on R2 through AS 65501 to Lo1 on R2, using the command traceroute vrf VPN_A 192.168.2.2 source lo1 on R2 (full circle).
2. Successful IPv6 traceroute from S0/0/0 on R2 through AS65501 to Lo1 on R2, using the command traceroute vrf VPN_A ipv6 2001:db8:cafe:222::2 on R2.

Taking advantage of the short-term administrative sanction for testing VRF, Sapna decided to also implement MST and VTP version 3 in the LAN. She implemented MST and VTPv3 according to the following sequential specifications:

• Ensure that VLANs 99,100,110,120,200,300,666,999 are configured on all switches. The new E-PEER VLAN 300 is to be used as the sole VLAN for EIGRP peering between DLS1 and DLS2.
• To simplify the MST and VTPv3 configuration, allow VLANs 99,100,110,120,200,300 on all EtherChannel trunks.
• Change the VTP domain name to TSHOOT on all switches.
• Change the VTP version to 3 on all switches.
• Change the spanning tree mode to MST on all switches.
• Change the VTP mode for the MST database to transparent on all switches (vtp mode transparent mst in global configuration mode).
• Configure all switches with MST region name TSHOOT and configuration revision number 25 (administratively assigned – different from the VTP configuration revision number).
• Configure MST instance 1 on all switches to map to VLANs 99, 110, and 120.
• Change the VTP mode for both VLAN and MST databses to server on all switches.
• Configure DLS1 as the primary server for the VLAN VTP feature.
• Configure DLS2 as the primary server for the MST VTP feature.
• Configure an MD5 VTP password of cisco on all switches using the hidden keyword so that the key generated from the password cannot be discovered from the show vtp password command output and cannot be discovered by viewing the vlan.dat file (as a text file); the hidden keyword forces the password to be entered each time there is a change in primary server for the VLAN VTP feature or for the MST VTP feature.
• Configure DLS1 as the MST root for instance 1.
• Configure MST instance 2 on DLS2 to map to VLANs 100, 200, and 300. MST instance 2 should propagate to the other switches (check with show spanning-tree mst configuration and show spanning-tree mst).
• Configure DLS2 as the MST root for instance 2.

Sapna asked you to help troubleshoot some missing routes required for BGP-VRF implementation tests; for example, the VRF VPN_A IPv4 routing table should have a BGP-learned route for Lo1 on R2. Your task is to verify that the VRF-BGP implementation strictly follows her specifications, and to verify that VTPv3 is working properly with MST. Configuration changes should be made where necessary to realize the specifications.

Step 2: Load the device trouble ticket configuration files for TT-A.

Using the procedure described in the BASE Lab, verify that the lab configuration files are present in flash. Load the proper configuration files indicated in the Device Configuration File Table.

Note: Some of the devices have configuration files including alias commands, which are simply shortcuts for commands that are used frequently and are tedious to enter. For example, on R1 you will see the command alias exec srb show run | begin router bgp; this command allows you to enter srb in place of show run | begin router bgp.

Device Configuration File Table

Step 3: Configure SRV1 and start the syslog and TFTP servers.

Note: In this lab (Lab 9-2), R2 has its source interface for TFTP set as Loopback0 to enable archiving to work with the IPv4 instance of the VRF configuration.

Step 4: Release and renew the DHCP lease on PC-B and PC-C.

a. Ensure that PC-B is configured as an IPv4/IPv6 DHCP client in the OFFICE VLAN and PC-C is configured as an IPv4/IPv6 DHCP client in the GUEST VLAN.

b. After loading all TT-A device configuration files, issue the ipconfig /release and ipconfig /renew commands on PC-B and PC-C.

Step 5: Outline the troubleshooting approach and validation steps.

Use this space to identify your troubleshooting approach and the key steps to verify that the problem is resolved. Troubleshooting approaches to select from include the follow-the-path, perform-comparison, bottom-up, top-down, divide-and-conquer, shoot-from-the-hip, and swap-components (move-the-problem) methods.

Note: In addition to a specific approach, you can use the generic troubleshooting process: defining a problem, gathering information, analyzing the information, eliminating possible problem causes, formulating a hypothesis about the likely cause of the problem, testing that hypothesis, and solving the problem.
___________________________________________________________

Step 6: Record the troubleshooting process and configuration changes.

Use this log to document your actions and results during the troubleshooting process. List the commands you used to gather information. As you progress, record what you think the problem might be and which actions you will take to correct the problem.

Step 7: Document trouble ticket debrief notes.

Use this space to make notes of the key learning points that you picked up during the discussion of this trouble ticket with your instructor. The notes can include problems encountered, solutions applied, useful commands employed, alternate solutions and methods, and procedure and communication improvements.
________________________________________________________________

Note: For the remainder of this lab, MST and VTP are not included intentionally as trouble ticket issues. However, the nature of how the configurations of the devices load may require revisiting the techniques used to complete ticket TT-A. Often shutting down and bringing back up opposite ends of port-channel trunks is sufficient, but sometimes it may be necessary to manually add all missing VLANs to each switch, change VLAN and/or MST VTP modes to transparent, configure the MST region name and/or revision number, configure an MST instance, change the VLAN and/or MST VTP modes back to specifications, and configure the MST instance spanning-tree priority settings to specifications. After all this, it still may be necessary to bounce opposite ends of the trunks for MST to reconverge.

Task 2: Trouble Ticket Lab 9-2 TT-B

Step 1: Review trouble ticket Lab 9-2 TT-B.

With BGP, VRF, MST, and VTPv3 now functional and LABCO network upgrades scheduled over a week away, the network administrator, Sapna, decided to use the remaining time to secure the iBGP traffic, implement HSRP interface tracking, and configure EIGRP summarization in the development lab. Here is the implementation plan she followed:

• Add ACLs on DLS1 and DLS2 to restrict traffic between the loopbacks of R1 and R3. (The ACLs cannot be applied on R1 and R3 because packets sourced by a router are not filtered by an ACL on the same router.) Add an ACE for all UDP traffic (used for network management). Since EIGRP updates must also be supported, add an ACE for EIGRP messaging. Add an ACE to enable ICMP testing.

• Implement HSRP interface tracking on DLS1 so that if the uplink is down then DLS2 becomes standby for all VLANs. Similarly, configure DLS1 to become standby for all VLANs if the uplink from DLS2 is down.

• Create loopbacks on DLS1 and implement IPv4 and IPv6 EIGRP summarization on the uplink from DLS2 so that the DLS1 loopback routes are summarized before propagation. Make sure that the IPv4 and IPv6 summary addresses are as economical as possible.

Sapna called you in to help her troubleshoot several issues. The iBGP connection is down. And testing indicates that the HSRP interface tracking is not working properly. Also, R3 is not receiving the summary routes for the loopbacks on DLS1.

You are tasked with helping Sapna troubleshoot the issues described, as well as verifying that the IPv4 and IPv6 EIGRP summary routes are as economical as possible.

Step 2: Load the device trouble ticket configuration files for TT-B.

Using the procedure described in the BASE Lab, verify that the lab configuration files are present in flash. Load the proper configuration files indicated in the Device Configuration File Table.

Device Configuration File Table

Step 3: Configure SRV1 and start the syslog and TFTP servers, as described in Task 1.

Step 4: Release and renew the DHCP leases on PC-B and PC-C, as described in Task 1.

Step 5: Outline the troubleshooting approach and validation steps.

Use this space to identify your troubleshooting approach and the key steps to verify that the problem is resolved. Troubleshooting approaches to select from include the follow-the-path, perform-comparison, bottom-up, top-down, divide-and-conquer, shoot-from-the-hip, and swap-components (move-the-problem) methods.

Note: In addition to a specific approach, you can use the generic troubleshooting process: defining a problem, gathering information, analyzing the information, eliminating possible problem causes, formulating a hypothesis about the likely cause of the problem, testing that hypothesis, and solving the problem.
_______________________________________________________________

Step 6: Configure DHCP redundancy for IPv4 and IPv6.

Use this log to document your actions and results during the troubleshooting process. List the commands you used to gather information. As you progress, record what you think the problem might be and which actions you will take to correct the problem.

Step 7: Document trouble ticket debrief notes.

Use this space to make notes of the key learning points that you picked up during the discussion of this trouble ticket with your instructor. The notes can include problems encountered, solutions applied, useful commands employed, alternate solutions and methods, and procedure and communication improvements.
_________________________________________________________________

Task 3: Trouble Ticket Lab 9-2 TT-C

Step 1: Review trouble ticket Lab 9-2 TT-C.

Time was running short for the network administrator, Sapna, to wrap up any testing in the development lab prior to the network upgrade. In the remaining time she decided to focus on SLA object tracking for HSRP, LLDP, and port security. Sapna introduced SLA object tracking and LLDP into the topology. She made initial attempts to scale the port security configuration. Here is the implementation plan she followed:

• Remove HSRP interface tracking from DLS1 and DLS2.

• Configure HSRP with SLA object tracking. On DLS1, create 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 then DLS2 becomes the active router for VLANs 99, 110, and 120. The IPv4 networks for the serial links are not advertised via EIGRP to the LAN but the IPv6 networks are – this explains why IPv6 is used for the SLA. Also, there is a known issue with the ICMP echo SLA with IPv6 – this explains why the TCP Connect option is used. When the line protocol for F0/5 on DLS1 is down, the IPv6 route for R1 S0/0/0 is not in the routing table of DLS1 (Inter-VRF routing is not configured on R2, so DLS1 has no way to learn the IPv6 route for R1 S0/0/0 if F0/5 on DLS1 is down), so R1 S0/0/0 is not reachable from DLS1 when the line protocol for F0/5 on DLS1 is down. Hence, the SLA state is down when either the DLS1-R1 uplink is down or the R1-R2 serial link is down. The point is that this HSRP SLA object tracking solution improves upon the previous HSRP interface tracking solution.

• On DLS2, create 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.

• In consideration of the fact that the SLA objects are using TCP Connect with port 22, ensure that it is still possible to SSH to R1 and to R2.

• Globally enable Link Layer Discovery Protocol (LLDP) on all network devices (lldp run). Ensure that all network devices can “see” their neighbors via LLDP.

• Port security is removed from the ALS1 ports associated with OFFICE VLAN 120, and port security is added to the two ALS1 port-channel interfaces, allowing up to 10 sticky secure MAC addresses each.

Sapna has come to depend on your exceptional troubleshooting expertise. Help Sapna figure out why HSRP failover is not working when some uplinks and serial links are down. Also, she is not sure if TCP Connect is the cause, but she says SSH to one of the edge routers is failing. And the VRF router is not seeing any LLDP neighbors! Lastly, Sapna needs help determining how she underestimated the MAC address count required to prevent port security from placing interfaces in the err-disable state.

Step 2: Load the device trouble ticket configuration files for TT-C.

Using the procedure described in the BASE Lab, verify that the lab configuration files are present in flash. Load the proper configuration files indicated in the Device Configuration File Table.

Device Configuration File Table

Step 3: Configure SRV1 and start the syslog and TFTP servers, as described in Task 1.

Step 4: Release and renew the DHCP leases on PC-B and PC-C, as described in Task 1.

Step 5: Outline the troubleshooting approach and validation steps.

Use this space to identify your troubleshooting approach and the key steps to verify that the problem is resolved. Troubleshooting approaches to select from include the follow-the-path, perform-comparison, bottom-up, top-down, divide-and-conquer, shoot-from-the-hip, and swap-components (move-the-problem) methods.

Note: In addition to a specific approach, you can use the generic troubleshooting process: defining a problem, gathering information, analyzing the information, eliminating possible problem causes, formulating a hypothesis about the likely cause of the problem, testing that hypothesis, and solving the problem.
______________________________________________________________

Step 6: Record the troubleshooting process and configuration changes.

Use this log to document your actions and results during the troubleshooting process. List the commands you used to gather information. As you progress, record what you think the problem might be and which actions you will take to correct the problem.

Step 7: Document trouble ticket debrief notes.

Use this space to make notes of the key learning points that you picked up during the discussion of this trouble ticket with your instructor. The notes can include problems encountered, solutions applied, useful commands employed, alternate solutions and methods, and procedure and communication improvements.
_____________________________________________________________