I am struggling with the same problem, but it does not only include the default route and gif interfaces, but also any redistributed static route and gre interfaces. The workaround mentioned earlier in this thread to remove the tunnel interfaces from ospfd.conf and instead placing the external interface implies that ospf on both boxes communicates directly and therefore makes any tunnel unnecessary. This is not possible in a production environment where traffic between 2 locations flows across gre tunnels which use ipsec transport for encryption.
Thank you for looking into this, Sebastian On Fri, May 6, 2011 at 9:25 AM, Ross Alexander <[email protected]> wrote: > The following reply was made to PR system/6597; it has been noted by GNATS. > > From: Ross Alexander <[email protected]> > To: Claudio Jeker <[email protected]> > Cc: [email protected] > Subject: Re: system/6597: ospf can't propagate IPv4 default route across a > GIF interface > Date: Fri, 06 May 2011 10:05:56 -0600 (MDT) > > On Fri, 6 May 2011, Claudio Jeker wrote: > > > Hi Ross, > > > > thanks for the detailed bug report. > > Claudio, > > My pleasure. It's been a while, hope you and Reyk are well? Your > work has stood up very well over the last few years. We're a full AS > now, #16580. It has been a lot of fun. > > >>> Synopsis: default IPv4 route does not install on ospf client linked > via GIF interfaces > > >> 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 > > > > 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. > > I'll play around with 'ifconfig lladdr' before the GIF bringups and > see if that isn't the fix. Tnx. > > >> 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). > > FWIW, I googled around on "send_rtmsg: action 1" "Network is unreachable" > and > saw a note (from you ;) WRT an IPv6 ospfd bug that was very similar. > > > I will look into this > > My thanks, and your efforts are greatly appreciated. If you'd like to > charge for some consulting time, I can start the wheels turning at > this end. BTW, this is all around moving up to 4.8 from 4.5 (we got > stuck there for a long time, there were other fires burning hotter.) > I presume the fixes will run on 4.9 as well? Just let me know. > > regards, > Ross > -- > Ross Alexander, (780) 675-6823 desk / (780) 689-0749 cell, > [email protected] > > "Always do right. This will gratify some people, > and astound the rest." -- Samuel Clemens > > __ > This communication is intended for the use of the recipient to whom it > is addressed, and may contain confidential, personal, and or privileged > information. Please contact us immediately if you are not the intended > recipient of this communication, and do not copy, distribute, or take > action relying on it. Any communications received in error, or > subsequent reply, should be deleted or destroyed. > ---
