cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
702
Views
0
Helpful
10
Replies

Is there a reason why CEF shouldn't be enabled in a 7206 router?

jkeeffe
Level 2
Level 2

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?

10 Replies 10

royalblues
Level 10
Level 10

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

Richard Burts
Hall of Fame
Hall of Fame

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

HTH

Rick

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.

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

HTH

Rick

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?

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

HTH

Rick

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.

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?

"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.

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_cfg_unicast_rpf_ps6350_TSD_Products_Configuration_Guide_Chapter.html

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

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

HTH

Rick
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: