[c-nsp] PBR on a 6.5K

[Mezoth]

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 <tstev... at cisco.com> 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:tstev... at cisco.com]
> >Sent: Wednesday, February 25, 2009 12:24 PM
> >To: Dan Pinkard; cisco-... at puck.nether.net
> >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  cisco-... at puck.nether.net
> ><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, tstev... at cisco.com
> >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, tstev... at cisco.com
> 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  cisco-... at puck.nether.nethttps://puck.nether.net/mailman/listinfo/cisco-nsp
> archive athttp://puck.nether.net/pipermail/cisco-nsp/