Multi-area OSPF 1

By certskills April 18, 2016 09:05

When using the OSPF network command, whether single area of multi-area, you have to be careful with the wildcard mask used and which interfaces each network command matches. With multiple areas, that concern increases, because incorrect matching can place a router interface into the wrong area. This latest OSPF lab gives you a small multi-area OSPF design and asks you to enable OSPFv2 with network commands, for some practice with those network commands in particular.


Configure multi-area OSPFv2 (that is, OSPF for IPv4) on the four routers shown in the figure. Use the area design shown in the figure. The configuration should use OSPF network commands, and not use interface subcommand ip ospf. The specific rules for this lab are:

  • Use an OSPF process-ID of 10 on all routers
  • Use only the network command to enable OSPF on an interface.
  • Use one network command for each router interface shown in the figure. That network command should use a wildcard mask that matches all IP addresses in the subnet connected to the interface. (Note: I added this rule in lab just so that there is one correct way to answer this lab; in real life many different wildcard masks could be used.)
  • Configure router-ID’s explicitly in OSPF configuration mode, with router ID’s as follows:
    • Core1:
    • Core2:
    • Branch1:
    • Branch2:
  • Use all default OSPF parameters unless otherwise requested.
  • Assume all device interfaces shown in the lab are up, working and with correct IP addresses assigned.


Figure 1: Multi-area Topology


Initial Configuration

Example 1, 2, 3 and 4 show the beginning configuration state of Core1, Core2, Branch1 and Branch2.

Example 1: Core1 Config


Example 2: Core2 Config


Example 3: Access1 Config


Example 4: Access2 Config


Answer on Paper, or Maybe Test in Lab

Next, write your answer on paper. Or if you have some real gear, or other tools, configure the lab with those tools.

To test your solution, if you happen to try it with VIRL or real gear, you can verify that the correct configuration has been entered by verifying a couple of different items. First, check the OSPF neighbor relationships with the show ip ospf neighbor command. The two core routers should list two neighbors each, and the two branch routers should list one neighbor each. Check the routing tables, using the show ip route command, to ensure that all known networks have been learned on each device. Each router should list five subnets, with 3 subnets learned by OSPF.

From the branch routers, also test connectivity with the ping command. For instance, on router Branch1, use the ping source command to issue an extended ping from Branch1’s G0/2 interface IP address ( to router Branch2’s G0/2 interface address (


Do this Lab with Cisco’s VIRL

You can do these labs on paper and still get a lot out of the lab. As an extra help, we have added files for the Virtual Internet Routing Lab (VIRL) software as well. The .VIRL file found here is a file that when used with VIRL will load a lab topology similar to this lab’s topology, with the initial configuration shown in the lab as well. This section lists any differences between the lab exercise and the .VIRL file’s topology and configuration.

Download this lab’s VIRL file!

The virl topology matches this lab topology exactly.

Answers: Local DHCP Server 1
Remote DHCP Server 1
By certskills April 18, 2016 09:05
Write a comment


  1. Liooh December 21, 14:44

    Why does it list as a DR ? Shouldn’t it be a BDR ?

    Reply to this comment
    • certskills Author December 21, 15:52

      Sorry, I’m not catching what you’re asking. Nothing in the post mentions “DR” or “Designated Router”. So I don’t think this post lists as DR. Can you clarify?

      Reply to this comment
      • Liooh December 21, 16:06

        I did all the configurations as it is stated on the answers but when I type “show ip ospf neighbor” on Core2 it lists as a DR.

        Reply to this comment
        • certskills Author December 22, 09:22

          It’s probably a timing issue. The DR and BDR are elected, and then NOT preempted. EG, if you configured R1, and it had time to become DR before you configured R2, then R2 would not preempt R2’s role as DR.

          Maybe reload R1, or do a shut/no shut on the relevant interface, and see who becomes DR.

          Or to make it a real negotiation, shutdown both, then no shutdown both.

          Reply to this comment
  2. Junior January 18, 21:07


    Pienso que en la séptima línea de la configuración de Branch2, va GigabitEthernet0/2.

    Gracias por estos laboratorios.

    Reply to this comment
View comments

Write a comment

Comment; Identify w/ Social Media or Email


Subscribe to our mailing list and get interesting stuff and updates to your email inbox.

Thank you for subscribing.

Something went wrong.