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

[Sam Stickland]

Hi,

I've split this email into two versions:

Short Version: ;)

Would the following route-map used for policy routing be hardware 
accelerated on a SUP2/MFSC2/PFC2 combo?

   route-map ROUTE_PARTIAL permit 10
    match ip address match_partial
    set ip next-hop 1.2.3.4

   ip access-list extended ACL_MATCH_PARTIAL
     permit ip any any dscp af21

If the route-map is:

   route-map ROUTE_PARTIAL permit 10
    match ip address match_partial
    set ip next-hop 1.2.3.4  5.6.7.8

Then the router will try 1.2.3.4 if it's reachable, and if it's not it 
will go on to try 5.6.7.8 ?

Slightly longer version:

Our sales team would like to be able to sell our transit customers two 
types of transit. The standard, common or garden, global transit and 
"partial" transit. Partial transit would basically be traffic to and from 
our directly connected peers, and would be billed at a lower rate.

In order to measure and bill this traffic I'd like to be able to force it 
to take a seperate path at layer2, rather than measure and bill using 
Netflow. (This fits in much better with our current SNMP:IF-mib based 
billing infrastructure, which ties in semi-automatically with our accounts 
and invoicing system).

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.

Other than the hardware acceleration issues, does anyone see a problem in 
this? (Filtering issues and malevolent customers aside).

Sam