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

[Sam Stickland]

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/122cgcr/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.
>