cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5666
Views
28
Helpful
14
Replies

does PBR in VRF is hardware switched on cat6509/sup720-3B

tquero
Level 1
Level 1

Hello,

I have a question concerning the hardware switching when configuring PBR in VRF on catalyst 6509-E with SUP720-3B :

Do the packets will be treated in hardware or they will be treated by the CPU ?

Does the answer depends of the ios train installed on the catalyst : SXH or SXI train ?

Is there any document on the CCO web site that explain this ?

Thank You for your help.

2 Accepted Solutions

Accepted Solutions

Edison Ortiz
Hall of Fame
Hall of Fame

The Release Notes has a brief explanation on what's supported on hardware

"Policy-based routing (PBR) with hardware assist  for route-map sequences that use the match ip addressset 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

Other notes:

"

The PFC provides hardware support for  PBR configured on a tunnel interface.

The PFC does not provides 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. (CSCse86399)

Any options in Cisco IOS ACLs that  provide filtering in a PBR route map that would cause flows to be sent  to the MSFC3 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)"

Additionally, available since SXH1

"

Multi-VRF Selection Using  Policy Based Routing (PBR):

In releases where CSCsv22779 is not resolved, Multi-VRF Selection Using PBR does not support the use  of reflexive ACLs.

Adds hardware support for the set ip vrf next-hop command. Configure the set ip vrf next-hop command for policy based routing  within the same VRF.


Note The set ip  next-hop command is supported only within the global context, not  within the VRF context.

Regards

Edison

View solution in original post

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Tquero,

>> Do the packets will be treated in hardware or they will be treated by the CPU ?

it should be performed in hardware but it can fall back to software depending on exact commands used.

I remembered a thread where a colleague was seeing different behaviours depending on the commands used.

In his case he needed to divert traffic to a different VRF or to global routing table and to a specific next-hop.

Using two lines one for setting the VRF and one to specify the next-hop was hardware processed, using a single command combining both infos caused process switching

note: you will find out if traffic is software switched because CPU usage will suddenly increase ( I know it would be better to know before)

What are you trying to accomplish?

Edit:

see Edison's answer he has found the right reference.

Hope to help

Giuseppe

View solution in original post

14 Replies 14

Edison Ortiz
Hall of Fame
Hall of Fame

The Release Notes has a brief explanation on what's supported on hardware

"Policy-based routing (PBR) with hardware assist  for route-map sequences that use the match ip addressset 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

Other notes:

"

The PFC provides hardware support for  PBR configured on a tunnel interface.

The PFC does not provides 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. (CSCse86399)

Any options in Cisco IOS ACLs that  provide filtering in a PBR route map that would cause flows to be sent  to the MSFC3 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)"

Additionally, available since SXH1

"

Multi-VRF Selection Using  Policy Based Routing (PBR):

In releases where CSCsv22779 is not resolved, Multi-VRF Selection Using PBR does not support the use  of reflexive ACLs.

Adds hardware support for the set ip vrf next-hop command. Configure the set ip vrf next-hop command for policy based routing  within the same VRF.


Note The set ip  next-hop command is supported only within the global context, not  within the VRF context.

Regards

Edison

Hello,

Thank you for your reply.

That means that the hardware or software switching does not depend on the ios train installed but on the configuration I will implement.

Thank You for your help.

Regards,

Thomas

Thomas,

For the most part, that's correct. With that said, I suggest to always refer to the Release Notes or the IOS documentation for such particular release for any caveats.

Please remember to rate helpful posts.

Regards

Edison

Hi Edison ,

"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. (CSCse86399) "

What is the MSFC address ?

Chao

Vishwa

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Tquero,

>> Do the packets will be treated in hardware or they will be treated by the CPU ?

it should be performed in hardware but it can fall back to software depending on exact commands used.

I remembered a thread where a colleague was seeing different behaviours depending on the commands used.

In his case he needed to divert traffic to a different VRF or to global routing table and to a specific next-hop.

Using two lines one for setting the VRF and one to specify the next-hop was hardware processed, using a single command combining both infos caused process switching

note: you will find out if traffic is software switched because CPU usage will suddenly increase ( I know it would be better to know before)

What are you trying to accomplish?

Edit:

see Edison's answer he has found the right reference.

Hope to help

Giuseppe

Hello,

How do I know that PBR is implemented in H/W or S/W ?

Is there any command I can use to check for this , maybe show tcam something ???

BR,
Sherif Ismail

yes and no

for older code you might use 'show tcam int xxx acl in ip'

if you see something link this everything is in hw

permit       ip any 224.0.0.0 15.255.255.255

policy-route ip 81.5.176.128 0.0.0.63 any 

permit       ip any any

if you see instead

permit       ip any 224.0.0.0 15.255.255.255

policy-route ip 81.5.176.128 0.0.0.63 any 

punt      ip any any

you are in troubles.

On newer code however due to changes in the way mls forwarding is performed you might see the same 'policy-route' all for sw processed traffic.

If this is the case you need to check cpu utilization before and after.

Riccardo

Thanks Riccardo

Do your answer differs with router chassis or IOS used ?

I am mainly interested with 7609-s chassis

BR,

Sherif Ismail

Thanks Riccardo

Now 2 more queries plz

1- Can you verify more what do you mean with

"On newer code however due to changes in the way mls forwarding is performed you might see the same 'policy-route' all for sw processed traffic"

If you have examples from 7600 .. that will be great

2- If you have PBR, that have 5 statments

4 of them are configured with features that can be H/W implemented and 1 statment has feature that can not be done by H/W

result will be that all PBR will be implemented S/W, correct ??

Hi Sherif,

1. it is pretty complex as it has to do with the interactions with other features, namely copp.

In few words: if you see the 'punt' statement you know that the traffic matching that ACE is punted (redirected) to the CPU.

If you see for instance

    permit       ip any 224.0.0.0 15.255.255.255

    policy-route ip 212.104.149.120 0.0.0.3 any

    policy-route ip any any 

You need to do an extra check to see the exact redirect adjacency programmed in the tcam. It is too long to explain that here, anyway what i can tell you is too see if you have copp configured. If this is the case most likely the redirect adjacency which is programmed points to the copp internal vlan, therefore the cpu. That means that traffic is sent to copp to be rate-limited by the sw component of copp (therefore the cpu).

I am not sure this help you understanding more but those are engineering commands related to the pfc architecture. I am afraid I cannot disclose more than this.

2. correct. If instead you have a route-map with 2 sequence numbers of which one have an unsupported command, only the ACL bound to that unsupported sequence will be punted to the cpu.

Riccardo

Thanks Riccardo

So a conclusion

1- One has to check IOS release notes to see features supported by H/W

2- If there are features configured not supported by H/W or in doubt if supported or not and copp not configured, only way to verify is to check CPU utilization before and after applying config

Unfortunately this is not a convenient answer as customers wants to use H/W ... If we are in doubt they will ask us to use other vendors as Juniper !!

3- Again for sake for confirmation, cause your previous answer with "correct" and your explanation after that confused me

If I have route-map with 4 statments, 3 of them can be implemented by H/W and 1 statment is configured with feature that can not be implemented by H/W

What will be the result ??

a- All statments will be implemented S/W

b- Or all will be implemented H/W except that feature that will be punted and done S/W

Many thanks for your time & assistance

BR,
Sherif Ismail

Hi Sherif,

1. YES. first you must be sure whether what you are doing is supported and release notes and feature guides are to place to check.

2. It is the other way around. Without CoPP is easy to spot sw processing as you will see 'punt' in the tcam programming. With copp that is somehow hidden (but copp will reduce the drawback of sw processing as it will drop some traffic before it reaches the CPU).

Not commenting the other statement about Juniper... just try and see if you can get the same degree of support if yu have issue on Juniper devices and then let me know.

3. hw is complex and there is no generic answer applying to all scenarios.

in GENERAL if you have a a route map with 4 statements (read sequences), the 3 that can be implemented in hw will be in hw while the 4th will be in sw.

However if that statement interfeers badly with the tcam programming there is a chance that all statements are in s/w. Cannot give you a specific example though. In case of doubt you need to open a TAC case.

let me also add that you have another powerful command to check CPU utilization which is 'show ibc' which shows the exact number of packets per second received to and from the RP.

lan-7600-2#sh ibc

Interface information:

        Interface IBC0/0(idb 0x1CD71D24)

        5 minute rx rate 1701000 bits/sec, 365 packets/sec

        5 minute tx rate 479000 bits/sec, 722 packets/sec

TX represents the traffic sent to the RP while RX the traffic received from it.

With tcam programming command and this command taken before and after you apply the PBR you should be capable of spotting any issue.

RIccardo

Thanks Riccardo for your assistance

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco