What You’ll Learn

What You’ll Need

Open the Lab Environment in Cisco Packet Tracer

This tutorial requires the Cisco Packet Tracer simulator. The following steps provide general guidance on how to obtain and install this free software application. If you already have Cisco Packet Tracer installed, at version 8.2.0 or later, you can skip these instructions.

  1. Navigate to https://skillsforall.com/learningcollections/cisco-packet-tracer.
  2. This web page should tell you to enroll in a free Packet Tracer course, which in turn describes how to download and install the application. Follow the links and instructions to enroll in the free course. If you do not have an account yet, you will need to establish one.
  3. If you have never used Packet Tracer, you would benefit from taking the course to familiarize yourself with it. (You can return to this tutorial when you have some basic skills with the tool.)
  4. The course directs you to the download page to download Packet Tracer. (The link may move, but the download link may still be https://skillsforall.com/resources/lab-downloads.)
  5. Download and install the latest version of Packet Tracer for your operating system.

Download and Open the Packet Tracer File

  1. Click this link to download the Packet Tracer (.pkt) file to be used with this lab.

  2. Open the file in Cisco Packet Tracer. You can either:

    1. Double-click the filename as displayed in your file manager.
    2. Using Packet Tracer, use the upper menu for File… Open and open the file.

  3. You should see a topology window with four routers—R1, R2, R3, and R4—similar to the following figure.

    Figure 1: Lab Topology with Interface IDs fig-1.png

  4. Get into the console of each router with these steps:

    1. Click each router icon, opening a window.
    2. Click the console tab.
    3. Click inside the text area in the center of the console.
    4. Press Enter repeatedly to see the CLI prompt changing, proving that you are getting a response from the router.
    5. Use the enable command to move to privileged mode.

Basic Topology Familiarization

This lab has three large steps. First, it examines the expected OSPF neighbor relationship between routers R1 and R2, as shown in Figure 2. Then, it uses the same process to explore the next pair (R1 and R3), closing with the third pair (R1 and R4). For each pair, you will first gather facts about OSPF features that might cause problems for OSPF and then work to correct the configuration for any suspicious settings.

Figure 2: Expected R1-R2 Neighbor Relationship fig-2.png

Before setting about for the first pair, use these steps to confirm that no routers have OSPF neighbor relationships nor OSPF-learned routes.

  1. First, focus on R1. Use the show cdp neighbors brief command to display all Cisco Discovery Protocol-learned neighboring devices. Focus on the entries for routers R2, R3, and R4. Which interfaces does R1 use to connect to each?
  2. Use the show ip ospf interface brief command to display all OSPF-enabled interfaces on R1. Is OSPF enabled on all four Ethernet interfaces shown earlier in Figure 1—including the three interfaces that connect to the other routers, respectively?
  3. Use the show ip ospf neighbor command on R1. How many neighbors does R1 have? How many should it list when OSPF works correctly on all links shown in the figure?
  4. Use the show ip route ospf command on R1, which displays all OSPF-learned routes on the router. How many OSPF-learned IPv4 routes does R1 have?

In this topic, you will gather facts that could impact the R1-R2 neighbor relationship. In the next topic, you will analyze the suspicious settings and make configuration changes until the R1-R2 OSPF neighbor relationship is fully functional.

Confirm R2 Lacks OSPF Neighbor and Routes

First, from R2, confirm that it has no OSPF neighbor relationship with R1 and that it has no OSPF-learned routes.

  1. Use the show ip ospf neighbor brief command. How many neighbors does R2 have?

  2. Use the show ip route ospf command. How many IPv4 routes does R2 have? Does it have a route to R1’s LAN subnet 172.16.1.0/24?

Later, once you have repaired the OSPF neighbor relationship, you will use these same steps to verify that OSPF works between R1 and R2.

Gather IP Facts That Can Affect the R1-R2 Neighbor Relationship

Rather than looking at the configuration, practice finding all the settings that impact OSPF neighbors, using the following commands and questions. Take the time to consider where to find each fact in the suggested commands.

  1. Confirm which interfaces R1 and R2 use to connect to each other, using the show cdp neighbors command on R1. Note the interface that is used on each device.

  2. Use the following commands to complete Table 1’s facts about R1:

  1. Use the same sequence of commands on R2 to gather those same facts for R2’s interface on the other end of the link.

Gather OSPF Facts That Can Affect the R1-R2 Neighbor Relationship

  1. Gather OSPF facts in Table 2, first for R1. Use the following commands in order:

    1. show ip ospf interface brief
    2. show ip ospf interface interface-id
    3. show ip ospf
    4. show ip ospf neighbor

    Table 2: OSPF Interface Facts fig-2.png

  2. Complete Table 2, using the same sequence of commands, this time for R2.

  3. Reflect on the information in both tables versus your recollection of why two routers might not become OSPF neighbors, or why they might become neighbors but fail to add IP routes to the routing table.

    • Which items seem suspicious to you?
    • Which values should be the same on both routers, but are not?
    • Which should be different, but are not?
    • Make notes where you can refer to them when performing the steps in the next topic.

For reference, Tables 1 and 2 show the results that you should have gathered in the previous topic, with the potential issues highlighted.

Table 1: Related Interface Facts (Completed) fig-1.png

Table 2: OSPF Facts (Completed) fig-1.png

In this topic, work through the potential issues in the following order. For any fixes, change R2 rather than R1. For any access control list (ACL) changes, the lab will specify the steps.

Configure R2 to Match R1: Dead Interval

  1. To build skills in reviewing and understanding the show command output, resist the urge to look at the configuration files. Instead, look at the settings per show commands, and then attempt to configure to make R2’s configuration work with R1’s.
  2. Remind yourself of the hello and dead interval settings on R1 and R2 from your notes, or repeat the show ip ospf interface command on both routers to confirm the values.
  3. Change R2’s interface to use the same dead interval as R1, using the ip ospf dead-interval 40 interface subcommand.
  4. This single action should repair the OSPF neighbor relationship, so watch for a log message on R2’s console to that effect.
  5. Verify the new hello and dead interval values on R2. Does the hello interval match R1? How about the dead interval?

In this case, R1 uses default hello and dead interval settings (10 and 40, respectively). R2 originally used the default hello interval of 10 and a configured dead interval of 50. Configuring the dead interval on R2 to match R1 solved the problem.

Confirm the R1-R2 Neighbor Relationship Works

Even though the log message suggested that the neighbor relationship on R2 initialized, you should confirm that it works, reaches a FULL state, and results in working IP routes, by using these steps:

  1. Use the show ip ospf neighbor command. How many neighbors does R2 have? Does it list R1, with router ID 1.1.1.1? (It should.)

  2. Use the show ip route ospf command. How many OSPF-learned IPv4 routes does R2 have? Does it have a route to R1’s LAN subnet 172.16.1.0/24? (It should.)

Outbound ACL on R2 G0/0/0 Interface

The previous steps showed that the R1-R2 neighbor relationship came up, even though R2 has an ACL enabled. The next few steps investigate the ACL.

  1. From R2, confirm the name of the ACL and the direction with the show ip interfaces g0/0/0 command.
  2. The show access-lists command displays the ACL. Think through the matching logic in the ACL. Should the ACL match OSPF packets with a permit or deny action?
  3. Note that the matching logic would not match OSPF packets with either of the ACL’s two permit commands, because OSPF does not use TCP or UDP.

In fact, the ACL in this case has no effect on OSPF. For packets that the router creates, like OSPF messages, Cisco IOS bypasses all outbound ACLs. That is why the existence of the outbound ACL on R2 had no effect on the R1-R2 neighbor relationship.

In this topic, you will gather facts that could impact the R1-R3 neighbor relationship. In the next topic, you will analyze the suspicious settings and make configuration changes until the R1-R3 OSPF neighbor relationship is fully functional.

Confirm R3 Lacks OSPF Neighbor and Routes

First, from R3, confirm that it has no OSPF neighbor relationship with R1 and that it has no OSPF-learned routes.

  1. Use the show ip ospf neighbor command. How many neighbors does R3 have?

  2. Use the show ip route ospf command. How many IPv4 routes does R3 have? Does it have a route to R1’s LAN subnet 172.16.1.0/24?

Later, once you have repaired the OSPF neighbor relationship, you will use these same steps to verify that OSPF works between R1 and R3.

Gather IP Facts That Can Affect the R1-R3 Neighbor Relationship

Rather than looking at the configuration, practice finding all the settings that impact OSPF neighbors, using the following commands and questions. Take the time to consider where to find each fact in the suggested commands.

  1. Confirm which interfaces R1 and R3 use to connect to each other, using the show cdp neighbors command on each router. Note the interface that is used on each device.

  2. Use the following commands to complete Table 1’s facts about R1:

  1. Use the same sequence of commands on R3 to gather those same facts for R3’s interface on the other end of the link.

Gather OSPF Facts That Can Affect the R1-R3 Neighbor Relationship

  1. Gather OSPF facts in Table 2, first for R1. Use the following commands in order:

    1. show ip ospf interface brief
    2. show ip ospf interface interface-id
    3. show ip ospf
    4. show ip ospf neighbor

    Table 2: OSPF Interface Facts fig-2.png

  2. Complete Table 2, using the same sequence of commands, this time for R3.

  3. Reflect on the information in both tables versus your recollection of why two routers might not become OSPF neighbors, or why they might become neighbors but fail to add IP routes to the routing table.

For reference, Tables 1 and 2 show the results that you should have gathered in the previous topic, with the potential issues highlighted.

Table 1: Related Interface Facts (Completed) fig-1.png

Table 2: OSPF Facts (Completed) fig-1.png

In this topic, work through the potential issues in the following order. For any fixes, change R3 rather than R1. For any ACL changes, the lab will specify the steps.

Configure R3 to Match R1: IP Subnet Mismatch

  1. To build skills in reviewing and understanding the show command output, resist the urge to look at the configuration files. Instead, look at the settings per show commands, and then change R3’s configuration to work with R1’s.
  2. Recall the IP address and mask settings on R1 and R3 from your notes. Alternatively, repeat the show protocols or show ip ospf interface command to find those values.
  3. Remind yourself of the subnet ID associated with each address-mask combination from your notes. Alternately, use the show ip route connected command to find the connected route on the interface, which reveals the subnet ID calculated by the router for each interface.
  4. Are the subnet ID values different? (They should be different at this point in the lab, but they need to match for the neighbor to work.)
  5. Fix the mismatched subnet problem. Change R3’s interface IP address to 172.16.13.3, with the same mask, using the ip address 172.16.13.3 255.255.255.192 interface subcommand.
  6. Do you see any OSPF-related log messages appear?

Check the R1-R3 Neighbor Status

Because you fixed a configuration mistake that would impact the R1-R3 neighbor relationship, take a moment to check the OSPF neighbor status and check whether R3 has learned OSPF routes from R1, using these steps:

  1. Use the show ip ospf neighbor command. How many neighbors does R3 have? Does it list R1, with router ID 1.1.1.1? (It should not at this point.)

  2. Use the show ip route ospf command. How many OSPF-learned IPv4 routes does R3 have? Does it have a route to R1’s LAN subnet 172.16.1.0/24? (It should not at this point.)

Configure R3 to Match R1: Priority 0 on R3

  1. Recall the OSPF priority settings on R1 and R3 from your notes. Alternatively, repeat the show ip ospf interface command to find those values.
  2. Remind yourself of the rules about how OSPF priority can affect OSPF neighbors, as follows:
    1. If the routers use a designated router (DR) or backup designated router (BDR)
    2. If both use priority 0
    3. Then, neither will be willing to be DR or BDR. They will become neighbors and list each other in the show ip ospf neighbor command output. However, they will have problems adding routes to their IP routing tables because of confusion about the contents of the link-state advertisements (LSAs).
  3. Are both routers using priority 0? (You should find that only R3 has priority 0 configured in this scenario.)

In this case, the priority value may have looked suspicious, but it does not cause a problem, because R1 has a non-0 value. To prove the fact that R3’s priority 0 setting does not cause a problem, leave it unchanged. Then, complete the remaining steps to fix the neighbor relationship, which will confirm that the priority settings did not cause a problem.

Inbound ACL on R3 G0/0/0 Interface

Cisco IOS bypasses outbound ACLs for packets generated by the router itself. However, Cisco IOS considers all packets entering the interface for any ACL enabled in the inbound direction. Use these next steps to consider what happens with the ACL on R3.

  1. From your notes, recall the name of the ACL and the direction on R3. Alternately, find the information again, using the show ip interfaces g0/0/0 command on R3.
  2. Use the show access-lists command to display the ACL. Think through the matching logic in the ACL. Should the ACL match OSPF packets with a permit or deny action?
  3. Note that neither of the two permit commands match OSPF packets, because OSPF does not use TCP or UDP. As a result, all incoming OSPF packets match the implied deny all at the end of the ACL, preventing OSPF neighbor discovery and preventing the neighbor relationship.
  4. Change the ACL to match all OSPF packets, from and to any IP address, with these two commands in configuration mode:
    1. ip access-list extended R3-ACL
    2. permit ospf any any
  5. This action should repair the OSPF neighbor relationship, so watch for a log message on R3’s console to that effect.

Check the R1-R3 Neighbor Status Again

Repeat your checks of both the neighbors and OSPF-learned routes from R3 to confirm that OSPF works between R1 and R3.

  1. Use the show ip ospf neighbor command. How many neighbors does R3 have? Does it list R1, with router ID 1.1.1.1? (It should.)
  2. Use the show ip route ospf command. How many OSPF-learned IPv4 routes does R3 have? Does it have a route to R1’s LAN subnet 172.16.1.0/24? (It should.)

In this topic, you will gather facts that could impact the R1-R4 neighbor relationship. In the next topic, you will analyze the suspicious settings and make configuration changes until the R1-R4 OSPF neighbor relationship is fully functional.

Confirm R4 Lacks OSPF Neighbor and Routes

First, from R4, confirm that it has no OSPF neighbor relationship with R1 and that it has no OSPF-learned routes.

  1. Use the show ip ospf neighbor command. How many neighbors does R4 have?

  2. Use the show ip route ospf command. How IPv4 routes does R4 have? Does it have a route to R1’s LAN subnet 172.16.1.0/24?

Later, once you have repaired the OSPF neighbor relationship, you will use these same steps to verify that OSPF works between R1 and R4.

Gather IP Facts That Can Affect the R1-R4 Neighbor Relationship

Rather than looking at the configuration, practice finding all the settings that impact OSPF neighbors, using the following commands and questions. Take the time to consider where to find each fact in the suggested commands.

  1. Confirm which interfaces R1 and R4 use to connect to each other, using the show cdp neighbors command on each router. Note the interface that is used on each device.

  2. Use the following commands to complete Table 1’s facts about R1:

  1. Use the same sequence of commands on R4 to gather those same facts for R4’s interface on the other end of the link.

Gather OSPF Facts That Can Affect the R1-R4 Neighbor Relationship

  1. Gather OSPF facts in Table 2, first for R1. Use the following commands in order:

    1. show ip ospf interface brief
    2. show ip ospf interface interface-id
    3. show ip ospf
    4. show ip ospf neighbor

    Table 2: OSPF Interface Facts fig-2.png

  2. Complete Table 2, using the same sequence of commands, this time for R4.

  3. Reflect on the information in both tables versus your recollection of why two routers might not become OSPF neighbors, or why they might become neighbors but fail to add IP routes to the routing table.

    • Which items seem suspicious to you?
    • Which values should be the same on both routers, but are not?
    • Which should be different, but are not?
    • Make notes where you can refer to them when performing the steps in the next topic.

For reference, Tables 1 and 2 show the results that you should have gathered in the previous topic, with the potential issues highlighted.

Table 1: Related Interface Facts (Completed) fig-1.png

Table 2: OSPF Facts (Completed) fig-1.png

In this topic, work through the potential issues in the following order. For any fixes, change R4 rather than R1.

Check the R1-R4 Neighbor Status

First, confirm that the R1-R4 OSPF neighbor relationship does not work from R4.

  1. Use the show ip ospf neighbor command. How many neighbors does R4 have? Does it list R1, with router ID 1.1.1.1? (It should not at this point.)

  2. Use the show ip route ospf command. How many OSPF-learned IPv4 routes does R4 have? Does it have a route to R1’s LAN subnet 172.16.1.0/24? (It should not at this point.)

Enable the R4 WAN Interface

  1. To build skills in reviewing and understanding the show command output, resist the urge to look at the configuration files. Instead, look at the settings per show commands, and then change R4’s configuration to work with R1’s.
  2. With R4’s G0/0/0 interface disabled, no packets can flow in or out of the R4 link to R1. Enable that interface, using these commands:
    • interface g0/0/0
    • no shutdown
  3. Do you see any OSPF-related log messages appear? (You should.)

Check the R1-R4 Neighbor Status

  1. Use the show ip ospf neighbor command on R4. How many neighbors does R4 have? Does it list R1, with router ID 1.1.1.1? (It should at this point.)
  2. Use the same command on R1. Does it list R4, with OSPF RID 4.4.4.4?
  3. Consider the OSPF neighbor state on both routers and compare them. How do they differ?
  4. On R4, use the show ip route ospf command. How many OSPF-learned IPv4 routes does R4 have? Does it have a route to R1’s LAN subnet 172.16.1.0/24? (It should not at this point.)

These steps show one scenario in which two routers can be OSPF neighbors while other problems prevent them from using any routes based on the information learned from that neighbor. One remaining issue must be fixed before R1 and R4 can add routes to the routing table based on the LSAs learned over their neighbor relationship.

Configure R4 to Match R1: OSPF Network Type

  1. Recall the OSPF network type settings on R1 and R4 from your notes. Alternatively, repeat the show ip ospf interface command to find those values.
  2. Configure R4 to revert to the default network type (broadcast), using the following two commands:
    1. interface g0/0/0
    2. no ip ospf network point-to-point

Check the R1-R4 Neighbor Status Again

Remember, the routers already had a neighbor relationship but could not add routes based on any learned LSAs due to the network type mismatch. The most recent configuration change should have solved this issue. Repeat your checks of both the neighbors and OSPF-learned routes from R4 to confirm that OSPF works between R1 and R4.

  1. Use the show ip ospf neighbor command. How many neighbors does R4 have? Does it list R1, with router ID 1.1.1.1? (It should.)
  2. Use the show ip route ospf command. How many OSPF-learned IPv4 routes does R4 have? Does it have a route to R1’s LAN subnet 172.16.1.0/24? (It should.)

Congratulations! You have successfully completed this lab.

Training Resources

Learn More