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

[Sam Stickland]

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
>
>