Alternatives to PBR on 7606 (sup720's)??

[srue]

I'm running a route-map on one of our primary interfaces on a 7606..  All physical interfaces are layer 3 interfaces (no Vlan interfaces).  I believe this route-map is causing high CPU utilization. 

What I'm trying to accomplish is all traffic entering on this interface to go out a separate default route than everything else.  Is there a better alternative to PBR?

ios - 12.2(14)SX1

The route-map reads something like this:

ip access-list extended pbr_acl

permit ip any any

route-map ROUTEMAP permit 10

match ip address pbr_acl

set ip default next-hop 10.0.0.1

TIA

[Edison Ortiz]

You can try using VRF, with that said, I don't see why would that cause high CPU as the match and set options are processed in hardware.

Policy-based routing (PBR) with hardware assist for route-map sequences that use the match ip address,set ip next-hop, and set ip default next-hop PBR keywords.

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/features.html

[srue]

Based on the following:

http://www.cisco.com/en/US/products/hw/routers/ps359/products_tech_note09186a00801c2af3.shtml

....looks like I need to enable 'ip route-cache policy'....on the interface in question

[rsimoni]

no you don't... high cpu on this platform is addressed differently

by the way can you check again the IOS you are running... 12.2(14)SX1 seems to mee a ROMMON version instead.

About the pbr which is supposdely causing high cpu is 10.0.0.1 directly connected to the 7609 and MORE important resolved in ARP (in other words does that IP address exist in your network)?

More precisely what is 10.0.0.1 and how your router reaches it?

Lastly, what are you trying to achive with your pbr? you want to route traffic destined to destinations not in routing table to that next hop (this is what your pbr should do)?

Riccardo

[Richard Burts]

The original poster gives this explanation of what he wants to accomplish:

"What I'm trying to accomplish is all traffic entering on this interface to go out a separate default route than everything else." Given that objective I do not believe that there is any effective alternative except PBR.

But I would suggest a rewrite of the route map. Since PBR is applied on the interface and the access list will match everything I suggest that the route map does not need a match statement (and does not need the access list or any access list matching). I believe that it would accomplish what you need if it were written this way

route-map ROUTEMAP permit 10

set ip default next-hop 10.0.0.1

Give that a try and let us know what happens.

HTH

Rick

[rsimoni]

since he said

to go out a separate default route than everything else

we can assume that the router has already a default route in its RIB, therefore he configured the pbr wrongly.

he configured

set ip default next-hop 10.0.0.1

while in his case he should configure

set ip next-hop 10.0.0.1

Anyway he was also complaining of high cpu utilization that is something complitely different than wrong syntax

Riccardo

[srue]

@Riccardo,

There is a default route on this router already, as well as static routes.  That static routes should still be used, I'm just trying to override the default route on incoming traffic on this interface. 

I still think the set ip default next-hop is the correct command.

@Richard,

I like your idea of removing the match statement altogether since I am essentially matching everything.  Do you know if this will further decrease CPU utilization? 

I did apply the 'ip route-cache policy' command to several of my interfaces that I have route-maps applied to, and I've seen a 15-20% decrease in CPU. 

Thanks for all the replies.

[rsimoni]

if you have a default route and no specific route indeed set ip default next-hop is the correct command. I was wrong.

anyway the high cpu condition is something else. "ip route-cache policy" is not supposed to be used on this platform.

This is needed when you want to enable fast-switching instead of process switching, which is the default behavior on some software based platorms.

Sup720  based platforms are supposed to handle traffic in mls cef, so although this command alleviates the cpu utilization (as you forward it in software by the RP using fast-switching instead of process switching)  you still have an uderlying problem which is the fact that this traffic is NOT handled in hardware.

post a ' show tcam interace acl in ip' and we will see what happens at hardware level.

[Richard Burts]

I do think that eliminating the match statement from the route map will result in some greater efficiencies in execution of the route map. But I suspect that the amount of change will not be great and probably difficult to notice in the operation of the router. But simpler and more efficient is a good thing and I would like to see you make that change in the route map.

I am surprised that adding the ip route-cache policy on interfaces made a difference in CPU utilization. I wonder if the output of show proc cpu sorted would help identify what the issue might be?

HTH

Rick

[srue]

I will modify the route-map and eliminate the match statement sometime in the near future.  (next day or two)

I've been monitoring CPU usage using Cacti, along with the show proc cpu sorted command - which shows high IP INPUT cpu usage.

I've read conflicting information about using the 'set ip default next-hop' command. Some sources say that command always causes packets to be software switched, other sources don't say that.  Some of my route-maps use 'set ip next-hop' which may be where the actual cpu decreased..not sure though.

[rsimoni]

I am surprised that adding the ip route-cache policy on interfaces made a difference in CPU utilization.

it does when traffic is punted to the cpu

@srue; if you print the outputs requested we will be able to understand the reason of such cpu punting or else we will talk endlessly