High CPU load (check_reload_status) + IPv6 Gateways

thesnowedone

Created an bug for it - https://redmine.pfsense.org/issues/2555

Cynagen

I just read the bug ticket, and I can confirm this exact behavior with my pfSense as well, however I'm using a HE.net TunnelBroker GIF IPv6 configuration (http://doc.pfsense.org/index.php/Using_IPv6_on_2.1_with_a_Tunnel_Broker). Without using device polling, the process check_reload_status will eat up both cores and never let go, rendering the entire platform useless until there is a reboot.

My build:
2.1-BETA0 (amd64)
built on Thu Jul 26 01:49:39 EDT 2012
FreeBSD 8.3-RELEASE-p3

AMD Athlon 64 X2 Dual Core Processor 4200+ w/2GB DDR2

Issue still occuring in latest snapshot:

2.1-BETA0 (amd64) 
built on Wed Aug 15 08:43:33 EDT 2012 
FreeBSD 8.3-RELEASE-p4

Bug can be reproduced by going to Interfaces > WAN > IPv6 Configuration Type > "DHCP6"

CPU spikes immediately after committing changes.

mikesamo

same on embedded 2.1

mikesamo

to fix that issue I just have to edit my 2 default gateway and apply.

Editing my gateways (System >> Routing >> Gateways (Tab) ) does not resolve the issue. In addition, leaving the v6 WAN applied and rebooting does not clear the check_reload_status process on one of the CPU cores.

A reboot or a full clearing of my changes (including manually removing my v6 gateway) is the only way to bring the CPU load back under control.

+++
EDIT - Mod - would it be possible to edit the topic of this thread to something more descriptive (like "High CPU load (check_reload_status) + IPv6 Gateways") ?

As of this version:

2.1-BETA0 (amd64) 
built on Mon Aug 27 10:33:40 EDT 2012 
FreeBSD 8.3-RELEASE-p4

I am able to bring check_reload_status down from spiking by reversing my config changes. However, I believe that I may perhaps be approaching my v6 setup incorrectly - has anyone had any success with Internode on 2.1 BETA? I can bring a SLAAC WAN interface up without creating the same CPU spike, but am unsure as to appropriate setup (DHCPv6, RA and static LAN assignments from my static /56 from the ISP.)

Hmmm … so no one has any ideas about this?

If we have simply incorrectly configured IPv6 in our setups (and thus causing the the CPU spike) then it would be helpful if someone could point us in the right direction.

jimp

check_reload_status itself doesn't tend to be the problem in these cases. Something (such as rc.newwanip) calls pfSctl which routes a request through check_reload_status which in turn tries to take another action - the problem seems to happen more often when there are either:
(a) a lot of programs trying to make calls through check_reload_status
(b) whatever check_reload_status is calling is not behaving as expected

Usually running something like this is enough to bring it back:
killall -9 php; killall -9 lighttpd; /etc/rc.restart_webgui

Once the callers/callees of check_reload status are gone the load tends to return to normal.

Thanks Jimp and sorry for my late reply….

I have experimented with bringing a DHCPv6 WAN up and, while it still spikes, it can be brought under control by removing the interface (which I guess is expected behaviour). This is on the following version:

2.1-BETA0 (amd64) 
built on Sat Sep 15 17:04:58 EDT 2012 
FreeBSD 8.3-RELEASE-p4

I believe I probably need to go back to the drawing board and consider if I'm approaching my v6 setup in the correct way (as you indicated in (b)), although it seems that https://redmine.pfsense.org/issues/2555 is continuing to move along.