What is so special about a loopback interface in OSPF? For example that we create a loopback9 – 9.9.9.9/32 and lo99 – 99.99.99.99/24 and make these addresses available throughout the OSPF domain.

There are two ways to make these addresses available throughout the OSPF domain.

The first one is to include this to the OSPF process as below

int lo9
 ip addr 9.9.9.9 255.255.255.255
 ip ospf 1 a 2
int lo99
 ip addr 99.99.99.99 255.255.255.0
 ip ospf 1 a 2
exit

or you can use the good-old network command

int lo9
 ip addr 9.9.9.9 255.255.255.255
int lo99
 ip addr 99.99.99.99 255.255.255.0
exit

router ospf 1
 net 9.9.9.9 0.0.0.0 a 2
 net 99.99.99.99 0.0.0.0 a 2
exit

Interestingly, we’re seeing a network type as LOOPBACK and it is treated as a stub host.

Rack1SW3#sh ip ospf int lo9
Loopback9 is up, line protocol is up
  Internet Address 9.9.9.9/32, Area 2
  Process ID 1, Router ID 150.1.9.9, Network Type LOOPBACK, Cost: 1
  Enabled by interface config, including secondary ip addresses
  Loopback interface is treated as a stub Host
Rack1SW3#sh ip ospf int lo99
Loopback99 is up, line protocol is up
  Internet Address 99.99.99.99/24, Area 2
  Process ID 1, Router ID 150.1.9.9, Network Type LOOPBACK, Cost: 1
  Enabled by interface config, including secondary ip addresses
  Loopback interface is treated as a stub Host

More interestingly, as we know that those addresses are advertised as stub, therefore we should see those addresses were advertised as /32 subnet.

Rack1R5(config-router)#do sh ip route 9.9.9.9
Routing entry for 9.9.9.9/32
  Known via "ospf 1", distance 110, metric 67, type inter area
  Last update from 155.1.0.3 on Serial0/0, 00:00:18 ago
  Routing Descriptor Blocks:
  * 155.1.0.3, from 150.1.3.3, 00:00:18 ago, via Serial0/0
      Route metric is 67, traffic share count is 1

Rack1R5(config-router)#do sh ip route 99.99.99.99
Routing entry for 99.99.99.99/32
  Known via "ospf 1", distance 110, metric 67, type inter area
  Last update from 155.1.0.3 on Serial0/0, 00:03:45 ago
  Routing Descriptor Blocks:
  * 155.1.0.3, from 150.1.3.3, 00:03:45 ago, via Serial0/0
      Route metric is 67, traffic share count is 1

NOTE. We can actually make 99.99.99.99/24 advertised as /24 by changing the OSPF network type as below

int lo99
 ip addr 99.99.99.99 255.255.255.0
 ip ospf network-type point-to-point
exit

Also, from the above result, we can see that the area type is Inter Area, which mean it is advertised as OSPF Inter Area

Rack1R5(config-router)#do sh ip route | i _9.
     99.0.0.0/32 is subnetted, 1 subnets
O IA    99.99.99.99 [110/67] via 155.1.0.3, 00:17:19, Serial0/0
     9.0.0.0/32 is subnetted, 1 subnets
O IA    9.9.9.9 [110/67] via 155.1.0.3, 00:13:57, Serial0/0

From the above examples, we know that:
1. OSPF network type loopback will be advertised as stub (/32), and
2. will have route type as inter area.

The second example to make these addresses available throughout the OSPF domain is to redistribute these addresses into OSPF process.

int lo9
 ip addr 9.9.9.9 255.255.255.255
int lo99
 ip addr 99.99.99.99 255.255.255.0
exit

router ospf 1
 redistribute connected subnets
exit

If we try to see whether these interfaces are in the OSPF process, that’s just not possible. The reason is that these two addresses is not actually included int the OSPF process yet we only redistribute it into OSPF process. Just like any other routing protocol that we redistribute into OSPF domain. Check out the example below.

Rack1SW3#sh ip ospf int lo9
%OSPF: OSPF not enabled on Loopback9
Rack1SW3#sh ip ospf int lo99
%OSPF: OSPF not enabled on Loopback99

However, remember that when we redistribute something into OSPF it will have:
1. LSA type 7, which will be injected by ASBR, and which eventually will be translated to

Rack1SW3#sh ip ospf d self-originate

            OSPF Router with ID (150.1.9.9) (Process ID 1)
<ommitted>…
		Type-7 AS External Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Tag
9.9.9.9         150.1.9.9       434         0x80000001 0x0063BB 0
99.99.99.0      150.1.9.9       434         0x80000001 0x000910 0
<ommitted>...

2. LSA type 5 by ABR.

Rack1R5#sh ip ospf d          

            OSPF Router with ID (150.1.5.5) (Process ID 1)
<ommitted>...
                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
9.9.9.9         150.1.6.6       588         0x80000001 0x001F10 0
99.99.99.0      150.1.6.6       599         0x80000001 0x00C464 0
<ommitted>...

3. Route type as External type 2 (E2), and it maintains its subnet information and metric (by default is 20).

Rack1R5#sh ip route 9.9.9.9
Routing entry for 9.9.9.9/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 67
  Last update from 155.1.0.3 on Serial0/0, 00:14:36 ago
  Routing Descriptor Blocks:
  * 155.1.0.3, from 150.1.6.6, 00:14:36 ago, via Serial0/0
      Route metric is 20, traffic share count is 1

Rack1R5#sh ip route 99.99.99.99
Routing entry for 99.99.99.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 67
  Last update from 155.1.0.3 on Serial0/0, 00:14:42 ago
  Routing Descriptor Blocks:
  * 155.1.0.3, from 150.1.6.6, 00:14:42 ago, via Serial0/0
      Route metric is 20, traffic share count is 1

Note. We can change this default behaviour E2 with command redistribute connected subnets metric-type 1 which, unlike E2, E1 will change its metric information every time it passes L3 device.