I have a point-to-point line (PPP over asynchronous serial) between
two Unix machines. Both machines run Zebra and establishes an OSPF
adjacency over the PtP line. It works fine.

But there is a strange side effect: the route for the *local*
interface now goes to a remote machine. Apparently, Linux ignores this
strange route (traceroute indicates that the packet stays local) but
NetBSD follows blindly the routing table.

RTA is a Linux and has router ID 10.4.100.2 and address 172.22.131.65
on the point-to-point link.

RTB is a NetBSD and has router ID 192.134.7.241 and address
172.22.131.64 on the point-to-point link.

The routes are strange (here, seen from RTA):

============ OSPF network routing table ============
N    10.4.200.0/25         [100] area: (0.0.0.0)
                           directly attached to eth0
N    172.22.131.64/32      [10000] area: (0.0.0.0)
                           directly attached to ppp0
N    172.22.131.65/32      [10110] area: (0.0.0.0)
                           via 10.4.200.1, eth0
...

172.22.131.65, RTA's own address, goes outside!

It ends up in Zebra's routing table:

O   172.22.131.64/32 [110/10000] is directly connected, ppp0, 00:16:14
C>* 172.22.131.64/32 is directly connected, ppp0
O>* 172.22.131.65/32 [110/10110] via 10.4.200.1, eth0, 00:12:38

But Linux does not use it:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.22.131.64   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
172.22.131.65   10.4.200.1      255.255.255.255 UGH   10110  0        0 eth0

traceroute to 172.22.131.65 (172.22.131.65), 30 hops max, 38 byte packets
 1  172.22.131.65 (172.22.131.65)  0.520 ms  0.253 ms  0.202 ms

On RTB, the NetBSD box, the routes are the same (both with "show ip
ospf route" and "show ip route"). The difference is that the indirect
route is actually used :-(

Destination        Gateway            Flags     Refs     Use    Mtu  Interface
172.22.131.64      192.134.7.245      UGH1        0        9      -  epic0
172.22.131.65      172.22.131.64      UH          0      195      -  ppp0

traceroute to 172.22.131.64 (172.22.131.64), 30 hops max, 40 byte packets
 1  192.134.7.245 (192.134.7.245)  0.692 ms  0.304 ms  0.229 ms
 2  10.4.200.2 (10.4.200.2)  0.819 ms  0.604 ms  0.590 ms
 3  172.22.131.64 (172.22.131.64)  4.947 ms  3.732 ms  3.709 ms

The issue is described into the John Moy's book: "OSPF: Anatomy of an
Internet Routing protocol", chapter 8, the section entitled: "Why is
the representation of point-to-point links in OSPF so strange ?"

Moy seems to imply that NetBSD, unlike Linux, is wrong. The case of a
router having a routing table entry for one of its addresses is
discussed by Moy and dismissed on the grounds that no machine is
stupid enough to forward a packet which is destined to one of its
interfaces. But NetBSD is :-}

rachel:~ % uname -a
NetBSD rachel 1.6 NetBSD 1.6 (RACHEL) #1: Fri Feb  7 10:46:47 CET 2003     root@rachel:/usr/src/sys/arch/i386/compile/RACHEL i386