Created attachment 112946 [details]
ospfd config file

I can confirm this problem in another environment.  I upgraded a RHEL3 system to 
RHEL4 yesterday (April 10th) and hit this exact problem.  The same ospfd config 
worked fine on RHEL3 and on RHEL4 after upgrading to the FC3 version of quagga, 
but with the quagga RPM that comes with RHEL4 all I get is a spinning processes 
that generates and ton of error logs that make little sense.

Definitely looks like this package needs a rebuild with this bugfix.

Later,
Tom

I've put updated quagga rpms up on 
http://people.redhat.com/fenlason/.quagga/quagga*-0.97.0-1.4E.1.*.rpm  Please 
try them out and confirm that they fix this problem.  Note that these are 
unsupported pre-release packages. 

I've tested:

http://people.redhat.com/fenlason/.quagga/quagga-0.97.0-1.4E.1.i386.rpm

with the same result (100% CPU usage on startup).

That's not good.  The 1.4E.1 ospfd starts up OK for me, using the config file 
you attached.  I guess we'll have to isolate what's different between our two 
setups so I can reproduce the problem here.  How many interfaces do you have 
in your Quagga test box, what types are they, etc? 

I have two Ethernet interfaces each with two configured IPs. The primary IP on
each interface is in the 192.168.76.0/24 range. I've been testing the same setup
successfully on FC3 the last couple of weeks.

To be fair, the 100% CPU usage now only kicks in after a few seconds. Here is
some output with "debug ospf event" on:

...
2005/04/30 01:12:23 OSPF: ospf_ia_routing():start
2005/04/30 01:12:23 OSPF: ospf_ia_routing():not ABR, considering all areas
2005/04/30 01:12:23 OSPF: Pruning unreachable networks
2005/04/30 01:12:23 OSPF: Pruning unreachable routers
2005/04/30 01:12:23 OSPF: SPF: calculation complete
2005/04/30 01:12:23 OSPF: Timer[router-LSA]: (router-LSA Refresh expire)
2005/04/30 01:12:23 OSPF: counting fully adjacent virtual neighbors in area 0.0.0.0
2005/04/30 01:12:23 OSPF: there are 0 of them
2005/04/30 01:12:23 OSPF: ospf_flood_through_interface(): considering int
eth0:192.168.76.5, INBR(NULL), LSA[Type1,id(10.0.1.201),ar(10.0.1.201)]
2005/04/30 01:12:23 OSPF: ospf_flood_through_interface(): considering nbr
10.0.1.201 (2-Way)
2005/04/30 01:12:23 OSPF: ospf_flood_through_interface(): considering int
eth1:192.168.76.9, INBR(NULL), LSA[Type1,id(10.0.1.201),ar(10.0.1.201)]
2005/04/30 01:12:23 OSPF: ospf_flood_through_interface(): considering nbr
10.0.1.201 (2-Way)
2005/04/30 01:12:23 OSPF: Timer[router-LSA]: (router-LSA Refresh expire)
2005/04/30 01:12:23 OSPF: counting fully adjacent virtual neighbors in area 0.0.0.0
2005/04/30 01:12:23 OSPF: there are 0 of them
2005/04/30 01:12:23 OSPF: ospf_flood_through_interface(): considering int
eth0:192.168.76.5, INBR(NULL), LSA[Type1,id(10.0.1.201),ar(10.0.1.201)]
2005/04/30 01:12:23 OSPF: ospf_flood_through_interface(): considering nbr
10.0.1.201 (2-Way)
2005/04/30 01:12:23 OSPF: ospf_flood_through_interface(): considering int
eth1:192.168.76.9, INBR(NULL), LSA[Type1,id(10.0.1.201),ar(10.0.1.201)]
2005/04/30 01:12:23 OSPF: ospf_flood_through_interface(): considering nbr
10.0.1.201 (2-Way)
2005/04/30 01:12:23 OSPF: Timer[router-LSA]: (router-LSA Refresh expire)
2005/04/30 01:12:23 OSPF: counting fully adjacent virtual neighbors in area 0.0.0.0
2005/04/30 01:12:23 OSPF: there are 0 of them

... ad infinitum.

I am having the exact same problem of 100% CPU usage except with bgpd rather 
than ospfd on 2 RH-ES 4 machines with the following rpms installed: 

quagga-0.97.0-1.i386.rpm 
quagga-devel-0.97.0-1.i386.rpm

This is a pre-production environment with no active bgp neighbor sessions.

Removing the above rpms and installing quagga-0.97.3-1.FC3.i386.rpm from the 
Fedora 3 base corrects the problem. 

Also had the same problem after an upgrade to RHEL4. Installing the FC3 RPMs
solved the problem.

I had the same problem with ospfd and RHEL4.  The RPMS from comment #3 did not
resolve the problem.  Installing FC3 quagga rpms did.

Contact your Red Hat support person.  I have updated packages for RHEL-4, but 
I haven't been able to release them because this isn't listed as being a 
customer issue.  Once we have some support calls logged against this, there'll 
be a better chance of it making it into an update. 

What version would that updated package be (if we may know ;-))?  0.97.3 or one
of the 0.98.x versions (as rawhide now has 0.98.5)?

It's surprising me a bit that RH does not solve known, serious bugs, even if
these bugs are listed in bugzilla, unless customers complain via other ways.  I
have  seen this with more packages/bugs, containing bugs that are solved in
Fedora long ago.

(In reply to comment #16)
> Contact your Red Hat support person.
Can you do that with basic ES support? According to the web site
(https://www.redhat.com/software/rhel/compare/server/) not after the first 30 
days. 

RH needs to get it in gear or they will be loosing my business. This is a 
problem that has been known about for a long time. There is an update that has 
been available for a long time that resolves the problem. I have paid to 
receive updates. RH has not released the update for 6 months. I have had to 
diagnose the problem and correct it myself. I have had the same problem with 
the RHEL squid package where a long known problem has been fixed long ago by 
the authors, but no update has been release by Red Hat. So what does paying for 
a Red Hat subscription get you? So far, all I see is poor service and pathetic 
beaureucratic execuses. Maybe we should call the Better Business Bureau 
(www.bbb.org)instead.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2006-0083.html