Set clause interpretation with Multi-VRF selection using PBR

Answered Question
Dec 11th, 2008
User Badges:

I posted this on the LAN, Switching and Routing list, but I did not get any takers....


I am trying to figure out the semantic/operational differences between some of the set clauses used with Multi-VRF selection using Policy Based Routing (PBR).


Specifically, I am trying to figure what the difference is between this:


route-map Applied-to-a-VRF-Interface permit 100

match ip address 100

set global

set ip next-hop 192.168.0.1


and this:


route-map Applied-to-a-VRF-Interface permit 100

match ip address 100

set ip global next-hop 192.168.0.1



where:


interface Gig5/2

ip vrf forwarding NewVRF

ip address 192.168.1.1 255.255.255.0

ip policy route-map Applied-to-a-VRF-Interface


I've read the documentation found here http://www.cisco.com/en/US/docs/ios/12_2sr/12_2srb/feature/guide/srb2mvrf.html#wp1053934, but I don't quite follow the semantic differences between the "set global" clause followed by a "set ip next-hop" clause and the "set ip global next-hop" clause.


I have a particular application on a 6509 running 12.2(33)SXH3 whereby when I use the "set ip global next-hop" clause my traffic is getting software-switched but when I do a "set global / set ip next-hop" on different lines that the traffic is getting hardware switched. I just want to make sure I understand the difference with how these clauses are interpreted by the 6509 hardware.


I'm assuming that using the "set vrf" and "set ip vrf" syntax is conceptually the same as in the "global" instance.


Any ideas?


Clarke Morledge

College of William and Mary

Correct Answer by Giuseppe Larosa about 8 years 6 months ago

Hello Clarke,

from the document you have linked:


set global-Routes packets through the global routing table. This command is useful when you want to route ingress packets belonging to a specific VRF through the global routing table.


•set ip global-Routes packets through the global routing table, where the next-hop lookup will be in the global routing table.


You have probably found an implementation issue: the command in two lines is easier to map on C6509 HW.

the set global says that in any case the packets will be routed to the global routing table.

the second command might require to verify availability of that next hop in the global routing table.

It could mean that if the specified next-hop is not available the packets have to be routed within the VRF table.


So the two lines formulation can be more efficiently implemented in TCAM tables.


Hope to help

Giuseppe


  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
Correct Answer
Giuseppe Larosa Fri, 12/12/2008 - 03:14
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Clarke,

from the document you have linked:


set global-Routes packets through the global routing table. This command is useful when you want to route ingress packets belonging to a specific VRF through the global routing table.


•set ip global-Routes packets through the global routing table, where the next-hop lookup will be in the global routing table.


You have probably found an implementation issue: the command in two lines is easier to map on C6509 HW.

the set global says that in any case the packets will be routed to the global routing table.

the second command might require to verify availability of that next hop in the global routing table.

It could mean that if the specified next-hop is not available the packets have to be routed within the VRF table.


So the two lines formulation can be more efficiently implemented in TCAM tables.


Hope to help

Giuseppe


cmorledge Fri, 12/12/2008 - 08:30
User Badges:

Guiseppe,


I agree with your explanation, except that I'm still puzzled as to why I am getting software switched since the "next hop" in question has the route to the next hop available in the VRF.


There are a lot mysteries as to how Cisco programs these TCAMs. I just do not find the documentation to be particularly enlightening.


Thanks.


Clarke Morledge

Giuseppe Larosa Fri, 12/12/2008 - 09:07
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Clarke,

thanks but actually you solved the issue by yourself !


and yes in some cases we can just take note of the observed behaviour in these complex systems.


Best Regards

Giuseppe




lejoe.thomas Fri, 12/12/2008 - 03:51
User Badges:
  • Silver, 250 points or more

hi Clarke,


Out of curiosity, how did you know when the traffic was getting software-switched or hardware switched


Lejoe

cmorledge Fri, 12/12/2008 - 05:57
User Badges:

Lejoe,


Initially, I saw the problem right away. Typing on the router console got V-E-R-Y S-L-O-W.


show proc cpu sorted


also showed me that "IP Input" was the leader in grabbing the CPU. As soon as I pulled off the route-map from being applied, the CPU problem was corrected.


Generally, if my CPU utilization jumps up after I configured something, that's the best indication that I somehow got traffic to be software-switched instead of being handled by the TCAM.


Clarke

lejoe.thomas Fri, 12/12/2008 - 06:24
User Badges:
  • Silver, 250 points or more

Hi Clarke,


Thanks for that. Did you issue a debug ip policy and see the difference for both those configurations for traffic generated from access-list 100.

My thoughts are

set global

set ip next-hop


it's successfully able to route the packet using the first statement and not even reaching the final statement. However with set global ip next-hop, it's explicitly forced to choose the next-hop.


http://www.ciscosystems.com/en/US/docs/ios/mpls/configuration/guide/mp_mltvrf_slct_pbr.html#wp1053974


HTH

Lejoe

Actions

This Discussion