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

Answered Question
May 19th, 2010

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.

I have this problem too.
0 votes
Correct Answer by Giuseppe Larosa about 6 years 8 months ago

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

Correct Answer by Edison Ortiz about 6 years 8 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (8 ratings)
Loading.
Correct Answer
Edison Ortiz Wed, 05/19/2010 - 06:51

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

tquero Wed, 05/19/2010 - 07:14

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

Edison Ortiz Wed, 05/19/2010 - 07:38

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

vishwancc Sun, 09/26/2010 - 03:45

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

Correct Answer
Giuseppe Larosa Wed, 05/19/2010 - 06:52

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

Sherif Ismail Wed, 09/28/2011 - 06:40

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

rsimoni Wed, 09/28/2011 - 09:11

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

Sherif Ismail Wed, 09/28/2011 - 13:44

Thanks Riccardo

Do your answer differs with router chassis or IOS used ?

I am mainly interested with 7609-s chassis

BR,

Sherif Ismail

Sherif Ismail Wed, 09/28/2011 - 17:03

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 ??

rsimoni Thu, 09/29/2011 - 01:00

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

Sherif Ismail Fri, 09/30/2011 - 09:40

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

rsimoni Tue, 10/04/2011 - 04:02

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

Actions

This Discussion

Related Content