ccna fault finding labs · 2018-12-20 · lab 1: eigrp basic ..... 34 lab 2: eigrp advanced ........

84

Upload: others

Post on 10-Mar-2020

10 views

Category:

Documents


1 download

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

[email protected]

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 22

Both ports are DESG

CCNA Fault Finding Labs

Copyright Commsupport Networks Ltd Page 23

PAGE INTENTIONALLY LEFT BLANK

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 33

PAGE INTENTIONALLY LEFT BLANK

CCNA Fault Finding Labs

Copyright Commsupport Networks Ltd Page 34

EIGRP

Lab 1: EIGRP Basic

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 44

PAGE INTENTIONALLY LEFT BLANK

CCNA Fault Finding Labs

Copyright Commsupport Networks Ltd Page 45

NAT Lab 1: NAT & Telnet

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 52

PAGE INTENTIONALLY LEFT BLANK

CCNA Fault Finding Labs

Copyright Commsupport Networks Ltd Page 53

Fix the Networks

CCNA Fault Finding Labs

Copyright Commsupport Networks Ltd Page 54

Fix the Network: Lab 1

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 56

Solutions Fix the Network

CCNA Fault Finding Labs

Copyright Commsupport Networks Ltd Page 57

Solution: Fix the Network: Lab 1

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