Tshoot Workbook: Lab Ver.5

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 26

TSHOOT

WORKBOOK
Lab Ver.5

cciernslabs.com
Troubleshooting Guidelines
Important !!! Read the Following Guidelines Before Starting the Section:
This Section is compromised of a set of Troubleshooting section
you have a maximum o f 2 hour to complete the section
the final score of this section is combined with the configuration section and Diagnostic section to comprise your
final pass or fail status on the CCIE labs exams
A candidate is required to pass all three sections to scheme Cisco CCIE certification
1) You will be presented with preconfigured routers and frame Relay switches in the topology
DO NOT change the following configurations on the device
a)------>HOSTNAME
b)------>ENABLE PASSWORD "cisco"
c)------>CONSOLE LINE CONFIGRATION
2) For all the authentication configuration in the lab password is "cisco" unless changed to introduce a break
3) Points are awarded for finding AND fixing insert faults in the presented fully configured topiology .An inserted
fault is an introduced break for scenario that was previously working.
depending on the scenario fixing inserted faults could require one or multiple cammand lies on the same or multiple
devices.
4) The resolution of one incidents may depend on the resolution of previous incident. the dependency will not be
visible of incidents are resolved sequence.
5) There are NO physical faults introduced in the presented topology.
6) Do not change any routing protocol boundaries refer to the provided diagram
7) Do not remove any feature configured in order to resolve an incident you must resolve the mis-configuration rather
than removing it all. The only exception to this rule is when there is no other choice than removing the faulty
configuration in order to resolve the incident
8) Static and default route are not permitted unless preconfigured .these restrictions include floating static and those
generated by routing protocol. Routers to null 0 that are generated as a result of dynamic routing protocols solution
are permitted.
9) Tunneling and policy-routing are NOT permitted unless preconfigured
10)dynamic frame relay mappings are NOT permitted
11) Points will be deducted for every incident in which candidate uses a prohibited solution
12) Candidates have control of all required device in the topology.
13) If request to verify the reach-ability from a hot machine during the lab exam use the ping command with source
option on the router that is shown connected to the subjected host in the diagram
TSHOOT TOPOLOGY
1) TICKET- L2 SWITCHING 2 points
User's that are located in VLAN 100 of the BancoBank Headquarters have
lost access to Server1, which is located on Vlan 200. Fix the problem so that
the following sequence of commands produces the same relevant output:

PC101#ping SERVER1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echoes to 172.16.200.200, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
PC101#
Other Variation:
Same Question but the output should be:

While you are resolving these faults, you are not allowed to perform
redistribution, add static or default route, layer 3 interfaces or modify access lists. Refer
to the Troubleshooting guidelines to determine if your solution is appropriate.

CHECK POINTS:-

1) Switchport security on switch interface connecting to PC101.


2) Gateway IP address is missing in DHCP pool.
3) Vlan 12 is not created on SW1 and SW2.
4) User access port is configured in wrong vlan.
5) DHCP helper address is not configured on SW2.
6) Wrong subnet mask configured in DHCP Pool on R7 and R8.
7) Wrong client id pool for vlan 100
8) Vlan 12 not allowed on trunk
2) TICKET- PPP 2 points

Local Service Provider NOC connected to R11 has lost access to R17.
Local service provider Gateways must authenticate their ppp subscribers using chap.
Local service provider Gateways must offer Dynamic IP Addresses to ppp
subscribers.
Subscribers must have a default route in their routing table pointing to Local
Service Provider.
Subscribers must not use routing protocols to connect with Local Service
Provider Gateways.
Fix the so that the connectivity is restored as follows:

R17#ping 145.11.11.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echo's to 145.11.11.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/8/9 ms
R17#
While you are resolving these faults, you are not allowed to add any new
static routes, default routes or Layer 3 interfaces. Refer to the Troubleshooting
guidelines to determine if your solution is appropriate.
CHECK POINTS:-
1) Wrong DHCP Pool name on R12.
2) IP unnumbered is configured on R17.
3) R17 is configured PPP CHAP callout / callin
4) R12 is not enabled for PPP CHAP authentication.
5) R12 is not configured PPP IPCP Pool.
6) ppp ipcp route default not enabled on R17.
7) ppp ipcp route default enabled on R12.

Other Variation:
Same Question but asked to telnet from R11 to R17's IP address 145.67.89.22 as shown
below:

CHECK POINTS:-
1) Need to check line vty configuration on R17
2) access-list blocking port no. 23
3) TICKET- OSPF 2 points

Assume that there is a server located in OSPF Area 1 on the link between R21 and R22
in the Global Service Provider Network. The NOC team has identified that the traffic
that originates in OSPF Area 0 and destined to this server is not load balanced by R1.
Fix the so that R1 traffic be can load balanced as shown in output:
While you are resolving these faults, you are not allowed to configure static IP
and add any new static route, default route or Layer 3 interfaces. Refer to the
Troubleshooting guidelines to determine if your solution is appropriate.

CHECK POINTS:-
1) Wrong subnet mask is configured on R22 interface.
2) Passive interface is configured on R21.
3) OSPF cost 1 is configured on R22 interface connecting to R21.
4) Wrong OSPF metric configured on R5.
5) Wrong metric on R3.
6) OSPF point to point on R5.
7) Summary address on R3.
8) Passive interface is configured on R22.
4) TICKET- EIGRP 2 points

Traffic originating from R11 in Local Service Provider Core destined to loopback 0 of R14
must be load balanced via EIGRP as shown in the exhibit below :
R11#show ip route 145.14.14.14
Routing entry for 145.14.14.14/32
Known via "eigrp 145", distance 90, metric 1703, type internal
Redistributing via eigrp 145
Last update from 145.67.89.2 on Ethernet0/0, 00:03:35 ago
Routing Descriptor Blocks:
* 145.67.89.6, from 145.67.89.6, 00:03:35 ago, via Ethernet1/0
Route metric is 1703, traffic share count is 1
Total delay is 7000 microseconds, minimum bandwidth is
10000 Kbit Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
145.67.89.2, from 145.67.89.2, 00:03:35 ago, via Ethernet0/0
Route metric is 1703, traffic share count is 1
Total delay is 7000 microseconds, minimum bandwidth is
10000 Kbit Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
R11#
While you are resolving these faults, you are not allowed to add new static routes, default
routes or layer 3 interfaces. Refer to the Troubleshooting guidelines to determine if your
solution is appropriate

CHECK POINTS:-
1) Distribute list on R13 is denying R14 loopback advertisement.
2) Offset list on R13 is manipulating EIGRP metrics.
3) Incorrect Bandwidth/Delay on R13 and metric weight needs to be changed.
4) Incorrect interface bandwidth configured on R12.
5) TICKET- BGP 2 points

Networks hosted behind Internet must be able to be reached from R12 in EIGRP
145 Domain.
R12 should be able to prefer the reachability through R22 rather than R21.
Fix the so that the following traceroute from R12 should be matched with the
output as given below:
R12#traceroute
8.8.8.8
Goes via R21

R12#traceroute
194.1.1.1
Goes via R22

R12#traceroute
123.3.3.3
Goes via R4

R12#traceroute
123.21.21.21
Goes via R6
While you are resolving these faults, you are not allowed to and add any new static routes,
default routes or Layer 3 interfaces. Refer to the Troubleshooting guidelines to determine if
your solution is appropriate
CHECK POINTS:-
1) Next-hop-self missing on R22.
2) Metric (MED)configuration for selective prefixes on R21 and
R22.
3) R12 is not enabled for EBGP Multipath.
4) R21 or R22 is sending 194.1.0.0/24 with better local
preference.
5) Wrong metric on R4.
6) Wrong metric on R6.
7) Wrong metric on R3.
8)

Other Variation:
Same question but asked to trace the following routes with probe 2 from R12
R12# traceroute 8.8.8.8 probe 2
R12# traceroute 194.1.1.1 probe 2
R12# traceroute 123.3.3.3 probe 2
R12# traceroute 134.21.21.21 probe 2
The trace must match the following output:
6) TICKET- IPv6 2 points

The mobile phone which is connected in Mobile IPv6 network has lost access to
remote server that is located in the BGP AS 65535.
Global SP does not allow any IGP over IPv6 traffic to or from the Mobile IPv6
network.
Fix the so that the following sequence of commands produces the same relevant
output:

MOBILE#ping 2001::26
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001::26, timeout is 2 seconds:
Success rate is 100 percent (5/5), round trip min/avg/max =8/14/36 ms
MOBILE#

While you are resolving these faults, you are not allowed to configure static IP
and add any new static routes, default routes or Layer 3 interfaces. Refer to the
Troubleshooting guidelines to determine if your solution is appropriate.
CHECK POINTS:-
1) Mobile Network is not advertised on R25.
2) Wrong Next-hop configured on R25.
3) Mobile Host is not configured IPv6 address.
4) Mobile Host is advertised with wrong subnet mask.
5) IPv6 auto-config is not configured on MOBLIE

Other Variation:
Same question but asked to trace the following output:
7) TICKET- DMVPN 4 points
R15 in UBER Market HQ is configured as DMVPN HUB, it should be able to connect
R18 as Spoke Client. Fix the issue so that the USERs in UBER Market Sites can reach
to VPN Client PC 111 attached to R18.

While you are resolving these faults, you are not allowed to configure static IP
and add any new static routes, default routes or Layer 3 interfaces. Refer to the
Troubleshooting guidelines to determine if your solution is appropriate.
8) TICKET- MPLS 4 points
The BancoBank network design requires that any outbound traffic that generates
from any remote site be routed via the Headquarters' gateways, including internet
traffic.
R7 must be the primary gateway of the headquarters and R8 must take over if R7 is
down.
Both gateways must translate the source IP address of any private corporate traffic
that is destined to the internet using their interface E1/0.125.
The following output should be seen :
Part -1 Output:

PC106#ping 172.16.200.200
Type escape sequence to
abort.
Sending 5, 100-byte ICMP Echos to 172.16.200.200, timeout is 2 seconds:

Success rate is 100 percent (5/5), round-trip min/avg/max =


1/1/1 ms

Part - 2 Output:

PC105#traceroute 8.8.8.8
Type escape sequence to abort.
Tracing the route to 8.8.8.8
VRF info: (vrf in name/id, vrf out name/id)
1. 192.168.12.1 0 msec 0 msec 0 msec
2. 192.168.13.1 1 msec 0 msec 0 msec
3. 123.45.67.33 0 msec 0 msec 0 msec
4. 123.45.67.13 [MPLS: Labels 22/31 Exp 0] 1 msec 1 msec 0 msec
5. 123.45.67.1 [MPLS: Labels 16/31 Exp 0] 0 msec 1 msec 1 msec
6. 123.45.67.21 [MPLS: Label 31 Exp 0] 0 msec 7 msec 1 msec
7. 123.45.67.22 7 msec 0 msec 1 msec
8. 125.45.67.21 0 msec 0 msec 1 msec
9. 123.45.67.38 1 msec 0 msec 0 msec
10. 134.56.78.6 1 msec 1 msec 0 msec
11. 8.8.8.8 1 msec 1 msec *

While you are resolving these faults, you are not allowed to add any new static routes or Layer 3 interfaces
or modify ACL. Refer to the Troubleshooting guidelines to determine if your solution is appropriate.

CHECK POINTS:-
1) There are 3 s associated with this task:
a) RT is not imported on R3 and R4
b) R3 to R7 link is not advertised in to BGP
c) NAT is not correct on R7 and R8
2) R3-R7 Network is not advertised in to BGP.
3) R3-R4 are not importing RT of remote sites.
4) R7 is not advertising default route to remote sites.
5) R8 is not advertising default route to remote sites.
6) Default route on R7 configured incorrect next-hop.
7) NAT is missing inside word on R7.
8) IP NAT outside is not configured on R7.

Other Variation:
Same question but asked to trace the following output:
9) TICKET- MPLS 2 points

There is DMVPN configured between R7 - R24 via Nat Network (R23). R7 is configured as HUB
and R24 as Spoke.
User (PC 109) attached to R24 has lost the access to Headquarters.
It must be able to reach Server in BancoBank Headquarters in BGP AS 65100.
Fix the issue so that the user can reach to the Server through DMVPN.
PC109#ping server1.bancobank.org
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.200.200, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/11 ms
PC109#traceroute server1.bancobank.org Type escape sequence to abort.
Tracing the route to server1.bancobank.org (172.16.200.200) VRF
info: (vrf in name/id, vrf out name/id)
1 10.25.45.1 1 msec 1 msec 0 msec
2 172.247.247.1 9 msec 9 msec 10 msec
3 172.16.0.2 9 msec 9 msec 10 msec
4 Server1 .bancobank.org (172.16.200.200) 9 msec * 6 msec
While you are resolving these faults you are allowed to modify acl. Refer to the
Troubleshooting guidelines to determine if your solution is appropriate.

CHECK POINTS:-
1) ISAKMP key Address is wrong on R7.
2) R24 Tunnel source is incorrect.
3) R24 is missing crypto IPSec profile configuration.
4) R23 has NAT Transparent disabled.
5) IPSec parameters are not matching, transform set wrong on R24.
6) R24 has NAT Transparent disabled.
7) R7 has wrong peer address.
8) R7 has wrong group configured.
10) TICKET- NAS 2 points

Internet users have lost access to the NAS server that is located in the home network.
Fix the s so that the following sequence of commands produces the same output:
R21#telnet nas.home.net 8008
Trying net.home.net (134.56.78.10, 8008)... Open
get
HTTP/1.1 400 Bad Request
Date: Sun, 12 Oct 2014 21:08:02 GMT
Server: cisco-IOS
Accept-Ranges: none
400 Bad Request
[Connection to net.home.net closed by foreign host]
R21#
Disconnect the session after testing.
CHECK POINTS:-
1) Secondary IP address configured on R24.
2) NAS is unable to ping www.cciecould.net, no ip domain lookup on NAS.
3) Wrong DHCP client ID configured on R23.
4) R23 NAT is redirecting to wrong port of NAS.
5) NAT is not configured for cciecloud.net on R23.
6) R23 is not configured as DNS server

Internet users have lost access to the NAS server that is located in the home network. Fix
the s so that the following sequence of commands produces the same output:

You might also like