Bug 154400 - ospfd consumes 100% CPU on startup
ospfd consumes 100% CPU on startup
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: quagga (Show other bugs)
4.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
:
Depends On:
Blocks: 168429
  Show dependency treegraph
 
Reported: 2005-04-11 10:28 EDT by Robert Clark
Modified: 2014-08-31 19:27 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHEA-2006-0083
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-07 13:10:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ospfd config file (88 bytes, text/plain)
2005-04-11 10:28 EDT, Robert Clark
no flags Details

  None (edit)
Description Robert Clark 2005-04-11 10:28:34 EDT
On startup with the attached minimal config file, ospfd consumes as much CPU as
it can. This is with quagga-0.97.0-1. As far as I can tell ospfd isn't usable on
RHEL4 at the moment.

This is probably related to #140913 which was fixed in FC3 by updating to
quagga-0.97.3-1.FC3.
Comment 1 Robert Clark 2005-04-11 10:28:34 EDT
Created attachment 112946 [details]
ospfd config file
Comment 2 Tom Sightler 2005-04-11 13:57:35 EDT
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
Comment 3 Jay Fenlason 2005-04-25 16:22:33 EDT
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. 
Comment 4 Robert Clark 2005-04-29 06:55:08 EDT
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).
Comment 5 Jay Fenlason 2005-04-29 16:17:59 EDT
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? 
Comment 6 Robert Clark 2005-04-29 19:41:14 EDT
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.
Comment 8 rambler8 2005-06-01 17:25:32 EDT
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. 
Comment 13 Graham Leggett 2005-09-30 03:05:59 EDT
Also had the same problem after an upgrade to RHEL4. Installing the FC3 RPMs
solved the problem.
Comment 14 Jacob Leaver 2005-10-05 14:21:18 EDT
I had the same problem with ospfd and RHEL4.  The RPMS from comment #3 did not
resolve the problem.  Installing FC3 quagga rpms did.
Comment 16 Jay Fenlason 2005-10-05 14:35:37 EDT
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. 
Comment 17 Jos Vos 2005-10-05 16:11:21 EDT
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.
Comment 18 rambler8 2005-10-06 03:31:19 EDT
(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.
Comment 24 Red Hat Bugzilla 2006-03-07 13:10:53 EST
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

Note You need to log in before you can comment on or make changes to this bug.