CCIE TO BE

For OSPF point-to-multipoint networks, host routes to the neighbors will exist in the route table
It is unusual, but as designed.

Notice the last two routes:

R6#show ip route | inc /32
2.0.0.0/32 is subnetted, 1 subnets
3.0.0.0/32 is subnetted, 1 subnets
4.0.0.0/32 is subnetted, 1 subnets
5.0.0.0/32 is subnetted, 1 subnets
6.0.0.0/32 is subnetted, 1 subnets
O 172.12.45.5/32 [110/64] via 172.12.45.5, 00:34:42, Serial1/1
O 172.12.45.4/32 [110/64] via 172.12.45.4, 00:34:42, Serial1/1

These are addresses of OSPF neighbors:

R6#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
4.4.4.4 0 FULL/ - 00:01:37 172.12.45.4 Serial1/1
5.5.5.5 0 FULL/ - 00:01:37 172.12.45.5 Serial1/1
R6#

The host route is described in the router LSA for the advertising router:
(see 3rd entry)

R6#show ip ospf database router 4.4.4.4

OSPF Router with ID (6.6.6.6) (Process ID 1)

Router Link States (Area 0)

Routing Bit Set on this LSA
LS age: 889
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 4.4.4.4
Advertising Router: 4.4.4.4
LS Seq Number: 80000004
Checksum: 0x7CEA
Length: 72
Area Border Router
Number of Links: 4

Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 5.5.5.5
(Link Data) Router Interface address: 172.12.45.4
Number of TOS metrics: 0
TOS 0 Metrics: 64

Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 6.6.6.6
(Link Data) Router Interface address: 172.12.45.4
Number of TOS metrics: 0
TOS 0 Metrics: 64

Link connected to: a Stub Network
(Link ID) Network/subnet number: 172.12.45.4
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 0

Link connected to: a Stub Network
(Link ID) Network/subnet number: 4.4.4.4
(Link Data) Network Mask: 255.255.255.255
Number of TOS metrics: 0
TOS 0 Metrics: 1

The link is a stub network, however stub networks (not to be confused with stub areas) are usually only for links without OSPF neighbors.

Why are these host routes necessary?

Not really sure right now, but it is per RFC 2328, section 12.4.1.4.

Scenario:
Full mesh of PVCs between 3 routers: R4 R5 and R6
Frame-relay map statements DO NOT have broadcast statement
Adjacencies do not form.

This is from debug ip packet on R6:

R6#debug ip packet
IP packet debugging is on
*Mar 1 01:00:26.367: IP: s=172.12.45.6 (local), d=224.0.0.5 (Serial1/1), len 76, sending broad/multicast
*Mar 1 01:00:26.371: IP: s=172.12.45.6 (local), d=224.0.0.5 (Serial1/1), len 76, encapsulation failed

After enabling broadcast on the frame maps, adjacencies came up

Solution:
Point-to-multipoint ospf networks need broadcast keyword on frame-relay map.
Without it you will see "encapsulation failed" when the router tries to send multicast hellos.

Atom

Atom