Фільтр чорного отвору (RTBH) з дистанційним запуском BGP для ялівцю

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

Фільтр повинен:

1. Приймайте лише клієнти власні префікси зі списку префіксів
2. Лише приймати / 32 префікси
3. Тільки префікси з спільнотою blackhole
4. Встановити наступний перехід на RTBH наступний перехід (192.0.2.1)

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

Спершу я подумав про поєднання prefix-list-filterмаршрутів, які відповідають лише спискам клієнтів, і 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 знаходиться в діапазоні замовника, відповідає його як-шляху і має спільноту blackhole:

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;
        }
..
}

Таким чином має бути логічним І. Але я дійсно не бачу значення у створенні складності для зменшення виразності конфігурації.