[c-nsp] Hardware accel. paths for policy routing on C6500

Wed Feb 16 17:13:47 EST 2005

Yes, but of course this is true of any of the h/w accelerated features, 
even v4 unicast forwarding. If you run out of entries, you can't do it in 
h/w anymore.

For PBR, we use the ACL TCAM and the h/w Adj table. There are 32K max ACL 
TCAM entries for ACEs, and there are 2K max h/w adjacencies reserved for PBR.

Of course, with ACL TCAM as many folks know, YMMV. Using ODM as the merge 
algorithm usually helps in this respect.

Tim

At 01:13 PM 2/16/2005, Arie Vayner averred:
>You have to be very careful not to run out of TCAM!
>Every ACL and every route-map would take some of it, and there is not
>enough of it for a large number of connections (like in an edge
>scenario)
>
>Arie
>
>-----Original Message-----
>From: cisco-nsp-bounces at puck.nether.net
>[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tim Stevenson
>Sent: Tuesday, February 15, 2005 7:10 PM
>To: Sam Stickland
>Cc: cisco-nsp at puck.nether.net
>Subject: Re: [c-nsp] Hardware accel. paths for policy routing on C6500
>
>As long as you match on DSCP using an ACL, it is in hardware. ie:
>
>access-list 101 permit ip any any dscp cs5
>
>or similar.
>
>Tim
>
>At 08:56 AM 2/15/2005, Sam Stickland averred:
> >Is matching against dscp values also in done in software?
> >
> >Sam
> >
> >On Tue, 15 Feb 2005, Tim Stevenson wrote:
> >
> >>Correct, match ip community will force software switching.
> >>
> >>We support match ip address, set ip next-hop, set ip default next-hop,
>
> >>and set interface null0 in hardware - anything else is in software.
> >>
> >>Tim
> >>
> >>At 06:44 AM 2/15/2005, Sam Stickland averred:
> >>>On Tue, 25 Jan 2005, Per Carlson wrote:
> >>> > Sam Stickland wrote:
> >>> >> Measuring traffic from the customer to our peers is easy (simply
> >>> provision
> >>> >> another BGP session only containing peer route). Traffic from our
> >>> peers to
> >>> >> our customers is more difficult. Since there'd be two possible
> >>> >> paths
> >>> from
> >>> >> our network to the customers (full and partial), we'd need to
> >>> >> route
> >>> based
> >>> >> on the source address as well as the destination.
> >>> >>
> >>> >> My thinking is to dscp mark the traffic from our directly
> >>> >> connected
> >>> peers
> >>> >> (at the same point where we apply community tags), and then
> >>> >> policy
> >>> route on
> >>> >> the customers directly attached interface.
> >>> >
> >>> > afaik, policy routing is enabled on the *ingress* interface. from
> >>> > the
> >>> cisco
> >>> > config guide (http://tinyurl.com/2o5m7 [1])
> >>>Oh, of course you're right. Well that makes this a litte bit trickier
>
> >>>doesn't it?
> >>> > you would need to create route-maps matching the customer prefixes
> >>> with the
> >>> > right next-hop, like
> >>> >
> >>> > route-map partitial permit 10
> >>> >  match ip address cust1_prefixes
> >>> >  set ip next-hop 1.1.1.1
> >>> > route-map partitial permit 20
> >>> >  match ip address cust2_prefixes
> >>> >  set ip next-hop 2.2.2.2
> >>>Wouldn't this need to be:
> >>>route-map partitial permit 10
> >>>     match ip community 10
> >>>     match ip address cust1_prefixes
> >>>     set ip next-hop 1.1.1.1
> >>>route-map partitial permit 20
> >>>     match ip community 10
> >>>     match ip address cust2_prefixes
> >>>     set ip next-hop 2.2.2.2
> >>>Since we won't to not only match where the traffic is going, but also
>
> >>>where it is from (ie. direct traffic from directly connected peers to
>
> >>>a different next-hop). It would be nice if we could match this via
> >>>community, but once again I fear that this information isn't going to
>
> >>>be available at this point in the hardware?
> >>>Sam
> >>> > this doesn't scale well, you would need to maintain separate acl's
> >>> for each
> >>> > customer with all their prefixes. sure it would be maintainable
> >>> > with a handful of customers with a handful of prefixes each.
> >>> >
> >>> > i've been looking into this as well, but more or less given up the
>
> >>> > pbr track.
> >>> >
> >>> > i'd love if you could do it the following way:
> >>> >
> >>> > route-map partitial permit 10
> >>> >  match ip destination as-path 1
> >>> >  set ip next-hop 1.1.1.1
> >>> >
> >>> > ip as-path access-list 1 permit 1234
> >>> >
> >>> > this approach would be rather hard to do in hardware tough :-( if
> >>> > the cef-table did have information about the as number, it might
> >>> > be
> >>> possible...
> >>> >
> >>> > per
> >>> >
> >>> > [1]
> >>> >
> >>> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122c
> >>> gcr/fipr_c/ipcprt2/1cfindep.htm#wp1001398
> >>> >
> >>> >
> >>>_______________________________________________
> >>>cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >>>https://puck.nether.net/mailman/listinfo/cisco-nsp
> >>>archive at http://puck.nether.net/pipermail/cisco-nsp/
> >>
> >>
> >>
> >>Tim Stevenson, tstevens at cisco.com
> >>Routing & Switching CCIE #5561
> >>Technical Marketing Engineer, Catalyst 6500 Cisco Systems,
> >>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, tstevens at cisco.com
>Routing & Switching CCIE #5561
>Technical Marketing Engineer, Catalyst 6500 Cisco Systems,
>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-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>

Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Catalyst 6500
Cisco Systems, 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.