Hello David
This behavior is due to the fact that OSPF views the point-to-multipoint topology as a series of point-to-point links. Since these links are point-to-point, then by definition, there can only be a single host on the other end of that link. Therefore, it saves time and resources to advertise these routes to neighbors using the most specific subnet possible which is /32, indicating a host route.
This behavior is more efficient, especially in topologies that use underlying point-to-multipoint technologies such as Frame-Relay and DMVPN (typically in hub and spoke topologies). This way, direct point-to-point communication with a particular spoke is more efficiently achieved, rather than sending traffic into a broadcast or pseudo-broadcast network segment.
I went in and labbed this up and tried to create a point to multipoint network type on an Ethernet link between two OSPF routers. I get the following in the routing table:
R2#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 192.168.12.1, 00:00:06, GigabitEthernet0/1
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
192.168.12.0/24 is variably subnetted, 3 subnets, 2 masks
C 192.168.12.0/24 is directly connected, GigabitEthernet0/1
O 192.168.12.1/32
[110/1] via 192.168.12.1, 00:00:06, GigabitEthernet0/1
L 192.168.12.2/32 is directly connected, GigabitEthernet0/1
Note that you get the directly connected network of 192.168.12.0/24, but you also get the OSPF-learned route of 192.168.12.1/32. Since the latter is more specific, any packets destined for 192.168.12.1 will use that routing entry while any other destination in the subnet will use the directly connected entry. The result is the same of course when using Ethernet, but it’s interesting how OSPF adds an extra route in this case.
(BTW, this should not be done in a production network. Ethernet links should use the default broadcast type for optimal operation with OSPF. I did this only for the purpose of understanding the behavior.)
I hope this has been helpful!
Laz