I have 2 linux machines connected to one another over the internet via a IPSec protected GRE tunnel. Each of them are running OSPF from bird 1.3.2. The issue is that one of them will not fully peer with the other, unless the other is started after the one with the issue. Is just stays in state 'loading' while the other machine will be in state 'full'. In other words, node 2 will only go to state 'full' if node 1 is started after node 2. If node 2 is started after node 1, it will sit in state 'loading' forever. Node 1 has no issues. Here is a log from the node that is failing to sync up (node 2): http://pastebin.com/ZjVcc1wB bird> show ospf neighbors axa0: Router ID Pri State DTime Interface Router IP 111.222.333.444 1 loading/ptp 00:13 tun10 172.31.255.255 bird> the config on both machines is identical protocol kernel { learn;; persist; scan time 20; export all; } protocol device { scan time 10; } protocol static { } protocol ospf axa0 { tick 1; rfc1583compat yes; area 0.0.0.0 { stub no; interface "tun*" { hello 5; retransmit 5; cost 10; transmit delay 5; dead 15; wait 50; type ptp; }; }; }
On Thu, Jul 21, 2011 at 12:05 PM, Ryan Whelan <rcwhelan@gmail.com> wrote:
I have 2 linux machines connected to one another over the internet via a IPSec protected GRE tunnel. Each of them are running OSPF from bird 1.3.2.
The issue is that one of them will not fully peer with the other, unless the other is started after the one with the issue. Is just stays in state 'loading' while the other machine will be in state 'full'. In other words, node 2 will only go to state 'full' if node 1 is started after node 2. If node 2 is started after node 1, it will sit in state 'loading' forever. Node 1 has no issues.
Here is a log from the node that is failing to sync up (node 2): http://pastebin.com/ZjVcc1wB
bird> show ospf neighbors axa0: Router ID Pri State DTime Interface Router IP 111.222.333.444 1 loading/ptp 00:13 tun10 172.31.255.255 bird>
the config on both machines is identical
protocol kernel { learn;; persist; scan time 20; export all; }
protocol device { scan time 10; }
protocol static { }
protocol ospf axa0 { tick 1; rfc1583compat yes; area 0.0.0.0 { stub no; interface "tun*" { hello 5; retransmit 5; cost 10; transmit delay 5; dead 15; wait 50; type ptp; }; }; }
If it means anything, the machine that was stuck in 'loading' changed to 'full' after I left it alone, but it took about 30 minutes. Is that expected behaviour?
We have similar issues but looks that it get fixed when you take newest svn version. BUT you get new problem that some times some routes does not sync and you need restart bird =) 21.7.2011 23:39, Ryan Whelan kirjoitti:
On Thu, Jul 21, 2011 at 12:05 PM, Ryan Whelan<rcwhelan@gmail.com> wrote:
I have 2 linux machines connected to one another over the internet via a IPSec protected GRE tunnel. Each of them are running OSPF from bird 1.3.2.
The issue is that one of them will not fully peer with the other, unless the other is started after the one with the issue. Is just stays in state 'loading' while the other machine will be in state 'full'. In other words, node 2 will only go to state 'full' if node 1 is started after node 2. If node 2 is started after node 1, it will sit in state 'loading' forever. Node 1 has no issues.
Here is a log from the node that is failing to sync up (node 2): http://pastebin.com/ZjVcc1wB
bird> show ospf neighbors axa0: Router ID Pri State DTime Interface Router IP 111.222.333.444 1 loading/ptp 00:13 tun10 172.31.255.255 bird>
the config on both machines is identical
protocol kernel { learn;; persist; scan time 20; export all; }
protocol device { scan time 10; }
protocol static { }
protocol ospf axa0 { tick 1; rfc1583compat yes; area 0.0.0.0 { stub no; interface "tun*" { hello 5; retransmit 5; cost 10; transmit delay 5; dead 15; wait 50; type ptp; }; }; }
If it means anything, the machine that was stuck in 'loading' changed to 'full' after I left it alone, but it took about 30 minutes. Is that expected behaviour?
-- F-Solutions Oy Tapio Haapala PL 7, 90571 Oulu GSM 040-0998371 Skype burner- IRC Burner@ircnet
On Fri, Jul 22, 2011 at 3:37 AM, Tapio Haapala <tapio.haapala@f-solutions.fi> wrote:
We have similar issues but looks that it get fixed when you take newest svn version. BUT you get new problem that some times some routes does not sync and you need restart bird =)
Alright, well as long as its a known bug i can work around it for now. Still rather use bird than quagga if i can get away with it
21.7.2011 23:39, Ryan Whelan kirjoitti:
On Thu, Jul 21, 2011 at 12:05 PM, Ryan Whelan<rcwhelan@gmail.com> wrote:
I have 2 linux machines connected to one another over the internet via a IPSec protected GRE tunnel. Each of them are running OSPF from bird 1.3.2.
The issue is that one of them will not fully peer with the other, unless the other is started after the one with the issue. Is just stays in state 'loading' while the other machine will be in state 'full'. In other words, node 2 will only go to state 'full' if node 1 is started after node 2. If node 2 is started after node 1, it will sit in state 'loading' forever. Node 1 has no issues.
Here is a log from the node that is failing to sync up (node 2): http://pastebin.com/ZjVcc1wB
bird> show ospf neighbors axa0: Router ID Pri State DTime Interface Router IP 111.222.333.444 1 loading/ptp 00:13 tun10 172.31.255.255 bird>
the config on both machines is identical
protocol kernel { learn;; persist; scan time 20; export all; }
protocol device { scan time 10; }
protocol static { }
protocol ospf axa0 { tick 1; rfc1583compat yes; area 0.0.0.0 { stub no; interface "tun*" { hello 5; retransmit 5; cost 10; transmit delay 5; dead 15; wait 50; type ptp; }; }; }
If it means anything, the machine that was stuck in 'loading' changed to 'full' after I left it alone, but it took about 30 minutes. Is that expected behaviour?
-- F-Solutions Oy
Tapio Haapala
PL 7, 90571 Oulu GSM 040-0998371 Skype burner- IRC Burner@ircnet
On Thu, Jul 21, 2011 at 04:39:17PM -0400, Ryan Whelan wrote:
If it means anything, the machine that was stuck in 'loading' changed to 'full' after I left it alone, but it took about 30 minutes. Is that expected behaviour?
This is known bug, it happens rarely (at least in my setting). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
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. I have logs and tcpdumps if anyone is interested- assuming this is a bug and I'm not doing something wrong. 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? Any suggestions/direction would be much appropriated. I'd really love to standardize with bird. On Mon, Jul 25, 2011 at 2:10 AM, Ondrej Zajicek <santiago@crfreenet.org>wrote:
On Thu, Jul 21, 2011 at 04:39:17PM -0400, Ryan Whelan wrote:
If it means anything, the machine that was stuck in 'loading' changed to 'full' after I left it alone, but it took about 30 minutes. Is that expected behaviour?
This is known bug, it happens rarely (at least in my setting).
-- Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@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)
iEYEARECAAYFAk4tCMEACgkQw1GB2RHercPhngCfRHgf5gRTS0n5Tx1b8JMN6FjA KCkAnjAVEbkqWHhVX1c28c6aq0SIee4q =e2Kb -----END PGP SIGNATURE-----
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@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."
For me this looks just same problem what is on newest release but it if fixed on svn version. This cause that release was on our network totally unusable. Nasty thing on this bug is also that it goes trought network like domino effect, so some times you must restart ~10 routers before you get all loading hangs away. Try restart both side birds and if it does not help do it on different order. If that helps it is probaply same bug. Try compile new version from svn and if it helps just hope that new release coming soon :) One thing is also that try tcpdump your traffic on both sides and look if you bird try communitace with multicast but tunnel eats it. looks that bird does not order multicast with igmp so some switches can eat that traffic. 2.8.2011 11:44, Ondrej Zajicek kirjoitti:
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.
-- F-Solutions Oy Tapio Haapala PL 7, 90571 Oulu GSM 040-0998371 Skype burner- IRC Burner@ircnet
On Tue, Aug 02, 2011 at 12:03:56PM +0300, Tapio Haapala wrote:
For me this looks just same problem what is on newest release but it if fixed on svn version. This cause that release was on our network totally unusable. Nasty thing on this bug is also that it goes trought network like domino effect, so some times you must restart ~10 routers before you get all loading hangs away.
This seems like some confusion. There is nothing currently commited in GIT (we do not use SVN) related to such bug which is newer than latest release (v1.3.2). With which release do you have the problem? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
I am wery sorry. Looks that this new version has released 7 days after we compile svn version :) So no need to wait any more. Bug was on 1.3.1 2.8.2011 13:47, Ondrej Zajicek kirjoitti:
On Tue, Aug 02, 2011 at 12:03:56PM +0300, Tapio Haapala wrote:
For me this looks just same problem what is on newest release but it if fixed on svn version. This cause that release was on our network totally unusable. Nasty thing on this bug is also that it goes trought network like domino effect, so some times you must restart ~10 routers before you get all loading hangs away. This seems like some confusion. There is nothing currently commited in GIT (we do not use SVN) related to such bug which is newer than latest release (v1.3.2). With which release do you have the problem?
-- Kaikki viestissä ilmoitetut summat ovat alvittomia, ellei toisin ole kyseisen summan yhteydessä ilmoitettu. -- F-Solutions Oy Tapio Haapala PL 7, 90571 Oulu GSM 040-0998371 Skype burner- IRC Burner@ircnet
On Tue, Aug 2, 2011 at 4:44 AM, Ondrej Zajicek <santiago@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@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.
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@gmail.com> wrote:
On Tue, Aug 2, 2011 at 4:44 AM, Ondrej Zajicek <santiago@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@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.
On Thu, Jan 05, 2012 at 07:50:02PM -0500, Ryan Whelan wrote:
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.
If you could send me these i would look at it. To be useful, logs should be from both sides, tcpdump ones acquired with '-s 0' option. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
Pleas notify us if you find solution for that Ryans's problem. We have this same problem but with new version it is so random that we havent manage to capture it to tcp dump. It can be releated to huge ammout of routes or to /32 routes. Maybe network problem on some point of loading routes. Also we have problem that some times we lost some of /32 routes and when we restart bird they come back. We try get more debug info for that because it is quite impossible to fix with current "it do sometimes something" information :) 6.1.2012 12:57, Ondrej Zajicek kirjoitti:
On Thu, Jan 05, 2012 at 07:50:02PM -0500, Ryan Whelan wrote:
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.
If you could send me these i would look at it. To be useful, logs should be from both sides, tcpdump ones acquired with '-s 0' option.
-- F-Solutions Oy Tapio Haapala PL 7, 90571 Oulu GSM 040-0998371 Skype burner- IRC Burner@ircnet
On Thu, Jan 05, 2012 at 07:50:02PM -0500, Ryan Whelan wrote:
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 :-/
There is one patch in current GIT that fixes some instances of such problem. You can try the patch (attached), or wait for a new version of BIRD, which is expected to be released in a few days. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
Running bird 1.3.4 on freebsd 8.2 At what seems like random times one of my bird boxes starts spewing the following to the log file, followed by one of my Cisco 6500s becoming randomly unpredictable. The router and routes that are being complained about are half way around the world, and the link has been down for ~2 hours in this case. None of the other bird instances has this issue. Sorry no debug or tcpdump at this time. Any ideas, known issues? Jan 9 06:59:02 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.201, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:02 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: 10.8.0.0, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:02 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.198, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:02 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.253, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:02 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.254, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:07 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.201, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:07 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: 10.8.0.0, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:07 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.198, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:07 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.253, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:07 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.254, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:12 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.201, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:12 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: 10.8.0.0, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:12 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.198, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:12 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.253, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:12 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.254, Rt: <ip xx.yy.zz>.201) Jan 9 06:59:17 <hostName> bird: OSPF: LSA disappeared (Type: 0005, Id: <ip xx.yy.zz>.201, Rt: 208.91.16
On Thu, Jul 21, 2011 at 04:39:17PM -0400, Ryan Whelan wrote:
protocol ospf axa0 { tick 1; rfc1583compat yes;
BTW, do you really need rfc1583compat? Generally, it is a legacy option just for compatibility with some really old OSPF implementation and is not recommended to be used. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@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."
On Mon, Jul 25, 2011 at 2:27 AM, Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Thu, Jul 21, 2011 at 04:39:17PM -0400, Ryan Whelan wrote:
protocol ospf axa0 { tick 1; rfc1583compat yes;
BTW, do you really need rfc1583compat? Generally, it is a legacy option just for compatibility with some really old OSPF implementation and is not recommended to be used.
No, it came as part of the default config so I didn't change it. I will remove it any see if it makes a difference.
-- Elen sila lumenn' omentielvo
Ondrej 'SanTiago' Zajicek (email: santiago@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)
iEYEARECAAYFAk4tDM4ACgkQw1GB2RHercO21wCfRIIjt5fZ67elP0RXtCbB6BX0 WP8An0qInFn/XLyIwet17ob+NGCQx5te =kT+X -----END PGP SIGNATURE-----
participants (4)
-
harold barker -
Ondrej Zajicek -
Ryan Whelan -
Tapio Haapala