05-19-2010
06:43 AM
- last edited on
03-25-2019
04:10 PM
by
ciscomoderator
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.
Solved! Go to Solution.
05-19-2010 06:51 AM
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 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
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
05-19-2010 06:52 AM
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
05-19-2010 06:51 AM
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 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
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
05-19-2010 07:14 AM
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
05-19-2010 07:38 AM
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
09-26-2010 03:45 AM
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
05-19-2010 06:52 AM
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
09-28-2011 06:40 AM
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
09-28-2011 09:11 AM
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
09-28-2011 01:44 PM
Thanks Riccardo
Do your answer differs with router chassis or IOS used ?
I am mainly interested with 7609-s chassis
BR,
Sherif Ismail
09-28-2011 02:21 PM
IOS
09-28-2011 05:03 PM
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 ??
09-29-2011 01:00 AM
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
09-30-2011 09:40 AM
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
10-04-2011 04:02 AM
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
10-04-2011 05:29 AM
Thanks Riccardo for your assistance
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide