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

[Per Carlson]

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

"To enable policy routing on an interface, indicate which route map the
  router should use by using the following command in interface
  configuration mode. A packet arriving on the specified interface will
                               ^^^^^^^^
  be subject to policy routing except when its destination IP address is
  the same as the IP address of the router's interface."

the good thing is that you don't need to tag the packets from the 
connected peers, a route-map applied on those interfaces will take care 
of that. the bad thing is that you have got to match the packets based 
on destination prefixes.

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

and so forth.

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