I have done some work on this recently under the 12.2(33)SRC2 codebase, and as far as I can tell it is a hardware limitation that putting a PBR to a tunnel is a software switched traffic path. This does hit the control-plane for every packet and without some other configuration there is no way around it - and Cisco has so far told me it is not in the planned list of improvements for the SR(x) train.
However, I found an interesting work around, in that PBR->VRF is hardware switched. So pushing the traffic to a VRF, and having that VRF with a default route to the tunnel endpoint effectively pushes the traffic to the tunnel. The downside is that this is not truly bidirectional for the tunnel, so it depends on your application on if this work around would apply. - Eric Lent On Feb 26, 10:12 am, Tim Stevenson <[email protected]> wrote: > My sentence should have continued: "..., if you > want it to do hardware-switched PBR". > > As Rodney pointed out, more recent s/w releases > may have added this support, so could depend on > what release you are running whether it is hw or sw switched. > > Tim > > At 12:29 AM 2/26/2009, Dan Pinkard stated: > > > > > > >Thanks! > > >It certainly happily accepts the command, and > >even does the right thing for the first few > >kpps. After that, not so much, which is where > >the whole question began. It just does so poorly that it never catches up… > > >---------- > >From: Tim Stevenson [mailto:[email protected]] > >Sent: Wednesday, February 25, 2009 12:24 PM > >To: Dan Pinkard; [email protected] > >Subject: Re: [c-nsp] PBR on a 6.5K > > >IIRC, 6500 does not support PBR with the > >recursive next hops, you must specify a directly > >connected next hop that you have a resolved adj for. > > >Tim > > >At 11:47 AM 2/25/2009, Dan Pinkard stated: > > >What are the resource limitations on policy > >routing on SUP720s/MSFC3? Are the flows > >ultimately process switched every time or will it draw from the route-cache? > > >We were toying with a very simple route-map that > >called for both a next-hop and a recursive > >next-hop route. A moderate (20mbps/14kpps) > >traffic level pegged the cpu and send IQD > >counters sky-high. Which leads to the basic question of what went wrong? > > >Any ideas or observations from your own tests? > > >Thanks! > >_______________________________________________ > >cisco-nsp mailing list [email protected] > ><https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp > >archive at > ><http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/ > > >Tim Stevenson, [email protected] > >Routing & Switching CCIE #5561 > >Technical Marketing Engineer, Cisco Nexus 7000 > >Cisco -http://www.cisco.com > >IP Phone: 408-526-6759 > >******************************************************** > >The contents of this message may be *Cisco Confidential* > >and are intended for the specified recipients only. > > Tim Stevenson, [email protected] > Routing & Switching CCIE #5561 > Technical Marketing Engineer, Cisco Nexus 7000 > Cisco -http://www.cisco.com > IP Phone: 408-526-6759 > ******************************************************** > The contents of this message may be *Cisco Confidential* > and are intended for the specified recipients only. > _______________________________________________ > cisco-nsp mailing list > [email protected]https://puck.nether.net/mailman/listinfo/cisco-nsp > archive athttp://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
