The newer IOS code appears to convert the ACL match rules into prefix lists. They would still be less efficient from the initial processing perspective. But from an update processing perspective I am guessing they are competitive with prefix lists.
Eliminating anything with regex is obviously the first thing to speed routing updates. Keeping any as-path and community match rules short would be the second thing. Keep the number of route-map entries small. Route maps are definitely one place where shorter is better. Mack McBride Network Architect -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Keegan Holley Sent: Sunday, September 05, 2010 9:06 AM To: Łukasz Bromirski Cc: [email protected] Subject: Re: [c-nsp] C65K: Any significant correlation between import filter route-map complexity and BGP Router process utilization? No worries... I'll try to use more than one sentence when I post in the future. To answer the original poster's question the only way to cut down on cpu usage for routing updates is to use prefix lists with the shortest bit masks possible. They were created especially for this purpose although the software architecture details escape me at the moment. 2010/9/5 Łukasz Bromirski <[email protected]> > On 2010-09-05 04:11, Keegan Holley wrote: > > I understand turbo ACLs. I was saying that the enhancements only apply > to > > packet manipulations not routing protocols. I'm not sure if it is > causing > > the issues that started this thread, but the only way to optimize route > > filters is to use prefix lists to match the routes. For example all the > > items in the link you sent pertain to packet filtering, QOS or natting. > > Correct me if I'm wrong but, I don't believe the improvements in ACL > > processing applied to those used for route filters. > > Right, if the ACL is used for route manipulation, CPU has to process it > and there's no added value in hardware processing even if platform > supports it. Sorry, I didn't get your point. > > -- > "Everything will be okay in the end. | Łukasz Bromirski > If it's not okay, it's not the end." | http://lukasz.bromirski.net > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
