Hi! Travis
The access-list that you are going to put on the BGP peering session comes
into play only when you are activating the sessions. Let us say your
upstream ISP is sending you all the table and you are filtering out the AS
path, this happens only once for all the 70000 odd table.
Hence the CPU load is not persistent.
Also you go through the as-path access-list when new notifications like
addtion or withdrawn routes comes to your router..
So I think it is more of a one time load everytime you reset the bgp
session.
All the best
Bye
Mani
-----Original Message-----
From: Travis Pugh <tpugh@shore.net>
To: cisco-nsp@puck.nether.net <cisco-nsp@puck.nether.net>
Date: Tuesday, June 13, 2000 8:45 PM
Subject: [nsp] BGP Regex overhead
>
>I'm sitting here writing a new as-path access-list for a peer, and a
>question popped into my head:
>
>Is there any reference that gives some idea of the processor overhead of a
>given regular expression operand? In particular, if I do
>
>as-path access-list 1 permit ^100_((200|300|400|500)_)*$
>
>on the command line, it seems a lot faster than
>
>as-path access-list 1 permit ^100_((200|300|400|500)_)+$
>
>(which requires at least one instance of 200, 300, 400, or 500 in the path
>for a match). This all makes sense, of course, but I am curious how much
>of a performance penalty is incurred when a + or [] are used to whittle
>down path matches. An additional question (perhaps more relevant to the
>real world) is whether:
>
>permit ^100_200$
>permit ^100_300$
>permit ^100_400$
>
>is any faster than:
>
>permit ^100_(200$|300$|400$)
>
>or
>
>permit ^100_(200|300|400)$
>
>Any pointers of guesses appreciated.
>
>Thanks.
>
>-travis
>
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:13 EDT