[c-nsp] PBR performance gotchas

Karol Mares karol.mares at gmail.com
Thu Sep 6 11:34:32 EDT 2007


Hi,

On 9/6/07, Andrew Milner <andyman33 at gmail.com> wrote:
>
> Greetings
>
> We're contemplating a design that would make extensive use of policy
> based routing on our 7600 RSP720/WS-6704's..  Back in the day, you'd
> never do something like that because of performance but now it seems
> like that is fixed?  I don't have the means to test in a lab
> environment, so I'm just wondering if anyone has any experience with
> this and might be able to help me determine if/when this will fall
> over.
>
> Thanks in advance for any help,
>
> Andrew
>


PBR on 7600 is done in PFC (DFC) in CEF path, but PBR is just an ugly hack,
i would rather use VRs.
There are some restrictions that you should be aware of:

–The PFC does not provide hardware support for PBR configured with the *set
ip next-hop* keywords if the next hop is a tunnel interface.

–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)
should be fixed in SXE

--
                   iso


More information about the cisco-nsp mailing list