Lab Objective:
The focus of this lab is to hone your trouble isolation and resolution skills. This lab will include Layer 2 and Layer 3 technologies which fall within the scope of the current CCNP curriculum.
Lab Topology:
The lab network topology is illustrated below:
|
IMPORTANT NOTE If you are using the www.howtonetwork.net racks, please download and paste the troubleshooting lab configurations. If you are using your own rack or lab, please modify this configuration to reflect the actual interface types, etc, that you have on your devices. Prior to beginning all labs, apply the pre-lab configuration for each individual device. When completing these labs, it is important to resolve the trouble tickets in the order in which they are listed because they build on each other. For example, if you begin with Trouble Ticket # 3, you might not get the expected resolution or result if you have not completed Trouble Ticket # 1 and Trouble Ticket # 2. It is very important to follow the order listed. |
Trouble Ticket # 1
You have received a call from Level 1 stating that following some configuration changes, the OSPF neighbor adjacency between R1 and R2 has failed. Troubleshoot and resolve this issue.
Trouble Ticket # 2
You have received a call from Level 1 stating that following some basic network configuration changes, the OSPF adjacency between R2 and R3 is down. Troubleshoot and resolve this issue.
Trouble Ticket # 3
You have received a call from Level 1 stating that the OSPF adjacency between R3 and R4 is down. Troubleshoot and resolve this issue.
Trouble Ticket # 4
You have received a call from Level 1 stating that there is intermittent connectivity between the 150.1.1.0/24 and 150.2.2.0/24 subnets and the 150.4.4.0/24 subnet. Due to a current configuration freeze on R3, Management allows you to only make changes to ONE device. With this restriction in mind, troubleshoot and resolve this issue.
Lab Solutions
Solution # 1
The issue is that there is no clocking on the WAN link between R1 and R2:
| R1#show controllers serial 0/0 Interface Serial0/0 Hardware is PowerQUICC MPC860 DCE V.35, no clock |
| R2#show controllers serial 0/0 Interface Serial0/0 Hardware is PowerQUICC MPC860 DTE V.35 clocks stopped. |
To resolve this issue, configure clocking on R1s WAN interface:
| R1(config)#interface serial 0/0 R1(config-if)#clock rate 2000000 |
Solution # 2
The issue here is that there is an MTU mismatch between R2 and R3:
| R2#show running-config interface serial 0/1 Building configuration… Current configuration : 95 bytes |
| R3#show running-config interface serial 1/1 Building configuration… Current configuration : 102 bytes |
To resolve this issue, you can do one of the following:
- Apply the same configuration to R3s WAN interface
- Remove this configuration on R2s WAN interface
This solution shows the latter of the acceptable solutions:
| R2(config)#interface serial 0/0 R2(config-if)#no ip mtu 1492 |
Solution # 3
The issue here is that the interface configuration on R4 has been applied to the wrong interface. While R4 is connected to R3 via Serial 0/0, the configuration has been applied to Serial 0/1:
| R4#show running-config interface serial 0/1 Building configuration… Current configuration : 83 bytes |
To resolve this issue, remove this configuration from Serial 0/1 and apply it instead to Serial 0/0:
| R4(config)#default interface serial 0/1 Building configuration… Interface Serial0/1 set to default configuration |
Solution # 4
The issue here is that the configuration applied to R2 causes a recursive routing issue because the tunnel source address is learned via the tunnel interface itself:
| R2#show running-config interface loopback 0 Building configuration… Current configuration : 81 bytes |
This can be validated by looking at the contents of the routing table on R3:
| R3#show ip route 2.2.2.2 255.255.255.255 Routing entry for 2.2.2.2/32 Known via “ospf 3”, distance 110, metric 11112, type intra area Last update from 192.168.1.2 on Tunnel0, 00:00:02 ago Routing Descriptor Blocks: * 192.168.1.2, from 2.2.2.2, 00:00:02 ago, via Tunnel0 Route metric is 11112, traffic share count is 1 |
Given this issue, if logging was enabled, you would see the following printed on the console:
| R3(config)#logging console R3(config)# *Jul 10 04:34:34.091: %OSPF-5-ADJCHG: Process 3, Nbr 2.2.2.2 on Serial1/1 from LOADING to FULL, Loading Done *Jul 10 04:34:49.955: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up *Jul 10 04:34:50.067: %OSPF-5-ADJCHG: Process 3, Nbr 2.2.2.2 on Tunnel0 from LOADING to FULL, Loading Done *Jul 10 04:34:58.955: %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing *Jul 10 04:34:59.955: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down *Jul 10 04:34:59.955: %OSPF-5-ADJCHG: Process 3, Nbr 2.2.2.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or detached *Jul 10 04:35:59.955: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up *Jul 10 04:36:00.067: %OSPF-5-ADJCHG: Process 3, Nbr 2.2.2.2 on Tunnel0 from LOADING to FULL, Loading Done *Jul 10 04:36:08.955: %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing *Jul 10 04:36:09.955: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down *Jul 10 04:36:09.955: %OSPF-5-ADJCHG: Process 3, Nbr 2.2.2.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or detached |
Recursive routing issues are common when implementing tunneling. It is important to have a solid understanding of routing to avoid these issues. To resolve this issue, assign the Loopback interface to area 1 on R2:
| R2(config)#interface loopback 0 R2(config-if)#ip ospf 2 area 1 |
Final Working Router Configurations
R1
|
R1#term len 0 Current configuration : 906 bytes R1# |
R2
|
R2#term len 0 Current configuration : 1126 bytes R2# |
R3
|
R3#term len 0 Current configuration : 1624 bytes R3# |
R4
|
R4#term len 0 Current configuration : 887 bytes R4# |