| 1-06-2012 | Topic Notes from tonight's online CCNA study. |
|
|
|
|
|
|
| This was a challenge lab specifically geared for ICND1 and ICND2 students. There are 10 labs that will test your skills. You should go through them once with the documentation and then eventually have this embedded by memory. | |
|
|
|
|
Task 1 IMPLEMENTING A SMALL NETWORK: Routers Task 2 IMPLEMENTING A SMALL NETWORK: Switches and Connectivity Task 3 CONFIGURING EXPANDED SWITCHED NETWORKS: VLANs and VTP Task 4 CONFIGURING EXPANDED SWITCHED NETWORKS: RSTP and Troubleshooting Task 5 IMPLEMENTING AND TROUBLESHOOTING OSPF Task 6 IMPLEMENTING AND TROUBLESHOOTING EIGRP Task 7 IMPLEMENTING AND TROUBLESHOOTING ACLs Task 8 CONFIGURING NAT AND PAT Task 9 IMPLEMENTING IPv6: Addressing, Routing, and Dual Stacking Task 10 ESTABLISHING AND TROUBLESHOOTING A FRAME RELAY WAN 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. 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. NOTE: Initial passwords are cisco 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 10.2.1.1 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 1 sw1(config-if)# ip address 10.2.1.2 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. Action: 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 10.2.1.5 sw1(config)# Result: Explanation: The default gateway is always an address on the same subnet. In this lab, your switch has the IP address 10.2.1.2 and the core router has the IP address 10.2.1.5. Any packets sourced from the switch destined for networks outside the 10.2.1.0 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 into CoreSwC. Set the speed of port 1 on CoreSwC to 100Mb/s. Action: CoreSwC> enable CoreSwC# config t CoreSwC# interface f0/1 CoreSwC(config-if)# speed 100 CoreSwC(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 Sw1. Step 11 : Set the duplex of port f0/1 on CoreSwC to full. 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# 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# 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: 10.2.1.1 Action: sw1# ping 10.2.1.1 sw1# Result: Your pings should be successful. Step 23 : From Sw1, ping the TFTP server: 10.2.1.100 Action: sw1# ping 10.2.1.100 sw1# Result: Your pings should be successful. Step 24 : Console into R1. Use 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: 10.2.1.2 Action: r1# ping 10.2.1.2 r1# Result: Your pings should be successful. Scenario: The TFTP server will not ping. It is your job to find out why there is no connectivity. The whole idea is to make the PC0 talk to TFTP Server. Hint: See note 2 in the pkt! 1)Separate ip address put fast Ethernet and f0/0 of r1 also f0/0 of core must be same IP subnet than add the ip address on interface. 2) We have not configure
serial interface of each router so by IP address command (IP address
20.0.0.4 255.255.255.0 ) You need to put this on a different subnet
or the same router won't communicate each other and there will be
an overlap. Regardless of 10.0.2.03 on different interface ..
|
|
|
January 23, 2011 |
|
|
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. |
|
|
|
|
|
Reference blogs: https://learningnetwork.cisco.com/message/68317#68317 https://learningnetwork.cisco.com/message/197590#197590 https://learningnetwork.cisco.com/message/203378#203378
|
|
| Topic Notes from tonight's online CCNA study. | |
|
So this problem has finally been
solved. A couple of things needed to be changed in order to get a
working configuration. The biggest problem with this labs was the
tftp server with the ip 100.100.100.100.
The following problems were seen and documented:
1. Corrected the IP addresses on the devices from the Lab 1 2. Enabled interfaces which were logically and physically Down 3. Enabled the interface connected to the Frame Cloud on R1 4. Mistake on Gateway of the Server, was pointing to the Fa0/0 of Router Core 5. Corrected the ip default-geteway of SW1 to be the one of R1 fa0/0 6. VLAN 1 IP address was not configured on Core Switch B that's why you cannot telnet in. 7. The path VLAN 1 traffic would take from Sw1 to reach the core router is SW1 => Core Switch A => Core Router 8 Lowered Core Switch C Vlan 51's Priority to 4096 so it becomes the root bridge for VLAN 51 9. Mistake found on Lab 5 which ask to ping the ip 10.5.0.1 knowing this network doesn't even exist so changed 10.5.25.0 to 10.5.0.0 network to get it work. 10. Bandwitdh on R2 interface S1/1 adjusted to 128 to match bandwidth of R1 11. Bandwitdh on R1 interface S1/2 adjusted to 64 to match bandwidth of Core Router 12.Configured OSPF authentication MD5 encryption. 13 Couldn't find a tftp server with the IP 100.100.100.100 so created and assigned it to vlan 10 using encapuslation dot1q on Core Router to enable traffic between the other network devices and "don't forget to add the network 100.100.100.0/24 in OSPF." |
|
