ccna fault finding labs · 2018-12-20 · lab 1: eigrp basic ..... 34 lab 2: eigrp advanced ........
TRANSCRIPT
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 1
Copyright © 2007-2019 Commsupport Networks Ltd. All rights reserved.
The following publication, CCNA Fault Finding Lab Workbook series, was developed by
Commsupport Networks Ltd. All rights reserved. No part of this publication may be reproduced or
distributed in any form or by any means without prior written permission from Commsupport
Networks Ltd
Cisco, Cisco Systems, the Cisco logo, and CCIE are registered trademarks of Cisco Systems, Inc.
and/or its affiliates in the United States and certain other countries. All other products and
company names mentioned in this workbook are the trademarks, registered trademarks, or service
marks of their respective owners. Throughout this workbook, the authors have used their best
efforts to distinguish proprietary trademarks from descriptive names by following the capitalization
styles used by the manufacturer.
Disclaimer
The following publication: CCNA Fault Finding Labs is designed to assist students in their
preparation for the Cisco Systems CCNA Route and Switch Exam. The enclosed material is
presented to you on an “as is” basis. Every effort has been taken to ensure that all material
contained in this workbook is complete and accurate. The authors and Commsupport Networks
assume no liability or responsibility to any person or entity with respect to loss or damages
incurred by using the information contained in this workbook.
This workbook was developed by Commsupport Networks Ltd and is an original work of the
aforementioned authors.
Any similarities between material presented in this guide and actual CCNA Exam or other material
is completely coincidental.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 2
Table of Contents
DIRECTIONS ................................................................................................................................... 5
Equipment used in these labs ...................................................................................................... 5
Configurations for these labs ........................................................................................................ 5
Topology Diagram 1 ..................................................................................................................... 7
Topology Diagram 2 ..................................................................................................................... 8
Topology Diagram 3 ..................................................................................................................... 9
VLANs - SPANNING-TREE & ETHERCHANNEL ........................................................................ 12
Lab 1: Spanning-Tree ................................................................................................................. 12
Lab 2: Etherchannel and Layer 2 ................................................. Error! Bookmark not defined.
Lab 1: Spanning-Tree Solution ................................................................................................... 15
Lab 2: Etherchannel and Layer 2 Solution ................................... Error! Bookmark not defined.
INTERVLAN ROUTING ................................................................................................................. 24
Lab 1: Inter Vlan Routing ............................................................................................................ 24
Lab 2: Inter Vlan Routing “Router on a Stick” ............................... Error! Bookmark not defined.
Lab 3: Inter Vlan Routing “SVI’s on a Layer 3 Switch” .................. Error! Bookmark not defined.
Lab 1: IVR Solution .................................................................................................................... 27
Lab 2: IVR Router on a Stick Solution .......................................... Error! Bookmark not defined.
Lab 3: IVR Using Layer 3 SVI’s Solution ...................................... Error! Bookmark not defined.
EIGRP ............................................................................................................................................ 34
Lab 1: EIGRP Basic ................................................................................................................... 34
Lab 2: EIGRP Advanced .............................................................. Error! Bookmark not defined.
Lab 1: EIGRP Basic Solution ...................................................................................................... 35
Lab 2: EIGRP Advanced Solution ................................................ Error! Bookmark not defined.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 3
OSPF ................................................................................................... Error! Bookmark not defined.
Lab 1: OSPF Basic ....................................................................... Error! Bookmark not defined.
Lab 2: OSPF Medium ................................................................... Error! Bookmark not defined.
Lab 3: OSPF Advanced ................................................................ Error! Bookmark not defined.
Lab 1: OSPF Basic Solution ......................................................... Error! Bookmark not defined.
Lab 2: OSPF Medium Solution ..................................................... Error! Bookmark not defined.
Lab 3: OSPF Advanced Solution .................................................. Error! Bookmark not defined.
ACL Lab 1: ACL .................................................................................. Error! Bookmark not defined.
Lab 1: ACL Solution ..................................................................... Error! Bookmark not defined.
NAT Lab 1: NAT & Telnet............................................................................................................. 45
Lab 2: NAT & Telnet Basic ........................................................... Error! Bookmark not defined.
Lab 3: NAT & Telnet Medium ....................................................... Error! Bookmark not defined.
Lab 4: NAT & Telnet Advanced .................................................... Error! Bookmark not defined.
Lab 1: NAT & Telnet Solution ..................................................................................................... 47
Lab 2: NAT & Telnet Basic Solution ............................................. Error! Bookmark not defined.
Lab 3: NAT & Telnet Medium Solution ......................................... Error! Bookmark not defined.
Lab 4: NAT & Telnet Advanced Solution ...................................... Error! Bookmark not defined.
GRE Lab 1: GRE ................................................................................. Error! Bookmark not defined.
Lab 1: GRE Solution ..................................................................... Error! Bookmark not defined.
BGP ..................................................................................................... Error! Bookmark not defined.
Lab 1: BGP Basics ....................................................................... Error! Bookmark not defined.
Lab 1: BGP Basics Faults............................................................. Error! Bookmark not defined.
Lab 1: BGP Basics Solution ......................................................... Error! Bookmark not defined.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 4
IPv6 ..................................................................................................... Error! Bookmark not defined.
Lab 1: IPv6 ................................................................................... Error! Bookmark not defined.
Lab 2: IPv6 Auto 6to4 Tunnel ....................................................... Error! Bookmark not defined.
Lab 3: IPv6 ISATAP Tunnel .......................................................... Error! Bookmark not defined.
Lab 1: IPv6 Solution ..................................................................... Error! Bookmark not defined.
Lab 2: IPv6 Auto 6to4 Tunnel Solution ......................................... Error! Bookmark not defined.
Lab 3: IPv6 ISATAP Tunnel Solution ............................................ Error! Bookmark not defined.
HSRP ................................................................................................... Error! Bookmark not defined.
Lab 1: HSRP Basic ....................................................................... Error! Bookmark not defined.
Lab 2: HSRP Advanced ............................................................... Error! Bookmark not defined.
Lab 1: HSRP Basic Solution ......................................................... Error! Bookmark not defined.
Lab 2: HSRP Advanced Solution .................................................. Error! Bookmark not defined.
Fix the Networks .......................................................................................................................... 53
Fix the Network: Lab 1 ............................................................................................................... 54
Fix the Network: Lab 2 ................................................................. Error! Bookmark not defined.
Fix the Network: Lab 3 ................................................................. Error! Bookmark not defined.
Fix the Network: Lab 4 ................................................................. Error! Bookmark not defined.
Fix the Network: Lab 5 ................................................................. Error! Bookmark not defined.
Solutions Fix the Network ........................................................................................................... 56
Solution: Fix the Network: Lab 1 ................................................................................................. 57
Solution: Fix the Network: Lab 2 ................................................... Error! Bookmark not defined.
Solution: Fix the Network: Lab 3 ................................................... Error! Bookmark not defined.
Solution: Fix the Network: Lab 4 ................................................... Error! Bookmark not defined.
Solution: Fix the Network: Lab 5 ................................................... Error! Bookmark not defined.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 5
DIRECTIONS
Equipment used in these labs
Routers: 5 x 1841 12.4 64Mb RAM 128Mb Flash.
Switches: 3560 X 3.
Frame Relay Router: 2610 with NM-4AS.
Four Wic-1T Interfaces.
Using GNS3
It is possible to use GNS3 for these labs. With the exception of the VLANs - SPANNING-TREE &
ETHERCHANNEL and Intervlan Routing labs which can be done using live physical kit or Cisco
Packet Tracer
Configurations for these labs
Each of these labs has a text file with the broken configs which need to be loaded into the
individual devices. Templates can be downloaded from:
1. www.commsupportnetworks.co.uk
2. Hover mouse over contact us
3. Click on downloads
4. CCNA Fault Finding lab templates. This is a ZIP file
You will need to copy and paste the configurations into each router and switch before you start the
labs.
If you do intend to use physical equipment for these labs please cable the routers and switches as
you see in the Topology Diagrams 1 - 3 below. Alternatively, you can cable the routers directly if
you prefer. Please pay attention to the router interface numbering. All the routers use Fa0/0 and
Fa0/0 along with Serial 0/0/0. The Frame Relay router uses NM-4AS.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 6
For the “Fix the network” section we advise the use of GNS3.
GNS3 Devices
Routers = 7200 ios
Layer 3 Switches SW1 & SW2 = 3640 IOS with NM-16ESW in Slot0
Layer 2 Switches = One Layer 2 Ethernet switch
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 7
R1
Fa0/1Fa0/0
Fa0/1
Fa0/2
Fa0/3
Fa0/4
Fa0/5
R2
Fa0/1Fa0/0
R3
Fa0/1Fa0/0
R4
Fa0/1Fa0/0
R5
Fa0/1Fa0/0
Fa0/1
Fa0/2
Fa0/3
Fa0/4
Fa0/5
SW1 SW2
Topology Diagram 1
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 8
SW2SW1
SW3
Fa0/23 Fa0/23
Fa0/24 Fa0/24
Fa0/19
Fa0/19 Fa0/20
Fa0/20
Fa0/21
Fa0/21
Fa0/22
Fa0/22
Fa0/10
OUTSIDE
CONNECTION
Topology Diagram 2
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 9
SW2SW1
SW3
Fa0/23 Fa0/23
Fa0/24 Fa0/24
Fa0/19
Fa0/19 Fa0/20
Fa0/20
Fa0/21
Fa0/21
Fa0/22
Fa0/22
4
5
3
2
1
1 2 23 34 45 5 1
Fa0/1Fa0/0
Fa0/1
Fa0/1
Fa0/1
Fa0/1
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Topology Diagram 3
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 10
These fault-finding labs have been designed to not only take you through all of the core CCNA
Route & Switch 200-125 subjects but to hone your skills as a network engineer.
The fault finding manual was born from the idea that a network engineer is only a network
engineer if they can fix a fault in a network that they just arrived at that moment after having driven
5 hours in heavy traffic arriving 20 minutes late with the customer climbing the walls in anger that
you are the 4th network engineer your company has sent to remedy the problem.
Can you work under those conditions? Well you are going to have to because fault finding is the
holy grail of what makes the network engineer the fighter pilot of the I.T world.
Fault finding
1. Assume nothing
2. Believe nobody
3. Check everything
4. Don’t panic
5. Every question is valid
When you are fault finding try and collect as much information as you can by asking as many
questions as you deem necessary to ask so that you understand the problem as well as the
customer, when you have all the information take the time to analyse this information and rule out
anything that would not cause the problem.
When you have ruled out the possible causes you will need to hypothesise as to what could be
causing the problem, write them down and then one by one test each of your hypotheses and
document as you go along and remember to take backups as you do.
I would recommend that you attempt one lab per day each day until you complete all the labs,
there will be times that you will hit a brick wall and can’t see the solution, at that point stop, take a
break, go make a cup of tea (Coffee), relax close your eyes and think about the problem, try and
visualise the packets and frames flowing through the devices, see those parcels of data move out
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 11
of one device into another, see where in the network the problem exists, break the problem down
to its components one step at a time, draw the network out on paper and trace the flow of the data
and you will find the answer.
Above all do not give up, do not stop, do not quit. At the end of these labs you will be a great
network engineer.
Good luck
Joe Spoto
Senior Instructor
Commsupport Networks Ltd
www.commsupportnetworks.co.uk
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 12
VLANs - SPANNING-TREE & ETHERCHANNEL
Lab 1: Spanning-Tree
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 13
SCENARIO
There are three faults in the spanning-tree topology. Find them and fix them. SW1 should be the
only root bridge. SW2 ports 23 and 24 should be blocking.
EQUIPMENT USED
Cisco Packet Tracer: Cisco 3650 L3 switch x 3
Physical Kit: Cisco 3560 L3 switch x 3
CRITERIA AND LIMITATIONS
You must not reconfigure any etherchannels.
You must not change root bridge values.
REQUIRED OUTCOME:
A. SW1 is the only root bridge.
B. Port channel 1 on SW3 is a root port.
C. Port channel 2 on SW2 is a root port.
D. Ports 21 and 22 on SW3 are designated forwarding.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 14
SCENARIO
There are 4 faults in the topology. Find them and fix them. SW1 should be the only root bridge.
SW2 ports 23 and 24 should be blocking. R1 and R2 should be able to ping each other.
EQUIPMENT USED
Cisco Packet Tracer: Cisco 3650 L3 switch x 3
Physical Kit: Cisco 3560 L3 switch x 3
CRITERIA & LIMITATIONS
1. You must not reconfigure the root bridge.
2. You must not change root bridge values.
3. You must not create any additional Vlans.
REQUIRED OUTCOME
A. SW1 is the only root bridge.
B. Port channel 1 on SW3 is a root port.
C. Port channel 2 on SW2 is a root port
D. Ports 21 and 22 on SW3 are designated forwarding
E. R1 and R2 must be able to ping each other.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 15
Lab 1: Spanning-Tree Solution
Step 1
Run the “show int status” command on all three switches and focus only on the following
interfaces on each of the switches:
SW1# sho int status | inc Po
Note that Po1 is showing as not connected. This requires further investigation. Still on SW1 run
the command “show int status err”. Nothing appears in the output. Po1 is connected to SW3. Go to
switch SW3 and run the same command. You will get the following:
SW3# sho int status err-disabled
Port Name Status Reason
Fa0/19 err-disabled bpduguard
Fa0/20 err-disabled bpduguard
Po1 err-disabled bpduguard
Port Name Status Vlan Duplex Speed Type
Po1 notconnect 1 auto auto
Po2 connected trunk a-full a-100
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 16
It seems that Po1 and its associated ports are in the “Err-disabled” state. To fix this go to Interface
Port-Channel 1 to remove the command followed by bouncing the interface.
SW3(config)# inter port-channel 1
SW3(config-if)# no spanning-tree bpduguard enable
SW3(config-if)# shut
SW3(config-if)# no shut
Next check the port-channel interface on SW3 to see if the line is up and then check the status of
spanning-tree.
SW3# sho Etherchannel summary
Flags: D - down P - in port-channel
I - stand-alone s - suspended
H - Hot-standby (LACP only)
R - Layer3 S - Layer2
u - unsuitable for bundling
U - in use f - failed to allocate aggregator
d - default port
Number of channel-groups in use: 1
Number of aggregators: 1
Group Port-channel Protocol Ports
- - - - -+- - - - - - - - - - - - -+- - - - - - - - - - -+- - - - - - - - - - - - - - - - -
1 Po1(SU) PAgP Fa0/19(Pd) Fa0/20(P)
Next check the spanning-tree output on SW3. Is Po1 showing as the root port? If it is then we are
on the right track.
Etherchannel is up
on SW3
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 17
Step 2
Go to SW2 and run the command “show spanning-tree”.
On SW2 there are a few things which jump out at us. Let’s focus on the easy one first which is the
Root_Inc.
A port will go into this state when it receives a BPDU claiming to the root bridge. In this case SW1
is the root bridge so the BPDU’s that SW2 is receiving on its Po2 are legitimate. We need to
remove this command from the Po2 on SW2.
SW2(config)# int Port-channel 2
SW2(config-if)# no spanning-tree guard root
The port should now be out of Root Inc state. Once more run the “Show spanning-tree” command
on SW2.
Lots of broken stuff here Loop Inc and root Inc
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 18
Step 3
Loop Inc is caused when the interface has the “Loop Guard” command enabled. This command
keeps track of BPDU’s and is normally placed on the blocking port.
The event which will trigger Loop Guard to “Break” the connection is if it stops receiving or sending
BPDU’s. This is to prevent the port from going into the forwarding state inadvertently whilst a root
port exists.
WARNING: you must never remove loopguard from the interfaces. They are holding your
network together.
The issue here is that either ports Fa0/21 and Fa0/22 on SW2 have the BPDUFilter enabled or
ports Fa0/21 and Fa0/22 on SW3 have the BPDUFilter enabled.
Since we are on SW2 lets check here first.
Loop Inc is the last
issue
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 19
SW2#sho spanning-tree vlan 1 detail | inc Bpdu filter
Nothing there. And on SW3 it seems that there is something there.
SW3# sho spanning-tree vlan 1 detail | inc Bpdu filter
Bpdu filter is enabled
Bpdu filter is enabled
Next run the command fully without the pipe and examine the output under ports Fa0/21 and
Fa0/22.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 20
Port 21 (FastEthernet0/21) of VLAN0001 is forwarding
Port path cost 19, Port priority 128, Port Identifier 128.21.
Designated root has priority 1, address 0023.04bc.7780
Designated bridge has priority 4097, address 0006.2afb.0180
Designated port id is 128.21, designated path cost 12
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
Bpdu filter is enabled
BPDU: sent 273, received 89
Port 22 (FastEthernet0/22) of VLAN0001 is forwarding
Port path cost 19, Port priority 128, Port Identifier 128.22.
Designated root has priority 1, address 0023.04bc.7780
Designated bridge has priority 4097, address 0006.2afb.0180
Designated port id is 128.22, designated path cost 12
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 2
Link type is point-to-point by default
Bpdu filter is enabled
BPDU: sent 272, received 87
Now that we have found the issue we can easily fix this problem. Go to SW3 and remove the
BPDUFilter from the interfaces.
SW3(config)# inter range fa0/21 - 22
SW3(config-if-range)# no spanning-tree bpdufilter enable
Step 4
Verify the fixes. Recall the required outcome:
A. SW1 is the only root bridge.
BPDUFILTER
BPDUFILTER
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 21
B. Port Channel 1 on SW3 is a root port.
C. Port Channel 2 on SW2 is a root port.
D. Ports 21 and 22 on SW3 are designated forwarding.
Check that SW1 is the root bridge. The output below shows that it is, since there is no root port.
Po1 on SW3 is the root port.
Port channel 2 on SW2 is a root port.
Ports 21 and 22 on SW3 are designated forwarding.
Po2 is the root port
Po1 is root port
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 24
INTERVLAN ROUTING
Lab 1: Inter Vlan Routing
R1
192.168.10.100/24
D/G 192.168.10.254
192.168.20.100/24
D/G 192.168.20.254
PC A PC B
SW_1 SW_2
Fa0/1 Fa0/2
Vlan 10
Vla
n 2
0
Vlan 20
Vla
n 2
0
Vla
n 1
0
Router = R3
Int Fa0/0
192.168.10.254
Int Fa0/1
192.168.20.254
Fa0/3 Fa0/3
Fa0/1Fa0/0
R2R1
Fa0/1Fa0/0
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 25
Topology Using Packet Tracer
Topology Using Physical Equipment
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 26
SCENARIO
There are six faults in the Inter Vlan routing topology. Find them and fix them.
EQUIPMENT USED
Cisco Packet Tracer: Cisco 1841 Router and L3 switches x 2
Physical Kit: Cisco 1841 x 3 and 3560 L3 switches x 2
CRITERIA AND LIMITATIONS:
1. You must not use the show run command.
2. Do not enable logging or debugging.
REQUIRED OUTCOME:
A. R1 and R2 must be able to ping each other via R3.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 27
Lab 1: IVR Solution
Step 1
Test L3 connectivity from R1.
Ping 192.168.10.100 which is the local interface address and also ping 192.168.10.254 which is
the gateway for R1.
R1 can ping its own interface address, but not its own gateway.
Step 2
We know from the network diagram that R1 is connected to SW1 Fa0/1 and that Fa0/1 on SW1
should be in Vlan 10.
Go to SW1 and verify that Vlan 10 is present and that Fa0/1 is in Vlan 10. Also check that R3
Fa0/0 interface is connected to SW1 Fa0/3 and that this interface is a member of Vlan10.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 28
Look at the output. There is no mention of Fa0/1. Vlan 10 is in the “lshut” state, which means that
it has been shut down.
So what has happened to Fa0/1? One thing at a time. First of all, let’s fix Vlan.
SW1(config)# vlan 10
SW1(config-vlan)# no shut
SW1(config-vlan)# end
Now let’s find out what the issue is with Fa0/1. Run the command “show interface fa0/1
switchport”.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 29
Fa0/1 is a member of a non-existent vlan 20. All that needs to be done is to place this interface
into vlan 10 and test the ping once again.
SW1(config)# inter fas 0/1
SW1(config-if)# switchport access vlan 10
SW1(config-if)# end
Once more from R1 ping the gateway address of 192.168.10.254
Once more the ping has failed. Time to go over to R3 to see if there is a problem with the
interface.
Step 3
Go to R3 and look at the interfaces.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 30
Two issues are apparent here. Firstly, the inter Fa0/0 is shut down and the IP address on Fa0/1 is
incorrect. Let’s fix those issues now.
R3(config)# inter fa0/0
R3(config-if)# no shut
R3(config-if)# exit
R3(config)#
R3(config)# int fa0/1
R3(config-if)# ip address 192.168.20.254 255.255.255.0
R3(config-if)# end
Once more go back to R1 and ping 192.168.10.254
Success! That’s 4 faults out of 6 fixed. SW1 Fa0/1 wrong vlan; SW1 Vlan 10 was shut down;
R3 Fa0/0 interface was shut down; and R3 Fa0/1 interface address was incorrect.
Step 4
Now from R2 ping 192.168.20.100 and 192.168.20.254.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 31
Like R1, R2 can ping its own interface address but not its gateway address. Go to SW2 and check
which interfaces are in which Vlan’s. From the diagram we expect to find Fa0/2 and Fa0/3 in Vlan
20.
Two problems are apparent right away. Fa0/3 should be in Vlan 20, and Vlan 20 is showing as
unsupported which indicates that the media type has been changed for Vlan 20.
Step 5
The fix is simple. Change the media type for Vlan 20 back to Ethernet and move Fa0/3 into Vlan
20.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 32
SW2(config)# vlan 20
SW2(config-vlan)# media ethernet
SW2(config-vlan)# exit
SW2(config)# inter fas 0/3
SW2(config-if)# switchport access vlan 20
Now from R2 ping its gateway address of 192.168.20.254, then ping 192.168.10.254, followed by
pinging R1 on 192.168.10.100.
Success! All 6 faults are now fixed. The last two were simple; Fa0/3 was in the wrong vlan
and Vlan 20 was set to the wrong media type.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 35
SCENARIO
There are four faults in this topology. Find them and fix them.
EQUIPMENT USED
Physical Kit: Cisco 1841 x 4
OR
GNS3: 4 x 7200 with Module “C7200-IO-2FE” in slot 0
CRITERIA AND LIMITATIONS
1. You cannot run the show run command.
2. You must not add any static routes.
3. You must not add any new interfaces.
4. You must not change any routing processes.
REQUIRED OUTCOME
A. All prefixes must be reachable. For example, from R4 172.16.4.1 you must be able to ping
R1 172.16.1.1.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 36
Lab 1: EIGRP Basic Solution
Step 1
There is no EIGRP adjacency between R1 and R2.
First of all check the L3 connectivity.
R1# ping 10.1.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
At this point we know we have connectivity at L3.
Step 2
Check EIGRP is running on the interfaces.
R1#sho ip EIGRP interfaces detail fastEthernet 0/0
IP-EIGRP interfaces for process 1
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Fa0/0 0 0/0 0 0/1 50 0
Hello interval is 5 sec
Next xmit serial <none>
Un/reliable mcasts: 0/7 Un/reliable ucasts: 18/12
Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 0
Retransmissions sent: 6 Out-of-sequence rcvd: 0
Authentication mode is md5, key-chain is "EIGRP"
Use multicast
There is Authentication
set on Fa0/0 on R1
No peers
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 37
Step 3
Check authentication on R1.
R1# show key chain
Key-chain EIGRP:
key 1 -- text "COMMSUPPORT "
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
Step 4
Now check the key chain on R2.
R2# show key chain
Key-chain EIGRP:
key 1 -- text "COMMSUPPORT"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
There are spaces
after the password
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 38
Step 5
Fix the authentication issue on R1.
R1(config)# key chain EIGRP
R1(config-keychain)# key 1
R1(config-keychain-key)# key-string COMMSUPPORT
R1(config-keychain-key)# end
R1# sho ip EIGRP neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.12.2 Fa0/0 13 00:00:15 1 200 0 49
Step 6
There is no EIGRP neighbour adjacency between R2 an R3. Check that EIGRP is running on
Fa0/0 and Fa0/1, and that R2 and R3 are connected via F0/1.
Neighbour has
established with R2
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 39
R2# show ip EIGRP interfaces
IP-EIGRP interfaces for process 1
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Fa0/0 1 0/0 1 0/1 50 0
Lo0 0 0/0 0 0/1 0 0
F0/1 does not appear in the output above. Is it possible that EIGRP has not been enabled on R2
FA0/1? Run the command “Show ip protocols” on R2.
Step 7
The fix is as follows. On R2 remove Fa0/1 from the passive state.
Fa0/1 is set to passive
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 40
R2(config)# router EIGRP 1
R2(config-router)# no passive-interface fa0/1
When the command is removed from the EIGRP process the adjacency should
establish,
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.23.3 (FastEthernet0/1) is up:
new adjacency
This message is followed a few moment later by another message stating that the
neighbor is down
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.23.3 (FastEthernet0/1) is
down: holding time expired
Step 8
We have to dig further. Go to R3 and look at F0/1.
R3# sho run inter fas 0/1
Building configuration...
Current configuration : 124 bytes
interface FastEthernet0/1
ip address 10.1.23.3 255.255.255.0
ip hello-interval EIGRP 1 20
end
Step 9
The fix is as follows. Go to Fa0/1on R3 and change the hello timer back to 5 sec.
R3(config)# inter fas 0/1
R3(config-if)# ip hello-interval EIGRP 1 5
Now check the neighbour state with R2.
The hello timers on the interface are such
that the adj are always going out of sync
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 41
R3# show ip EIGRP neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.23.2 Fa0/1 12 00:06:05 2 300 0 1416
Step 10
There is no EIGRP neighbour state between R3 and R4. Once again verify that EIGRP is running
on the interfaces on R3.
From the output above we can see that EIGRP is operating on F0/0 which leads to R4. Next check
the EIGRP interface in detail.
Since authentication is enabled on this interface it makes sense to also check if authentication is
also enabled on the F0/0 interface on R4.
Authentication is enabled
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 42
While you are on R4 check the key-chain named “EIGRP”.
Go to R3.
The problem here seems to be a mismatch in the key numbers. You can either change the key on
R3 or on R4. Either way they must match for the EIGRP neighbours to form. Change the key
number on R3 to Key 2.
R3(config)# key chain EIGRP
R3(config-keychain)# key 2
R3(config-keychain-key)# key-string COMMSUPPORT
Next check for neighbours.
Authentication is enabled
Key 2, and no spaces
Key 1, and no spaces
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 43
Step 11
Verify that R4 172.16.4.1 can ping R1 172.16.1.1.
Success! All faults fixed.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 46
SCENARIO
The customer is reporting that when they telnet to 80.1.1.1 from R1 they cannot connect to R3. All
connections from 80.1.1.1 should be sent to 70.1.1.1.
EQUIPMENT USED
Physical Kit: Cisco 1841 x 3
OR
GNS3: 3 x 7200 with Module “C7200-IO-2FE” in slot 0
CRITERIA AND LIMITATIONS:
1. You must not change any interface addresses.
2. You must not address or remove any routes.
3. You must not telnet any address other than 80.1.1.1.
REQUIRED OUTCOME
A. When you telnet to 80.1.1.1 from R1 you should receive the telnet password prompt. The
password is “cisco”.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 47
Lab 1: NAT & Telnet Solution
Step 1
From R1 you attempt to telnet to 80.1.1.1 and there is no connection. Go to R3 and verify that the
interfaces are up and live. Also check the IP addresses on R3 loop0 interface.
R3# sho run inter loop 0
interface Loopback0
ip address 70.1.1.1 255.255.255.0
Step 2
The loop0 interface has the secondary address of 70.1.1.1. Next go to R2 and verify that R2 can
reach 70.1.1.1 by pinging 70.1.1.1 from R2.
R2# ping 70.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 70.1.1.1, timeout is 2 seconds:
Success rate is 0 percent (0/5)
No joy. Maybe this is a reachability issue from R2. Check the routing table
Step 3
Look at the routing table on R2. You should see a static route on R2 pointing to the next hop of
10.1.23.3. So the routing is good.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 48
R2# sho ip route | beg Gate
Gateway of last resort is not set
70.0.0.0/24 is subnetted, 1 subnets
S 70.1.1.0 [1/0] via 10.1.23.3
10.0.0.0/24 is subnetted, 2 subnets
C 10.1.12.0 is directly connected, FastEthernet0/0
C 10.1.23.0 is directly connected, FastEthernet0/1
S 192.168.1.0/24 [1/0] via 10.1.12.1
C 192.168.2.0/24 is directly connected, Loopback0
S 192.168.3.0/24 [1/0] via 10.1.23.3
Step 4
We know that we are expected to telnet to 80.1.1.1 and for the traffic to be received by 70.1.1.1 so
a translation should occur. We now need to locate where the translation is being performed. On
R2 run the below command.
R2# sho ip nat translations
Pro Inside global Inside local Outside local Outside global
--- 70.1.1.1 80.1.1.1 --- ---
We have a static translation rule on R2. Let’s examine the rule from the perspective of the packet
arriving to R2 from R1
The Inside Global is set to 70.1.1.1 which represents the destination the address post (after)
translation. The Inside Local is set to 80.1.1.1 which represents the address pre (before)
translation.
Below is what we want to achieve. The inside Global should be 80.1.1.1 and the Inside Local
should be 70.1.1.1 from the perspective of R2.
Route to 70.1.1.1 is in R2
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 49
R2
Towards R1Towards R3
F0/0 Fa0/1
S
D
10.1.12.1
80.1.1.1
Packet coming from R1 going to R3
S
D
10.1.12.1
70.1.1.1
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 50
Step 5
It looks like the static NAT statement on R2 is in the wrong order for this setup.
R2# show run | inc ip nat inside
ip nat inside source static 80.1.1.1 70.1.1.1
Run the command and view the syntax. When you question the command is states that the IP
address that should follow is the inside local IP address, which in our case is 70.1.1.1.
R2(config)# ip nat inside source static ?
A.B.C.D Inside local IP address
Step 6
The fix is as follows.
R2(config)# no ip nat inside source static 80.1.1.1 70.1.1.1
R2(config)#
R2(config)# ip nat inside source static 70.1.1.1 80.1.1.1
Step 7
Test and verify. Go to R1 and telnet once more to 80.1.1.1 and you should connect via telnet to
R3.
Swap the address
around
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 51
R1# telnet 80.1.1.1
Trying 80.1.1.1 ... Open
User Access Verification
Password:
R3> exit
[Connection to 80.1.1.1 closed by foreign host]
R1#
Success!
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 55
EQUIPMENT USED
Physical Kit: Cisco 1841 x 5
Cisco Layer 3 switches x 2
OR
GNS3:
4 x 7200 with Module “C7200-IO-2FE” in slot 0
2 x 3600 with Module “NM-ESW16” in slot 0
Fault 1: Host 2 cannot ping its own gateway address of 192.168.50.254
Fault 2: Host 2 cannot ping 192.168.40.100, fix this issue without using any commands on R5
Fault 3: Host 1 cannot ping its gateway of 192.168.10.254, fix this issue without configuring any
commands on R1.
Fault 4: SW1 cannot ping 192.168.20.100
Fault 5: Host 1 cannot ping 192.168.20.100, fix this using only one command.
Fault 6: R2 cannot ping the loopback address of 3.3.3.3 on R3
Fault 7: SW1 cannot ping 10.1.23.3, fix this without running any OSPF commands
Fault 8: R2 cannot ping 10.1.34.4, use only one command to fix this fault, use only an interface
level command.
Fault 9: Host 2 cannot ping 10.1.23.2. Use only two interface level commands to fix this problem
and do not advertise 192.168.50.0/24 to the rest of the network.
Fault 10: Host 2 cannot ping 192.168.10.100, use only one command to fix this problem.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 58
Fault 1: Host 2 cannot ping its own gateway address of 192.168.50.254
Step 1: First test is to ping 192.168.50.254 from Host 2
OK, so no joy
Step 2: Go to SW2 and ping 192.168.50.254 locally
Can’t ping 192.168.50.254 locally on SW2, next check if this interface is up or down
Looks like the interface is up/down. From this we can tell that the IP address is correct and
the interface does exist.
1. For an SVI on a layer 3 switch to be up/up the following conditions must be met:
Interface must be unshut
2. There must be at least one interface that is a member of the SVI corresponding vlan
3. The Vlan which corresponds to the SVI must be present.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 59
Step 3: We can see the point 1 is satisfied as the interface appears to be unshut. Next let’s take a
look at the interface which connects to R5, this interface ought to be in Vlan 50
Looks like we have something here, instead of being a member of vlan 50 the interface is a
member of vlan 500. Time to change this to vlan 50 and then test from Host 2 once it is done.
SW2(config)# int fa0/5
SW2(config-if)# switchport access vlan 50
SW2(config-if)# end
Wait around 30 seconds for spanning-tree to do its thing, then from Host 2 ping once again.
Success! First fault fixed. Interface Fa0/5 was in the incorrect vlan causing the
corresponding SVI to go into the UP/DOWN state.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 60
Fault 2: Host 2 cannot ping 192.168.40.100, fix this issue without configuring any commands on
R5
Go to R4 and check that this is indeed the address on the interface.
Next from R4 ping SVI interface vlan 40 with the ip address of 192.168.40.254 on SW2
So R4 can ping the SVI, next go to Host 2 and see if it can ping 192.168.40.100
No luck on Host 2, next look into R5s routing table, is there a default gateway configured?
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 61
Here we see the problem, there is no gateway, we ought to enter it, but the criteria states that we
are not permitted to configure Host 2. So how do we get the frames which Host 2 would like to
send off-net to the gateway?
The answer is to use the “proxy-arp” feature. When Host 2 has a packet it needs to hand to the
gateway it will arp for the gateways layer 2 address, but since Host 2 does not have a gateway
configured it instead sends an ARP out of its interface asking if there is any interface out there with
the knowledge of how to get to a particular destination and could it have that interfaces layer 2
address.
Turn on arp debugging on Host 2 and then send 1 ping to 192.168.40.254 or 192.168.40.100
Host 2 is clearly ARPing for the Layer 2 address 192.168.40.254, hoping that there is an interface
in the same broadcast domain which will answer.
Interface vlan 50 on SW2 ought to answer these ARPs since the proxy-arp feature is on by
default. Go to SW2 and check under the vlan 50 SVI to see if it has been disabled.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 62
Looks like it is turned off, turn proxy-arp back on.
SW2(config)# int vlan 50
SW2(config-if)# ip proxy-arp
Once again from Host 2 ping 192.168.40.254 and 192.168.40.100
It works, and also ping 192.168.40.100 ought to work too
Success! Second fault fixed. Here Host 2 was reliant on Proxy-ARP coming to the rescue
since Host 2 did not have a local default gateway configured.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 63
Fault 3: Host 1 cannot ping its gateway of 192.168.10.254, fix this issue without configuring any
commands on R1.
Step 1: From Host 1 ping 192.168.10.254.
Step 2: Go to SW1 and check the status of SVI interface vlan 10
This looks like it might a nice easy one after the last fault, the interface is in the shutdown state.
Best bring it on-line then test from R1 once again.
SW1# conf t
SW1(config)# int vlan 10
SW1(config-if)# no shut
SW1(config-if)# exit
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 64
Now from Host 1 test, remember to give spanning-tree time to go through its states of listening
and learning which will take around 30 seconds.
Nice one, fixed it.
Success! Third fault fixed. Host 1s gateway was shutdown, re-enable the SVI and the pings
are successful
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 65
Fault 4: SW1 cannot ping 192.168.20.100
Step 1: First test, from SW1 ping 192.168.20.100
Ok, so it does not work, you have to try these things, never take anyone’s word for it in the real
world.
Step 2: Is interface vlan 20 in the up/up state? this interface is in the next hop for R2 to the
192.168.10.0/24 subnet.
It appears that the SVI is in the up/up state so the layer 2 vlan i.e. vlan 20 is present and a
member of at least one interface.
Step 3: Go to R2 and check the interfaces to see what state they happen to be in.
The ip address we are trying to reach has been placed under a sub-interface, this means that the
frames from the switch will need to be tagged with a particular vlan id, to find out what that vlan id
is run the command “show run | sec interface Fastethernet0/0.20” or just show run
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 66
It seems that this interface is expecting the frames from SW1 to be tagged with vlan 20.
Step 4: Go to SW1 and examine Fa0/2, how is it configured?
From the output you can see that the interface is configured as a static access port, this needs to
be changed to a trunk link.
SW1(config)# default inter fa0/2
Interface FastEthernet0/2 set to default configuration
SW1(config)# int fa0/2
SW1(config-if)# switchport trunk encap dot1q
SW1(config-if)# switchport mode trunk
Once again from SW1 ping 192.168.20.100, (Remember spanning-tree delays)
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 67
We have fixed another one. This one was a little tricky.
Success! Fourth fault fixed. R2s 192.168.20.100 interface was a sub-interface expecting all
traffic to arrive tagged with the correct vlan id, the interface on SW1 was configured as an
access port and therefore all of the frames it sent towards R2 were untagged, make Fa0/2
on SW1 a trunk link and the frames retain their vlan tags
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 68
Fault 5: Host 1 cannot ping 192.168.20.100, fix this using only one command.
Step 1: From Host 1 ping 192.168.20.100
Can Host 1 ping 192.168.20.254?
Right, next, go to R2 and ping 192.168.20.254 followed by pinging 192.168.10.254
And
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 69
Looks like the problem is on R2 since Host 1 can ping an address on another subnet but R2
cannot, it maybe that R2 just does not know how to reach 192.168.10.0/24, check the routing table
on R2 for a route to 192.168.10.0/24.
Right, looks like we may be onto something here, on R2 configure a static route to 192.168.10.0
via 192.168.20.254 on SW1
R2(config)# ip route 192.168.10.0 255.255.255.0 192.168.20.254
Now from Host 1 ping 192.168.20.100
Back of the net, fixed another one !!!
Success! Fifth fault fixed. R2 did not have a static route to reach 192.168.10.0/24 subnet
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 70
Fault 6: R2 cannot ping the loopback address of 3.3.3.3 on R3
Step 1: Check the routing table on R2 for a route to 3.3.3.0/24
Step 2: Check the OSPF adjacency between R2 and R3
Nothing but the howling wind, so there ought to be an OSPF adjacency between Fa0/1 interfaces
on R2 and R3.
Step 3: From R2 ping 10.1.23.3, just to be sure it’s not an ip address issue
The pings above prove that the IP addresses are fine.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 71
Step 4: Check the fa0/1 under OSPF on R2
Looks like there is authentication applied to this interface, run the same command on R3.
Run the following command on R3, there seems to be authentication also applied to this interface.
Before we rule out it being an authentication problem, run a simple debug on R2. The debug is
showing that it is receiving a HELLO with a message digest key of 0 in the interface from R3
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 72
Look at the configuration of R3s Fa0/1 interface
The authentication key is missing. Run the same command over on R2.
The configuration on R2 has the MD5 password but no the method, in this fault the method is
configured under the ospf process on R2. Go back to R3 and enter the correct MD5 password of
“PASSWORD”
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 73
R3(config)# interface FastEthernet0/1
R3(config-if)# ip ospf message-digest-key 1 md5 PASSWORD
Next verify there is a neighbor between R2 and R3
Step 5: From R2 ping 3.3.3.3
YES, PINGS!!
Success! Sixth fault fixed. OSPF Authentication problem on R3, missing password
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 74
Fault 7: SW1 cannot ping 10.1.23.3, fix this without running any OSPF commands
Step 1: Go to SW1 and ping 10.1.23.3
Step 2: Look to see if SW1 has any routes to 10.1.23.3 in its routing table.
Nothing other than directly connected interfaces on SW1. Looks like SW1 needs a static default
route point to the next hop of 192.168.20.100
Step 2: Create the static default route on SW1
SW1(config)# ip route 0.0.0.0 0.0.0.0 192.168.20.100
Step 3: Once more from SW1 ping 10.1.23.3.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 75
These faults are falling like dominos
Success! Seventh fault fixed. SW1 was missing a default route
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 76
Fault 8: R2 cannot ping 10.1.34.4, use only one command to fix this fault, use only an interface
level command.
Step 1: On R2 and R3 ping 10.1.34.4
Nothing from R2
So we can see that the problem is not an IP addressing issue.
Step 2: Check to see it R2 has the 10.1.34.0/24 subnet in its routing table
R2 seems to know how to get to the 10.1.34.0/24 network, next item to check is to see if R4 knows
how to get to 10.1.23.0/24 subnet
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 77
R4 does not seem to have any route to 10.1.23.0/24 network. The reachability between R2 – R3 –
R4 is OSPF, next check to see if there is an OSPF adjacency between R3 and R4
No neighbor, just silence here
Step 3: Check out the OSPF setting on Fa0/0 on R3 and R4
On R3:
What are we looking for in the output from the “show ip ospf inter fa0/0” command?
1. Router-id has to be unique
2. Timers must match
3. Subnet mask must match
4. Network type must match (There are exceptions)
5. Area id must match
6. Any authentication
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 78
On R4:
Compare the following from both interfaces:
1. Router-id has to be unique = YES
2. Timers must match = YES
3. Subnet mask must match = YES
4. Network type must match (There are exceptions) = YES
5. Area id must match = NO
6. Any authentication = N/A
Fa0/0 on R3 is in Area 0 and Fa0/0 on R4 is in Area 10, to fix this problem we just have to put
Fa0/0 on R4 into Area0 using an interface level command.
R4(config)# int fa0/0
R4(config-if)# ip ospf 1 area 0
R4(config-if)# end
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 79
Step 4: Check the neighbour status on R4.
Step 5: Go back to R2 and ping 10.1.34.4
We had to work a little on that one, but in the end we got there,
Success! Eighth fault fixed. Area mis-match between R3 and R4
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 80
Fault 9: Host 2 cannot ping 10.1.23.2. Use only two interface level commands to fix this problem
and do not advertise 192.168.50.0/24 to the rest of the network.
Step 1: Go to Host 2 and ping 10.1.23.2
Step 2: Go to R4, try pinging 10.1.23.2 from there.
Step 3: Does R2 know about the 192.168.50.0/24 subnet?
Ok, looks like R2 does not know, if you ran the same command on R3 it too would have no entry
for the 192.168.50.0/24 subnet.
The criteria state we cannot advertise the 192.168.50.0/24 into the network, so how else are we
going to achieve reachability, we could use default routes, but again the criteria say we can only
use interface level commands to fix this problem.
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 81
Step 4: Take a look at R4 Fa0/0 interface for clues
Looks like there is NAT configured here, run the same command on R4 for Fa0/1 interface.
It seems that there is NAT on this router, but the interface level NAT commands are the wrong
way around.
Step 5: Swap the commands around on the interfaces, the trick it remove them both then re-apply.
R4# conf t
R4(config)# interface FastEthernet0/0
R4(config-if)# no ip nat inside
R4(config-if)# exit
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 82
R4(config)# interface FastEthernet0/1
R4(config-if)# no ip nat outside
R4(config-if)# ip nat inside
R4(config-if)# exit
R4(config-if)# interface FastEthernet0/0
R4(config-if)# ip nat outside
R4(config-if)# exit
Once again from R5 ping 10.1.23.2, this ought to now work.
Look at the NAT translations on R4.
Another horrible problem.
Success! Ninth fault fixed. NAT misconfiguration under the interface only one more to go
CCNA Fault Finding Labs
Copyright Commsupport Networks Ltd Page 83
Fault 10: Host 2 cannot ping 192.168.10.100, use only one command to fix this problem.
Step 1: None of the routers other than R2 is aware of the 192.168.10.0/24 network, there are a
few ways to fix this issue, but they all require more than one command, for example we could set
up OSPF between R1 – SW1 – R2 but again more than one command is required to make this
work.
R2 is the only router to have any knowledge of 192.168.10.0/24. R2 is running OSPF with R3, why
not import the static route into OSPF and have it advertise the 192.168.10.0/24 to its OSPF
neighbors.
R2(config)# router ospf 1
R2(config-router)# redistribute static subnets
Now if you check the routing table on R3 and R4 you will find an “ O E2” entry for 192.168.10.0/24,
go to R5 and ping 192.168.10.100, it ought to work.
Success! Tenth and final fault fixed. R2 OSPF redistributed the local static route to
192.168.10.0/24 into the OSPF process and advertised it to OSPF and R3 and R4