OSPF loading State

[Ryan Whelan]

I'm having prolonged 'loading' state issues again.  It only seems to happen
on a single side of the relationship; one side says its 'full' and the
other sticks to 'loading' for about 30 minutes.  Im using version 1.3.4.
The 2 hosts are communicating over an OpenVPN link but its only with some
openvpn clients :-/

I have a tcpdump and debug logs if someone would like to see them.

I'm not quite sure what to do to address it

On Wed, Aug 3, 2011 at 1:22 PM, Ryan Whelan <rcwhelan at gmail.com> wrote:

> On Tue, Aug 2, 2011 at 4:44 AM, Ondrej Zajicek <santiago at crfreenet.org>
> wrote:
> > On Mon, Aug 01, 2011 at 10:57:01PM -0400, Ryan Whelan wrote:
> >>    I'm now having this issue with a new device and its chronic.  It
> goes into
> >>    'loading' every time bird starts without fail and does not seem to
> ever
> >>    fully peer.  One end of the tunnel is in 'full', with the other
> contently
> >>    in 'loading'; no routing information gets exchanged.  I'm not really
> sure
> >>    how to trouble shoot the issue, I tried removing the security and
> other
> >>    static protocols to no avail.
> >
> > If it is a permanent problem, it could be be easily debugged. But in the
> > past, permanent problems with the same manifestation showed to be some
> > some different problems, usually with the interface (like mismatching
> MTUs)
> >
> >>    I have logs and tcpdumps if anyone is interested- assuming this is a
> bug
> >>    and I'm not doing something wrong.
> >
> > Could you send me these? For BIRD logs, i would be useful to have logs
> > with enabled 'debug { events, packets }' for OSPF on both sides.
> >
> >>    The only difference between this PtP link and the others I've setup,
> is
> >>    this link is a tunnel setup with OpenVPN instead of IPSec.  In the
> past
> >>    I've used Bird with Quagga over OpenVPN links, so I wouldn't assume
> thats
> >>    the issue?
> >
> > Shouldn't be. But OpenVPN is a strange beast, perhaps it has some
> > strange behavior to packets. One possible change in BIRD is that packets
> > for PTP ifaces were sent to unicast IP in the past but it was changed to
> > allrouters-multicast IP (to be consistent with standard). If OpenVPN
> > have some problems with multicast, that may be the problem.
> > In that case the solution would be to switch the iface type to PTMP.
> >
> > --
> > Elen sila lumenn' omentielvo
> >
> > Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
> > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
> > "To err is human -- to blame it on a computer is even more so."
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iEYEARECAAYFAk43uQQACgkQw1GB2RHercOx+ACfXdhSYbpafaSiuHuk3EwI2MwX
> > DeoAnjh6zb9E2mC/zvGeO3Bi8iu6te9a
> > =Odkl
> > -----END PGP SIGNATURE-----
> >
> >
>
> Upon trying again, I am unable to get it to go into the loading state.
> When I posted my last message on the list, I had a peer that would go
> in to loading, and regardless of which bird instance I restarted, in
> any order, it refused to move to state full.  The next day I was
> unable to reproduce it consistently.  The only difference I can think
> of (and I don't know for sure) is on the opposite peer from the one
> that was stuck in loading, I had an interface in the bird config that
> was not up on the system.  I can't be sure as I don't recall, but
> that's the only thing I can think of that might have changed from one
> day to the next.
>
> I apologise for 'crying wolf', but for a couple hours it really was a
> chronic issue. Sorry I can't be of more help on this.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20120105/255499d1/attachment.html>