OSPF Virtual Link Multi-Area

Categories Cisco

Lab Objectives

  • Configure OSPF as shown in diagram.
  • Configure routers ID’s as 1.1.1.1 for R1, etc.
  • Make sure R4 can reach Area 3 networks.
  • Make sure R4 sees only 22.22.0.0/16 instead of 22.22.22.0/24 & 22.22.23.0/24
  • Inject 111.11.1.1/24 without using network command and see if the route is O-E2 or O-E1 on other routes
  • R1 should inject default route into ospf domain.
  • Make sure R4 doesn’t see inter-area and external routes
  • Configure Area 2 NSSA and remove virtual link.
  • Make sure 4.4.4.0/24 network is seen as /24 on R2.
  • Configure link authentication on R1 & R2 using the best authentication between R3 & R4 use “CISCOPETE” as password.

Since Loopback 1 is in area 3 in order to advertise it to R2 which belongs to area 2 we create a route-map called LOOP1. We then redistribute the route in our OSPF process 1 on R1. This means that from the connected network we will advertise Loopback 1 – by default it should appear as an O E2 in R-2 routing table.

Now, if we inspect the routing table for R-4 we see that their is one O route which is a local route within the area R-4 is in. We notice one E2 route which is an external route that is being redistributed to R-4 from R-1. Last we notice 8 inter-area routes which are routes learned in different areas.

R-4 doesn’t have a route to the 1.1.1.1 network. In order to get a route to it we will need to create a virtual-link on R-1 and R-2.


Notice that once we create the virtual-link on R-1’s side we start getting a mismatched area ID from backbone area. This is because we haven’t created the virtual-link on R-2’s side.

Now we can check on R-4 to see if we have a route to 1.1.1.1

If we check our OSPF neighborship on R-1 we will now see that we have 2 neighbors instead of one. This is because of our virtual-link.

Our next step is to perform route summarization because we want R-4 to only see 22.22.0.0/16 in our routing table. This can help with maintenance and general housekeeping to clean up our routing table. Currently we are seeing two routes – 22.22.22.0/24 and 22.22.23.0/24

To solve this task we will go to R-3 which is directly connected to R-4 and use the ospf range command. This command should be applied to the ABR.

Checking on R-4 we can see that our 2 network routes have now been summarized by 22.22.0.0/16 advertisement.

Our next step is to set a default route. If we look at R-4 we notice that their is currently no default gateway. We can solve this by using the default originate command on R-1.


Now, let’s check R-4’s routing table.

For the sake of our objectives we will remove this default route from the OSPF process and continue with our next task.

Notice that defaul-information is still configured under our OSPF process 1. We must delete out the default-information originate command.

We will configure area 1 as a totally stubby area now by going to R-3 and we will need to do some configuration on R-4 as well.

Notice our neighborship on R-3 goes down – this is due to our stub flag being mismatched so we much now go to R-4 and create the stub for Area 1. After this our neighborship will come back.

Now let’s verify with R-4’s routing table that we have a totally stubby area. Notice our O*IA route in the table.

For our next task we will remove our virtual-link’s from R-1 and R-2 and create an NSSA on Area 2.

We can now see we have N2 routes on R-2’s routing table. N2 routes tell OSPF routers to set the metric as the metric at the point of redistribution. N2 routes will occur for routers within the same area. If the routers are in different areas you will see E2 route in the routing table.

Now we will have the 4.4.4.4 network be displayed as a /24 instead of a /32 route on R-2’s routing table. We can do this by configuring out Loopback 0 interface as a point-to-point with OSPF.

Checking R-2’s routing table we will now see the 4 network as a /24.

Finally, we will configure link authentication between R-1 and R-2 using MD5. Notice that once we enable authentication on R-1’s side we eventually lose our neighborship.

To solve this issue we need to configure the same authentication on R-2’s link side.

Now we can see the neighborship has formed back up.