Jump to content

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

Цитата

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

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

Без PBR/

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

Цитата

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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-таблица этому никак не способствует

Share this post


Link to post
Share on other sites

Цитата

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

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

 

Цитата

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

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

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

 

Цитата

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

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

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

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

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

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.