05-27-2008 10:16 AM - edited 03-05-2019 11:15 PM
We have a 7206 router used as our internet router and have BGP facing our ISP and EIGRP on the inside. The CPU is really high and I noticed that CEF is not enabled. Fastswitching is enabled though.
Somewhere along the line someone said that CEF should not be enabled because it conflicts with something in the router. (really vague eh?)
Anyway, is there a reason why CEF should ever be disabled?
05-27-2008 10:31 AM
Never heard of anything like that
What NPE are you using?
I think you should enable CEF and also check for the processes that are eating up the CPU
Narayan
05-27-2008 10:33 AM
Jim
In the early days of the introduction of CEF there were some reports of instability (of various sorts) that got better when CEF was disabled. That was a long time ago and I do not remember many details. Assuming that the 7206 is running any where near recent code I do not know of a reason why CEF should not be enabled.
I have seen some situations where someone would disable CEF to force process switching while they ran debug. And occasionally they forgot to enable CEF when debug was completed. I wonder if you might have something like that?
My advice is to enable CEF.
HTH
Rick
05-27-2008 12:38 PM
That was my suspicion - that someone needed to turn all all flow switching in order to debug with and ACL. This is VXR router with an NPE400 and running 12.3(11)T.
I think I'll go ahead and re-enable CEF and watch the CPU load.
05-27-2008 12:43 PM
Jim
Please let us know the results. I believe that when you enable CEF that you will see a noticeable improvement in CPU utilization.
HTH
Rick
05-27-2008 01:10 PM
I haven't gotten permission to enable CEF yet, but when the CPU is high, the process that is hogging it the most is 'BGP Scanner'
ROC-7206F-XO#sh proc cpu
CPU utilization for five seconds: 82%/14%; one minute: 27%; five minutes: 23%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 8 252 31 0.00% 0.00% 0.00% 0 Chunk Manager
.
.
191 256248 2228564 114 0.00% 0.01% 0.00% 0 BGP I/O
192 191615024 974591 196623 67.83% 12.08% 8.66% 0 BGP Scanner
ROC-7206F-XO#
Here is a quick 'show proc cpu history' showing that the CPU reaches 100% very regularly:
ROC-7206F-XO#sh proc cpu history
ROC-7206F-XO 02:05:58 PM Tuesday May 27 2008 pdt
.
.
. 7799879997799987998779986579986799879996899867998589978997
9989293955539971396053978997957539619997397049792949753988
100 ** ** ** * * ** * *** ** ** ** ** *
90 ** *** **** *** *** *** *** *** ** ** ** ** *
80 *************** *** **** **** **** *** **** **** **********
70 ************************* ****************** **** **********
60 ************************************************************
50 ************************************************************
40 ************************************************************
30 *****#*********#**********************************####******
20 ############################################################
10 ############################################################
0....5....1....1....2....2....3....3....4....4....5....5....
0 5 0 5 0 5 0 5 0 5
CPU% per minute (last 60 minutes)
* = maximum CPU% # = average CPU%
1111 11 1 11 111 111 111 1111 1 1111 1 111 111 1 1 1 11
0000900909009000900099000900009999999999909000090990009000909090900999
0000900909009000900099000900009999999999909000090990009000909090900999
100 ************************************************************************
90 ************************************************************************
80 ************************************************************************
70 ************************************************************************
60 ************************************************************************
50 ************************************************************************
40 ************************************************************************
30 ************************************************************************
20 #######*****************************************************************
10 ########################################################################
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
0 5 0 5 0 5 0 5 0 5 0 5 0
CPU% per hour (last 72 hours)
* = maximum CPU% # = average CPU%
.............................................
Is the 'BGP Scanner' process acting within expected utilization, or should I dig into what may be causing that re-occurring spike?
05-28-2008 04:08 AM
Jim
The BGP scanner does run every minute. It looks through the routing table to check for all routes that are in the routing table and that match network statements in BGP, and some related things. So depending on the size of your routing table and the amount of BGP activity I might expect the BGP scanner to be fairly busy when it runs.
HTH
Rick
05-28-2008 04:28 AM
Agree with Rick's description of the impact of BGP scanner. Note, though, CEF activation will likely not impact the CPU utilization of the BGP scanner (also agree with other posters that CEF should be enabled).
The one problem I've seen with the CPU spikes caused by the BGP scanner has been interface input drops, so you might want to check. To minimize this, increase the input queue sizes. Believe there's a Cisco tech note about this.
05-28-2008 06:15 AM
We're starting to remember some snippets as to why CEF was turned off. This is part of an article concerning CEF and asymmetric routing:
"In almost all Cisco IOS software versions that support Cisco Express Forwarding (CEF), it's possible to have the router check the source address of any packet against the interface through which the packet entered the router. If the input interface isn't a feasible path to the source address according to the routing table, the packet will be dropped.
This works only when routing is symmetric. If the network is designed in such a way that traffic from host A to host B may normally take a different path than traffic from host B to host A, the check will always fail and communication between the two hosts will be impossible. This sort of asymmetric routing is common in the Internet core. You should make sure that your network doesn't use asymmetric routing before enabling this feature."
We have two 7206 routers as our CPEs, each one connected via DS3 to a different provider (7206A connected to Provider A, 7206B connected to Provider B). Both share a common inside /27 network and both are also connected together via a crossover cable and a /30 subnet.
Memory seems to indicate that we were advised that since we have two CPE routers and two providers, we may end up in an asymmetric routing situation and it would be best to disable CEF.
Is this beginning to make sense and do you agree with the above article's comments?
05-28-2008 06:23 AM
"it's possible to have the router check the source address of any packet against the interface through which the packet entered the router", but it does not do so by default. To run that check, you would have to ip verify unicast reverse-path.
This is not a reason to disable CEF; CEF is quite OK with asymmetric routing. I would question that advice you were given.
Kevin Dorrell
Luxembourg
05-28-2008 07:15 AM
Jim
I find the reference in the article you mention to be a bit ambiguous. When it says :"make sure that your network doesn't use asymmetric routing before enabling this feature" I am not sure what this feature is. But it sure sounds like Reverse Path Forwarding checking. And it surely is not CEF.
I absolutely agree with Kevin that this article is not a reason to disable CEF.
HTH
Rick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide