This tutorial looks into OSPF unnumbered serial links & the effects of using different ways to enable OSPF under an interface.
This post is somewhat lengthy so you may want to grab your beverage of choice before reading

There are 2 ways to enable OSPF to run on an interface:

• network … under ospf process
• ip ospf [process-id] area [area-id] … under interface

Minor exception between the 2 ways:

If an interface is unnumbered & there is a network statement that matches the IP address of the primary interface, both the primary interface & unnumbered interface will have OSPF enabled on them in the designated area, whereas with the ip ospf command, this would JUST enable ospf under the unnumbered interface.

Let’s do some tests with OSPF on unnumbered serial links.

Consider the following topology:

Configs:

With a debug ip ospf adj running on R4 (or R5) we see the following:

Observe also above that the area is 0.0.0.45.
This is because OSPF areas are actually 32-bit numbers, so when we specified area 45, IOS kindly translates that to the 32-bit no: 0.0.0.45.

Ok so lets configure IP Unnumbered:

As soon as we do the above, an OSPF adjacency is formed!

Now observe the output from sh ip ospf int brief:

Obvious statement: 0.0.0.0/0 is as a result of ip unnumbered on S0/1 interfaces

Now let’s add a network to Area 45 on R5, so that R4 will learn of it via R4 s0/1:

Checking R4 we should see an OSPF route for 45.45.45.45/32:

Now a problem we run into here, is that although we have a route for 45.45.45.45/32, it is not unreachable, as we do not know how to route to 5.5.5.5:

There are a number of ways we can resolve this issue:

1. Create a static route on R4 pointing to 5.5.5.5 out S0/1 <— CCIE Lab hates static routes
2. Advertise the loopback interfaces on R4 & R5 into OSPF.
3. Create a network statement for 4.4.4.4 on R4 & 5.5.5.5 on R5

As way is boring, let’s look at 2 & 3:

Advertise the loopback interfaces on R4 & R5 into OSPF

Now the thing to bear in mind here, is that we can use ANY area to advertise our loopbacks, as long as OSPF is advertising them.
To illustrate this, let’s put R4 lo1 in Area 400, and R5 lo1 in Area 500:

Now R4 has a route for R5s loopback, and R5 has an ospf route for R4s loopback, we should have reachability:

Cool!

Now onto Way 3:

Create a network statement for 4.4.4.4 on R4 & 5.5.5.5 on R5

This brings us to the key difference between using ip ospf x area y on an interface, & using the traditional network x.x.x.x, which is (quoting Internetwork Expert):

• If an interface is unnumbered & there is a network statement that matches the IP address of the primary interface, both the primary interface & unnumbered interface will have OSPF enabled on them in the desginated area, whereas with the ip ospf command, this would JUST enable ospf under the unnumbered interface

Ok so by this, we know that if we use the network statement, both the S0/1 and loopback interfaces will be advertised by OSPF, which will mean we will have reachability.

To illustrate this, we need to remove R4 lo1 from Area 400 and R5 lo1 from Area500.

Lets add the network statements under Area 45 (matching the area configured under the interfaces):

Now what happens when we use the above commands, is that OSPF is enabled on R4 lo1 and R5 lo1 in area 45.
OSPF is already enabled on R4 s0/1 & R5 s0/1 with the ip ospf 1 area 45 command, which takes priority over any network statements.

Note above that the route to 5.5.5.5 is an INTRA area route, as the network statement for 5.5.5.5 is also in area 45.

Now a final test here, is to change the network statements to be in a different area altogether.
Now, recall the statement made earlier that the ip ospf x ospf y command takes priority over the network command?
Lets put it to the test by making the network statement for R4 to be in area 400, and the network statement for R5 to be in area 500.

OK, rechecking, we see R4 now has an INTER AREA route for R5’s loopback, as R5’s loopback is in Area 500:

Finally, checking sh ip ospf int brief, we see that the network statement on R4: net 4.4.4.4 0.0.0.0 area 400, only results in putting the Lo1 in area 400, & NOT s0/1, which remains in area 45 (by virtue of the ip ospf 1 area 45 command):

Rack1R4#sh ip o int b Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C Se0/0        1     0               155.1.0.4/24       64    DR    1/1 Fa0/1        1     1               155.1.146.4/24     1     BDR   2/2 <————- R4 is the BDR on int f0/1 Rack1R4#conf t Enter configuration commands, one per line.  End with CNTL/Z. Rack1R4(config)#int f0/1 Rack1R4(config-if)#ip ospf priority 0 Rack1R4(config-if)#^Z Rack1R4#sh ip o int b Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C Se0/0        1     0               155.1.0.4/24       64    DR    1/1 Fa0/1        1     1               155.1.146.4/24     1     DROTH 2/2 <—- R4 is now a DROTHER on int f0/1