CCNA Online Prep Guide - Edited by : Greg Sykes

DOWN

There are 10 labs that will test your skills. This will test your troubleshooting skills as well ability to configure Cisco devices.

Task Index
Task1	IMPLEMENTING A SMALL NETWORK: Routers
Task2	IMPLEMENTING A SMALL NETWORK: Switches and Connectivity
Task3	CONFIGURING EXPANDED SWITCHED NETWORKS: VLANs and VTP
Task4	CONFIGURING EXPANDED SWITCHED NETWORKS: RSTP and Troubleshooting
Task5	IMPLEMENTING AND TROUBLESHOOTING OSPF
Task6	IMPLEMENTING AND TROUBLESHOOTING EIGRP
Task7	IMPLEMENTING AND TROUBLESHOOTING ACLs
Task8	CONFIGURING NAT AND PAT
Task9	IMPLEMENTING IPv6: Addressing, Routing, and Dual Stacking
Task10	ESTABLISHING AND TROUBLESHOOTING A FRAME RELAY

NOTE: MODIFICATIONS ARE HIGHLIGHTED IN YELLOW. CHANGES WERE MADE IN RED.

Task 1

IMPLEMENTING A SMALL NETWORK: Routers

Step 1 : Console into R1 (Router1). Enter privileged EXEC mode and erase the startup configuration.
Action:

r1> enable

r1# erase startup-config

r1#

Result:
When prompted to confirm, press ENTER.

Explanation:
The router already has a baseline configuration. You are erasing it so that you can configure one from scratch. Anytime you see a device blinking, it is a reminder to console into a new device.

System configuration has been modified. Save? [yes/no]: no
Proceed with reload? [confirm]

Step 2 : Reload R1.
Action:

r1# reload

Result:
When prompted to confirm the reload, press ENTER. If you are prompted to save your configuration before reloading, answer no. Saving your configuration at this point would undo the erasure of the startup configuration.

Step 3 : Configure R1 with a hostname.
Action:

Router> enable

Router# config t

Router(config)# hostname r1

r1(config)#

Result:
After the router reboots, type no when asked about the configuration dialog and then press ENTER two or three times so that you see the Router> prompt.

Step 4 : Configure an enable secret password of sanfran, which will be used to gain access to privileged EXEC mode.
Action:

r1(config)# enable secret sanfran

r1(config)#

Result:
Although you could change the password to something other than sanfran, you may run into unnecessary problems in later labs that are assuming that your password matches what is listed here.

Step 5 : Assign the IP address and subnet mask of 10.2.1.1 255.255.255.0 to the first Ethernet interface (f0/0) of R1.
Action:

r1(config)# interface f0/0

r1(config-if)# ip address 192.168.10.100 255.255.255.0

r1(config-if)#

Result:

Step 6 : Enable the first Ethernet interface (f0/0) of R1.
Action:

r1(config-if)# no shut

r1(config-if)#

Result:

Step 7 : Provide a description for the interface configuration describing the connected destination.
Action:

r1(config-if)# description CONNECTION TO SW1

r1(config-if)#

Result:

Step 8 : Configure a message of the day banner warning unauthorized users not to log in.
Action:

r1(config-if)# exit

r1(config)# banner motd $        (PRESS ENTER)

UNAUTHORIZED ACCESS PROHIBITED.  (PRESS ENTER)

$                                (PRESS ENTER)

r1(config)#

Result:

Explanation:
A configured banner MOTD appears before a user logs into a Cisco device. In the example here, a $ was used as the delimiter to show where the message starts and stops. The $ will not show up in the message.

Step 9 : Configure R1 to require a password when accessing the router through the console port. Use the password cisco.
Action:

r1(config)# line con 0

r1(config-line)# password cisco

r1(config-line)# login

r1(config-line)#

Result:
Although you could change the password to something other than cisco, you may run into unnecessary problems in later labs that are assuming that your password matches what is listed here.

Explanation:
There is only one console port, console port 0. When configuring a password on a console port, the default behavior is not to be prompted to enter the password when a user tries to access. To place a guard at the door, so to speak, that requests the password, you need to also enter the login command.

Step 10 : Configure R1 to require a password when accessing the router through the first five vty lines, 0 through 4. Use a password of sanjose.
Action:

r1(config-line)# exit

r1(config)# line vty 0 4

r1(config-line)# password sanjose

r1(config-line)# login

r1(config-line)#

Result:
Although you could change the password to something other than sanjose, you may run into unnecessary problems in later labs that are assuming that your password matches what is listed here.

Explanation:
VTY lines allow an admin to telnet into the router. Actually, it is not necessary to enter the login command on vty lines, since unlike the console port, it is there by default. However, it is included here to remind you that both the login and the password commands must be present in the configuration for the security to work.

Step 11 : Configure the console port on R1 with the logging synchronous command.
Action:

r1(config-line)# logging synchronous

r1(config-line)#

Result:

Explanation:
By default, status messages will appear on your router as they occur. This can be annoying if you are interrupted in the middle of configuring a command. The status message itself doesn?t affect the command you are entering, but you may become confused as to where you left off. The logging synchronous command rectifies this by automatically repainting the line you were entering after the status message appears.

Step 12 : Save your running configuration to NVRAM.
Action:

r1(config-line)# end

r1# copy run start

r1#

Result:
When prompted to use the destination filename [startup-config], press ENTER.

Explanation:
You can use the exit command over and over until you eventually get to the # prompt. However, the end command will take you there directly. When you enter commands, they change the running configuration in RAM. So that these changes will be persistent even after a reload, you need to copy your running configuration to your startup configuration.

Step 13 : On R1, use a show command to verify the currently running configuration found in RAM. In the next step, you will look at the stored configuration in NVRAM. Both should match since you just saved.
Action:

r1# show run

r1#

Result:

Explanation:
After entering the command, you will see --More-- listed at the bottom of the configuration. You can scroll down to the next page of configuration by pressing the space bar. You will notice that the commands you recently configured are present, such as: hostname, enable secret, description, and ip address.

Step 14 : On R1, use a show command to verify that the stored configuration found in NVRAM matches the running configuration you viewed in the previous step.
Action:

r1# show start

r1#

Result:
RAM is volatile, which means that all information stored there is lost when the device is powered off or rebooted. NVRAM is non-volatile RAM and is used to store your configuration.

Explanation:
The configuration commands you previously viewed with the show run command are also now present in the startup configuration. This means that if you were to lose power to your router all of the changes you have made in this lab would still be present.

Step 15 : You have finished Lab 1.
Action:
You can: A) Continue on to the next lab. -or- B) Take this lab again if time permits.

Result:
To take any lab a second time, you first need to reset the devices back to the baseline configurations that were present at the beginning of the lab. This can be done by clicking on the Device Controls link on the left bar, selecting all devices, and clicking the Reload button. Once the devices are all marked green, you can begin the lab. This process takes several minutes.

You can also test your mastery of the material when you take a lab for the second time. Instead of using the Sample Solution link which walks you through each step, you can use the Suggested Approach link. This provides the same steps, but without the walkthrough.

Task 2

IMPLEMENTING A SMALL NETWORK: Switches and Connectivity

Step 1 : Console into Sw1 (Switch1). Erase the configuration on Sw1.
Action:

sw1> enable

sw1# erase start

sw1#

Result:
When prompted to confirm, press ENTER. Anytime you see a device blinking, it is a reminder to console into a new device.

Explanation:
The switch already has a baseline configuration. You are erasing it so that you can configure one from scratch.

Step 2 : Reload Sw1.
Action:

sw1# reload

sw1#

Result:
When you are prompted to confirm, press ENTER. If you are prompted to save modifications, answer no since this would undo the erasure of the configuration.

Step 3 : Configure Sw1 with a hostname.
Action:

Switch> enable

Switch# config t

Switch(config)# hostname sw1

sw1(config)#

Result:
After Sw1 reboots, you may have to press ENTER to get to the configuration dialog prompt. Answer no to the configuration dialog question and press ENTER twice.

Step 4 : Assign the IP address and subnet mask 10.2.1.2 255.255.255.0 to the management VLAN interface of Sw1.
Action:

sw1(config)# interface vlan 10

sw1(config-if)#  ip address 192.168.10.4 255.255.255.0

sw1(config-if)#

Result:

Explanation:
The management VLAN interface is not a physical interface on the switch. It is logical, or in other words, a fake interface. On it, an IP address can be configured which gives admins an address to telnet to so that the switch can be managed remotely. An advantage of using a logical interface is that it never goes down due to connection problems once it is enabled.

Step 5 : Enable the management VLAN interface of Sw1.

sw1(config-if)# no shut

sw1(config-if)#

Result:

Explanation:
By default, interface VLAN 1 is administratively shutdown.

Step 6 : Assign a default gateway to your workgroup switch. Use the address of the core router, 10.2.1.5.
Action:

sw1(config-if)# exit

sw1(config)# ip default-gateway 192.168.10.254

sw1(config)#

Result:

Explanation:
The default gateway is always an address on the same subnet. In this lab, your switch has the IP address 192.168.10.4 and the core router has the IP address 192.168.5.1 Any packets sourced from the switch destined for networks outside the 192.168.10.4 network are sent to the default gateway.

Step 7 : Configure a message-of-the-day banner warning unauthorized users not to log in.
Action:

sw1(config)# banner motd $       (PRESS ENTER)

UNAUTHORIZED ACCESS PROHIBITED.  (PRESS ENTER)

$                                (PRESS ENTER)

sw1(config)#

Result:

Explanation:
A configured banner MOTD appears before a user logs into a Cisco device. In the example here, a $ was used as the delimiter to show where the message starts and stops. The $ will not show up in the message.

Step 8 : Set the speed of port 1 on Sw1 to 100Mb/s.
Action:

sw1(config)# interface f0/1

sw1(config-if)# speed 100

sw1(config-if)#

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface f0/1 command gives you an error, enter interface g0/1 instead.

Explanation:
Port 1 connects to CoreSwC. The speed of the link is currently set to auto configure, however, it is often recommended to hard code speed and duplex on links where network devices connect to other network devices such as routers and switches.

Step 9 : Set the duplex setting of port f0/11 on Sw1 to full duplex.

Action:

sw1(config-if)# duplex full

sw1(config-if)#

Result:

Step 10: Console inte CoreSwc. Set the speed of port 1 on CoreScV to 100Mb/s.

Action:

CoreSwC> enable

CoreSwC# config t

CoreSwC# interface f0/1

CoreSwC(config-if)# speed 100

CoreSwC(config-if)#

Action:

CoreSwC(config-if)# duplex full

CoreSwC(config-if)#

Result:

Step 12 : Console into Sw1. Provide a description for port 1 describing the connected destination.
Action:

sw1(config-if)# interface f0/1

sw1(config-if)# description CONNECTION TO CORESWC

sw1(config-if)#

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface f0/1 command gives you an error, enter interface g0/1 instead.

Step 13 : Provide a description for port 11 describing its connected destination.
Action:

sw1(config-if)# interface f0/11

sw1(config-if)# description CONNECTION TO CORESWA

sw1(config-if)#

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface f0/11 command gives you an error, enter interface g0/11 instead.

Step 14 : On Sw1, configure port security on port 2 to allow only the first MAC address learned from R1 to be able to use the port.
Action:

sw1(config-if)# interface f0/2

sw1(config-if)# switchport mode access

sw1(config-if)# switchport port-security

sw1(config-if)# switchport port-security max 1

sw1(config-if)#

  


					Result: 

					You may find that your switch has upgraded gigabit 
					interfaces. If the interface f0/2 command gives you 
					an error, enter interface g0/2 instead. 


					Explanation: 

					The interface has to first be hard coded as an access port. 
					By default, it is a dynamic port, which technically is an 
					access port that is a trunk port wannabe. In this state, it 
					cannot have port security because of the potential of 
					becoming a trunk if a connecting switch is also set to 
					trunk. The switchport port-security max 1 command 
					tells the switch to only allow one mac address to use this 
					port. The final command, switchport port-security, 
					actually enables the security. On some switches, without 
					this final command, the port never becomes locked down.


					
					
					Step 15 : Provide a description for port 2 on 
					Sw1 describing the connected destination. 

					
					Action:

sw1(config-if)# description CONNECTION TO R1

sw1(config-if)#

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface f0/2 command gives you an error, enter interface g0/2 instead.

Step 16 : Configure the console port of Sw1 with the logging synchronous command.
Action:

sw1(config-if)# exit

sw1(config)# line con 0

sw1(config-line)# logging synchronous

sw1(config-line)#

Result:

Step 17 : Save your running configuration on Sw1 to NVRAM.
Action:

sw1(config-line)# end

sw1# copy run start

sw1#

Result:
When prompted for the destination filename of [startup-config], press ENTER.

Step 18 : On Sw1, verify the duplex and speed of port 1 using a show command.
Action:

sw1# show interface f0/1

SW1#show interface f0/1
FastEthernet0/1 is down, line protocol is down (disabled)
Hardware is Lance, address is 0001.96a5.c801 (bia 0001.96a5.c801)
Description: Connected to Core SW C
BW 100000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:08, output 00:00:05, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
956 packets input, 193351 bytes, 0 no buffer
Received 956 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
2357 packets output, 263570 bytes, 0 underruns
0 output errors, 0 collisions, 10 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

sw1#

Result:
You may find that your switch has upgraded gigabit interfaces. If the show interface f0/1 command gives you an error, enter show interface g0/1 instead.

Explanation:
Look about 8 lines down in the output. You should see Full-duplex, 100Mb/s.

Step 19 : On Sw1, verify the port security settings.
Action:

sw1# show port-security

sw1#

Result:

Explanation:
Here is how you interpret the columns reading left to right: Interface f0/2 only permits a maximum of 1 address to use the port. Currently, it has found that 1 address. There have been no security violations (other mac addresses attempting to use this port), but if a violation occurs, the default behavior is to shut down the port.

Step 20 : On Sw1, verify that the running configuration matches the saved configuration using two show commands.
Action:

sw1# show run

sw1# show start

sw1#

Result:

Explanation:
Since you just saved, the running configuration should match the saved configuration. Look for commands like speed and duplex under port 1 and port security commands under port 2.

Step 21 : Use Cisco Discovery Protocol on Sw1 to identify which Cisco devices are directly connected neighbors.
Action:

sw1# show cdp neighbor

sw1#


SW1#show port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action
(Count) (Count) (Count)
--------------------------------------------------------------------
Fa0/2 1 1 0 Shutdown
----------------------------------------------------------------------

SW1#show cdp neighbor

Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone

Device ID Local Intrfce Holdtme Capability Platform Port ID

CoreSwB Fas 0/12 147 3560 Fas 0/3

CoreSwC Fas 0/1 147 3560 Fas 0/1

CoreSwA Fas 0/11 147 S 2960 Fas 0/11

SW1#

Result:
You should find that R1, CoreSwA, CoreSwB, and CoreSwC are directly connected to this device.

Step 22 : From Sw1, ping the first Ethernet interface (f0/0) of R1: 192.168.10.100
Action:

sw1# 192.168.10.4

sw1#

Result:
Your pings should be successful.

Step 23 : From Sw1, ping the TFTP server: 192.168.5.100
Action:

sw1# ping 192.168.5.100

sw1#

Results:

Your pings should be successful

Step 24: Console into R1. Use the Cisco Discovery Protocol to identify which Cisco devices are directly connected neighbors.

Action:

r1> enable

r1# show cdp neighbor

r1#

Result:
If you are prompted for passwords, cisco is the user mode password and sanfran is the enable mode password. Anytime you see a device blinking, it is a reminder to console into a new device.

Explanation:
You should find that Sw1 is directly connected to this device.

Step 25 : From R1, ping the VLAN 1 interface of Sw1: 192.168.10.4
Action:

r1# ping 192.168.10.4

r1#

Result:
Your pings should be successful.

Step 26 : From R1, ping the TFTP server: 192.168.5.100
Action:

r1# ping 192.168.5.100

r1#

Result:
Your pings should be successful.

Step 27 : You have finished Lab 2.
Action:
You can: A) Continue on to the next lab. -or- B) Take this lab again if time permits.

Result:
To take any lab a second time, you first need to reset the devices back to the baseline configurations that were present at the beginning of the lab. This can be done by clicking on the Device Controls link on the left bar, selecting all devices, and clicking the Reload button. Once the devices are all marked green, you can begin the lab. This process takes several minutes.

You can also test your mastery of the material when you take a lab for the second time. Instead of using the Sample Solution link which walks you through each step, you can use the Suggested Approach link. This provides the same steps, but without the walkthrough.

CONFIGURING EXPANDED SWITCHED NETWORKS: VLANs and VTP

Step 1 : Console into Sw1. Delete the VLAN database.
Action:

sw1> enable

sw1# delete vlan.dat

sw1#

Result:
When prompted to Delete filename [vlan.dat]? press ENTER. When asked to Delete flash:vlan.dat? [confirm] press ENTER. If you see an error stating that there is no such file or directory; it simply means that no VLANs were previously configured.

Explanation:
The VLAN database holds information about existing VLANs. Even if you erase your startup configuration, the VLAN database will still retain information about VLANs you have previously configured. This step ensures that you are starting with nothing but the default VLAN information on the switch.

Step 2 : Reload Sw1.
Action:

sw1# reload

sw1#

Result:
When prompted to [confirm], press ENTER.

Explanation:
Although you deleted the VLAN database in the previous step, there may still be previous VLAN information gathered in RAM and being actively used. This step will flush that information, if it exists.

Step 3 : On Sw1, shut down ports 1 and 12.
Action:

sw1> enable

sw1# config t

sw1(config)# interface f0/1

sw1(config-if)# shut

sw1(config)# interface f0/12

sw1(config-if)# shut

sw1(config-if)#

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface f0/1 and interface f0/12 commands give you an error, enter interface g0/1 and interface g0/12 instead.

Explanation:
Press ENTER after the device finishes reloading from the previous step to view the sw1> prompt. Port 1 connects to CoreSwC. Port 12 connects to CoreSwB.

Step 4 : On Sw1, enable port 11, the interface that connects to CoreSwA.
Action:

sw1(config-if)# interface f0/11

sw1(config-if)# no shut

sw1(config-if)#

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface f0/11 command gives you an error, enter interface g0/11 instead.

Explanation:
In this lab, you will only be using one path, through port 11, to connect to the core. port 11 connects Sw1 to CoreSwA.

Step 5 : On Sw1, set the VTP domain name to ICND.
Action:

sw1(config-if)# exit

sw1(config)# vtp domain ICND

sw1(config)#

Result:

Step 6 : On Sw1, set the VTP mode to transparent.
Action:

sw1(config)# vtp mode transparent

sw1(config)#

Result:

Explanation:
In transparent mode, VLANs created or deleted on other switches will not affect the transparent mode switch. For instance, if you were in charge of the Engineering department and created an Engineering VLAN, your entire group could lose all connectivity if someone from another department were to delete the Engineering VLAN. Changing to transparent mode prevents this.

Step 7 : Verify the VTP configuration using a show command.
Action:

sw1(config)# exit

sw1# show vtp status

sw1#

Result:

Explanation:
You should see that the VTP mode is set to Transparent and that the domain name is ICND.

Step 8 : Set the trunk encapsulation type on port 11 to 802.1Q.
Action:

sw1# config t

sw1(config)# interface f0/01spanning-tree mode pvstspanning-tree mode pvst

sw1(config-if)# switchport trunk encapsulation dot1q

sw1(config-if)#spanning-tree-mode pvst

note: For Packet Tracer: Just use the switchport mode trunk command!

					You may find that your switch has upgraded gigabit 
					interfaces. If the interface f0/11 command gives you 
					an error, enter interface g0/11 instead. 


					Explanation: 

					Many Cisco switches can be configured to use either ISL or 
					802.1Q trunks. However, some switches only have the ability 
					to use one or the other. On any given trunk link, both sides 
					must match.


					
					
					Step 9 : Set port 11 on Sw1 to trunk mode. 

					
					Action:

sw1(config-if)# switchport mode trunk

sw1(config-if)#

Result:

Explanation:
Interfaces on switches can be access ports, meaning they belong to one and only one VLAN, or they can be trunk ports, which carry traffic from multiple VLANs. An example of an access port would be a connection to a PC. An example of a trunk port, as you see here, is a connection from one switch to another switch.

Step 10 : Verify the trunk configuration.
Action:

sw1(config-if)# end

sw1# show interface f0/11 switchport

sw1#

SW1#show interface f0/13 switchport
Name: Fa0/13
Switchport: Enabled
Administrative Mode: dynamic auto
Operational Mode: down
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk private VLANs: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Appliance trust: none

NOTE: show interface f0/13 switchport

sult:
You may find that your switch has upgraded gigabit interfaces. If the show interface f0/11 switchport command gives you an error, enter interface g0/11 switchport instead.

Explanation:
About 4 lines down, you should see that the Operational mode is trunk. Below that line, you should also see that the encapsulation is set to dot1q (IEEE 802.1Q).

Step 11 : To verify trunk connectivity, ping the core router at 10.2.1.5 from Sw1.
Action:

sw1# ping 110.5.1.5

sw1#

Result:
Your pings should be successful.

Step 12 : Configure 1192.168.10.254 to be the default gateway on Sw1.
Action:

sw1# config t

sw1#(config) interface vlan 51

sw1#(config) ip address 192.168.10.4 255.255.255.0

sw1(config)# ip default-gate 192.168.10.254

sw1(config)#

Result:
192.168.10.254 is the core router.

Step 13 : On Sw1, create VLAN 51
Action:

sw1(config)# vlan 51

sw1(config-vlan)#

Explanation:

Interfaces cannot be configured as members of a VLAN until after the VLAN itself is created, which is what you are doing in this step.


 .
Step 14 : Using the show vlan command from the EXEC mode, verify that the correct VLAN has been added.

Action:

sw1(config-vlan)# end

sw1# show vlan

sw1#

Result:

Explanation:
Notice that to the right of VLAN 1, you see all of the ports listed as members except for Fa0/11, which is missing. The reason port 11 is not included is because you configured it as a trunk. Also notice that to the right of VLAN 21, you see no ports listed. This is because you haven?t yet assigned any ports to VLAN 21.

Step 15 : On Sw1, assign port 2, which is connected to R1, to VLAN 21.
Action:

sw1# config t

sw1(config)# interface f0/2

sw1(config-if)# switchport access vlan 21

sw1(config-if)#

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface f0/2 command gives you an error, enter interface g0/2 instead.

Explanation:
The interface is, by default, an access port in VLAN 1. This command changes the access port to instead belong to VLAN 21.

Step 16 : On Sw1, configure portfast on port 2.
Action:

sw1(config-if)# spanning-tree portfast

sw1(config-if)#

Result:
You will see a warning stating that portfast should only be enabled on ports connected to a single host and will only work if the port is not trunking. In this step, you are fine since the connection is to R1 and is not a trunk.

Explanation:
Normally, an interface on a switch must transition from blocking into forwarding (30-50 seconds) when it first connects. This is the preferred behavior when the port connects to another switch because there is a chance that it will create a bridging loop and cause problems. However, when connecting to a PC or a router, this waiting for convergence is unnecessary. Portfast, esentially disables Spanning Tree for a particular port.

Step 17 : Enter the proper show command for verifying that port 2 is now in the correct VLAN.
Action: * **********

sw1(config-if)# end

sw1#  show vlan brief

sw1#

Result:
Looking to the right of VLAN 21, you will see that port 2 is now a member. The rest of the interfaces are still in VLAN 1.

Step 18 : Console to R1. Change the address and subnet mask on f0/0 to 10.2.50.1 255.255.255.0.
Action:

r1> enable

r1# config t

r1(config)# interface f0/0

r1(config-if)# ip address 1192.168.10.100 255.255.255.0.

r1(config-if)#

Result:
If you are prompted for passwords, cisco is the user mode password and sanfran is the enable mode password. Anytime you see a device blinking, it is a reminder to console into a new device.

Explanation:
A VLAN is a subnet. If you have different VLANs, they must be on different subnets. Before you placed the Sw1 interface connecting to R1 in VLAN 51, it was in VLAN 1, on the 10.2.1.0 subnet. Now, it is in VLAN 51 so the IP address had to be changed. VLAN 1 is the 10.2.1.0 subnet and VLAN 51 is the 10.2.50.0 subnet.

Step 19 : From R1, ping the core router's 10.5.50.5 address.
Action:

r1(config-if)# end

r1# ping 10.5.50.5

r1#

Result:
Your pings should be successful.

Explanation:
One of the interfaces on the core router is in the same VLAN as R1. R1 should be able to ping it because they are in the same subnet, 10.2.50.0. However, if you were to attempt to ping Sw1, 10.2.1.2, it would fail. The reason is that they are now in different subnets and inter-VLAN routing has not yet been configured.

Step 20 : On R1, enable inter-VLAN communications by configuring a default route that points to the core router?s 10.5.50.5 address.
Action:

r1# config t

r1(config)# ip route 0.0.0.0 0.0.0.0 10.5.50.5

r1(config)#

Result:

Explanation:
The default route instructs R1 to send packets to 10.2.50.5 if all else fails. In other words, if a packet is destined for a route not explicitly found in the routing table, send it to the core router. The core router has interfaces in both VLAN 1 (10.2.1.5) and VLAN 21 (10.2.50.5). Therefore, it knows how to get to both subnets. Sw1 has a default gateway pointing to the core router as well, which acts just like the default route you just configured. At this point, the core router can now route packets between the two VLANs.

Step 21 : From R1, verify that inter-VLAN routing is taking place by pinging Sw1: 192.168.10.4
Action:

ve doubts hot go about it

basically sw1 is in different subnet than r1

in o

we will destroy connectivity between r1 and core router

are you prepared for that?

r1(config)# end

r1# ping 10.2.1.2

r1#

NOTE: Not able to ping???

Explanation from research:

SW1 is in a different subnet that R1. In order to establish connection between

them we should use sub interfaces and inter vlan routing. In order to ensure

connectivity in the other segments we need to insure that inter vlan connecectivity

will not destroy connectivity between R1 and the Core Router.

'm th

Result:
Your pings should be successful.

Step 22 : You have finished Lab 3.
Action:
You can: A) Continue on to the next lab. -or- B) Take this lab again if time permits.

Result:
To take any lab a second time, you first need to reset the devices back to the baseline configurations that were present at the beginning of the lab. This can be done by clicking on the Device Controls link on the left bar, selecting all devices, and clicking the Reload button. Once the devices are all marked green, you can begin the lab. This process takes several minutes.

You can also test your mastery of the material when you take a lab for the second time. Instead of using the Sample Solution link which walks you through each step, you can use the Suggested Approach link. This provides the same steps, but without the walkthrough.

Task 4

CONFIGURING EXPANDED SWITCHED NETWORKS: RSTP and Troubleshooting

Step 1 : Console into Sw1. Shut down ports 1, 11, and 12.
Action:

sw1> enable

sw1# config t

sw1(config)# interface f0/1

sw1(config-if)# shut

sw1(config)# interface f0/11

sw1(config-if)# shut

sw1(config)# interface f0/12

sw1(config-if)# shut

sw1(config-if)#

Result:
You may find that your switch has upgraded gigabit interfaces. If the commands interface f0/1, interface f0/11, and interface f0/12 give you an error, enter interface g0/1, interface g0/11, and interface g0/12 instead.

Explanation:
In this lab you will enable RSTP and view its behavior. To simplify your understanding, three switches will be the focus: Sw1, CoreSwB, and CoreSwC. These three switches form a physical loop. The connection to CoreSwA will be shut down for the remainder of the lab.

Step 2 : On Sw1, configure port 12 with the trunk encapsulation of 802.1Q, change the mode to trunking, and enable the interface.
Action:

sw1(config-if)# interface f0/12 (makes sure you on the right port) do a show vlan brief

sw1(config-if)# switchport trunk encap dot1 N/A - valid on real equipment

sw1(config-if)# switchport mode trunk

sw1(config-if)# no shut

sw1(config-if)#  end

sw1# show interface trunk

Will show you that the interfce is now dot1q

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface f0/12 command gives you an error, enter interface g0/12 instead.

Explanation:
Port 12 connects to CoreSwB.

Step 3 : Configure Sw1?s port 1 with the trunk encapsulation of 802.1Q, change the mode to trunking, and enable the interface.
Action:

sw1(config-if)# interface f0/1

sw1(config-if)# switchport trunk encap dot1q

sw1(config-if)# switchport mode trunk

sw1(config-if)# no shut

sw1(config-if)#

sw1(config-if)# exit

sw1(config)# spanning-tree mode rapid-pvst

sw1(config)#

Result:

Step 5 : On Sw1, enter the command to determine the spanning-tree states for ports in VLAN 1.
Action:

sw1(config)# end

sw1# show spanning-tree vlan 1

sw1#

Result:

Explanation:

If you look at the diagram, you will see that the Sw1 interfaces to focus on are port 1 and port 12. There is a physical loop connecting Sw1 to CoreSwB to CoreSwC and then back to Sw1. Notice at the bottom of your show command output, that port 1 (the connection to CoreSwC) shows the status of blocking and port 12 (the connection to CoreSwB) shows forwarding.

Step 6 : From Sw1, telnet to CoreSwB, 10.2.1.7. Enter the command to determine the spanning-tree states for ports in VLAN 1.
Action:

sw1# telnet 1192.168.10.2.

Username: cisco

Password: cisco

CoreSwB# show spanning-tree vlan 1

CoreSwB#

Result:
You do not have direct console access to CoreSwB, so you must use telnet. When prompted for a username, use cisco and use cisco again for the password. The prompt should then indicate that you are on CoreSwB.

Explanation:
About five lines down, you should see the words: This bridge is the root. It has been manually configured with a priority of 0. Since the lowest priority wins, this has become the root bridge for VLAN 1. All of the ports should be forwarding.

Step 7 : Exit out of CoreSwB so that you are back on Sw1.
Action:

CoreSwB# exit

sw1#

Result:

Explanation:
You will know that you are back on Sw1 by the command prompt.

Step 8 : Console to CoreSwC. Enter the command to determine the spanning-tree states for interfaces in VLAN 1.
Action:

CoreSwC> enable

CoreSwC# show spanning-tree vlan 1

CoreSwC#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Explanation:

If you look at the diagram, you will see that the CoreSwC interfaces to focus on are port 1 and port 12. In the output you should see both port 1 (connecting to Sw1) and port 12 (connecting to CoreSwB) forwarding.

Step 9 : Based on your findings in the last few steps, examine the diagram and determine which path VLAN 1 traffic would take from Sw1 to reach the core router.
Action:

There is nothing to configure in this step.

Result:
Sw1 is sending VLAN 1 traffic through port 12 to CoreSwB to reach the core router. The path out port 1 to CoreSwC is blocked.

Explanation:

You discovered that CoreSwB is the root bridge for VLAN 1. Sw1 forwards VLAN 1 traffic out port 12 to CoreSwB, which then sends it on to the core router. You also discovered in the previous steps using the show spanning-tree command that port 1 on Sw1 is blocking.

Step 10 : Console to Sw1. Configure the VTP domain ICND, change the VTP mode to transparent, and create VLAN 21.
Action:

sw1# config t

sw1(config)# vtp domain ICND

sw1(config)# vtp mode transparent

sw1(config)# vlan 21

sw1(config-vlan)#

Note: no VTP per gns3.!!

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 11 : Configure port 2 as a member of VLAN 21 on Sw1.
Action:

sw1(config-vlan)# exit

sw1(config)# interface f0/2

sw1(config-if)# switchport access vlan 21

sw1(config-if)#

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface f0/2 command gives you an error, enter interface g0/2 instead.

Explanation:
Port 2 connects to R1.

Step 12 : Configure portfast on port 2 of Sw1.
Action:

sw1(config-if)# spanning-tree portfast

sw1(config-if)#

Result:
You will see a warning message stating that portfast only works when the interface is non-trunking. In this step, port 2 is an access port, so you are fine.

Step 13 : Console to CoreSwC, configure VLAN 21 traffic to use CoreSwC as its root bridge.
Action:

CoreSwC# config t

CoreSwC(config)# spanning-tree vlan 21 root primary

CoreSwC(config)#

Result:
The default priority for a bridge ID is 32768. Entering the command in this step will change the priority to 24576. It is also possible to configure another switch as a backup for the root bridge in case it fails using the spanning-tree vlan 21 root secondary command, which would change its priority to 28672.

Explanation:
By configuring CoreSwC as the root bridge for VLAN 21, all VLAN 21 traffic will instead take the path from Sw1 through CoreSwC to reach the core network. VLAN 1 traffic will still use the path through CoreSwB. This effectively utilizes both links.

Step 14 : Console back into Sw1. Using two show commands, prove that VLAN 1 traffic is taking one path to reach the core router, while VLAN 21 traffic takes the other path.
Action:

sw1(config-if)# end

sw1# show spanning-tree vlan 1

sw1# show spanning-tree vlan 21

sw1#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Explanation:

Focus on the output for port 1 and port 12 when entering both commands. You now have VLAN 1 traffic blocked on port 1 and forwarded out port 12, while VLAN 21 is forwarded on port 1 and blocked on port 12.

Step 15 : Console into R1. Configure the address, 10.2.50.1 255.255.255.0 on interface f0/0.
Action:

r1> enable

r1# config t

r1(config)# interface f0/0

r1(config-if)# ip address 192.168.10.100 255.255.255.0

r1(config-if)#

r1(config-if)# end

r1# ping 192.168.10.254

r1#

Result:
Your pings should be successful.

Step 17 : Create a stream of 30,000 pings from R1 to the core router, 10.2.50.5.
Action:

r1# ping  (PRESS ENTER)

Protocol [ip]:   (PRESS ENTER)

Target IP address: 10.2.50.5

Repeat count [5]: 30000

Datagram size [100]:      (PRESS ENTER)

Timeout in seconds [2]:   (PRESS ENTER)

Extended commands [n]:    (PRESS ENTER)

Sweep range of sizes [n]: (PRESS ENTER)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Result:
When you are using the Java window to access R1 (the window is black), you should see View: single | tabbed in the top right corner. Make sure that tabbed is selected before going to the next step.

Explanation:
Because the traffic from R1 is in VLAN 21, you are sending a stream of packets to Sw1 which then takes the path to CoreSwC. In the next step, you will make that path fail and observe how long it takes spanning tree to reconverge and send the packets instead to CoreSwB. Do not wait for the pings to finish. Proceed to the next step.

Step 18 : Console into Sw1. Shutdown port 1 and then check R1 again.
Action:

sw1# config t

sw1(config-if)# interface f0/1

sw1(config-if)# shut

sw1(config-if)#

Result:
If you are using the Java window and have selected tab view, click on the Sw1 tab for this step.

Explanation:
Port 1 connects Sw1 to CoreSwC. This is the path VLAN ${USER_POD_ID]1 uses to reach the core.

Step 19 : Back on R1, observe that the exclamation marks change to dots. Wait until the exclamation marks start again.
Action:

There is nothing to configure in this step.

Result:
If you didn?t see any dots, if it appeared that the exclamation points never missed a beat, it is because you configured rapid spanning tree. Convergence is extremely fast, often within a second.

Explanation:
Initially, the packets (which are in VLAN 21) were traveling from Sw1 to CoreSwC. You shut down that connection. This caused spanning tree to change the status on interface f0/12 from being blocked for VLAN 21 to forwarding. This process is known as convergence. Once this was complete, you should have seen the dots change back to exclamation marks.

Step 20 : Return to Sw1 and re-enable port 1.
Action:

sw1(config-if)# interface f0/1

sw1(config-if)# no shut

sw1(config-if)#

NOTE: sw1(config-if)# interface f1/1

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface f0/1 command gives you an error, enter interface g0/1 instead.

Explanation:
Spanning tree will detect the change and will converge again.

Step 21 : On R1, configure a default route pointing to the core router, 10.2.50.5, as the next hop.
Action:

r1# config t

r1(config)# ip route 0.0.0.0 0.0.0.0 10.2.50.5

r1(config)#

NOTE: ip route 0.0.0.0 0.0.0.0 10.2.4.5

Result:

Explanation:
This allows devices in VLAN 21 (like R1) to be able to communicate with devices in VLAN 1 (like the TFTP server).

Step 22 : From R1, ping the TFTP server, 10.2.1.100.
Action:

r1(config)# end

r1# ping 10.2.1.100

r1#

NOTE:r1# ping 10.2.4.100

Result:
Your pings should be successful. Now R1 has connectivity to the TFTP server.

Explanation:
If the pings do not go through at first, try shutting down the f0/0 interface with the shut command, waiting until it goes down, and then re-enabling it with the no shut command.

Step 23 : Console into Sw1. Ping the TFTP server, 10.2.1.100.
Action:

sw1(config-if)# end

sw1# ping 10.2.1.100

sw1#

NOTE: sw1# ping 10.2.4.100

Result:
Your pings should be successful. The TFTP server is on the same VLAN as Sw1.

Step 24 : Copy the file lab4-sw1 from the TFTP server into your running configuration on Sw1. Once the copy has completed, type in the exit command on the switch.
Action:

sw1# copy tftp run

Address or name of remote host []?  10.2.1.100

Source filename []? lab4-sw1

Destination filename [running-config]?    (PRESS ENTER)

sw1# exit    (PRESS ENTER TWICE)

Result:
After typing exit and hitting ENTER twice, if you were successful, you should see a new banner message appear.

Explanation:
When you copy a configuration into your running configuration, the two are merged together. Error messages should begin to repeat. This is supposed to happen and will be fixed in the upcoming steps.

Step 25 : Console into R1. Attempt to ping 10.2.1.100 again and you will see that it fails due to changes to the configuration you pulled into Sw1 from the TFTP server.
Action:

r1# ping 10.2.1.100

r1#

(NOTE: THIS STEP IS SUPPOSED TO FAIL)

Result:
The ping is supposed to fail. You are simply verifying that you have lost connectivity.

Step 26 : Console into Sw1. Without using the show run command, troubleshoot Sw1 to discover what has changed using other show commands you have learned. Port 11 was shutdown previously in the lab and should remain so.
Action:

NOTE: If the repeating status messages are making it hard for you to concentrate, you can temporarily stop
the notifications by entering the no logging console command in global configuration mode.

To check to see if any interface has port security violations, use the show port-security command.

To check to see if ports 2, 1, or 12 have been shut down, use the show interface f0/X command.
(Enter a number in place of the X.)

To check to see if the speed and duplex of ports 2, 1, or 12 have been changed to anything other than
100MB/s and full, again use the show interface f0/X command.

To check to see if ports 1 and 12 are trunking, use the show interface f0/X switchport command.

To check to see if port 2 is configured as a member of VLAN 21, use the show vlan command.

Result:
You may find that your switch has upgraded gigabit interfaces. If the show interface commands give you an error, enter show interface g0/X instead.

Step 27 : Based on what you learned in the last step, make configuration changes on Sw1, to restore connectivity. If you are successful, R1 should be able to ping the TFTP server, 10.2.1.100.
Action:

Attempt to make the configuration changes on your own to restore connectivity. Spend no more that five minutes troubleshooting. If you are still stuck after five minutes and cannot ping the TFTP server from R1, go to the next step, which will walk you through the solution.

Result:

Step 28 : Sw1 troubleshooting solution.
Action:

SHOW PORT-SECURITY
You should have received repeating status messages about a port security violation. Using the show port-security command, you should have discovered that port 2 is in violation.

An incorrect MAC address in the port security settings has been configured. Disable port security on port 2 to allow traffic to once again flow through the port.

sw1# config t

sw1(config-if)# interface f0/2

sw1(config-if)# no switchport port-security

sw1(config-if)# end

sw1#

SHOW INTERFACE F0/X
Using the show interface f0/X command for each interface, you should have discovered that ports 2, 1, and 12 have not been shut down (which is good). You can find this information in the very first line of output. The speed is 100Mb/s and duplex is full on all three interfaces (which is also good). To find this information, look at the 8th line of output.

SHOW INTERFACE F0/X SWITCHPORT
Using show interface f0/X switchport command for ports 1 and 12 to see if both are trunking, you should have discovered that they are now access ports (which is bad). You will find this information in the 4th line of output.

Change both to 802.1Q trunks.

sw1# config t

sw1(config)# interface f0/1

sw1(config-if)# switchport trunk encap dot1q

sw1(config-if)# switchport mode trunk

sw1(config-if)# interface f0/12

sw1(config-if)# switchport trunk encap dot1q

sw1(config-if)# switchport mode trunk

sw1(config-if)# end

sw1#

SHOW VLAN
Port 2 should belong to VLAN 21. You should have discovered that not only does it not belong to VLAN 21 (which is bad), but that VLAN 21 no longer exists (even worse).

Recreate VLAN 21 and then assign port 2 to VLAN 21.

sw1# config t

sw1(config)# vlan 21

sw1(config-vlan)# exit

sw1(config)# interface f0/2

sw1(config-if)# switchport access vlan 21

sw1(config-if)#

Result:
You may find that your switch has upgraded gigabit interfaces. If the interface commands give you an error, enter interface g0/X instead.

Step 29 : Console to R1. Ping the TFTP server: 10.2.1.100 to see if you have restored connectivity.
Action:

r1# ping 10.2.1.100

r1#

Result:
Your pings should now be successful.

Step 30 : Copy the file lab4-r1 from the TFTP server into your running configuration on R1. Once the copy has completed, type in the exit command on the router.
Action:

r1# copy tftp run

Address or name of remote host []?  10.2.1.100

Source filename []? lab4-r1

Destination filename [running-config]?    (PRESS ENTER)

r1# exit    (PRESS ENTER TWICE)

Result:
If you were successful, you should see a new banner message appear after exiting the router.

Step 31 : You have finished Lab 4.
Action:
You can: A) Continue on to the next lab. -or- B) Take this lab again if time permits.

Result:
To take any lab a second time, you first need to reset the devices back to the baseline configurations that were present at the beginning of the lab. This can be done by clicking on the Device Controls link on the left bar, selecting all devices, and clicking the Reload button. Once the devices are all marked green, you can begin the lab. This process takes several minutes.

You can also test your mastery of the material when you take a lab for the second time. Instead of using the Sample Solution link which walks you through each step, you can use the Suggested Approach link. This provides the same steps, but without the walkthrough.

Task 5

IMPLEMENTING AND TROUBLESHOOTING OSPF

Step 1 : Console into R2. Enable interfaces s1/0 and s1/2.
Action:

r2> enable

r2# config t

r2(config)# interface s1/0

r2(config-if)# no shut

r2(config-if)# interface s1/2

r2(config-if)# no shut

r2(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 2 : Console into R1. Enable interfaces s1/1 and s1/2.
Action:

r1> enable

r1# config t

r1(config)# interface s1/1

r1(config-if)# no shut

r1(config-if)# interface s1/2

r1(config-if)# no shut

r1(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 3 : On R1, verify that the IP address configured on interface s1/2 is: 172.41.2.1
Action:

r1(config-if)# end

r1# show ip interface brief

r1#

Result:

Explanation:
In addition to verifying the IP address, you can also see that the status of the interface is up/up. This indicates that both layer 1 and layer 2 are operational.

Step 4 : From R1, ping the core router: 172.41.2.5
Action:

r1# ping 172.41.2.5

r1#

NOTE: match all duplex and speed for serial interfaces and input IP addresses as described in pings.

Result:

Your pings should be successful. If not wait 60 seconds and then try again.
Step 5: View the IP routing table on R1. Verify that you can see three directly connected routes.

Action:

r1# show ip route

r1#

Result:
You should see that 172.41.2.0, 10.2.0.0, and 10.2.1.0 are directly connected. At first glance, it may look like five routes, but there are three. Each route is directly connected and this is indicated with the letter C to the left of the route.

Explanation:
At the end of each line, the exiting interface for that route is shown. Because a routing protocol has not yet been enabled to allow the router to ?talk? with other routers, it only knows of its directly connected routes.

Step 6 : Verify whether DCE or DTE cables are connected to interfaces s1/1 and s1/2.
Action:

r1# show controllers s1/1

r1# show controllers s1/2

r1#

Result:
On some routers, the show controllers command doesn?t work unless you put a space between the s and the numbers like this: show controllers s 1/1. On the routers in this lab, either variation will work. You should find that both interfaces are the DTE side of the cable.

Explanation:
There is a lot of output, but focus on third line down. At the very end of the line it reads: V.35 DTE cable. Normally, you would connect your router to a service provider. One of the services they provide is clock rate. Without clock rate, synchronous serial connections do not work. When you connect two routers directly together with a serial cable, there?s no service provider to provide clock rate, so one of the routers must take this role. The side with the DCE end of the cable has to have an additional clock rate command.

Step 7 : Console into R2. Verify whether DCE or DTE cables are connected to interfaces s1/0 and s1/2.
Action:

r2(config-if)# end

r2# show controllers s1/0

r2# show controllers s1/2

r2#

Result:
You should find that a DCE cable is connected to interface s1/0. A DTE cable is connected to interface s1/2.

Explanation:
Again, focus on the third line of output. Since interface s1/0 (the connection to R1) is DCE, the clock rate command is required.

Step 8 : On R2, configure a clock rate of 128000 on interface s1/0.
Action:

r2# config t

r2(config)# interface s1/0

r2(config-if)# clock rate 128000

r2(config-if)#

Result:

Explanation:
Clock rate is analogous to the tempo of a song. No tempo means no song. However, interfaces will only support certain clock rates. For instance, if you entered 127000, you would get an error. For a listing of the supported clock rates, you can enter the command: clock rate ?

Step 9 : Configure a bandwidth of 128 on R2?s interface s1/0.
Action:

r2(config-if)# bandwidth 128

r2(config-if)#

Result:
The bandwidth value is the primary characteristic OSPF uses to determine the cost of a link to determine the shortest paths.

Explanation:
In the previous step, you configured a clock rate of 128000. This number is in bits per second. The value for the bandwidth command is in kilobits per second. To make the bandwidth value aligned with the clock rate, you therefore have to configure 128.

Step 10 : Configure a bandwidth of 64 on R2?s interface s1/2 to match the bandwidth configured on the core router.
Action:

r2(config-if)# interface s1/2

r2(config-if)# bandwidth 64

r2(config-if)#

Result:

Explanation:
Bandwidth values should match on both sides of a link. Otherwise, traffic that goes out one path may return on a completely different path.

Step 11 : On R2, test connectivity of the serial link to R1 by pinging: 10.2.0.1
Action:

r2(config-if)# end

r2# ping 10.2.0.1

r2#

Result:
Your pings should be successful.

Step 12 : Create a loopback 0 interface on R2 with the address: 2.2.2.2 255.255.255.255
Action:

r2# config t

r2(config)# interface loopback 0

r2(config-if)# ip address 2.2.2.2 255.255.255.255

r2(config-if)#

Result:
The subnet mask shown is not a typo. It indicates that this network only has one host on it, itself.

Explanation:
If only one loopback address exists, the address will become the OSPF RID (Router ID) when we configure OSPF. The stability of the RID is important because the entire OSPF database hinges on being able to uniquely identify each OSPF router. If this were to change, your database on every OSPF router would need to be reconstructed. If you didn?t create a loopback, the highest numbered IP address (172.41.2.2) would become the RID. If this interface were to ever go down, a new RID would be needed. Loopbacks are instead chosen because they never go down.

Step 13 : On R2, verify the IP addresses for all interfaces.
Action:

r2(config-if)# end

r2# show ip interface brief

r2#

Result:
Make note of the three IP addresses you see. You will use them in an upcoming step to configure OSPF.

Step 14 : Enable the OSPF routing protocol on R2. Use the OSPF process ID of 1.
Action:

r2# config t

r2(config)# router ospf 1

r2(config-router)#

Result:

Explanation:
The purpose of the OSPF process ID is to give an admin the ability to create two or more entirely separate instances of OSPF on the same router. This might be a valid solution, for instance, if you had two companies merge.

Step 15 : On R2, configure all of the interfaces to be in Area 0. Use three network statements with a wildcard mask of 0.0.0.0 for each.
Action:

r2(config-router)# network 10.2.0.2 0.0.0.0 area 0

r2(config-router)# network 172.41.2.2 0.0.0.0 area 0

r2(config-router)# network 2.2.2.2 0.0.0.0 area 0

r2(config-router)#

Result:

Explanation:
The network statement identifies which interfaces should be enabled with OSPF and which area they belong to. The 0.0.0.0 is a wildcard mask that indicates ?this exact address.?

Step 16 : Console into R1. Create a loopback 0 interface with the address: 2.2.2.1 255.255.255.255
Action:

r1# config t

r1(config)# interface loopback 0

r1(config-if)# ip address 2.2.2.1 255.255.255.255

r1(config-if)#

Result:

Explanation:
Once OSPF is enabled, this will become the RID.

Step 17 : On R1, configure interface s1/1 with a bandwidth of 128 to match what is configured on the opposite end of the link.
Action:

r1(config-if)# interface s1/1

r1(config-if)# bandwidth 128

r1(config-if)#

Result:
Interface s1/1 connects to R2, which you already configured with a bandwidth of 128.

Explanation:
Bandwidth values should match on both sides of a link. Otherwise, traffic that goes out one path may return on a completely different path.

Step 18 : On R1, configure interface s1/2 with a bandwidth of 64 to match what is configured on the core router.
Action:

r1(config-if)# interface s1/2

r1(config-if)# bandwidth 64

r1(config-if)#

Result:

Step 19 : On R1, verify the IP addresses for all interfaces.
Action:

r1(config-if)# end

r1# show ip interface brief

r1#

Result:

Explanation:
Make note of the four IP addresses you see. You will use them in an upcoming step to configure OSPF.

Step 20 : Enable the OSPF routing protocol on R1. Use the OSPF process ID of 1.
Action:

r1# config t

r1(config)# router ospf 1

r1(config-router)#

Result:

Step 21 : On R1, configure all of the interfaces to be in Area 0. Use four network statements with a wildcard mask of 0.0.0.0 for each.
Action:

r1(config-router)# network 10.2.1.1 0.0.0.0 area 0

r1(config-router)# network 10.2.0.1 0.0.0.0 area 0

r1(config-router)# network 172.41.2.1 0.0.0.0 area 0

r1(config-router)# network 2.2.2.1 0.0.0.0 area 0

r1(config-router)#

Result:

Step 22 : On R1, assign a password on interfaces s1/1 and s1/2 to be used to authenticate neighboring OSPF routers and then enable authentication. Use sanfran as the password.
Action:

r1(config-router)# exit

r1(config)# interface s1/1

r1(config-if)# ip ospf authentication-key sanfran

r1(config-if)# ip ospf authentication

r1(config)# interface s1/2

r1(config-if)# ip ospf authentication-key sanfran

r1(config-if)# ip ospf authentication

r1(config-if)#

Result:

Explanation:
Since there are two similar commands, ip ospf authentication-key and ip ospf authentication, you cannot abbreviate the word authentication in this command.

Step 23 : Console into R2. Assign a password on interfaces s1/0 and s1/2 to be used to authenticate neighboring OSPF routers and then enable authentication. Use sanfran as the password.
Action:

r2(config-router)# exit

r2(config)# interface s1/0

r2(config-if)# ip ospf authentication-key sanfran

r2(config-if)# ip ospf authentication

r2(config)# interface s1/2

r2(config-if)# ip ospf authentication-key sanfran

r2(config-if)# ip ospf authentication

r2(config-if)#

Result:

Note: authentication commands may not work in Packet Tracer. GNS3 will be the alternative .

Step 24 : On R2, view the routing table to verify which routes have been learned by OSPF.
Action:

r2(config-if)# end

r2# show ip route

r2#

Result:
Look for the routes that are marked with the letter O in the left column. These indicate routes learned by OSPF.

Step 25 : On R2, use a single show command that verifies: OSPF is enabled, the process ID, the Router ID, and the interfaces that are exchanging OSPF routing information.
Action:

r2# show ip protocol

r2#

Result:

Explanation:
The first line should indicate that OSPF is enabled and is configured with the process ID of 1. The fourth line of output should indicate that the RID is 2.2.2.2. Seven lines down, you should see Routing for Networks. This indicates what interfaces are participating in OSPF and what areas they belong to.

Step 26 : On R2, use a debug command to display OSPF hello messages exchanged with the other routers.
Action:

r2# debug ip ospf events

r2#

Result:
View the debug output for about a minute.

Explanation:
You should see hellos from 2.2.2.1 (R1) and 200.200.200.5 (core router). When you receive hellos, you should see the RID of that router. You should also see hellos sent to 172.41.2.5 (core router) and to the multicast address 224.0.0.5. This multicast address is a way of addressing the packet to all OSPF routers on a network segment.

Step 27 : Turn debugging off on R2.
Action:

r2# undebug all

r2#

Result:

Step 28 : On R2, use a show command to verify the directly connected OSPF neighbors and their status.
Action:

r2# show ip ospf neighbor

r2#


Result: 
You should find two OSPF neighbors. One is the core router, which has the RID 200.200.200.5. The other is R1 which has the RID 2.2.2.1. Both should show a FULL state indicating that they have converged. 

Explanation: 
The connection between R2 and R1 is point-to-point, meaning no other devices can possibly be between the two. Because of this, a Designated Router does not need to be elected. The connection between R2 and the core router goes through a Frame Relay cloud, using the non-broadcast OSPF network type. There could potentially be several destinations on the other side of the cloud. Because of this, a Designated Router is chosen. You should see that the core router is the DR.

Step 29 : There is a TFTP server in the core network with the address: 100.100.100.100. From R2, ping the TFTP server. 
Action:

r2# ping 100.100.100.100

r2#

Result:
Your pings should be successful.

Explanation:
None of your devices have interfaces in the same subnet as the TFTP server. It is a remote subnet. Your devices have learned of this subnet through OSPF.

Step 30 : Copy the file lab5-r2 from the TFTP server into your running configuration on R2. Once the copy has completed, type in the exit command on the router.
Action:

r2# copy tftp run

Address or name of remote host []?  100.100.100.100

Source filename []? lab5-r2

Destination filename [running-config]?    (PRESS ENTER)

r2# exit    (PRESS ENTER TWICE)

Result:
After typing exit and hitting ENTER twice, if you were successful, you should see a new banner message appear.

Explanation:
When you copy a configuration into your running configuration, the two are merged together.

Step 31 : On R2, ping the TFTP server, 100.100.100.100 again and you will find that you have lost connectivity.
Action:

r2> enable

r2# ping 100.100.100.100

r2#

(NOTE: THIS STEP IS SUPPOSED TO FAIL)

Result:
The ping is supposed to fail. You are simply verifying that you have lost connectivity.

Step 32 : Without using the show run command, troubleshoot R2 to discover what has changed using other show commands you have learned.
Action:

To check to see if interface s1/0 or s1/2 has been shut down, use the show ip interface brief command.

Using the same command, you can also see if the IP addresses have changed. Interface s1/0 was previously 10.2.0.2 and interface s1/2 was 172.41.2.2

To check to see if OSPF is enabled, use the show ip protocol command.

Use the same command to verify that your interfaces are participating in OSPF and are in area 0.

To check to see if the authentication password has been changed, use the debug ip ospf events command.

Result:

Step 33 : Based on what you learned in the last step, make configuration changes on R2, to restore connectivity. If you are successful, R2 should be able to ping the TFTP server, 100.100.100.100.
Action:

Attempt to make the configuration changes on your own to restore connectivity. Spend no more that five minutes troubleshooting. If you are still stuck after five minutes and cannot ping the TFTP server from R2, go to the next step, which will walk you through the solution.

Result:

Step 34 : R2 troubleshooting solution.
Action:

SHOW IP INTERFACE BRIEF
You should have discovered that everything is fine here. Both interfaces show the status of up/up and the IP addresses have not changed.

SHOW IP PROTOCOL
You should find that OSPF has been configured, however, if you look closely, you?ll find it isn?t running on any of your interfaces. This can be found under the Routing For Networks section. You have 10.2.0.2 configured on interface s1/0, but you are routing for 10.0.0.0 0.0.0.255 area 0. The way to read the wildcard of 0.0.0.255 is: ?exactly match on the first three octets, but the last octet can be anything.? That means it is looking to run OSPF on any interface with an IP that starts with 10.0.0. Your IP starts with 10. 2.0, so you don?t have a match. You can fix this either with: network 10.0.0.0 0.255.255.255 area 0, or use the wildcard mask to match on every octet like this: network 10.2.0.2 0.0.0.0 area 0. Either will work.

Change the network statement to include 10.2.0.2.

r2# config t

r2(config)# router ospf 1

r2(config-router)# no network 10.0.0.0 0.0.0.255 area 0

r2(config-router)# network 10.2.0.2 0.0.0.0 area 0

r2(config-router)#

You also see that it is currently routing for 192.168.0.0. This is pointless, because you don?t have any interfaces that even start with 192. You do have interface s1/2 with the address 172.41.2.2 and you have a loopback with 2.2.2.2.

Change the network statement to include 172.41.2.2 and 2.2.2.2.

r2# config t

r2(config)# router ospf 1

r2(config-router)# no network 192.168.0.0 0.0.255.255 area 0

r2(config-router)# network 172.41.2.2 0.0.0.0 area 0

r2(config-router)# network 2.2.2.2 0.0.0.0 area 0

r2(config-router)#

DEBUG IP OSPF EVENTS
Once you have fixed the problem with the network statements, if you enable the debug for OSPF events, you will soon see the messages: Serial1/0 : Mismatch Authentication and Serial1/2 : Mismatch Authentication in the output. This indicates that the password does not match on the remote end of s1/0 (R1) or on the remote end of s1/2 (core router). The passwords set on both of these routers is sanfran.

Change the OSPF authentication password to sanfran on interface s1/0 and on interface s1/2.

r2# config t

r2(config)# interface s1/0

r2(config-if)# ip ospf authentication-key sanfran

r2(config)# interface s1/2

r2(config-if)# ip ospf authentication-key sanfran

r2(config-if)# end

r2# undebug all

Result:

Step 35 : Verify that you have restored connectivity on R2. Ping the TFTP server: 100.100.100.100
Action:

r2# ping 100.100.100.100

r2#

Result:
Your pings should now be successful.

Step 36 : You have finished Lab 5.
Action:
You can: A) Continue on to the next lab. -or- B) Take this lab again if time permits.

Result:
To take any lab a second time, you first need to reset the devices back to the baseline configurations that were present at the beginning of the lab. This can be done by clicking on the Device Controls link on the left bar, selecting all devices, and clicking the Reload button. Once the devices are all marked green, you can begin the lab. This process takes several minutes.

You can also test your mastery of the material when you take a lab for the second time. Instead of using the Sample Solution link which walks you through each step, you can use the Suggested Approach link. This provides the same steps, but without the walkthrough.

Task 6

IMPLEMENTING AND TROUBLESHOOTING EIGRP

Step 1 : Console into R2. Enable interfaces s1/0 and s1/2.
Action:

r2> enable

r2# config t

r2(config)# interface s1/0

r2(config-if)# no shut

r2(config-if)# interface s1/2

r2(config-if)# no shut

r2(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 2 : Console into R1. Enable interfaces s1/1 and s1/2.
Action:

r1> enable

r1# config t

r1(config)# interface s1/1

r1(config-if)# no shut

r1(config-if)# interface s1/2

r1(config-if)# no shut

r1(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 3 : Using a single show command on R1, verify that interfaces f0/0, s1/1, and s1/2 have the status up/up and make note of the IP addresses.
Action:

r1(config-if)# end

r1# show ip interface brief

r1#

Result:

Explanation:
You will need to know the IP addresses for an upcoming step. You should see: 10.2.1.1, 10.2.0.1, and 172.41.2.1

Step 4 : On R1, enable the EIGRP routing process. Use an EIGRP autonomous system number of 100.
Action:

r1# config t

r1(config)# router eigrp 100

r1(config-router)#

Result:

Explanation:
An autonomous system number is completely different from the process ID that OSPF uses. Process IDs do not have to match, they only have significance to the router they are configured on. Autonomous system numbers must be the same for all EIGRP routers, otherwise, the routers will not exchange routing information.

Step 5 : Configure EIGRP to advertise R1?s directly connected networks using only two network statements.
Action:

r1(config-router)# network 10.0.0.0

r1(config-router)# network 172.41.0.0

r1(config-router)#

Result:
The Class A range is from 1-126.
The Class B range is from 128-191.
The Class C range is from 192-223.

Explanation:
When you advertise networks in EIGRP, you can simply use the default class address without a mask. For instance, 172.41.2.1 is a Class B address, meaning that the first two octets are the network portion. You only need to enter network 172.41.0.0 for it to advertise any interface that starts with 172.41. This makes it much easier to advertise your other two interfaces: 10.2.1.1 and 10.2.0.1. Since they start with 10, they are Class A addresses, meaning that only the first octet is the network portion. You can advertise both in one statement: network 10.0.0.0

Step 6 : Console into R2. With a single show command, verify that interfaces s1/0 and s1/2 have the status up/up and make note of the IP addresses.
Action:

r2(config-if)# end

r2# show ip interface brief

r2#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Explanation:
You will need to know the IP addresses for an upcoming step. You should see: 10.2.0.2 and 172.41.2.2

Step 7 : On R2, enable the EIGRP routing process. Use an EIGRP autonomous system number of 100.
Action:

r2# config t

r2(config)# router eigrp 100

r2(config-router)#

Result:

Step 8 : Configure EIGRP to advertise R2?s directly connected networks.
Action:

r2(config-router)# network 10.0.0.0

r2(config-router)# network 172.41.0.0

r2(config-router)#

Result:
The Class A range is from 1-126.
The Class B range is from 128-191.
The Class C range is from 192-223.

Step 9 : You will configure EIGRP MD5 authentication so that R2 and R1 will only exchange EIGRP routing information if both sides have matching security settings. Begin on R2 by creating a key chain named: icndchain
Action:

r2(config-router)# exit

r2(config)# key chain icndchain

r2(config-keychain)#

NOTE: Key command doesn?t work in gns3.

Result:

Explanation:
You can conceptually picture the key chain as a ring of keys attached to the belt of a security guard. At this point, the guard has the key ring, but no keys. In the next step you will add one of the keys to that ring.

Step 10 : On R2, under the key chain you just created, create key 1 with the key-string: sanfran
Action:

r2(config-keychain)# key 1

r2(config-keychain-key)# key-string sanfran

r2(config-keychain-key)#

Result:

Explanation:
Again, trying to conceptually understand what you are configuring, the guard has a key with the number 1 etched on the side. Since every key is cut differently to make it unique, you are doing the same by assigning a unique password.

Step 11 : On interface s1/0 of R2, specify MD5 as the authentication mode for EIGRP 100.
Action:

r2(config-keychain-key)# interface s1/0

r2(config-if)# ip authentication mode eigrp 100 md5

r2(config-if)#

Result:
Interface s1/0 connects to R1.

Explanation:
The authentication mode is analogous to the type of lock you want to use. At this point, you have almost all of the security components: A key ring (labeled icndchain), a numbered key to go on the ring (key 1), a unique cut of the key (password sanfran), and the type of lock (MD5). The only thing missing, is to enable security so that all of the components will be put to use. You will do this in the next step.

Step 12 : On R2, specify the key-chain you created that contains the key to be used to authenticate EIGRP 100 packets on interface s1/0.
Action:

r2(config-if)# interface s1/0

r2(config-if)# ip authentication key-chain eigrp 100 icndchain

r2(config-if)#

Result:

Explanation:
This step ties together all of the security components you have individually configured and enables authentication on the interface.

Step 13 : Console into R1. Create a key chain named: icndchain
Action:

r1(config-router)# exit

r1(config)# key chain icndchain

r1(config-keychain)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 14 : On R1, under the key chain you just created, create key 1 with the key-string: sanfran
Action:

r1(config-keychain)# key 1

r1(config-keychain-key)# key-string sanfran

r1(config-keychain-key)#

Result:

Step 15 : On R1, specify MD5 as the authentication mode for EIGRP 100 on interface s1/1.
Action:

r1(config-keychain-key)# interface s1/1

r1(config-if)# ip authentication mode eigrp 100 md5

r1(config-if)#

Result:
Interface s1/1 connects to R2.

Step 16 : On R1, specify the key-chain you created that contains the key to be used to authenticate EIGRP 100 packets on interface s1/1.
Action:

r1(config-if)# interface s1/1

r1(config-if)# ip authentication key-chain eigrp 100 icndchain

r1(config-if)#

Result:

Step 17 : Console into R2. Verify that EIGRP 100 is running and that it is routing for networks: 10.0.0.0 and 172.41.0.0
Action:

r2(config-if)# end

r2# show ip protocol

r2#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Explanation:
In addition to verifying the autonomous system and routed networks, the show ip protocol command also indicates Administrative Distance at the end of the output. With AD, the lower, the better. Therefore, if you had OSPF (AD of 110) and EIGRP (AD of 90) running and both discovered different routes to the same destination network, only the EIGRP route would be placed in the routing table.

Step 18 : Verify that R2 is learning routes through EIGRP.
Action:

r2# show ip route

r2#

Result:
Routes marked with the letter D in the left column indicate that they were learned via EIGRP.

Explanation:
Look specifically for an EIGRP route to 10.2.1.0/24 exiting interface s1/0. You will only see this route if you configured EIGRP authentication correctly. This subnet connects R1 to Sw1.

Step 19 : Verify that R2 has two EIGRP neighbors.
Action:

r2# show ip eigrp neighbors

r2#

Result:
10.2.0.1 is R1. 171.41.2.5 is the core router.

Explanation:
If you have configured the network statements and authentication properly, you should see two EIGRP neighbors: R1 and the core router.

Step 20 : Enable a debug command to display EIGRP neighbor events on R2.
Action:

r2# debug eigrp neighbors

r2#

Result:

Explanation:
After enabling it, nothing happens. This is because the EIGRP neighbor relationships have already formed.

Step 21 : To cause EIGRP neighbors to re-establish adjacencies, shut down interface s1/0 on R2. Wait until you see a status message, and then re-enable the interface.
Action:

r2# config t

r2(config)# interface s1/0

r2(config-if)# shut        (WAIT ABOUT 5 SECONDS AFTER ENTERING)

r2(config-if)# no shut

r2(config-if)#

Result:

Explanation:
A status message should appear informing you of a new EIGRP 100 peer (10.2.0.1) and that a new adjacency has been established.

Step 22 : Using a different debug command on R2, verify the EIGRP routing updates as they are exchanged. To trigger the output, shut down interface s1/2 and then re-enable it.
Action:

r2(config-if)# end

r2# debug ip eigrp

r2# config t

r2(config)# interface s1/2

r2(config-if)# shut        (WAIT ABOUT 5 SECONDS AFTER ENTERING)

r2(config-if)# no shut

r2(config-if)#

(AFTER ENTERING THE NO SHUT COMMAND, WAIT ABOUT 90 SECONDS FOR NEW OUTPUT TO APPEAR)
Result:

Explanation:
The message you are waiting for in the output is Neighbor 171.41.2.5 (Serial1/2) is up: new adjacency. It will take about 90 seconds for this to appear after you enter the no shut command. You will then see even more output. Take note that some lines read ?don?t advertise out? and others say ?do advertise out.?

Step 23 : From R2, ping the TFTP server with the address: 100.100.100.100
Action:

r2(config-if)# end

r2# ping 100.100.100.100

r2#

Result:
Your pings should be successful.

Explanation:
The 100.0.0.0 network is not a directly connected network. It is a directly attached network on the core router and you are learning the route through EIGRP.

Step 24 : On R2, ping another address whose network is advertised by the core router: 10.2.50.5. You will find that your ping fails.
Action:

r2# ping 10.2.50.5

r2#

(NOTE: THIS STEP IS SUPPOSED TO FAIL)

Result:
The ping is supposed to fail. You are simply verifying that you do not have connectivity to this network.

Step 25 : Without using the show run command, troubleshoot R2 to discover why you cannot ping: 10.2.50.5
Action:

To check to see if there is a route to 10.2.50.0, use the show ip route command.

To see exactly what is being advertised and what is being received by EIGRP, use the debug ip eigrp command. Trigger a new adjacency by shutting down interface s1/2 and then re-enabling it. Make note of the lines that read ?don?t advertise? and ?do advertise? for routes that whose first octet is 10. The output may take up to 90 seconds to appear.

Result:

Step 26 : Based on what you learned in the last step, make configuration changes on R2, to restore connectivity. If you are successful, R2 should be able to ping: 10.2.50.5
Action:

Attempt to make the configuration changes on your own to restore connectivity. Spend no more that five minutes troubleshooting. If you are still stuck after five minutes and cannot ping 10.2.50.5 from R2, go to the next step, which will walk you through the solution.

Result:

Step 27 : R2 troubleshooting solution.
Action:

SHOW IP ROUTE
At first glance, it appears that you don?t have a route to the 10.2.50.0 network, but actually you do. You should see a route to 10.0.0.0/8. Since the mask is /8 (255.0.0.0) it means that any route that matches the first octet, 10, is a match. However, look where it is sending the packets: to Null 0. This is a logical interface, which acts like a trash can. So, although you have a route, it?s not pointing back to the core router like you want it to. Investigate the problem further with the debug ip eigrp command before making any changes.

DEBUG IP EIGRP
After entering this command, be sure to shut down interface s1/2 and then re-enable it so that you can see output. The output may take up to 90 seconds to appear. You should see:

10.2.1.0/24 ? don?t advertise out Serial1/2

10.2.0.0/24 ? don?t advertise out Serial1/2

10.0.0.0/8 ? do advertise out Serial1/2

Here?s the problem. The core router is advertising 10.0.0.0/8 to reach 10.2.50.5. So, you do have a valid route to it. But you are advertising the same 10.0.0.0/8 network back to the core router, as shown by 10.0.0.0/8 ? do advertise out Serial1/2. EIGRP, by default, automatically summarizes networks to their classful addresses. How does it do this? It creates a ?trash can? route to Null 0 using the classful network (10.0.0.0) which it advertises to the other EIGRP routers and then it keeps quiet about the actual subnets (10.2.1.0 and 10.2.0.0) as indicated with ?don?t advertise out.? The reason it does this is to reduce the size of routing tables further down the line, but in some cases, (like this one) it causes reachability problems. To fix this, you simply need to configure EIGRP to stop automatically summarizing at the classful boundary. When you do, it will advertise the actual routes with their actual masks and it will no longer advertise the ?trash can? route. Turn off EIGRP auto-summarization on R2.

r2(config-if)# exit

r2(config)# router eigrp 100

r2(config-router)# no auto-summary

r2(config-router)#

It will take about a minute for all of the changes to take place, but eventually, when you enter the show ip route command, you will no longer see any summary routes destined for Null 0. Also, the advertised route from the core router to 10.0.0.0/8 will be in the routing table, exiting interface s1/2.

Result:

Step 28 : From R2, ping: 10.2.50.5
Action:

r2(config-router)#end

r2# ping 10.2.50.5

r2#

Result:
Your pings should now be successful.

Explanation:
If your pings aren?t successful right away, wait about 60 seconds and try again. If you are seeing the message: Neighbor(172.41.2.5) not yet found this is normal. Within 60 seconds, you should see Neighbor 172.41.2.5 (Serial1/2) is up: new adjacency which means that it has found the core router. At this point the two routers exchange routing information and converge.

Step 29 : Turn off all debug commands.
Action:

r2# undebug all

r2#

Result:

Step 30 : You have finished Lab 6.
Action:
You can: A) Continue on to the next lab. -or- B) Take this lab again if time permits.

Result:
To take any lab a second time, you first need to reset the devices back to the baseline configurations that were present at the beginning of the lab. This can be done by clicking on the Device Controls link on the left bar, selecting all devices, and clicking the Reload button. Once the devices are all marked green, you can begin the lab. This process takes several minutes.

You can also test your mastery of the material when you take a lab for the second time. Instead of using the Sample Solution link which walks you through each step, you can use the Suggested Approach link. This provides the same steps, but without the walkthrough.

Task 7

IMPLEMENTING AND TROUBLESHOOTING ACLs

Step 1 : Console into R2. Enable interfaces s1/0 and s1/2.
Action:

r2> enable

r2# config t

r2(config)# interface s1/0

r2(config-if)# no shut

r2(config-if)# interface s1/2

r2(config-if)# no shut

r2(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 2 : Console into R1. Enable interfaces s1/1 and s1/2.
Action:

r1> enable

r1# config t

r1(config)# interface s1/1

r1(config-if)# no shut

r1(config-if)# interface s1/2

r1(config-if)# no shut

r1(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 3 : On R1, configure interface f0/0 with the address: 10.2.4.1 255.255.255.0
Action:

r1(config-if)# interface f0/0

r1(config-if)# ip address 10.2.4.1 255.255.255.0

r1(config-if)#

Result:

Step 4 : Configure EIGRP 100 on R1. Advertise networks 10.0.0.0, 172.41.0.0, and turn off auto-summarization.
Action:

r1(config-if)# exit

r1(config)# router eigrp 100

r1(config-router)# network 10.0.0.0

r1(config-router)# network 172.41.0.0

r1(config-router)# no auto-summary

r1(config-router)#

Result:

Explanation:
This step will provide routes to subnets in the core network, such as 100.100.100.0.

Step 5 : Console into R2. Configure a password on VTY lines 0 through 4. Use the password: sanjose
Action:

r2(config-if)# exit

r2(config)# line vty 0 4

r2(config-line)# password sanjose

r2(config-line)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 6 : Use a show command to verify the status of R2?s interfaces and the IP addresses configured on them.
Action:

r2(config-line) end

r2# show ip interface brief

r2#

Result:

Explanation:
You should see two IP addresses: 10.2.0.2 and 172.41.2.2 The status of both interfaces should be up/up.

Step 7 : Create a numbered IP extended access list statement that denies Telnet traffic to R2?s address: 10.2.0.2
Action:

r2# config t

r2(config)# access-list 100 deny tcp any 10.2.0.2 0.0.0.0 eq 23

r2(config)#

Result:
A standard ACL would not be sufficient since more than source addresses are involved. The number 100 was chosen because the ranges 100-199 and 2000-2699 indicate that it is an IP extended access list. Any number within these ranges would have been fine.

Explanation:
Immediately following the access list number in the syntax is the keyword deny. Next in the statement is an ?umbrella? protocol. The rest of the list will focus on the protocol listed. It can either be generically referring to all of IP or it can be a specific flavor of IP, like UDP, TCP, ICMP, etc. TCP was chosen here because Telnet is TCP-based. If you look at the very end of the statement, you see the TCP port that is being denied equals 23. Port 23 is Telnet. Immediately following TCP is source and destination. The source is any. The destination is 10.2.0.2 0.0.0.0. Wildcard masks use zero to mean ?exact match.? Therefore the destination is exactly one IP address: 10.2.0.2

Taken altogether, you read it like this: Access-list 100 (an extended IP access list) deny TCP port 23 (telnet) from any IP address that is attempting to reach 10.2.0.2.

Step 8 : Configure a second statement in the same access list to also deny Telnet traffic to R2?s address: 172.41.2.2
Action:

r2(config)# access-list 100 deny tcp any 172.41.2.2 0.0.0.0 eq 23

r2(config)#

Result:

Explanation:
A single access list can be made up of multiple statements. The statements are executed from top to bottom and once a match is found the packet is permitted or denied and the rest of the list is ignored.

Step 9 : On R2, configure a third statement in the same access list that allows everything else.
Action:

r2(config)# access-list 100 permit ip any any

r2(config)#

Result:
Every access list must contain at least one permit statement. There is an implicit ?deny everything else? at the end of every access list. Without at least one permit statement, everything would be denied.

Explanation:
The ?umbrella? protocol that covers the rest of the list in this case is IP. Since only TCP and UDP use port numbers, none are needed here. Similar to the syntax of the first two statements, immediately following the protocol is the source and destination. You would read the line like this: Access-list 100 (an extended IP access list) permit IP (all of IP, nothing protocol specific) coming from any IP address, going to any IP address.

Step 10 : On R2, apply the access list inbound on interfaces s1/0 and s1/2.
Action:

r2(config)# interface s1/0

r2(config-if)# ip access-group 100 in

r2(config-if)# interface s1/2

r2(config-if)# ip access-group 100 in

r2(config-if)#

Result:
If you created an access-list without grouping it to an interface it would simply be ignored. Likewise, if you grouped a non-existent access-list to an interface, it would also be ignored. As you see here, a single access list can be applied to multiple interfaces.

Explanation:
To easily understand inbound vs. outbound, picture yourself being inside the router. An inbound list would permit or deny packets trying to enter the router. An outbound list would allow the packets in, but would permit or deny them before they exited the router.

Step 11 : Verify the contents of the access list on R2 using a show command other than show run.
Action:

r2(config-if)# end

r2# show access-lists

r2#

Result:
The show access-lists command displays all access lists configured on the router. If you had a mix of IP and IPX access lists, you could use the show ip access-lists command to view only the IP based lists.

Explanation:
Notice that there are some slight modifications to what you typed in. For example, in the first line, the destination is no longer 10.2.0.2 0.0.0.0. Instead, since this specifies a single host, it was changed to host 10.2.0.2. Also, eq 23 has been replaced with eq telnet. These same modifications are now also found in your running configuration.

Step 12 : Verify that the access list has been applied to interfaces s1/0 and s1/2 on R2 using a show command other than show run.
Action:

r2# show ip interface s1/0

r2# show ip interface s1/2

r2#

Result:
Be sure to use the keyword ip in the command or you will not see any output related to access list.

Explanation:
About 9 lines down in the output, you should see: Inbound access list is 100.

Step 13 : Console into R1. Test your access list by first attempting to ping R2?s 10.2.0.2 address.
Action:

r1(config-router)# end

r1# ping 10.2.0.2

r1#

Result:
Your pings should be successful.

Explanation:
Remember that the access list denied Telnet, but allowed everything else. Therefore, your pings should still work with the new access list.

Step 14 : On R1, perform a second test of your access list by attempting to Telnet to the same address that you pinged: 10.2.0.2
Action:

r1# telnet 10.2.0.2

r1#

(TELNET IS SUPPOSED TO FAIL)

Result:
You should see: % Destination unreachable; gateway or host down

Explanation:
Your access list on R2 is working correctly. Telnet is denied, but other types of traffic, such as pings, are still allowed.

Step 15 : Console into Sw1. On the VLAN 1 interface, configure the address: 10.2.4.2 255.255.255.0
Action:

sw1> enable

sw1# config t

sw1(config)# interface vlan 1

sw1(config-if)# ip address 10.2.4.2 255.255.255.0

sw1(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 16 : Configure 10.2.4.1 as the IP default gateway on Sw1.
Action:

sw1(config-if)# exit

sw1(config)# ip default-gateway 10.2.4.1

sw1(config)#

Result:
10.2.4.1 is R1.

Step 17 : From Sw1, ping the TFTP server with the address: 100.100.100.100
Action:

sw1(config)# end

sw1# ping 100.100.100.100

sw1#

Result:
Your pings should be successful.

Step 18 : Console back into R1. Copy the file lab7-r1 from the TFTP server into your running configuration on R1. Once the copy has completed, type in the exit command on the router.
Action:

r1# copy tftp run

Address or name of remote host []?  100.100.100.100

Source filename []? lab7-r1

Destination filename [running-config]?    (PRESS ENTER)

r1# exit    (PRESS ENTER TWICE)

Result:
After typing exit and hitting ENTER twice, if you were successful, you should see a new banner message appear.

Explanation:
Be sure to do this step on R1, not Sw1.

Step 19 : The configuration you downloaded contains a new access list. Without using the show run command, use other show commands you have learned to discover the contents of that list and where it is applied.
Action:

To see the contents of all access lists configured on the router, use the show access-lists command.

To see where the access list has been applied, check all of your active interfaces with the commands: show ip interface s1/1, show ip interface s1/2, and show ip interface f0/0

Result:
UDP port 69 is TFTP.

Step 20 : Console into Sw1. Ping the TFTP server: 100.100.100.100
Action:

sw1# ping 100.100.100.100

sw1#

(THE PINGS ARE SUPPOSED TO FAIL.)

Result:
U.U.U indicates that the pings were blocked by an access list.

Explanation:
The pings failed, but why? The downloaded access list on R1 was supposed to only deny UDP port 69 (TFTP traffic). The admin that created the access list meant for R1 to still be able to pass other traffic, like pings, from the pod devices like Sw1 to the core network. Continue to the next step.

Step 21 : Based on what you learned in the last few steps, make configuration changes so that R1 continues to deny TFTP requests passing through the router to the core network, while everything else is allowed. The access list should be applied outbound.
Action:

Try to make the configuration changes on your own to restore the ability to ping while still denying TFTP. When you think that your access list is working properly, see if you can successfully ping the TFTP server from Sw1. You can also attempt to copy the file lab7-sw1 from the TFTP server into your running configuration on Sw1 to test port 69. If your access list is working properly, the TFTP copy should be unsuccessful. Spend no more that five minutes troubleshooting. If you are still stuck after five minutes, go to the next step, which will walk you through the solution.

Result:
Be aware that any new statements added to the existing access list will be placed at the bottom of the list. To recreate the list from scratch, enter the no access-list 175 command and then re-enter the access-list.

Step 22 : R1 troubleshooting solution.
Action:

SHOW ACCESS-LIST
The key to understanding the problem is knowing how to read the access list.

deny udp any any eq tftp

This says, ?deny any source going to any destination the ability to TFTP.?

permit udp any any

This says, ?allow any source going to any destination access to all other UDP ports.? Taken together, it looks as though the only thing denied is TFTP. However, there is an implicit (hidden) deny all at the end of every access list, including this one. So this list allows all other UDP ports, but then denies everything else that isn?t UDP. Everything else would include pings, FTP, e-mail, web traffic, and so on. To fix the access list, it simply needs one more statement at the end, to permit everything else.

r1(config)# access-list 175 permit ip any any

SHOW IP INTERFACE
When using this command specifically for s1/1, s1/2, and f0/0, you should have been looking 8-9 lines down in the output of each to see where the access list was applied. You would have found this on interface s1/2 applied outbound. Since the challenge was to create an access list so that only TFTP requests passing through R1 to reach the core network would be denied, applying it to s1/2 outbound was already correct.

Result:

Step 23 : Verify that you can now ping the TFTP server from Sw1.
Action:

sw1# ping 100.100.100.100

sw1#

Result:
Your pings should now be successful.

Step 24 : Attempt to copy the file lab7-sw1 from the TFTP server into your running configuration on Sw1. If your access list is working properly, the copy should be unsuccessful.
Action:

sw1# copy tftp run

Address or name of remote host []?  100.100.100.100

Source filename []? lab7-sw1

Destination filename [running-config]?    (PRESS ENTER)

sw1# exit    (PRESS ENTER TWICE)

(THE COPY IS SUPPOSED TO FAIL)

Result:
The switch will attempt to access the TFTP for about 45 seconds before finally giving up.

Explanation:
After the copy attempt is made, type in exit and press the ENTER key twice. If you are successful, you will NOT see a banner message. Instead, you simply see the switch prompt: sw1>

Step 25 : You have finished Lab 7.
Action:
You can: A) Continue on to the next lab. -or- B) Take this lab again if time permits.

Result:
To take any lab a second time, you first need to reset the devices back to the baseline configurations that were present at the beginning of the lab. This can be done by clicking on the Device Controls link on the left bar, selecting all devices, and clicking the Reload button. Once the devices are all marked green, you can begin the lab. This process takes several minutes.

You can also test your mastery of the material when you take a lab for the second time. Instead of using the Sample Solution link which walks you through each step, you can use the Suggested Approach link. This provides the same steps, but without the walkthrough.

Task 8

CONFIGURING NAT AND PAT

Step 1 : Console into R2. Enable interface s1/0.
Action:

r2> enable

r2# config t

r2(config)# interface s1/0

r2(config-if)# no shut

r2(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 2 : Console into R1. Enable interfaces s1/1 and s1/2.
Action:

r1> enable

r1# config t

r1(config)# interface s1/1

r1(config-if)# no shut

r1(config-if)# interface s1/2

r1(config-if)# no shut

r1(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 3 : On R1, configure interface f0/0 with the address: 10.2.4.1 255.255.255.0
Action:

r1(config-if)# interface f0/0

r1(config-if)# ip address 10.2.4.1 255.255.255.0

r1(config-if)#

Result:

Step 4 : Configure EIGRP 100 on R1. Advertise networks 10.0.0.0, 172.41.0.0, and turn off auto-summarization.
Action:

r1(config-if)# exit

r1(config)# router eigrp 100

r1(config-router)# network 10.0.0.0

r1(config-router)# network 172.41.0.0

r1(config-router)# no auto-summary

r1(config-router)#

Result:

Step 5 : Console into Sw1. On the VLAN 1 interface, configure the address: 10.2.4.2 255.255.255.0
Action:

sw1> enable

sw1# config t

sw1(config)# interface vlan 1

sw1(config-if)# ip address 10.2.4.2 255.255.255.0

sw1(config-if)#

Result:

Step 6 : On Sw1, configure an IP default gateway of 10.2.4.1
Action:

sw1(config-if)# exit

sw1(config)# ip default-gateway 10.2.4.1

sw1(config)#

Result:
10.2.4.1 is R1.

Step 7 : From Sw1, ping the TFTP server: 100.100.100.100
Action:

sw1(config)# end

sw1# ping 100.100.100.100

sw1#

Result:
Your pings should be successful.

Step 8 : Console into R1. Configure interface f0/0 as a NAT inside interface.
Action:

r1(config-router)# exit

r1(config)# interface f0/0

r1(config-if)# ip nat inside

r1(config-if)#

Result:
The address on interface f0/0 is: 10.2.4.1 In this lab, you will configure NAT to translate any address that begins with the number 10.

Explanation:
An inside interface is typically where addresses that can potentially be translated can enter the router. Often these will be private addresses used by a company or home. The outside interface is typically where you?ll find the globally routable addresses. As an example, you might have a home network with two PCs. Each has an address on the 10.0.0.0 network. Your ISP has given you one real address, say 200.50.10.17. Users on the Internet never see the addresses on your PCs. These addresses are both translated into 200.50.10.17. The ?conversations? from each PC are kept separate by the translating router marking each with different port numbers. Generically, any translation is NAT, but this variation where ports are used is specifically referred to as PAT (Port Address Translation).

Step 9 : On R1, configure interface s1/1 as a NAT inside interface.
Action:

r1(config-if)# interface s1/1

r1(config-if)# ip nat inside

r1(config-if)#

Result:
The address on interface s1/1 is: 10.2.0.1

Explanation:
Since an address to be translated could also enter the router from this interface, it is an inside interface.

Step 10 : On R1, configure interface s1/2 as a NAT outside interface.
Action:

r1(config-if)# interface s1/2

r1(config-if)# ip nat outside

r1(config-if)#

Result:
The address on interface s1/2 is: 172.41.2.0.1

Explanation:
The address on this interface is the one that all of your inside addresses will be translated into.

Step 11 : Configure a standard access list on R1 that specifies that any address beginning with the first octet of 10 should be translated.
Action:

r1(config-if)# exit

r1(config)# access-list 1 permit 10.0.0.0 0.255.255.255

r1(config)#

Result:
Every address that is permitted in the access list will be translated. Since there is an implicit deny at the end, this means that only addresses starting with 10 will be translated.

Explanation:
Since this access list is only used to identify addresses to be translated, it is not applied to an interface.

Step 12 : Configure PAT on R1 so that the inside source addresses specified in your access list are translated into the address found on interface s1/2.
Action:

r1(config)# ip nat inside source list 1 interface s1/2 overload

r1(config)#

Result:

Explanation:
The key to understanding this translation statement is knowing how to read it. It says, ?ip nat (I want to translate) inside source (generically speaking, the source addresses on the inside of my network) list 1 (specifically, the ones permitted in access list 1) interface s1/2 (into the address found on s1/2) overload (using PAT).?

Step 13 : Console into Sw1. Ping the TFTP server: 100.100.100.100
Action:

sw1# ping 100.100.100.100

sw1#

Result:
Your pings should be successful.

Explanation:
The packets sourced from the switch (10.2.4.2) have been translated on R1 and sent to 100.100.100.100. From 100.100.100.100?s perspective, it believes that the packets were instead sourced from 172.41.2.1

Step 14 : Console into R1. Use a show command to view the NAT translation table.
Action:

r1(config)# end

r1# show ip nat translations

r1#

Result:

Explanation:
Under the Inside Local column, you will see the original address, 10.2.4.2 (Sw1) that sourced the packets. You will also see under the Inside Global column, what address this was translated into: 172.41.2.1 Beside each IP address in these two columns you will also see a port number. No matter how many addresses from your inside network get translated, the Inside Global address will be the same, 172.41.2.1. However, what will be different for each is the port number. To the rest of the world, it looks like all of your inside traffic is coming from a single host: 172.41.2.1

Step 15 : Enable a debug that will show NAT translation as it occurs on R1.
Action:

r1# debug ip nat

r1#

Result:

Explanation:
You will be able to trigger output for this command after completing the next step.

Step 16 : From R1, issue an extended ping to 100.100.100.100, but source it from 10.2.4.1
Action:

r1# ping  (PRESS ENTER)

Protocol [ip]:   (PRESS ENTER)

Target IP address: 100.100.100.100

Repeat count [5]:        (PRESS ENTER)

Datagram size [100]:      (PRESS ENTER)

Timeout in seconds [2]:   (PRESS ENTER)

Extended commands [n]: y

Source address or interface: 10.2.4.1

Type of service [0]:              (PRESS ENTER)

Set DF bit in IP header? [no]:    (PRESS ENTER)

Validate reply data? [no]:        (PRESS ENTER)

Data pattern [0xABCD]:            (PRESS ENTER)

Loose, Strict, Verbose[none]:     (PRESS ENTER)

Sweep range of sizes [n]:         (PRESS ENTER)

Result:
If you were to do a regular ping to 100.100.100.100, the source would be the address of outgoing interface, 172.41.2.1. This would not trigger NAT because you specified that only packets whose first octet begins with 10 would be translated. To see a translation without leaving the router, you can instead use an extended ping to force it to use a source address from a different interface.

Explanation:
The output shows the letter s indicating the source address. After that you see the original address (10.2.4.1) and then an arrow (->) showing what it was translated into (172.41.2.1). Next you see the letter d indicating the destination address (100.100.100.100).

Step 17 : On R1, use a show command to view the general statistics of your NAT translations.
Action:

r1# show ip nat statistics

r1#

Result:

Explanation:
This command, among other things, identifies the inside and outside interfaces as well as the hits and misses. A miss occurs if NAT has identified an address that should be translated, but it is not yet in the table. When you first attempted to ping 100.100.100.100 from a 10 address, it recorded it as a miss. After the translation was entered into the table, the other packets to 100.100.100.100 were recorded as hits.

Step 18 : On R1, clear the NAT translation table.
Action:

r1# clear ip nat translation *

r1#

Result:

Explanation:
This command comes in handy when troubleshooting. If you make a change to your NAT configuration, the old translations may still be resident in your table and the router doesn?t behave the way you think it should. By clearing the table, new translations will be created using the updated configuration.

Step 19 : Check the NAT translation table again to see if it has been cleared.
Action:

r1# show ip nat translations

r1#

Result:

Explanation:
The table should now be completely empty.

Step 20 : You have finished Lab 8.
Action:
You can: A) Continue on to the next lab. -or- B) Take this lab again if time permits.

Result:
To take any lab a second time, you first need to reset the devices back to the baseline configurations that were present at the beginning of the lab. This can be done by clicking on the Device Controls link on the left bar, selecting all devices, and clicking the Reload button. Once the devices are all marked green, you can begin the lab. This process takes several minutes.

You can also test your mastery of the material when you take a lab for the second time. Instead of using the Sample Solution link which walks you through each step, you can use the Suggested Approach link. This provides the same steps, but without the walkthrough.

Task 9

IMPLEMENTING IPv6: Addressing, Routing, and Dual Stacking

Step 1 : Console into R2. Enable interface s1/0.
Action:

r2> enable

r2# config t

r2(config)# interface s1/0

r2(config-if)# no shut

r2(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 2 : Console into R1. Enable interface s1/1.
Action:

r1> enable

r1# config t

r1(config)# interface s1/1

r1(config-if)# no shut

r1(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 3 : On R1, enter the global command that enables IPv6 traffic forwarding.
Action:

r1(config-if)# exit

r1(config)# ipv6 unicast-routing

r1(config)#

Result:

Explanation:
Don?t be confused that the command has the word routing in it. Pretend that the command was ipv6 unicast-forwarding and it makes more sense. By default, IPv6 traffic forwarding is disabled on Cisco routers. Without this command, IPv6 will not work.

Step 4 : On interface s1/1 of R1, assign the IPv6 address 2001:0410:0002:99::/64 eui-64
Action:

r1(config)# interface s1/1

r1(config-if)# ipv6 address 2001:0410:0002:99::/64 eui-64

r1(config-if)#

Result:
The eui-64 parameter forces the router to use the MAC address of the first LAN interface to automatically create the host portion of the address.

Explanation:
The :99 indicates the subnet portion of your IPv6 address. To understand this better, look at an IPv4 example. With IPv4, you might refer to 150.10.99.0/24 as simply the 99 subnet, with 150.10 being the network portion. Or you could refer to the subnet as being 150.10.99. Both are correct references. Likewise, with IPv6, the address you entered in this step can be referred to as the 99 subnet, or can be referenced in its entirety: the 2001:0410:0002:99 subnet.

Step 5 : Create a loopback 0 interface on R1 and assign it the IPv6 address 2001:0410:0002:1::/64 eui-64
Action:

r1(config-if)# interface loopback 0

r1(config-if)# ipv6 address 2001:0410:0002:1::/64 eui-64

r1(config-if)#

Result:
With :1 as the subnet portion, it places the loopback of R1 on subnet :1

Step 6 : Use a show command to verify the IPv6 address information configured on all of the R1 interfaces.
Action:

r1(config-if)# end

r1# show ipv6 interface

r1#

Result:

Explanation:
On the 5th and 6th lines of output, you should see Global unicast address(es): indicating the entire address, followed by just the subnet portion. The additional fields of numbers found in the entire address were automatically assigned based on the MAC address of interface f0/0. This is the host portion of the address. If you scroll down through the output using the space bar, you will see that both interface s1/1 and your loopback interface have been assigned exactly the same host address. This is not a conflict because they are on different subnets.

Step 7 : Console into R2. Enter the global command that enables IPv6 traffic forwarding.
Action:

r2(config-if)# exit

r2(config)# ipv6 unicast-routing

r2(config)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 8 : On interface s1/0 of R2, assign the IPv6 address 2001:0410:0002:99::/64 eui-64
Action:

r2(config)# interface s1/0

r2(config-if)# ipv6 address 2001:0410:0002:99::/64 eui-64

r2(config-if)#

Result:

Explanation:
This is exactly the same command with the same address that you entered on R1?s connecting serial interface. However, there is no conflict. Remember that the eui-64 parameter is used to automatically configure the host portion. Since the host portion is unique on this router, there is no conflict with the address on R1. You have simply put them on the same :99 subnet.

Step 9 : Create a loopback 0 interface on R2 and assign it the IPv6 address 2001:0410:0002:2::/64 eui-64
Action:

r2(config-if)# interface loopback 0

r2(config-if)# ipv6 address 2001:0410:0002:2::/64 eui-64

r1(config-if)#

Result:
With :2 as the subnet portion, it places the loopback of R2 on subnet :2

Explanation:
At this point, you have configured the :1 subnet on R1, the :2 subnet on R2, and the :99 subnet connecting them together.

Step 10 : On R2, globally enable IPv6 RIP. Use the process name cisco.
Action:

r2(config-if)# exit

r2(config)# ipv6 router rip cisco

r2(config-rtr)#

Result:

Explanation:
The process name is equivalent to the process ID you configured with OSPF; it just uses a word instead of a number. It is locally significant, which means that if you had multiple instances of RIP running on the same router, you would use different process names to keep them separate.

Step 11 : Enable the IPv6 RIP process on R2?s interface s1/0.
Action:

r2(config-rtr)# exit

r2(config)# interface s1/0

r2(config-if)# ipv6 rip cisco enable

r2(config-if)#

Result:

Explanation:
Rather than using a network statement like you did with IPv4, you need to do two steps to have IPv6 RIP advertise routes. The first is to globally enable RIP and the second is to enable RIP on the individual interfaces that will participate.

Step 12 : Enable the IPv6 RIP process on R2?s loopback 0 interface.
Action:

r2(config-if)# interface loopback 0

r2(config-if)# ipv6 rip cisco enable

r2(config-if)#

Result:

Step 13 : Console into R1. Globally enable IPv6 RIP. Use the process name cisco.
Action:

r1# config t

r1(config)# ipv6 router rip cisco

r1(config-rtr)#

Result:

Step 14 : Enable the IPv6 RIP process on R1?s interface s1/1.
Action:

r1(config-rtr)# exit

r1(config)# interface s1/1

r1(config-if)# ipv6 rip cisco enable

r1(config-if)#

Result:

Step 15 : Enable the IPv6 RIP process on R1?s loopback 0 interface.
Action:

r1(config-if)# interface loopback 0

r1(config-if)# ipv6 rip cisco enable

r1(config-if)#

Result:

Step 16 : Use a show command on R1 that provides information specific to IPv6 RIP processes currently running.
Action:

r1(config-if)# end

r1# show ipv6 rip

r1#

Result:

Explanation:
From the output, you can find: the process name, administrative distance, timer values for updates, and interfaces currently running IPv6 RIP.

Step 17 : Enter a show command on R1 to display the IPv6 routing table.
Action:

r1# show ipv6 route

r1#

Result:
The letter C indicates directly connected routes. You should see that the :1 network is directly connected and so is the :99 network.

Explanation:
The R signifies routes learned through IPv6 RIP. You should see a route to subnet :2 The letter L indicates a local route. There are 128 bits in an IPv6 address. Notice the subnet mask of /128. This says to mask the entire address, which makes it a host route. With IPv4, a host route also uses a mask of its entire address: /32 (255.255.255.255). Local routes are not forwarded. You will also see a local summary route to the multicast address FF00. Multicast addresses are used in the basic operation of the IPv6 protocol.

Step 18 : Configure the IPv4 address: 10.111.2.1 255.255.255.0 on R1?s loopback 0 interface.
Action:

r1# config t

r1(config)# interface loopback 0

r1(config-if)# ip address 10.111.2.1 255.255.255.0

r1(config-if)#

Result:

Explanation:
One way to integrate IPv6 into an IPv4 network is to dual stack the protocols. This means that the interfaces are configured with both IPv4 and IPv6 simultaneously. This obviates the need to translate one protocol into the other while providing the support for both protocols.

Step 19 : Advertise IPv4 network 10.0.0.0 under EIGRP 100 on R1.
Action:

r1(config-if)# exit

r1(config)# router eigrp 100

r1(config-router)# network 10.0.0.0

r1(config-router)#

Result:

Step 20 : Console into R2. Configure the IPv4 address: 10.222.2.1 255.255.255.0 on R2?s loopback 0 interface.
Action:

r2(config-if)# interface loopback 0

r2(config-if)# ip address 10.222.2.1 255.255.255.0

r2(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 21 : Advertise IPv4 network 10.0.0.0 under EIGRP 100 on R2.
Action:

r2(config-if)# exit

r2(config)# router eigrp 100

r2(config-router)# network 10.0.0.0

r2(config-router)#

Result:

Step 22 : View the IPv4 routing table on R2 to verify that it has learned a route to network: 10.111.2.0
Action:

r2(config-router)# end

r2# show ip route

r2#

Result:

Explanation:
10.111.2.0 is the IPv4 network configured on R1?s loopback interface. The letter D indicates that it was learned via EIGRP.

Step 23 : From R2, ping 10.111.2.1 to verify that you have connectivity to R1?s IPv4 loopback address.
Action:

r2# ping 10.111.2.1

r2#

Result:
Your pings should be successful.

Step 24 : On R2, enter a show command that will allow you to see neighboring routers? layer 3 addressing information.
Action:

r2# show cdp neighbor detail

r2#

Result:
This command shows not only the IPv4 address of R1, but the IPv6 address as well.

Step 25 : From R2, ping R1?s IPv6 global unicast address you discovered in the previous step.
Action:

r2# ping 2001:410:2:99:XXX:XXXX:XXXX:XXXX

r2#

Result:
Your pings should be successful. The address you are pinging is configured on R1?s interface s1/1.

Explanation:
In place of the Xs, use the address information discovered in the previous step.

Step 26 : From R2, ping the IPv6 address configured on R1?s loopback interface.
Action:

r2# ping 2001:410:2:1:XXX:XXXX:XXXX:XXXX

r2#

Result:
Your pings should be successful. This verifies that the network is routing both IPv4 and IPv6 packets concurrently over the same interfaces (dual stacking), while maintaining connectivity.

Explanation:
Since the host portion (what you see represented here by Xs) will be identical for both interfaces s1/1 and loopback 0, the only difference between these two addresses is that loopback 0 is on the :1 subnet and interface s1/1 is on the :99 subnet. Therefore, you can enter the same ping command you did in the last step, but replace :99 with :1

Step 27 : You have finished Lab 9.
Action:
You can: A) Continue on to the next lab. -or- B) Take this lab again if time permits.

Result:
To take any lab a second time, you first need to reset the devices back to the baseline configurations that were present at the beginning of the lab. This can be done by clicking on the Device Controls link on the left bar, selecting all devices, and clicking the Reload button. Once the devices are all marked green, you can begin the lab. This process takes several minutes.

You can also test your mastery of the material when you take a lab for the second time. Instead of using the Sample Solution link which walks you through each step, you can use the Suggested Approach link. This provides the same steps, but without the walkthrough.

Task 10

ESTABLISHING AND TROUBLESHOOTING A FRAME RELAY WAN

Step 1 : Console into R2. Enable interfaces s1/0 and s1/2.
Action:

r2> enable

r2# config t

r2(config)# interface s1/0

r2(config-if)# no shut

r2(config-if)# interface s1/2

r2(config-if)# no shut

r2(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 2 : Console into R1. Enable interfaces s1/1 and s1/2.
Action:

r1> enable

r1# config t

r1(config)# interface s1/1

r1(config-if)# no shut

r1(config-if)# interface s1/2

r1(config-if)# no shut

r1(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 3 : From global configuration mode on R1, enter a command that will set the configuration on interface s1/2 back to its default.
Action:

r1(config-if)# exit

r1(config)# default interface s1/2

r1(config)#

Result:

Explanation:
This command is helpful when you want to clear the existing configuration on an interface with just one line of code.

Step 4 : On R1, configure the address 172.41.2.1 255.255.255.0 on interface s1/2.
Action:

r1(config)# interface s1/2

r1(config-if)# ip address 172.41.2.1 255.255.255.0

r1(config-if)#

Result:

Step 5 : Change the encapsulation type of interface s1/2 on R1 to frame-relay.
Action:

r1(config-if)# encapsulation frame-relay

r1(config-if)#

Result:

Explanation:
When you previously entered the default interface s1/2 command, the encapsulation type changed to HDLC.

Step 6 : Enter a debug that shows the LMI exchanges between this router and the frame switch.
Action:

r1(config-if)# end

r1# debug frame-relay lmi

r1#

Result:
Wait until you see at least one Type 0 message before proceeding to the next step. It can take up to 60 seconds to appear.

Explanation:
LMI is the signaling (the conversation) between your router and the frame switch. Every 10 seconds, your router says ?hello? to the frame switch to let it know that it?s still alive. If you look at the output from the debug, you will see that the timestamps increment by 10 seconds with each batch of output. Look at the next to the last line of output. You will either see Type 1 or Type 0. Type 1 messages are the hellos. Type 0 messages are the full status updates from the frame switch. When you get one of these, you will see the valid DLCI numbers and hopefully a status of 0x2. 0x2 is code meaning that the PVC for this DLCI is active from end to end.

Step 7 : Disable all debugging on R1.
Action:

r1# undebug all

r1#

Result:

Step 8 : On R1, enter a show command to verify that the encapsulation type is now frame-relay for interface s1/2.
Action:

r1# show interface s1/2

r1#

Result:

Explanation:
On the 5th or 6th line of output, you should see Encapsulation FRAME-RELAY.

Step 9 : Verify the LMI type used for R1?s frame relay connection.
Action:

r1# show frame-relay lmi

r1#

Result:
The LMI type cisco is being used on the frame switch and was automatically detected by your router. If you look at the output, third line from the bottom, you will see the number of status messages received (from the frame switch) and the number of status messages sent (to the frame switch).

Explanation:
Using the analogy that LMI is a conversation between the frame switch and the router, there are three languages (LMI types) that could be spoken. For the conversation to be understandable, the languages have to match on both sides. The LMI type for every IOS version since 11.2 has supported auto-detection so that you do not have bother with manually configuring it. The three LMI types are: cisco, ansi, and q933a.

Step 10 : Enter a show command to view the frame relay PVCs, their status, and the interface each is associated with on R1.
Action:

r1# show frame-relay pvc

r1#

Result:

Explanation:
You should see DLCI 42 and 72 are both active and exit through interface s1/2. If you see other DLCIs, they are configured on the frame switch but are not being used in this lab. In addition, you should also see DLCI USAGE = LOCAL for DLCI 42 and 72. This indicates that the DLCIs are not only available, but are being used by this router. If the DLCIs were configured on the frame switch, but not being used by R1, it would read DLCI USAGE = UNUSED.

Step 11 : Verify the mappings of the local DLCI numbers on R1 to the remote IP addresses on the other side of frame relay cloud.
Action:

r1# show frame-relay map

r1#

Result:
The mappings were learned dynamically through inverse-arp. The regular version of ARP maps a known layer 3 address (IP address) to a layer 2 address (MAC address) that has to be discovered. Inverse-arp starts out with a known layer 2 address (DLCI) and maps it to a remote layer 3 address (IP address) that has to be discovered, which is why it is an inverse.

Explanation:
You should see that DLCI 42 maps to the core router?s IP address: 172.41.2.5 You should also see that DCLI 72 maps to R2?s IP address: 172.41.2.2 If you see other mappings, they will not be used in this lab.

Step 12 : Ping the core router?s 172.41.2.5 address and R2?s 172.41.2.2 address to verify that you have connectivity through the frame cloud.
Action:

r1# ping 172.41.2.5

r1# ping 172.41.2.2

r1#

Result:
Your pings should be successful.

Step 13 : On R1, configure EIGRP 100 to advertise networks 10.0.0.0 and 172.41.0.0
Action:

r1# config t

r1(config)# router eigrp 100

r1(config-router)# network 10.0.0.0

r1(config-router)# network 172.41.0.0

r1(config-router)#

Result:

Step 14 : On R1, remove the IP address from interface s1/2.
Action:

r1(config-router)# exit

r1(config)# interface s1/2

r1(config-if)# no ip address

r1(config-if)#

Result:

Explanation:
In the previous steps of this lab, you configured and tested frame relay on the physical interface, s1/2. Here, you are removing the IP address from the physical interface in preparation for configuring frame relay on a subinterface.

Step 15 : On R1, create subinterface s1/2.1 and make the type point-to-point.
Action:

r1(config-if)# exit

r1(config)# interface s1/2.1 point-to-point

r1(config-subif)#

Result:

Explanation:
From global configuration mode, a physical interface can be split into logical subinterfaces by placing a dot after the interface and specifying a unique subinterface number. You can pick any number between 1 and about 4 billion.

Step 16 : Configure the address 172.41.2.1 255.255.255.0 on R1?s s1/2.1 interface.
Action:

r1(config-subif)# ip address 172.41.2.1 255.255.255.0

r1(config-subif)#

Result:

Step 17 : Manually configure interface s1/2.1 on R1 to use DLCI 42.
Action:

r1(config-subif)# frame-relay interface-dlci 42

r1(config-fr-dlci)#

Result:

Explanation:
When subinterfaces are used, frame relay has no way of knowing which subinterface is the correct one to send packets to when they arrive on the physical interface. To remedy this, the subinterface must contain a command that references the local DLCI.

Step 18 : Create a second point-to-point subinterface on R1: s1/2.2
Action:

r1(config-fr-dlci)# exit

r1(config)# interface s1/2.2 point-to-point

r1(config-subif)#

Result:

Step 19 : Configure the address 172.21.2.1 255.255.255.0 on R1?s s1/2.2 interface.
Action:

r1(config-subif)# ip address 172.21.2.1 255.255.255.0

r1(config-subif)#

Result:

Explanation:
Each point-to-point interface is on a different subnet.

Step 20 : Manually configure interface s1/2.2 on R1 to use DLCI 72.
Action:

r1(config-subif)# frame-relay interface-dlci 72

r1(config-fr-dlci)#

Result:

Step 21 : Console into R2. Remove the IP address from interface s1/2.
Action:

r2(config-if)# interface s1/2

r2(config-if)# no ip address

r2(config-if)#

Result:
Anytime you see a device blinking, it is a reminder to console into a new device.

Step 22 : On R2, create subinterface s1/2.1 and make the type point-to-point.
Action:

r2(config-if)# exit

r2(config)# interface s1/2.1 point-to-point

r2(config-subif)#

Result:

Step 23 : Configure the address 172.21.2.2 255.255.255.0 on R2?s s1/2.1 interface.
Action:

r2(config-subif)# ip address 172.21.2.2 255.255.255.0

r2(config-subif)#

Result:

Step 24 : Manually configure interface s1/2.1 on R2 to use DLCI 22.
Action:

r2(config-subif)# frame-relay interface-dlci 22

r2(config-fr-dlci)#

Result:

Step 25 : Console into R1. Ping the core router: 172.41.2.5 and R1: 172.21.2.2
Action:

r1(config-fr-dlci)# end

r1# ping 172.41.2.5

r1# ping 172.21.2.2

r1#

Result:
Your pings should be successful. Anytime you see a device blinking, it is a reminder to console into a new device.

Explanation:
Through the frame cloud, you now have a point-to-point subnet from R1 to the core router, 172.41.2.0 and a point-to-point subnet from R1 to R2, 172.21.2.0

Step 26 : From R1, ping the TFTP server: 100.100.100.100
Action:

r1# ping 100.100.100.100

r1#

Result:
Your pings should be successful.

Explanation:
R1 has learned of the 100.0.0.0 network from the core router via EIGRP.

Step 27 : Copy the file lab10-r1 from the TFTP server into your running configuration on R1. Once the copy has completed, type in the exit command on the router.
Action:

r1# copy tftp run

Address or name of remote host []?  100.100.100.100

Source filename []? lab10-r1

Destination filename [running-config]?    (PRESS ENTER)

r1# exit    (PRESS ENTER TWICE)

Result:
After typing exit and hitting ENTER twice, if you were successful, you should see a new banner message appear.

Step 28 : From R1, ping the TFTP server: 100.100.100.100 again and you will find that the pings fail.
Action:

r1> enable

r1# ping 100.100.100.100

r1#

(THE PINGS ARE SUPPOSED TO FAIL.)

Result:

Explanation:
This step simply verifies that you have lost connectivity to the TFTP server. Continue to the next step.

Step 29 : The configuration you downloaded contains a frame relay issue that prevents you from pinging the TFTP server. Without using the show run command, use other verification commands you have learned to discover what has changed on R1.
Action:

To see if frame relay is still the encapsulation type configured on interface s1/2, use the show interface s1/2 command.

To see if the two PVCs are both active, use the show frame-relay pvc command.

To find out which DLCIs the frame switch says are valid by viewing the conversation between the frame switch and R1, use the debug frame-relay lmi command and wait for a Type 0 message.

Result:

Step 30 : Based on what you learned in the last few steps, make configuration changes so that R1 is able to re-establish connectivity to the TFTP server through the frame cloud.
Action:

Try to make the configuration changes on your own to restore connectivity. Spend no more that five minutes troubleshooting. If you are still stuck after five minutes, go to the next step, which will walk you through the solution.

Result:

Step 31 : R1 troubleshooting solution.
Action:

SHOW INTERFACE S1/2
You are looking to see if the encapsulation type is still frame-relay. If you look at the 5th or 6th line of output, it confirms that this is fine. The encapsulation type is frame-relay.

SHOW FRAME-RELAY PVC
You expect to see two PVCs, both active. Instead you see three PVCs.
DLCI 42 is ACTIVE, but it also says DLCI USAGE = UNUSED. So there is a problem here. DLCI 72 is ACTIVE, and DLCI USAGE = LOCAL. This one is fine.
DLCI 115 is DELETED, and DLCI USAGE = LOCAL. This is also a problem. When the status is DELETED, it makes it sound like it used to exist but now it?s gone. What it really means is ?bad DLCI.? It also tells you where this DLCI is configured: on the s1/2.1 subinterface.
Before making any changes, view the output of the next command.

DEBUG FRAME-RELAY LMI
After entering the command, wait until you see a Type 0 message. It contains a full status update. The update is from the frame switch and it is telling us the valid DLCIs that R1 can use.
You should see DLCI 42 and DLCI 72 listed. You may see others as well, but one thing you definitely won?t see is DLCI 115. Since the frame switch does not specifically mention DLCI 115, it is wrong. This was also indicated in the previous show command when it was marked DELETED. You have a misconfigured DLCI statement on the s1/2.1 subinterface. Use the undebug all command to turn off the debug.

To fix it, change it to what it should be, DLCI 42. From your investigations, you found that it was ACTIVE, but UNUSED.

r1# config t

r1(config)# interface s1/2.1

r1(config-subif)# frame-relay interface-dlci 42

r1(config-fr-dlci)# end

Result:

Step 32 : On R1, use a show command to see if the PVCs are active and being used locally.
Action:

r1# show frame-relay pvc

r1#

Result:

Explanation:
You should find that both DLCI 42 and 72 are both active and are being used locally. The entry for DCLI 115, DELETED, should no longer be present.

Step 33 : On R1, ping the TFTP server: 100.100.100.100 to verify that you have restored connectivity through the frame cloud.
Action:

r1# ping 100.100.100.100

r1#

Result:
Your pings should be successful, however, it may take a minute for EIGRP to catch up with the recent configuration changes before your route to 100.0.0.0 is restored. If this is the case, wait a minute and try the ping again.

Step 34 : You have finished Lab 10.
Action:
You can take this lab or a previous lab again if time permits.

Result:
To take any lab a second time, you first need to reset the devices back to the baseline configurations that were present at the beginning of the lab. This can be done by clicking on the Device Controls link on the left bar, selecting all devices, and clicking the Reload button. Once the devices are all marked green, you can begin the lab. This process takes several minutes.

You can also test your mastery of the material when you take a lab for the second time. Instead of using the Sample Solution link which walks you through each step, you can use the Suggested Approach link. This provides the same steps, but without the walkthrough.

Reference blogs:

https://learningnetwork.cisco.com/message/68317#68317

https://learningnetwork.cisco.com/message/197590#197590

https://learningnetwork.cisco.com/message/203378#203378