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 problem report indicating that no one is able to reach switch DLS2. Troubleshoot and resolve this issue.
Trouble Ticket # 2
The NOC calls you to advise that they are unable to reach the 172.16.1.0/24 subnet from the 150.2.2.0/24 subnet. Troubleshoot and resolve this issue. However, ensure that your solution does NOT include advertising the 150.1.1.0/24 subnet via BGP or using static routes.
Trouble Ticket # 3
There is a secure tunnel between R1 and R4 that protects traffic between the 150.1.1.0/24 and 150.4.4.0/24 subnets. For some reason, this tunnel is not working and you are unable to ping between these subnets. Troubleshoot and resolve this issue.
Trouble Ticket # 4
A Multicast video solution is being tested between the 150.2.2.0/24 and the 150.3.3.0/24 subnets. However, the users are reporting that this is not working. Troubleshoot and resolve this issue. For proprietary reasons, the company does not allow RPs within the network.
Lab Solutions
Solution # 1
The issue is that DLS2 is running RIPv1 while switch DLS2 is running RIPv2. Switch DLS2 will therefore not receive any routing information from switch DLS1:
| DLS2#show ip protocols *** IP Routing is NSF aware *** Routing Protocol is “rip” |
To resolve this issue, configure switch DLS2 to also run RIPv2:
| DLS2(config)#router rip DLS2(config-router)#version 2 |
Solution # 2
There are two issues here: the first issue is that R1 has been configured with the incorrect AS number for its peer, switch DLS1:
| R1#show ip bgp summary BGP router identifier 1.1.1.1, local AS number 254 BGP table version is 12, main routing table version 12 6 network entries using 702 bytes of memory 6 path entries using 312 bytes of memory 5/4 BGP path/bestpath attribute entries using 620 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 1634 total bytes of memory BGP activity 7/1 prefixes, 7/1 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd |
To resolve this issue, implement the following configuration on router R1:
| R1(config)#router bgp 254 R1(config-router)#neighbor 150.1.1.2 remote-as 65500 |
The second issue is that the NEXT_HOP for this subnet will be unknown to R2. R2 will not be able to reach this subnet because of this. Resolve this issue on R1 as follows:
| R1(config)#router bgp 254 R1(config-router)#neighbor 10.0.0.2 next-hop-self |
Solution # 3
There issue actually resides on R2, which has an ACL applied in the inbound direction. This ACL needs to be modified to permit ESP (protocol number 50):
| R2#show ip access-lists Extended IP access list INTERNET-PROTECTION 10 permit tcp any any eq bgp (27 matches) 20 permit tcp any eq bgp any 30 deny ospf any any 40 deny eigrp any any 50 deny udp any any eq rip 60 deny 41 any any 70 permit tcp any any eq www 80 permit tcp any any eq 443 90 deny tcp any any eq telnet 100 deny tcp any eq telnet any 110 permit icmp any any 120 permit gre any any 130 permit udp any eq 50 any 140 permit udp any any eq 50 150 permit udp any eq isakmp any 160 permit udp any any eq isakmp 200 deny ip any any (83 matches) |
To resolve this issue, implement the following configuration on R2:
| R2(config)#ip access-list extended INTERNET-PROTECTION R2(config-ext-nacl)#170 permit esp any any |
Solution # 4
The issue is that Sparse Mode forwarding is being used and there is no Rendezvous Point configured on the network:
| R2#show ip pim interface
Address Interface Ver/ Nbr Query DR DR |
| R3#show ip pim interface
Address Interface Ver/ Nbr Query DR DR |
To resolve this issue, without using an RP, configure Dense Mode forwarding instead:
| R2(config)#int f0/0 R2(config-if)#ip pim dense-mode R2(config-if)#exit R2(config)#int s0/1 R2(config-if)#ip pim dense-mode |
| R3(config)#int f0/0 R3(config-if)#ip pim dense-mode R3(config-if)#exit R3(config)#int s1/1 R3(config-if)#ip pim dense-mode |
Final Working Router Configurations
R1
|
R1#ter len 0 Current configuration : 1641 bytes R1# |
R2
|
R2#term len 0 Current configuration : 1278 bytes R2# |
R3
|
R3#term len 0 Current configuration : 1532 bytes R3# |
R4
|
R4#term len 0 Current configuration : 1498 bytes R4# |
Final Working Switch Configurations
DLS1
|
DLS1#term len 0 Current configuration : 7674 bytes DLS1# |
DLS2
|
DLS2#term len 0 Current configuration : 6541 bytes DLS2# |
ALS1
|
ALS1#term len 0 Current configuration : 1830 bytes ALS1# |
ALS2
|
ALS2#term len 0 Current configuration : 1733 bytes ALS2# |