Фильтр черной дыры (RTBH) BGP для Juniper

Я пытаюсь найти самый элегантный способ реализовать фильтр RTBH для маршрутов, полученных от клиента.

Фильтр должен:

1. Принимайте только собственные префиксы клиентов из списка префиксов
2. Только принимать / 32 префикса
3. Только префиксы с сообществом blackhole
4. Установите следующий переход к следующему переходу RTBH (192.0.2.1)

Для начала я посмотрел документ « Настройка условий совпадения в условиях политики маршрутизации » от Juniper.

Сначала я подумал о комбинировании a prefix-list-filterдля сопоставления только маршрутов из списка префиксов клиентов и a route-filterдля ограничения принятых префиксов до / 32, например, так:

from {
    as-path customer;
    community blackhole;
    prefix-list-filter customer-prefixes orlonger;
    route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}

Но потом я наткнулся на эту информацию в документе:

Если вы настраиваете политику, которая включает некоторую комбинацию фильтров маршрутов, списков префиксов и фильтров адресов источника, они оцениваются в соответствии с логической операцией ИЛИ или поиском совпадения с самым длинным маршрутом.

Как я понимаю , это (и я считаю , это немного неясно), если я использую prefix-list-filter, route-filterи / или source-address-filterв тот же срок он будет оцениваться с длинной-матч или между всеми ними, что делает этот подход непригодным для использования .

Я придумал следующий фильтр. Этот hostroutes-onlyтермин переводит все префиксы короче / 32 на следующую политику. После этого prefixesтермин совпадает, если / 32 находится в диапазоне клиента, совпадает с его as-path и имеет установленное сообщество черной дыры:

term hostroutes-only {
    from {
        route-filter 0.0.0.0/0 prefix-length-range /0-/31;
    }
    then next policy;
}
term prefixes {
    from {
        as-path customer;
        community blackhole;
        prefix-list-filter customer-prefixes orlonger;
    }
    then {
        next-hop 192.0.2.1;
        accept;
    }
}

Итак, это самый элегантный способ справиться с этим? Любые другие решения?

Нет никаких оснований ограничивать клиента только черной дырой / 32, разрешать ему черную дыру что-либо из них.

Что-то вроде этого:

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            prefix-list-filter AS42 orlonger;
        }
        then {
            community add NO-EXPORT;
            next-hop 192.0.2.1;
            accept;
        }
    }
    term advertise {
        from {
            prefix-list AS42;
        }
        then {
            community add ADVERTISE;
            next-hop peer-address;
            accept;
        }
    }
    term reject {
        then reject;
    }
}

Не забудьте установить 'accept-remote-nexthop' в настройках BGP, чтобы следующий переход мог быть изменен на что-то другое, чем адрес ссылки.

Я также решительно поддерживаю, что провайдеры начинают поддерживать разные сообщества черных дыр, а не просто «полную черную дыру». Особенно, если вы работаете в более чем одной стране, обычно атака осуществляется транзитом, и часто клиент фактически хочет получить доступ к пирингам внутри страны, поэтому полезно реализовать несколько уровней черной дыры:

1. Полный
2. За пределами местной страны (местный IXP, видны целые клиенты AS +)
3. Вне локального района (если применимо, как для меня это может быть 'Nordics')
4. Включить / исключить определенный пиринг-маршрутизатор в черной дыре

Я рад привести пример того, как реализовать нечто подобное с помощью JNPR DCU / SCU, при условии, что ваши пиринговые маршрутизаторы являются JNPR, но это возможно только с сообществами, просто немного более неловко.

Если вы абсолютно хотите ограничить возможности вашего клиента, вы можете добавить это:

policy-statement /32 {
    term /32 {
        from {
            route-filter 0.0.0.0/0 prefix-length-range /32-/32;
        }
        then accept;
    }
    term reject {
        then reject;
    }
}

policy-statement AS42-IN {
    term blackhole {
        from {
            community BLACKHOLE;
            policy /32;
            prefix-list-filter AS42 orlonger;
        }
..
}

Таким образом, это должно быть логическим И. Но я действительно не вижу смысла в создании сложности для уменьшения выразительности конфигурации.