[c-nsp] Best practice - Core vs Access Router

[Phil Mayers]

On 09/02/10 12:21, Andy B. wrote:
> CPU load is fairly normal at 20-30%

Is this average or during a performance event? What about the SP and any 
DFC CPUs?

What linecards do you have in the box?

> No congestion. Most links are under 50%.
> I have no Control Plane Policies in place, but I have already been
> advised to do so - this might help, right?
>
> Redesigning the network and shifting the busy (uncongested!) VLAN to
> another router seemed like the only choice we have left, unless this

Your network doesn't sound that unusual to me. Provided you have 
PFC-3B/XL (and DFC-3B/XL if you're running DFCs) the 6500 ought to be 
able to handle it in a "steady state" (see below). What does:

sh mls cef maximum-routes
sh mls cef summary

...say?

The first thing to do is determine why these performance problems are 
occurring. Otherwise, installing a new router might do nothing other 
than cost money.

You say "so that the new router can handle these many MAC addresses"; do 
you have any reason to believe that MAC or adjacency table size is the 
problem? The 6500 can handle 64k MAC addresses at layer2 and variable 
numbers of ARP/layer3 adjacencies.

Control-plane policing will only help if CPU-punted or CPU-directed 
packets are causing the performance problems.

MLS rate limiters may also help in that situation.

Alternatively if you're getting the BGP scanner eating lots of CPU 
because of churn in your full feeds, then you need to address that.

It could be ICMP redirects, or layer2 loops downstream.

How often are these performance problems occurring? Is anything logged 
on the router at the time? What does the output of:

sh proc cpu | ex 0.00
remote command switch sh proc cpu | ex 0.00
sh platform hardware capacity forwarding

...say after a window of poor performance? How long do the events last?

As you can see, there's a lot to look into.

As to whether it's "wise" to have one router doing both jobs - it 
depends. Some people will I guess say "no split them" but it's really a 
matter of costs and benefits. We do similar things where one 6500 does a 
*LOT* of work (without the full table) and have no problems.