×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

High CPU due to BGP Scanner

Unanswered Question
Sep 23rd, 2014
User Badges:

Hi,

one of our internet facing router(Cisco 7206) is showing processor 87% in our monitoring system while  CPU utilization for five seconds: 2%/1%; one minute: 8%; five minutes: 9%..

BGP scanner for five min is 6.23% .

sh processes memory
Total: 456789536, Used: 396148408, Free: 60641128

 

This issue we have for around three weeks.

Any solution for this please?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Joseph Nelson Tue, 09/23/2014 - 07:52
User Badges:

Hi,

What Network Proc do you have in that box ( NPE-G1, NPE-G2, NPE-400)? Also, what IOS version are you running? Can you post the output of:

 

show ver

show ver

show ip bgp sum 

 

Could be that your NPE can't handle the number of routes your getting. Also, your IOS version may not support BGP Next-Hop tracking which may reduce CPU utilization.

 

Joseph Nelson Tue, 09/23/2014 - 09:30
User Badges:

Hi,

Can you show the output of:

 

show proc cpu history 

What is the baseline CPU utilization? Are you getting high CPU alerts intermittently? A one-off CPU spike doesn't mean much--if the condition persist over a period there can/will be a problem. From your original post, the "show proc cpu sort 5sec" output seems normal.

Your NPEG1 and memory load out should handle your BGP table without a problem. I check Cisco Bug Search Tool and couldn't find an open case.

What is the peak throughput your seeing on that box? Can you correlate the Hi CPU condition with peak traffic flows through the device? What other services are you running on that device?

Joseph Nelson Wed, 09/24/2014 - 12:47
User Badges:

Hi,

Looking at your "show proc" confirms your original report, BGP Scanner runtime is very high. Here are some things you can try:

  • Reduce the routes you accept from your upstream ISP; you can filter on ASN or prefix
  • Insure CEF is enabled on all interfaces ( "ip cef" global config command )
  • Disable BGP Next-hop tracking ( in router bgp mode, "no bgp nexthop trigger enable"
  • If you have an OSPF adjacency with your iBGP peer, verify that its adjacency is not flapping. 

Every 60s by default the BGP Scanner process walks the entire BGP table. Therefore, reducing the BGP table size makes sense to ease the load on the CPU. 

The last two points are related. Next-hop tracking feature improves efficiency of the BGP Scanner process, namely by letting BGP Scanner know when the next-hop for a prefix changes--then BGP Scanner need only work on that prefix ( in practice, now BGP only needs to invalidate a subset ). If your iBGP peer is known via IGP, then flaps in the IGP will cause unnecessary BGP Scanner runs.

 

Your iBGP peer session has been up for sometime so IGP instability seems unlikely, but please check your OSPF peer table.

 

Edit: Some additional resources for you:

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/107615-highcpu-bgp.html

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/irg-nexthop-track.pdf

jeliasoncisco Tue, 09/23/2014 - 09:50
User Badges:

Hello

How many BGP Peers did you have at the time? How many routes in your table?

Thanks.

 

Revised:

I noticed the attached output from the router. Have you read this article? https://supportforums.cisco.com/document/12202206/size-internet-global-r...

 

The internet may be periodically getting to big for your router. I recommend that you trim the routes you receive to only directly connected prefixes at each of your two upstream providers. Then in addition, put in place two default routes to each of your upstream peers. If there is one you prefer because it is faster or cheaper then set it as the preferred and the other as a more costlier route (metric).

We have done the above and extended the life of our router. However, if it is not the number of routes causing your issues, you may be putting too much throughput through your router. Cheers.

Actions

This Discussion