On Tue, Feb 11, 2003 at 10:16:39AM +0100, Stephane Bortzmeyer wrote:
> 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 :-}

Actually I can't see how this is wrong. If you have an entry in the routing
table, it's expected to be used :)

BTW, this would probably be better on the tech-net list.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--