The following reply was made to PR system/6597; it has been noted by GNATS.
From: Claudio Jeker <[email protected]> To: Ross Alexander <[email protected]> Cc: [email protected] Subject: Re: system/6597: ospf can't propagate IPv4 default route across a GIF interface Date: Fri, 6 May 2011 12:22:16 +0200 Hi Ross, thanks for the detailed bug report. On Thu, Apr 28, 2011 at 01:18:55PM -0600, Ross Alexander wrote: > >Number: 6597 > >Category: system > >Synopsis: default IPv4 route does not install on ospf client linked > >via GIF interfaces > >Confidential: yes > >Severity: serious > >Priority: medium > >Responsible: bugs > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: unknown > >Arrival-Date: Thu Apr 28 19:30:02 GMT 2011 > >Closed-Date: > >Last-Modified: > >Originator: > >Release: > >Organization: > >Environment: > > System : OpenBSD 4.8 > Details : OpenBSD 4.8 (GENERIC) #0: Thu Apr 21 00:11:28 MDT 2011 > > [email protected]:/usr/src/sys/arch/i386/compile/GENERIC > Architecture: OpenBSD.i386 > Machine : i386 > ... > > >Description: > > Consider two nets (192.168.2/24 and 192.168.4/24 for concreteness) > routed via two 4.8 i386 systems (details as above); between the > two routing hosts there is an auxiliary network: 172.16.16/28. > I will call the hosts LEFT and RIGHT. Crude ascii art: > > 192.168.2/24 <--> (192.168.2.10) em0 > [LEFT] > em1 (172.16.16.1) > | > em0 (172.16.16.2) > [RIGHT] > 192.168.4/24 <--> (192.168.2.250) em1 > ... > BTW, I am seeing this on RIGHT: > > gif1: DAD detected duplicate IPv6 address > fe80:0007::0a00:27ff:fe0e:734e: NS in/out=0/1, NA in=1 > gif1: DAD complete for fe80:0007::0a00:27ff:fe0e:734e - duplicate > found > gif1: manual intervention required > What's *that* about, I wonder? But it's an IPv6 thing, and this is > strictly an IPv4 bug report. This seems to be a problem with the virtual machines all having the same mac addrs on their interfaces. Since gif(4) does not have a mac the stack uses the mac of the first interface. ... > However, on RIGHT not so good; first we see in /var/log/daemon as > follows: > > Apr 28 10:21:07 right ospfd[22673]: startup > Apr 28 10:21:24 right ospfd[22673]: send_rtmsg: action 1, > prefix 0.0.0.0/0: Network is unreachable > This is the actual problem. For some reason the nexthop is not properly resolved to 172.31.1.1. There is a difference between P2P and broadcast interfaces (the latter have a network LSA were the nexthop lookup succeeds). I will look into this -- :wq Claudio
