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

[Tim Stevenson]

Correct, match ip community will force software switching.

We support match ip address, set ip next-hop, set ip default next-hop, and 
set interface null0 in hardware - anything else is in software.

Tim

At 06:44 AM 2/15/2005, Sam Stickland averred:
>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
> >
> >
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/



Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Catalyst 6500
Cisco Systems, http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.