Здесь описывается, как клиентам маршрутизировать свой трафик в blackhole.

Время от времени у клиентов возникает необходимость "отсеивать" нежелательный трафик на свои IP
со стороны своего ISP. На контакт с администратором ISP (описание ситуации, просьба зафильтровать
трафик на указанные адреса или отмаршрутизировать этот трафик в Null, если фильтра не помогают)
в телефонном режиме или через e-mail как правило уходит много времени. Что если разрешить клиентам
самим управлять маршрутизацией в Null нежелательного трафика на свои адреса на оборудовании ISP?

При условии, что клиент уже имеет BGP peering со своим провайдером, существует довольно простой
и безопасный метод, позволяющий клиентам настроить это в "неинтерактивном" режиме с ISP.

Для осуществления подобной схемы мы предлагаем клиентам анонсировать prefix в пиринг с нами
в специальном community. Как только наш роутер "увидит" новый анонс в этом community, он
просто поменяет next-hop атрибут на адрес, который уже "заворачивается" в Null0/discard на
наших маршрутизаторах.
Необходимая часть конфига:
Пример конфига для Cisco на клиентской стороне:

!
! переходим в конфигурацию bgp router-а
!
router bgp 3333 (AS3333 взята для примера, вместо нее необходио указывать свою)
!
! разрешаем редистрибутировать "статику" с фильтрацией в соответствующей route-map-е
! static-to-bgp
!
redistribute static route-map static-to-bgp
!
! В route-map-е прописываем следующее
!
route-map static-to-bgp permit 5
match tag 7777
set community 21219:7777
!
! Маршрутизируем атакуемый ip в Null0 с tag-ом, чтобы "отловить" route-map-ой
!
ip route 192.168.0.1 255.255.255.255 Null0 tag 7777
!

Кроме того, возможно Вам придется установить атрибут send-community на наш neighbor и обновить
фильтр-полиси на исходящие анонсы, чтобы "пропускать" такие префиксы.
Если фильтрация организована с помощью prefix-list, то он должен быть аля:

ip prefix-list example permit 192.168.0.0/24 le 32

Пример конфига для Quagga/Zebra на клиентской стороне:

router bgp 3333
!
redistribute static route-map static-to-blackhole
!
route-map static-to-blackhole permit 5
match ip address  prefix-list prefix-to-blackhole
set community 21219:7777
!
ip prefix-list prefix-to-blackhole permit 192.168.0.1/32
!
ip route 192.168.0.1 255.255.255.255 Null0

Таким образом возможное развитие событий при DDoS атаке пойдет по такому сценарию:

1. Атака началась
2. Клиент устанавливает какой хост в его сети DDoS-ят
3. Cisco: Клиент маршрутизирует статически этот ip на своем маршрутизаторе с тагом, чтобы анонс ушел к нам по BGP:
ip route host.under.attack 255.255.255.255 Null0 tag 7777
Quagga: Клиент маршрутизирует статически этот ip на своем маршрутизаторе и добавляет его в prefix-to-blackhole, чтобы анонс ушел к нам по BGP.

4. анонс по BGP приходит в community 21219:7777 на наш маршрутизатор
5. Трафик на IP из community 21219:7777 на нашей стороне уходит в Null, клиент спасен.
6. Трафик на IP из community 21219:7777 на стороне наших апстримов тоже уходит в Null, мы тоже спасены.

Если Вас заинтересовало подобное policy, Вы можете оттестировать его на каком-либо IP из Вашей сети, который
в данный момент не используется. И проверить traceroute-ом с "внешних" Looking Glass-ов.