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,-JJOn Fri, Nov 8, 2013 at 3:58 AM, Sergey Popovich <popovich_sergei@mail.ru> wrote:
÷ ÐÉÓØÍÅ ÏÔ 7 ÎÏÑÂÒÑ 2013 16:05:50 ÐÏÌØÚÏ×ÁÔÅÌØ John Jensen ÎÁÐÉÓÁÌ:
> Hi,Also, pay attention, you should use something like
>
> 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 ];
š š ixpnet = [ x.x.x.x/24+, y.y.y.y/23+ ];
To match subnets.
Even simpler:
> š if ! (nexthop ~ ixpnet) then return false;
> š return true;
> }
>
-------------
function check_ixp_next_hop(ip nexthop)
{
š return nexthop ~ [ x.x.x.x/24+, y.y.y.y/23+ ];
}
--
SP5474-RIPE
Sergey Popovich