2021-02-01 13:20:00
Хорошая попытка разбора терминологии Bogons и Martians применительно к адресному пространству, включая ASn. Итог,
Bogons=Martians + Unallocated Address Space at IANA and RIRs/NIRs. Всё то, что ни под каким видом не должно появляться в вашей таблице маршрутизации и/или при передаче из вашей сети или в вашу сеть.
В статье нет списка с сетями, хотя есть ссылки на RFC. Попробуем восполнить пробел, применительно к границе сети и Интернет в обе стороны, от вас эти сети тоже не должны улетать:
0.0.0.0/8
10.0.0.0/8
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.0.0/24, кроме
192.0.0.9,
192.0.0.10
192.0.2.0/24
192.88.99.0/24
192.168.0.0/16
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
224.0.0.0/3
Для IPv6 из Интернет не стоит ожидать ничего отличающегося от 2000::/3 из которого надо исключить:
2001::/23, кроме
2001:1::1,
2001:1::2,
2001:3::
2001:4:112::/48 и
2001:20::/28
2002::/16
Сюда же включаются и ваши собственные сети со стороны Интернет и запросы к сетям которые вы не маршрутизируете. Это ни в коем случае не исчерпывающий список (тут как минимум не хватает ещё не распределённых сетей) и может быть не совсем правильный для вашей ситуации, будьте аккуратней с мультикаст и локальными частными сетями они вполне могут быть использованы на пограничных стыках. И не забывайте про dataplane - мало добавить это в фильтры BGP это надо сделать и в ACL на интерфейсах.
Что касается ASn и куда дополнительно, я думаю, можно добавить ещё и запрет работать с AS_SET как рекомендует RFC6472 и что сделали в OpenBGPd одной опцией и в Bird тоже можно.
Если вы большой транзитный оператор с сотнями клиентов, которые тоже являются большими транзитными операторами, то конечно так однозначно и просто избавиться от bogons анонсов и трафика не получится. Но положа руку на сердце, большинство владельцев сетей в мире не являются такими, они просто этим не занимаются.
663 views10:20