High cpu util

[tdorduncu]

We have 7200 VXR with npe-g2 processor.We've 150 branches connected on ATM and QoS with NBAR for voice on it.When traffic rates goes up so our CPU util approxly %70. What could be a problem with services ? is it any fine tunning for this ?

Regards

[Giuseppe Larosa]

Hello Tolga,

150 bramches on ATM pvcs with QoS and OSPF can be enough to rise the cpu.

Notice that this is still a software based device where packets are moved by main cpu.

verify if CEF is enabled that is more efficient way to move traffic

use

sh proc cpu sorted

to see what processes are using more resources

Hope to help

Giuseppe

[Joseph W. Doherty]

As Giuseppe already noted, software based routers use their CPU for forwarding all traffic, so it's possible the issue is just volume of traffic.

The one snapshot for a "show proc cpu" you've posted, only shows a delta of 3% between total CPU and interrupt CPU, which would indicate fairly reasonable (as to how its being used) CPU usage.

What's the total volume of traffic passing though the router and what's total CPU vs. interrupt CPU when the CPU gets busy?

PS:

One simple service feature that might help on a 7200 is the "Turbo ACL" feature, if supported on the IOS you're running.

[tdorduncu]

Total volume of traffic nearly 180 mbps. During the high load on traffic it will %80 when interrupted.

Can i use traffic describing method for Turbo acl on 7200 instead of nbar?

[Wilson Samuel]

Hi,

I would beg to differ a little bit over here. In my opinion, NBAR works pretty well for light traffic loads (around 50Mbps) and I doubt it would be suitable for any WAN Agregation levels, reason being the CPU utilization/hogging (NBAR requires Deep Packet Inspection) that might take place in high load conditions such as the case presented by you.

http://www.cisco.com/en/US/technologies/tk543/tk759/technologies_white_paper0900aecd8031b712_ps6616_Products_White_Paper.html

On the other hand, I would like to know, if its possible for you to turn back to the normal ACL based classification than NBAR, if the number of applications involved is not that "high".

Hope this helps, please rate all helpful posts.

Regards

Wilson Samuel

[Joseph W. Doherty]

As Wilson documents, NBAR protocol matching can impact performance, although not all NBAR's protocols matching impact is the same. Much would depend on how deeply a particular NBAR match needs to examine a packet and whether it keeps state information for it. (I.e. some NBAR is nothing more than port based matching with a "pretty face". The reference Wilson provided used a mix of traffic types. The documented performance would likely change with a change in the traffic content and/or perhaps with different sequence of match statements.)

Depending on the nature of your traffic, it's possible an ACL might introduce less overhead for equivalent matching.

The Turbo ACL feature is most useful when you have extensive ACLs, since I believe it reduces the impact of ACL sequence processing. (It's also very easy to activate with the "access-list compiled" command, if it's supported on your IOS.)

Similar to typical ACLs, NBAR matching performance impact might be decreased by careful ordering of match statements and/or perhaps by netflow caching.

Something else to consider, can the voice (or any other) traffic be classified and tagged before getting to the 7200? If you could trust VoIP markings, you might then only need to look at the ToS octet to identify them.