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

[Arie Vayner]

You have to be very careful not to run out of TCAM!
Every ACL and every route-map would take some of it, and there is not
enough of it for a large number of connections (like in an edge
scenario)

Arie 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tim Stevenson
Sent: Tuesday, February 15, 2005 7:10 PM
To: Sam Stickland
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Hardware accel. paths for policy routing on C6500

As long as you match on DSCP using an ACL, it is in hardware. ie:

access-list 101 permit ip any any dscp cs5

or similar.

Tim

At 08:56 AM 2/15/2005, Sam Stickland averred:
>Is matching against dscp values also in done in software?
>
>Sam
>
>On Tue, 15 Feb 2005, Tim Stevenson wrote:
>
>>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/122c
>>> gcr/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.



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.
_______________________________________________
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/