bgp_path multiple AS match on single rule
Hello, I'm wondering, is there any way to configure following example to single rule only. if bgp_path ~ [= * 100 * =] then return false; if bgp_path ~ [= * 200 * =] then return false; if bgp_path ~ [= * 300 * =] then return false; if bgp_path ~ [= * 400 * =] then return false; On this way, If we want to filter many ASs, it seems that we should generate too much rows. On Cisco we can implement it like following example: AS path access list 85 deny _(100|200|300|400)_ permit .* Thanks in advance! Best~ -- --- Find out about our new Cloud service - Cloudware.bg <http://cloudware.bg/?utm_source=email&utm_medium=signature&utm_content=link&utm_campaign=newwebsite> Access anywhere. Manage it yourself. Pay as you go. ------------------------------------------------------------------------ *Javor Kliachev* IP Engineer Neterra Ltd. Telephone: +359 2 975 16 16 Fax: +359 2 975 34 36 www.neterra.net <http://www.neterra.net>
On Mon, Jul 08, 2013 at 09:35:02AM +0300, Javor Kliachev wrote:
Hello,
I'm wondering, is there any way to configure following example to single rule only.
if bgp_path ~ [= * 100 * =] then return false; if bgp_path ~ [= * 200 * =] then return false; if bgp_path ~ [= * 300 * =] then return false; if bgp_path ~ [= * 400 * =] then return false;
On this way, If we want to filter many ASs, it seems that we should generate too much rows.
Well, you could replace that with this: if 10 ~ bgp_path then return false; which is probably slightly faster, but you still need all the rows. If you would test just for last (or first) ASN, you could use: if bgp_path.last ~ [10, 20, 30, 40, ... ] then return false; Perhaps we should implement this: if bgp_path ~ [10, 20, 30, 40, ... ] then return false; (i.e. check every ASN from bgp_path against set of numbers) That would be simple to implement, consistent with our filtering features for community lists and works fast for a large sets of ASN. We don't support full regular expressions for bgp_path matching, just the shell-like wildcard patterns. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Dear Ondrej, Thanks for the detailed response. We will be very happy if this feature be implemented soon. Best~ On 07/09/2013 12:02 PM, Ondrej Zajicek wrote:
On Mon, Jul 08, 2013 at 09:35:02AM +0300, Javor Kliachev wrote:
Hello,
I'm wondering, is there any way to configure following example to single rule only.
if bgp_path ~ [= * 100 * =] then return false; if bgp_path ~ [= * 200 * =] then return false; if bgp_path ~ [= * 300 * =] then return false; if bgp_path ~ [= * 400 * =] then return false;
On this way, If we want to filter many ASs, it seems that we should generate too much rows. Well, you could replace that with this:
if 10 ~ bgp_path then return false;
which is probably slightly faster, but you still need all the rows. If you would test just for last (or first) ASN, you could use:
if bgp_path.last ~ [10, 20, 30, 40, ... ] then return false;
Perhaps we should implement this:
if bgp_path ~ [10, 20, 30, 40, ... ] then return false;
(i.e. check every ASN from bgp_path against set of numbers) That would be simple to implement, consistent with our filtering features for community lists and works fast for a large sets of ASN.
We don't support full regular expressions for bgp_path matching, just the shell-like wildcard patterns.
-- --- Find out about our new Cloud service - Cloudware.bg <http://cloudware.bg/?utm_source=email&utm_medium=signature&utm_content=link&utm_campaign=newwebsite> Access anywhere. Manage it yourself. Pay as you go. ------------------------------------------------------------------------ *Javor Kliachev* IP Engineer Neterra Ltd. Telephone: +359 2 975 16 16 Fax: +359 2 975 34 36 www.neterra.net <http://www.neterra.net>
On Tue, Jul 09, 2013 at 11:43:50AM +0300, Javor Kliachev wrote:
Dear Ondrej,
Thanks for the detailed response.
We will be very happy if this feature be implemented soon.
You could try attached patch. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello, I have some troubles defining a pair set object using the following assignment: PAIR=[(X,1:1001)]; Where X is predefined integer variable with assigned value. Upon multiple issueing of the "configure" statement, BIRD sometimes complains about unproer values used in the assignment and sometimes not. Like this: BIRD 1.3.9 ready. bird> conf Reading configuration from /usr/local/bird-new/etc/bird.conf Reconfigured Immediately after: bird> configure Reading configuration from /usr/local/bird-new/etc/bird.conf /usr/local/bird-new/etc/functions3.conf, line 281: Value 31343232 out of range (0-65535) bird> The actual line 281: roopoi=[(RoO,1001..1999)]; RoO is an integer (inside the interval 0:65535) passed as a function argument: function M_BGP_OUT (int peer_as; int RoO; bool LOCAL) pair NOEXP; pair set roopoi; Bird version 1.3.9. It seems recursive assignment for variables of this particular type is not allowed. Is there a fix or workaround for achieving this functionality, despite the pure numerical assignment? Thank you! -- --- Find out about our new Cloud service - Cloudware.bg Access anywhere. Manage it yourself. Pay as you go. Javor Kliachev IP Engineer Neterra Ltd. Telephone: +359 2 975 16 16 Fax: +359 2 975 34 36 www.neterra.net
On Fri, Jul 26, 2013 at 10:01:30AM +0300, Javor Kliachev wrote:
Hello,
I have some troubles defining a pair set object using the following assignment:
Reading configuration from /usr/local/bird-new/etc/bird.conf /usr/local/bird-new/etc/functions3.conf, line 281: Value 31343232 out of range (0-65535) bird>
The actual line 281:
roopoi=[(RoO,1001..1999)]; ... It seems recursive assignment for variables of this particular type is not allowed.
Yes, pair sets are preprocessed during reading config files, so only constant expressions are allowed in them. The nonsensical error message 'Value 31343232 out of range' is a result of a bug - some random value is used instead of void value. But the fix for this bug would not help you.
Is there a fix or workaround for achieving this functionality, despite the pure numerical assignment?
Probably no, you have to define separate functions with constant pair sets. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi Ondrej, Thanks you for the explanation. Best~ On 07/26/2013 12:00 PM, Ondrej Zajicek wrote:
On Fri, Jul 26, 2013 at 10:01:30AM +0300, Javor Kliachev wrote:
Hello,
I have some troubles defining a pair set object using the following assignment:
Reading configuration from /usr/local/bird-new/etc/bird.conf /usr/local/bird-new/etc/functions3.conf, line 281: Value 31343232 out of range (0-65535) bird>
The actual line 281:
roopoi=[(RoO,1001..1999)]; ... It seems recursive assignment for variables of this particular type is not allowed. Yes, pair sets are preprocessed during reading config files, so only constant expressions are allowed in them. The nonsensical error message 'Value 31343232 out of range' is a result of a bug - some random value is used instead of void value. But the fix for this bug would not help you.
Is there a fix or workaround for achieving this functionality, despite the pure numerical assignment? Probably no, you have to define separate functions with constant pair sets.
-- --- Find out about our new Cloud service - Cloudware.bg <http://cloudware.bg/?utm_source=email&utm_medium=signature&utm_content=link&utm_campaign=newwebsite> Access anywhere. Manage it yourself. Pay as you go. ------------------------------------------------------------------------ *Javor Kliachev* IP Engineer Neterra Ltd. Telephone: +359 2 975 16 16 Fax: +359 2 975 34 36 www.neterra.net <http://www.neterra.net>
participants (2)
-
Javor Kliachev -
Ondrej Zajicek