Hi, We're about to migrate our exchange to a /23 and we're likely going to do it over time. I have a simple filter in place to check and make sure that the NEXT_HOP is within our exchange's subnet. Originally it looked like this: function check_ixp_next_hop(ip nexthop) prefix ixpnet; { ixpnet = x.x.x.x/24; if ! (nexthop ~ ixpnet) then return false; return true; } And then within the inbound filter for each peer's ASN: if ! (check_ixp_next_hop(bgp_next_hop)) then reject; Since we're going to be caring about two distinct prefixes while we perform the migration, I changed the filter to look like this: function check_ixp_next_hop(ip nexthop) prefix set ixpnet; { ixpnet = [ x.x.x.x/24, y.y.y.y/23 ]; if ! (nexthop ~ ixpnet) then return false; return true; } However I'm getting the following errors in the log: 07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:04 <ERR> filters, line 61: ~ applied on unknown type pair Am I missing something? Thanks, -JJ
However I'm getting the following errors in the log:
07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:04 <ERR> filters, line 61: ~ applied on unknown type pair
Am I missing something?
Thanks,
What version of BIRD you are using? I can confirm this on 1.3.9. On current upstream (and probably on 1.3.11 also) everything is ok.
-JJ
-- SP5474-RIPE Sergey Popovich
В письме от 8 ноября 2013 10:08:39 пользователь Sergey Popovich написал:
However I'm getting the following errors in the log:
07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:04 <ERR> filters, line 61: ~ applied on unknown type pair
Am I missing something?
Thanks,
What version of BIRD you are using? I can confirm this on 1.3.9. On current upstream (and probably on 1.3.11 also) everything is ok.
Sorry, 1.3.11 also affected.
-JJ
-- SP5474-RIPE Sergey Popovich
(sorry, replying-all this time) I'm using 1.3.11, compiled from source on Debian 7.1 amd64. On Fri, Nov 8, 2013 at 3:13 AM, Sergey Popovich <popovich_sergei@mail.ru>wrote:
В письме от 8 ноября 2013 10:08:39 пользователь Sergey Popovich написал:
However I'm getting the following errors in the log:
07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:04 <ERR> filters, line 61: ~ applied on unknown type pair
Am I missing something?
Thanks,
What version of BIRD you are using? I can confirm this on 1.3.9. On current upstream (and probably on 1.3.11 also) everything is ok.
Sorry, 1.3.11 also affected.
-JJ
-- SP5474-RIPE Sergey Popovich
Okay - assuming this may be a bug. This did work when I wasn't using the ~ operator on a prefix set, but when using it to compare the NEXT_HOP to a single prefix to determine if that IP was in the subnet. Is it possible to implement a workaround with a nested if or a case statement and compare the two prefixes separately without the use of the prefix set data type? Thanks, -JJ
On Nov 8, 2013, at 3:13 AM, Sergey Popovich <popovich_sergei@mail.ru> wrote:
В письме от 8 ноября 2013 10:08:39 пользователь Sergey Popovich написал:
However I'm getting the following errors in the log:
07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:04 <ERR> filters, line 61: ~ applied on unknown type pair
Am I missing something?
Thanks,
What version of BIRD you are using? I can confirm this on 1.3.9. On current upstream (and probably on 1.3.11 also) everything is ok.
Sorry, 1.3.11 also affected.
-JJ
-- SP5474-RIPE Sergey Popovich
В письме от 8 ноября 2013 03:53:16 Вы написали:
Okay - assuming this may be a bug. This did work when I wasn't using the ~ operator on a prefix set, but when using it to compare the NEXT_HOP to a single prefix to determine if that IP was in the subnet.
Is it possible to implement a workaround with a nested if or a case statement and compare the two prefixes separately without the use of the prefix set data type?
Thanks,
-JJ
On Nov 8, 2013, at 3:13 AM, Sergey Popovich <popovich_sergei@mail.ru> wrote:> В письме от 8 ноября 2013 10:08:39 пользователь Sergey Popovich написал:
However I'm getting the following errors in the log:
07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:00 <ERR> filters, line 61: ~ applied on unknown type pair 07-11-2013 12:33:04 <ERR> filters, line 61: ~ applied on unknown type pair
Right. Could you try attached patch? It seems matching an IP address to prefix set using ~ operator not implemented in BIRD. -- SP5474-RIPE Sergey Popovich
В письме от 7 ноября 2013 16:05:50 пользователь John Jensen написал:
Hi,
We're about to migrate our exchange to a /23 and we're likely going to do it over time. I have a simple filter in place to check and make sure that the NEXT_HOP is within our exchange's subnet. Originally it looked like this:
function check_ixp_next_hop(ip nexthop) prefix ixpnet; { ixpnet = x.x.x.x/24; if ! (nexthop ~ ixpnet) then return false; return true; }
And then within the inbound filter for each peer's ASN:
if ! (check_ixp_next_hop(bgp_next_hop)) then reject;
Since we're going to be caring about two distinct prefixes while we perform the migration, I changed the filter to look like this:
function check_ixp_next_hop(ip nexthop) prefix set ixpnet; { ixpnet = [ x.x.x.x/24, y.y.y.y/23 ];
Also, pay attention, you should use something like ixpnet = [ x.x.x.x/24+, y.y.y.y/23+ ]; To match subnets.
if ! (nexthop ~ ixpnet) then return false; return true; }
Even simpler: ------------- function check_ixp_next_hop(ip nexthop) { return nexthop ~ [ x.x.x.x/24+, y.y.y.y/23+ ]; } -- SP5474-RIPE Sergey Popovich
Thanks for the function optimization. This does indeed make it simpler! I also believe I had misunderstood the documentation when I expected this to work - obviously "ip" and "prefix" are different types, and now that I've re-read the documentation on the ~ operator - "it can be used on element and set of elements of the same type " My apologies. I appreciate the patch and will apply it shortly. Thanks, -JJ On Fri, Nov 8, 2013 at 3:58 AM, Sergey Popovich <popovich_sergei@mail.ru>wrote:
В письме от 7 ноября 2013 16:05:50 пользователь John Jensen написал:
Hi,
We're about to migrate our exchange to a /23 and we're likely going to do it over time. I have a simple filter in place to check and make sure that the NEXT_HOP is within our exchange's subnet. Originally it looked like this:
function check_ixp_next_hop(ip nexthop) prefix ixpnet; { ixpnet = x.x.x.x/24; if ! (nexthop ~ ixpnet) then return false; return true; }
And then within the inbound filter for each peer's ASN:
if ! (check_ixp_next_hop(bgp_next_hop)) then reject;
Since we're going to be caring about two distinct prefixes while we perform the migration, I changed the filter to look like this:
function check_ixp_next_hop(ip nexthop) prefix set ixpnet; { ixpnet = [ x.x.x.x/24, y.y.y.y/23 ];
Also, pay attention, you should use something like
ixpnet = [ x.x.x.x/24+, y.y.y.y/23+ ];
To match subnets.
if ! (nexthop ~ ixpnet) then return false; return true; }
Even simpler: -------------
function check_ixp_next_hop(ip nexthop) { return nexthop ~ [ x.x.x.x/24+, y.y.y.y/23+ ]; }
-- SP5474-RIPE Sergey Popovich
Again, speaking too soon here. Sorry for the spam. I read the documentation again - the ~ operator can be used with an "ip" type on the left and a "prefix" type on the right. So it would seem as though applying this to a prefix set should be something useful/an extension of checking if an IP is within a single prefix. I'll post back when I've applied the patch to let folks know if it worked. Thanks again! -JJ On Fri, Nov 8, 2013 at 12:08 PM, John Jensen <jensenja@gmail.com> wrote:
Thanks for the function optimization. This does indeed make it simpler! I also believe I had misunderstood the documentation when I expected this to work - obviously "ip" and "prefix" are different types, and now that I've re-read the documentation on the ~ operator - "it can be used on element and set of elements of the same type "
My apologies. I appreciate the patch and will apply it shortly.
Thanks,
-JJ
On Fri, Nov 8, 2013 at 3:58 AM, Sergey Popovich <popovich_sergei@mail.ru>wrote:
В письме от 7 ноября 2013 16:05:50 пользователь John Jensen написал:
Hi,
We're about to migrate our exchange to a /23 and we're likely going to do it over time. I have a simple filter in place to check and make sure that the NEXT_HOP is within our exchange's subnet. Originally it looked like this:
function check_ixp_next_hop(ip nexthop) prefix ixpnet; { ixpnet = x.x.x.x/24; if ! (nexthop ~ ixpnet) then return false; return true; }
And then within the inbound filter for each peer's ASN:
if ! (check_ixp_next_hop(bgp_next_hop)) then reject;
Since we're going to be caring about two distinct prefixes while we perform the migration, I changed the filter to look like this:
function check_ixp_next_hop(ip nexthop) prefix set ixpnet; { ixpnet = [ x.x.x.x/24, y.y.y.y/23 ];
Also, pay attention, you should use something like
ixpnet = [ x.x.x.x/24+, y.y.y.y/23+ ];
To match subnets.
if ! (nexthop ~ ixpnet) then return false; return true; }
Even simpler: -------------
function check_ixp_next_hop(ip nexthop) { return nexthop ~ [ x.x.x.x/24+, y.y.y.y/23+ ]; }
-- SP5474-RIPE Sergey Popovich
participants (2)
-
John Jensen -
Sergey Popovich