Перейти к содержимому
Калькуляторы

Игры с анонсами less specific и more specific, или из-за чего страдают клиенты

Материал: К написанию данной статьи меня сподвигли участившиеся случаи обращения сторонних провайдеров с проблемами о недоступности части ресурсов отдельных наших клиентов. Суть подобных проблем довольно проста, и заключается в желании клиентов получать более дешевый трафик с обменников с одной стороны, и нежелании ISPs осуществлять транзит трафика своих клиентов по схемам Uplink-->ISP-->IX-->Client, Uplink-→ISP-→Uplink-→Client, IX-→ISP-→IX-→Client, IX-→ISP-→Uplink-→Client с другой стороны. Полный текст

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за статью. Насколько я понимаю, основная идея просто дропать транзитный трафик upstream-upstream ix-ix upstream-ix При этом мы по прежнему платим за входящий трафик который мы дропнем. Понятно, что он не большой т.к. там ничего не работает. Но при отсутствии lg клиент не понимает в чем дело и просто уводит трафик на другого isp. По чему бы, все таки не фильтровать маршруты своих клиентов от ix и upstream ? понятно, что они могут меняться, но в as-path AS client то будет. Выделять все маршруты полученные от ix и upstreams с AS Client и дропать или удалять с forwafding-tabel. При таком подходе и у клиента все работает и провайдер в плюсе или есть какие то вилы ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Понять схему по set-ам тяжеловато, подскажите что будет при наличии таких фильтров если клиент уберет анонс своего /16 на стыке с isp, оставив его на ix?

P.S. Не принимать маршруты клиента с ix? Да не, бред какой-то, так он все поймет. Лучше в тихую подропать, пускай поищет почему у него что-то отъехало.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Зачем вам схема по set ? Если клиент уберет анонс в isp, то isp перестанет анонсить выше и трафика клиента не будет в обще. Бред ?, я думаю это самое разумное, что он поймет ? Да и как он поймет ? все равно это ваше право как isp. Если дропать, он ничего искать не будет просто напишет вам заявку, о чем автор и говорит. А вы будите ему объяснять какой он нехороший...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Руками более специфичные укажите у себя в таблице маршрутизации без анонса далее. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мы тут хотим уйти от ручной работы, а вы нас в каменный век...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Попытаюсь дополнить здесь содержимое статьи, заодно прокомментировать обсуждение.
Скрытой нитью в статье отражается преднамеренность подобных действий со стороны клиента, что подвтерждается и на практике. Наверное, только одна десятая из всех случаев - ошибка администрирования. Какой смысл отдавать более специфичный маршрут на обменник, при этом анонсировать менее специфичный своему аплинку? Почему нельзя аносировать во все линки одинаково? Все же знают, что у всех, кто пристутствует на обменнике, Local Preference для анонсов с IX всегда выше, чем для аплинков, и поэтому трафик от участников обменника клиент будет всегда получать через обменник. Специфики  здесь абсолютно не нужны. "Обьяснения о нехорошости " все клиенты безоговорочно принимают и немедленно исправляют ситуацию, что подтверждает осознанность их действий.
Фильтровать все клиенсткие анонсы с IX? Конечно нет же. Правильно выразил причину, почему этого не стоит делать, vurd. Во-первых, на каком основании? Только из-за отдельных "мудрых" клиентов? Во-вторых, да, действительно, что произойдет, если клиент снимет анонс с вас (своего аплинка), оставит его только через IX, и вы его отфильтруете? В лучшем случае вы его увидите в FV от своих апстримов и весь ваш трафик на такие префиксы пойдет через линки с апстримами вместо обменника (экономически теряете вы же). В худшем, вы его совсем потеряете в своих таблицах, чем нарушите связность.
В целом, подобная практика далеко не нова. Ей, как минимум, лет десять и применяется во многих крупных ISP. Из известных мне, Ростелеком, РЕТН...

 

Только что, BanZ4y сказал:

Мы тут хотим уйти от ручной работы, а вы нас в каменный век...

Все верно. Self Driving Network & Artificial Intelligence )))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

15 часов назад, SyJet сказал:

Руками более специфичные укажите у себя в таблице маршрутизации без анонса далее. 

Попробуйте, особенно для клиента, у которого распарсенный as-set включает несколько тысяч route-objects, большая часть из которых еще и агрегированна. И если таких клиентов далеко не один. Устанут ручки, и не только... Другой, не менее значимой, проблемой статиков является возможный blackhole трафика при падении канала без падения линка.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я, наверное повторюсь, но всё же. Кто виноват в том, что клиент вынужден нести дополнительные затраты организовывая дополнительный канал до IX, при этом получая теоретически более дешевую, быструю связанность с меньшими задержкой, джиттером и потерями? Ну не динамическая же маршрутизация! Как говорится, Интернет был задуман для работы в условиях атомной войны, а отдали коммерсам и они всё испортили. Увы, если в сумме затрат клиенту получается дешевле и качественнее, он будет искать такие обходные пути, а виновато будет коммерческое жлобство ISP, к которому он имеет прямой первый линк. Вы уже доигрались, что в приказном порядке федералов перевели на РТ. Теперь очередь за муниципалами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

18 минут назад, vodz сказал:

Я, наверное повторюсь, но всё же. Кто виноват в том, что клиент вынужден нести дополнительные затраты организовывая дополнительный канал до IX, при этом получая теоретически более дешевую, быструю связанность с меньшими задержкой, джиттером и потерями? Ну не динамическая же маршрутизация! Как говорится, Интернет был задуман для работы в условиях атомной войны, а отдали коммерсам и они всё испортили. Увы, если в сумме затрат клиенту получается дешевле и качественнее, он будет искать такие обходные пути, а виновато будет коммерческое жлобство ISP, к которому он имеет прямой первый линк. Вы уже доигрались, что в приказном порядке федералов перевели на РТ. Теперь очередь за муниципалами.

Почему жлобство ISP? Не клиента? Ведь ничего же не мешает отдавать свои анонсы ровно, и в IX-ы, и своим аплинкам, и не тянуть трафик тирванов через своих аплинков и обменник. Писалось же выше об этом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 01.12.2018 в 21:04, tec1 сказал:

В целом, подобная практика далеко не нова. Ей, как минимум, лет десять и применяется во многих крупных ISP. Из известных мне, Ростелеком, РЕТН...

Более того, практика несколько устарела. ReTN уже очень давно от неё отказался, отправляя кросс-пиринговый трафик по less-specific маршруту в стык с клиентом, без сизифовой работы по фильтрации морспецификов. В итоге и волки не голодные, и овцам нет повода для обид :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 02.12.2018 в 12:40, tec1 сказал:

Попробуйте, особенно для клиента, у которого распарсенный as-set включает несколько тысяч route-objects, большая часть из которых еще и агрегированна. И если таких клиентов далеко не один. Устанут ручки, и не только... Другой, не менее значимой, проблемой статиков является возможный blackhole трафика при падении канала без падения линка.

 Вы бог ? Умеете разпрарсить  бгп рукой ? И да, где бы такого клиента найти, который сумел несколько тыщ роут-обьектов создать. Типа ростелекома.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Цитата
1 час назад, evd сказал:

Более того, практика несколько устарела. ReTN уже очень давно от неё отказался, отправляя кросс-пиринговый трафик по less-specific маршруту в стык с клиентом, без сизифовой работы по фильтрации морспецификов. В итоге и волки не голодные, и овцам нет повода для обид :)

 

Вот и я про, что тупо блокировать это глупо, надо перенаправлять.  А есть инфа механизма ?

Но блокировку все равно надо оставить для залетного трафика..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 12/3/2018 в 21:30, evd сказал:

Более того, практика несколько устарела. ReTN уже очень давно от неё отказался, отправляя кросс-пиринговый трафик по less-specific маршруту в стык с клиентом, без сизифовой работы по фильтрации морспецификов. В итоге и волки не голодные, и овцам нет повода для обид :)

 

Года два назад еще было актуально). Спасибо за подсказку, Евгений. Попытаемся внедрить у себя ваш передовой опыт) 

 

В 12/3/2018 в 22:59, BanZ4y сказал:

Вот и я про, что тупо блокировать это глупо, надо перенаправлять.  А есть инфа механизма ?

Но блокировку все равно надо оставить для залетного трафика..

Мне кажется, механизмы те же, DCU/SCU, FBF. Без последнего явно никак...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 03.12.2018 в 21:59, BanZ4y сказал:

Вот и я про, что тупо блокировать это глупо, надо перенаправлять.  А есть инфа механизма ?

Но блокировку все равно надо оставить для залетного трафика..

Imho надо бы чуть по-другому: глупо ломать себе связность морспецификами, с невинным видом объясняя своим энд-юзерам, что-де все беды от криворукого аплинка. И в качестве доказательства демонстрируя трейсы в его сторону, но "забывчиво" обходя стороной вопрос об обратном маршруте :)

 

А "залётный" от пира трафик, для которого нет вообще никаких клиентских маршрутов, в т.ч. less-specific - да, блокируется. Пирам (как, впрочем, и аплинкам) гарантируется связность только с клиентами

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Цитата

Мне кажется, механизмы те же, DCU/SCU, FBF. Без последнего явно никак...

Я думал в сторону, пометить more specific  клиентские от ix/upstreams  и если трафик идет по ним через полиси менять им некст хоп на клиентский, но это под каждого клиента надо писать term и полиси на forwording-table.

Без PBR/

Мб у кого то есть уже от тестированное решение и он поделится...  

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

22 часа назад, tec1 сказал:

Мне кажется, механизмы те же

Правильно кажется :)

Механизм ровно тот же, что описан в статье. Надо только поменять цель: не дропать, а отправлять в клиентский лесспецифик (if any)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Цитата

цель: не дропать, а отправлять в клиентский лесспецифик (if any)

что это значит ? заставить железку сделать еще один lookup ?  или направить в определенный интерфейс или ip  ?

Если направлять в клиентский интерфейс, то надо для каждого клиента помечать сетки и выделять DCU вопрос по какому критерию ? по АС ?, что-то мне не нравиться этот вариант.

Этот фильтр будет расти пропорционально количеству клиентов + надо предусмотреть трафик от клиента к клиенту, чтобы не ушел через ix.

И при наличии таких фильтров какой смысл от more specific ot ix  в РТ если трафик туда не пойдет ?  

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

6 часов назад, evd сказал:

Правильно кажется :)

Механизм ровно тот же, что описан в статье. Надо только поменять цель: не дропать, а отправлять в клиентский лесспецифик (if any)

Евгений, в очередной раз спасибо за подсказку! 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

21 час назад, BanZ4y сказал:

что это значит ? заставить железку сделать еще один lookup ?

А есть альтернатива?

 

21 час назад, BanZ4y сказал:

Этот фильтр будет расти пропорционально количеству клиентов + надо предусмотреть трафик от клиента к клиенту, чтобы не ушел через ix.

И при наличии таких фильтров какой смысл от more specific ot ix  в РТ если трафик туда не пойдет ?  

Вообще-то речь изначально о кросс-пиринговом трафике. Клиентов эти ограничения не затрагивают ни разу, их исходящий трафик отправляется ровно туда, куда показывает bgp. Если по морспецифику в ix или в аплинк, значит так тому и быть, это их святое право

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 06.12.2018 в 22:28, evd сказал:

... А есть альтернатива? ...

Есть. Не слишком просто, но идеологически, кмк, более верно: https://gul-tech.livejournal.com/3790.html

К сожалению, исходный текст Гигзбурга overcoming-peer-fraud, похоже, затерялся.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Самое красивое решение - разносить по VRF.

1. VRF#1 - в нем живут только маршруты на клиентов и апстримы 

2. VRF#2 - в нем живут только маршруты на IX и на клиентов

3. VRF#3 - в нем уже стыки на клиентов

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

15 часов назад, ugluck сказал:

Есть. Не слишком просто, но идеологически, кмк, более верно: https://gul-tech.livejournal.com/3790.html

Завернуть пакет в vrf - это разве не "заставить железку сделать еще один lookup"? Альтернатива ихде? ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

15 часов назад, alexmern сказал:

Самое красивое решение - разносить по VRF.

1. VRF#1 - в нем живут только маршруты на клиентов и апстримы 

2. VRF#2 - в нем живут только маршруты на IX и на клиентов

3. VRF#3 - в нем уже стыки на клиентов

И как из этих vrf'ов нарезать full view, который попросит multihomed клиент? А в Looking Glass какой из vrf'ов светить? :o

А памяти PFE маршрутизаторов под эту красоту не жалко? Табличка маршрутов на пиринге может оказаться вполне сравнимой по размерам с full view

 

Для полноты картины FYI: оператор, для которого транзит не развлечение, но хлеб насущный, будет бороться за каждый as-хоп в as-path. Порезанная на кусочки bgp-таблица этому никак не способствует

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Цитата

А есть альтернатива?

Смысл от lookup и как вы его сделаете, если вы никакие маршруты не фильтруете.  Или я чего то не понимаю ?  

 

Цитата

Вообще-то речь изначально о кросс-пиринговом трафике. Клиентов эти ограничения не затрагивают ни разу, их исходящий трафик отправляется ровно туда, куда показывает bgp. Если по морспецифику в ix или в аплинк, значит так тому и быть, это их святое право

В общето  речь идет о ликвидации транзитного трафика и универсального решения для него.

Если у вас 2 клиента и исходящий одного является входящим другого, который уйдет по мореспецифик через ix  хорошего тут мало.

 

Цитата

Самое красивое решение - разносить по VRF.

1. VRF#1 - в нем живут только маршруты на клиентов и апстримы 

2. VRF#2 - в нем живут только маршруты на IX и на клиентов

3. VRF#3 - в нем уже стыки на клиентов

По мне так себе решение, дублировать маршрутов в разных врфах..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.