I am struggling with the same problem, but it does not include the default route and gif interfaces, but instead any redistributed static route and gre interfaces across 2 locations.
The workaround mentioned earlier in this thread to remove the tunnel interfaces from ospfd.conf and instead placing the external interface does only account for a scenario where the 2 routers are local to each other. Is there any fix in the works for this problem? 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. > ---
