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

Wed Feb 16 17:20:08 EST 2005

Note, for Sup2, there are 1K, not 2K, h/w adjacencies reserved.

Tim

At 02:13 PM 2/16/2005, Tim Stevenson averred:
>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.

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.