Добрый день!

Подскажите как правильно реализовать такую схему: все в bgp. Клиенты, аплинки и IX`ы. Бывает клиент нам анонсит less-specific, а в IX more specific, который мы тоже получаем. Мы соответственно аплинкам отдаем его less specific. Т.е. трафик пришедший к нам с аплинка роутер должен передать в IX, ведь там он видит more specific. Внимание вопрос - как с IX`ов зафильтровать more specific маршруты если у нас есть less specific от клиента? При этом роутеров где клиенты и где IX`ы несколько.

У вас должно существовать и обрабатываться community no-readvertise, если нужно чтобы анонс клиента не уходил за пределы вашей AS. А фильтровать не надо.

Нужно чтобы уходил. Клиенту предоставляется обычный IP-transit.

У циски есть conditional advertisement, как раз для изменения анонсов по условию отсутствия-наличия префикса.
Но использование таких штук по-моему плохой дизайн, эта задача должна решаться в ЗО клиента.

Ну так дело в том, что клиент хитрожопый и за проблему это не считает. Он хочет и тут и тут. И чтобы летел трафик к нему с IX, т.к. дешево. А то, что в нашей AS при этом получается мы покупаем трафик у аплинка и отдаем его практически забесплатно в IX - клиента не колышет.

Похоже не пойдёт.. Ведь мне нужно принимать решение не об анонсировании, а о фильтрации принимаемых анонсов. conditional advertisement это что то вроде "если есть такое то маршрут, то мы анонсируем такой то. Если его нет, то и мы не анонсируем такой то". А мне нужна логика вроде "если есть такой маршрут, то мы фильтруем другой маршрут оттуда то, а если его нет, то не фильтруем".

Тогда увы, по-моему кроме как созданием vrf для иксов, или для клиентов, иначе это не решить.
С последующими роут-ликами.

Тоже навязчиво вертится в голове такой вариант, но это куча усложнений в схемах и т.п. прелести типа ещё одной кучи которую надо будет ворошить при траблшутинге... всё ещё таю надежду что есть более легкий способ..

https://nag.ru/articles/article/102518/igryi-s-anonsami-less-specific-i-more-specific-ili-iz-za-chego-stradayut-klientyi.html ?

Да, только там реализовано решение о дропе этого трафика А как его не дропать, а отправлять по less-specific.. в комментах хвалятся такой реализацией, но не раскрывают.

Думаю всё проще, скриптовая проверка fib роутера, с прибиванием пойманных спецификов внутри сети без анонса их наружу.
Даже раз в полчаса проверять достаточно.
Я вот тоже понял что ваш вопрос для меня актуален, и изо всех придуманных вариантов по-моему это получится самая простая реализация. Иначе надо держать 4 врфа - иксы, международка, клиенты, и врф куда сливаются все маршруты.

Под прибиванием вы статики имеете ввиду?

Да без разницы - или статика, или заскриптовать на RR и раздавать на внутренние роутеры с community no-readvertise. Причём если сливать с бордеров rib полностью , то можно и не лазить на них для анализа префиксов.

И вы считаете это красивое решение, если есть например десятки клиентов с AS-SET под 10тыс префиксов у каждого?

Я не сказал что это красивое решение, я написал "простое".

Боюсь уж слишком простое На столько простое что сильно пахнет опасным костылём

У меня в транзите роутер с MPC1, где нежелательно удваивать fullview. Иного решения кроме 4 vrf я не вижу, например.

Да и схема с несколькими vrf тоже не сильно удачна. В статье приведенной выше участником qwexak в комментариях точно есть человек из РЕТН, который пишет что у них реализовано гораздо проще. Но не признается как

Ну обычно это означает применение костылей.
Иначе сердито буркают про документацию, пункт такой-то, и всё, пошёл скролить интернет дальше.

Не думали над вариантом поместить клиентов и иксы в один routing-instance virtual-router например, с дефолтом next-table на международку?

Примерно такие схемы сейчас и обсуждаем.

А зачем вообще принимать клиентские префиксы от IX? Да и все равно фильтры же по RADb строятся, что мешает more specific префикс фильтровать при наличии less specific?

А как же распознать, что IX шлет нам в том числе префиксы наших клиентов? Клиенты при этом, у нас довольно часто перестают быть клиентами и наоборот, возвращаются и снова становятся клиентами. Какое автоматическое решение существует для этого?




Вот в этом и вся тема - как это сделать?
Наличие же роут объектов в RADB не диктует ведь обязательное требование их анонсировать. У нас многие имея в своем AS-SET тысячи записей анонсируют нам только сотню префиксов. А то и десяток.

ps да и статус самой RADB весьма сомнителен. Удобно конечно, что всё слито в едино, но ведь это всё равно не официальная помойка... но это уже оффтоп, мысли вслух.

А зачем это распознавать? Вы знаете что такая-то AS ваш клиент и если вы есть в евойном export'е, фильтруйте евойные анонсы с IX, иначе фильтруйте евойные анонсы по прямому линку. Это RADb-то не официально? Вы попробуйте проанонсировать что-то чего нет в AS-SET любому Tier 1'у.

У клиентов есть не только AS, но и многие с AS-SET`ами, которые каждый день меняются.



Не знаю кто как, а мы это давно не используем. Просто включаем клиентскую AS или её AS-SET в свой AS-SET и всё.




Ну и как это автоматом сделать, если клиентские AS-SET`ы, которые мы от них принимаем, каждый день меняются?



Вы уверены, что все тирваны используют RADB, для подтягивания вашего as-set, а не региональные регистраторы?

А что мешает обновлять фильтры каждый час? RADb для того и есть чтобы это дело автоматизировать. Как что устроено у апстримов я доподлинно не ведаю, но не представляю зачем что-то придумывать при наличии стандартной стабильно работающей системы.