CPU impact on PBR

[carlo.galicia]

Hi,

I have a Cisco 7609 with 2 x RSP720-3CXL module. The current traffic utilization is about 3Gbps and the CPU is less than 5%. Traffic utilization is expected to increase up to 10Gbps.

I need to do PBR for all TCP (only) traffic to another device. Would like to know what will be the impact on the CPU?

thanks,

Carlo

[Reza Sharifi · Accepted solution]

Hi,

It is hard to tell since no documentation can truly tell you if you for example create 10 PBRs, you CPU will increase 20% or 20 PBR, the CPU increase 40%. If you are deploying few PBRs, you shouldn't have to worry about CPU increases, but if you are planning to deploy a lots of PBR, you may want to do a few at a time and monitor the CPU to get an idea.

HTH

[mtsb · Accepted solution]

Hi Carlo,

I believe the PBR is done on hardware in 7600 so if you operate within the scalability limits of that platform it should be fine I guess. As Reza suggested if you are not sure I would do an incremental approach of applying few PBR policies and monitor for the CPU usage and tcam usage and keep applying untill all configs are applied.

Thanks,

Madhu

[carlo.galicia]

Thank you both for the reply.

I found these pbr guide at some cisco forums. Can help to explain this further?

–If  the MSFC address falls within the range of a PBR ACL, traffic addressed  to the MSFC is policy routed in hardware instead of being forwarded to  the MSFC. To prevent policy routing of traffic addressed to the MSFC,  configure PBR ACLs to deny traffic addressed to the MSFC.

–Any  options in Cisco IOS ACLs that provide filtering in a PBR route-map  that would cause flows to be sent to the MSFC to be switched in software  are ignored. For example, logging is not supported in ACEs in Cisco IOS  ACLs that provide filtering in PBR route-maps.

–PBR  traffic through switching module ports where PBR is configured is  routed in software if the switching module resets. (CSCee92191)

thanks,

Carlo

[mtsb]

 –If   the MSFC address falls within the range of a PBR ACL, traffic  addressed  to the MSFC is policy routed in hardware instead of being  forwarded to  the MSFC. To prevent policy routing of traffic addressed  to the MSFC,  configure PBR ACLs to deny traffic addressed to the MSFC. 

This means that the packet destined to the router itself should not be part of PBR. MSFC is the routing engine and the Ip address that is hosted on the router itself should not be matched by PBR. PBR is good for transit traffic.

 –Any  options in Cisco IOS ACLs that provide filtering in a PBR route-map  that would cause flows to be sent to the MSFC to be switched in software  are ignored. For example, logging is not supported in ACEs in Cisco IOS  ACLs that provide filtering in PBR route-maps. 

If there are any options like 'log' keyword in ACL will be sent to CPU for central forwarding instead of hardware forwarding. Such options should not be included in PBR which will drop such packets and will not be software switched.

#
 –PBR  traffic through switching module ports where PBR is configured is  routed in software if the switching module resets. (CSCee92191) 

This is just a release note of a bug and can be ignored if your IOS version is not affected by this bug.

Thanks,

Madhu

[carlo.galicia]

thanks again, Madhu.

[mtsb]

Hi Carlo,

Just FYI, after configing PBR you can verify it with "show ip policy" and "show tcam interface Gix/y acl in ip" which will tell you what traffic will be policy routes, what will be sent to cpu for software switching, what follows normal hw switching etc.

test-76#show tcam interface gigabitEthernet 3/6 acl in ip       

* Global Defaults not shared

Entries from Bank 0

Entries from Bank 1

    policy-route ip host 10.1.1.1 host 20.1.1.1

    permit       ip any any

test-76#

if you see a 'punt' entry for an supposed to be pbr then its a problem.

Please mark answered if your queries are answered!

Thanks,

Madhu