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