If I had to pick a favorite protocol, it would have to be OSPF. OSPF is badass. It does a million cool things, and because I am pretty Type-A OCD, I love how organized it is. How can the hierarchy and structure of OSPF not scratch the worst OCD itch?
It’s also kinda cranky and complicated sometimes, with some quirks that can cause some real hangups. One such quirk, which I have recently come across in my CCIE studies, is the Loopback network type. Loopback interfaces are not only functional to OSPF (and other protocols and network management systems) for a variety of reasons, they’re also useful to have in a lab environment. You can inject routes that wouldn’t otherwise be there by having a bunch of loopbacks. But this can introduce other problems into the environment without careful consideration.
OSPF has several different network types…Broadcast, Non-Broadcast, Point-to-Point, etc. Loopback is another network type, and just like the rest, certain kinds of interfaces will default to certain types. It is also a configurable value, just like the rest. An Ethernet interface, for example, may default to Broadcast, but it can be changed to Non-broadcast, or Point-to-Multipoint, or whatever fits your given scenario. It is no different with the loopback type, and in a few cases it is advisable.
One such case may be the advertisement of masks. Regardless of the mask length configured on a loopback interface, if the interface is left with the default network type of Loopback, the mask will be advertised as a /32 host route. So if the address of the loopback has a native mask of /24, it will appear in the routing table as a /32.
This is fine in most production cases, though it can cause problems with MPLS L3VPNs and label bindings when OSPF is used as the IGP on the backbone. In a lab scenario, this could be problematic if a loopback is the way certain routes are being injected and the expectation is that the native mask will be advertised. See the following example using Loopback10 on R2, advertised into Area 0 as a /24:
Topology
R2#sh run int loopback10
!
interface Loopback10
ip address 10.10.10.1 255.255.255.0
end
!
R2#sh ip ospf interface loopback0
Loopback0 is up, line protocol is up
Internet Address 150.1.2.2/24, Area 0
Process ID 1, Router ID 150.1.2.2, Network Type LOOPBACK, Cost: 1
Loopback interface is treated as a stub Host
!
R2#sh run | b router ospf 1
router ospf 1
router-id 150.1.2.2
log-adjacency-changes
network 10.10.10.0 0.0.0.255 area 0
network 150.1.2.2 0.0.0.0 area 0
network 155.1.0.2 0.0.0.0 area 0
network 155.1.23.2 0.0.0.0 area 0
!
Yet on R3, the route is in the table as a /32 host route, despite its native mask of /24:
R3#sh ip route 10.10.10.0
% Subnet not in table
!
R3#sh ip route 10.10.10.1
Routing entry for 10.10.10.1/32
Known via “ospf 1”, distance 110, metric 65, type intra area
Last update from 155.1.23.2 on Serial0/2/1, 00:07:18 ago
Routing Descriptor Blocks:
* 155.1.23.2, from 150.1.2.2, 00:07:18 ago, via Serial0/2/1
Route metric is 65, traffic share count is 1
!
If it is a requirement to advertise the native mask, one solution is to change the OSPF network type of the loopback interface. Here I used the Point-to-Point network type:
R2(config)#interface loopback10
R2(config-if)#ip ospf network point-to-point
R2(config-if)#exit
R2(config)#
!
R2#sh ip ospf interface loopback10
Loopback10 is up, line protocol is up
Internet Address 10.10.10.1/24, Area 0
Process ID 1, Router ID 150.1.2.2, Network Type POINT_TO_POINT, Cost: 1
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Supports Link-local Signaling (LLS)
Index 4/4, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
!
Now, on R3, the native mask appears in the routing table:
R3#sh ip route 10.10.10.0
Routing entry for 10.10.10.0/24
Known via “ospf 1”, distance 110, metric 65, type intra area
Last update from 155.1.23.2 on Serial0/2/1, 00:01:53 ago
Routing Descriptor Blocks:
* 155.1.23.2, from 150.1.2.2, 00:01:53 ago, via Serial0/2/1
Route metric is 65, traffic share count is 1
!
R3#sh ip route 10.10.10.1
Routing entry for 10.10.10.0/24
Known via “ospf 1”, distance 110, metric 65, type intra area
Last update from 155.1.23.2 on Serial0/2/1, 00:01:59 ago
Routing Descriptor Blocks:
* 155.1.23.2, from 150.1.2.2, 00:01:59 ago, via Serial0/2/1
Route metric is 65, traffic share count is 1
Nexiilicious 