Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154400 - ospfd consumes 100% CPU on startup
Summary: ospfd consumes 100% CPU on startup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: quagga
Version: 4.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Jay Fenlason
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 168429
TreeView+ depends on / blocked
 
Reported: 2005-04-11 14:28 UTC by Robert Clark
Modified: 2014-08-31 23:27 UTC (History)
5 users (show)

Fixed In Version: RHEA-2006-0083
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-07 18:10:53 UTC


Attachments (Terms of Use)
ospfd config file (deleted)
2005-04-11 14:28 UTC, Robert Clark
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2006:0083 normal SHIPPED_LIVE quagga enhancement update 2006-03-06 05:00:00 UTC

Description Robert Clark 2005-04-11 14:28:34 UTC
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 14:28:34 UTC
Created attachment 112946 [details]
ospfd config file

Comment 2 Tom Sightler 2005-04-11 17:57:35 UTC
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 20:22:33 UTC
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 10:55:08 UTC
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 20:17:59 UTC
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 23:41:14 UTC
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 21:25:32 UTC
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 07:05:59 UTC
Also had the same problem after an upgrade to RHEL4. Installing the FC3 RPMs
solved the problem.


Comment 14 Jacob Leaver 2005-10-05 18:21:18 UTC
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 18:35:37 UTC
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 20:11:21 UTC
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 07:31:19 UTC
(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 18:10:53 UTC
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.