 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
10 messages in net.nether.puck.cisco-nsp[c-nsp] Hardware accel. paths for pol...| From | Sent On | Attachments |
|---|---|---|
| Sam Stickland | Jan 24, 2005 12:27 pm | |
| lis...@hojmark.org | Jan 24, 2005 7:13 pm | |
| Per Carlson | Jan 25, 2005 2:27 am | |
| Sam Stickland | Feb 15, 2005 9:39 am | |
| Tim Stevenson | Feb 15, 2005 11:36 am | |
| Sam Stickland | Feb 15, 2005 11:51 am | |
| Tim Stevenson | Feb 15, 2005 12:11 pm | |
| Arie Vayner | Feb 16, 2005 4:13 pm | |
| Tim Stevenson | Feb 16, 2005 5:13 pm | |
| Tim Stevenson | Feb 16, 2005 5:20 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | [c-nsp] Hardware accel. paths for policy routing on C6500 | Actions... |
|---|---|---|
| From: | Per Carlson (ml...@carlson.homeunix.net) | |
| Date: | Jan 25, 2005 2:27:36 am | |
| List: | net.nether.puck.cisco-nsp | |
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