Robot_NagNews Опубликовано 30 ноября, 2018 · Жалоба Материал: К написанию данной статьи меня сподвигли участившиеся случаи обращения сторонних провайдеров с проблемами о недоступности части ресурсов отдельных наших клиентов. Суть подобных проблем довольно проста, и заключается в желании клиентов получать более дешевый трафик с обменников с одной стороны, и нежелании ISPs осуществлять транзит трафика своих клиентов по схемам Uplink-->ISP-->IX-->Client, Uplink-→ISP-→Uplink-→Client, IX-→ISP-→IX-→Client, IX-→ISP-→Uplink-→Client с другой стороны. Полный текст Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BanZ4y Опубликовано 30 ноября, 2018 · Жалоба Спасибо за статью. Насколько я понимаю, основная идея просто дропать транзитный трафик upstream-upstream ix-ix upstream-ix При этом мы по прежнему платим за входящий трафик который мы дропнем. Понятно, что он не большой т.к. там ничего не работает. Но при отсутствии lg клиент не понимает в чем дело и просто уводит трафик на другого isp. По чему бы, все таки не фильтровать маршруты своих клиентов от ix и upstream ? понятно, что они могут меняться, но в as-path AS client то будет. Выделять все маршруты полученные от ix и upstreams с AS Client и дропать или удалять с forwafding-tabel. При таком подходе и у клиента все работает и провайдер в плюсе или есть какие то вилы ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 1 декабря, 2018 · Жалоба Понять схему по set-ам тяжеловато, подскажите что будет при наличии таких фильтров если клиент уберет анонс своего /16 на стыке с isp, оставив его на ix? P.S. Не принимать маршруты клиента с ix? Да не, бред какой-то, так он все поймет. Лучше в тихую подропать, пускай поищет почему у него что-то отъехало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BanZ4y Опубликовано 1 декабря, 2018 · Жалоба Зачем вам схема по set ? Если клиент уберет анонс в isp, то isp перестанет анонсить выше и трафика клиента не будет в обще. Бред ?, я думаю это самое разумное, что он поймет ? Да и как он поймет ? все равно это ваше право как isp. Если дропать, он ничего искать не будет просто напишет вам заявку, о чем автор и говорит. А вы будите ему объяснять какой он нехороший... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 1 декабря, 2018 · Жалоба Руками более специфичные укажите у себя в таблице маршрутизации без анонса далее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BanZ4y Опубликовано 1 декабря, 2018 · Жалоба Мы тут хотим уйти от ручной работы, а вы нас в каменный век... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tec1 Опубликовано 1 декабря, 2018 · Жалоба Попытаюсь дополнить здесь содержимое статьи, заодно прокомментировать обсуждение. Скрытой нитью в статье отражается преднамеренность подобных действий со стороны клиента, что подвтерждается и на практике. Наверное, только одна десятая из всех случаев - ошибка администрирования. Какой смысл отдавать более специфичный маршрут на обменник, при этом анонсировать менее специфичный своему аплинку? Почему нельзя аносировать во все линки одинаково? Все же знают, что у всех, кто пристутствует на обменнике, Local Preference для анонсов с IX всегда выше, чем для аплинков, и поэтому трафик от участников обменника клиент будет всегда получать через обменник. Специфики здесь абсолютно не нужны. "Обьяснения о нехорошости " все клиенты безоговорочно принимают и немедленно исправляют ситуацию, что подтверждает осознанность их действий. Фильтровать все клиенсткие анонсы с IX? Конечно нет же. Правильно выразил причину, почему этого не стоит делать, vurd. Во-первых, на каком основании? Только из-за отдельных "мудрых" клиентов? Во-вторых, да, действительно, что произойдет, если клиент снимет анонс с вас (своего аплинка), оставит его только через IX, и вы его отфильтруете? В лучшем случае вы его увидите в FV от своих апстримов и весь ваш трафик на такие префиксы пойдет через линки с апстримами вместо обменника (экономически теряете вы же). В худшем, вы его совсем потеряете в своих таблицах, чем нарушите связность. В целом, подобная практика далеко не нова. Ей, как минимум, лет десять и применяется во многих крупных ISP. Из известных мне, Ростелеком, РЕТН... Только что, BanZ4y сказал: Мы тут хотим уйти от ручной работы, а вы нас в каменный век... Все верно. Self Driving Network & Artificial Intelligence ))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tec1 Опубликовано 2 декабря, 2018 · Жалоба 15 часов назад, SyJet сказал: Руками более специфичные укажите у себя в таблице маршрутизации без анонса далее. Попробуйте, особенно для клиента, у которого распарсенный as-set включает несколько тысяч route-objects, большая часть из которых еще и агрегированна. И если таких клиентов далеко не один. Устанут ручки, и не только... Другой, не менее значимой, проблемой статиков является возможный blackhole трафика при падении канала без падения линка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vodz Опубликовано 2 декабря, 2018 · Жалоба Я, наверное повторюсь, но всё же. Кто виноват в том, что клиент вынужден нести дополнительные затраты организовывая дополнительный канал до IX, при этом получая теоретически более дешевую, быструю связанность с меньшими задержкой, джиттером и потерями? Ну не динамическая же маршрутизация! Как говорится, Интернет был задуман для работы в условиях атомной войны, а отдали коммерсам и они всё испортили. Увы, если в сумме затрат клиенту получается дешевле и качественнее, он будет искать такие обходные пути, а виновато будет коммерческое жлобство ISP, к которому он имеет прямой первый линк. Вы уже доигрались, что в приказном порядке федералов перевели на РТ. Теперь очередь за муниципалами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tec1 Опубликовано 2 декабря, 2018 · Жалоба 18 минут назад, vodz сказал: Я, наверное повторюсь, но всё же. Кто виноват в том, что клиент вынужден нести дополнительные затраты организовывая дополнительный канал до IX, при этом получая теоретически более дешевую, быструю связанность с меньшими задержкой, джиттером и потерями? Ну не динамическая же маршрутизация! Как говорится, Интернет был задуман для работы в условиях атомной войны, а отдали коммерсам и они всё испортили. Увы, если в сумме затрат клиенту получается дешевле и качественнее, он будет искать такие обходные пути, а виновато будет коммерческое жлобство ISP, к которому он имеет прямой первый линк. Вы уже доигрались, что в приказном порядке федералов перевели на РТ. Теперь очередь за муниципалами. Почему жлобство ISP? Не клиента? Ведь ничего же не мешает отдавать свои анонсы ровно, и в IX-ы, и своим аплинкам, и не тянуть трафик тирванов через своих аплинков и обменник. Писалось же выше об этом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 3 декабря, 2018 · Жалоба В 01.12.2018 в 21:04, tec1 сказал: В целом, подобная практика далеко не нова. Ей, как минимум, лет десять и применяется во многих крупных ISP. Из известных мне, Ростелеком, РЕТН... Более того, практика несколько устарела. ReTN уже очень давно от неё отказался, отправляя кросс-пиринговый трафик по less-specific маршруту в стык с клиентом, без сизифовой работы по фильтрации морспецификов. В итоге и волки не голодные, и овцам нет повода для обид :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 3 декабря, 2018 · Жалоба В 02.12.2018 в 12:40, tec1 сказал: Попробуйте, особенно для клиента, у которого распарсенный as-set включает несколько тысяч route-objects, большая часть из которых еще и агрегированна. И если таких клиентов далеко не один. Устанут ручки, и не только... Другой, не менее значимой, проблемой статиков является возможный blackhole трафика при падении канала без падения линка. Вы бог ? Умеете разпрарсить бгп рукой ? И да, где бы такого клиента найти, который сумел несколько тыщ роут-обьектов создать. Типа ростелекома. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BanZ4y Опубликовано 3 декабря, 2018 · Жалоба Цитата 1 час назад, evd сказал: Более того, практика несколько устарела. ReTN уже очень давно от неё отказался, отправляя кросс-пиринговый трафик по less-specific маршруту в стык с клиентом, без сизифовой работы по фильтрации морспецификов. В итоге и волки не голодные, и овцам нет повода для обид :) Вот и я про, что тупо блокировать это глупо, надо перенаправлять. А есть инфа механизма ? Но блокировку все равно надо оставить для залетного трафика.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tec1 Опубликовано 4 декабря, 2018 · Жалоба В 12/3/2018 в 21:30, evd сказал: Более того, практика несколько устарела. ReTN уже очень давно от неё отказался, отправляя кросс-пиринговый трафик по less-specific маршруту в стык с клиентом, без сизифовой работы по фильтрации морспецификов. В итоге и волки не голодные, и овцам нет повода для обид :) Года два назад еще было актуально). Спасибо за подсказку, Евгений. Попытаемся внедрить у себя ваш передовой опыт) В 12/3/2018 в 22:59, BanZ4y сказал: Вот и я про, что тупо блокировать это глупо, надо перенаправлять. А есть инфа механизма ? Но блокировку все равно надо оставить для залетного трафика.. Мне кажется, механизмы те же, DCU/SCU, FBF. Без последнего явно никак... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 5 декабря, 2018 · Жалоба В 03.12.2018 в 21:59, BanZ4y сказал: Вот и я про, что тупо блокировать это глупо, надо перенаправлять. А есть инфа механизма ? Но блокировку все равно надо оставить для залетного трафика.. Imho надо бы чуть по-другому: глупо ломать себе связность морспецификами, с невинным видом объясняя своим энд-юзерам, что-де все беды от криворукого аплинка. И в качестве доказательства демонстрируя трейсы в его сторону, но "забывчиво" обходя стороной вопрос об обратном маршруте :) А "залётный" от пира трафик, для которого нет вообще никаких клиентских маршрутов, в т.ч. less-specific - да, блокируется. Пирам (как, впрочем, и аплинкам) гарантируется связность только с клиентами Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BanZ4y Опубликовано 5 декабря, 2018 · Жалоба Цитата Мне кажется, механизмы те же, DCU/SCU, FBF. Без последнего явно никак... Я думал в сторону, пометить more specific клиентские от ix/upstreams и если трафик идет по ним через полиси менять им некст хоп на клиентский, но это под каждого клиента надо писать term и полиси на forwording-table. Без PBR/ Мб у кого то есть уже от тестированное решение и он поделится... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 5 декабря, 2018 · Жалоба 22 часа назад, tec1 сказал: Мне кажется, механизмы те же Правильно кажется :) Механизм ровно тот же, что описан в статье. Надо только поменять цель: не дропать, а отправлять в клиентский лесспецифик (if any) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BanZ4y Опубликовано 5 декабря, 2018 · Жалоба Цитата цель: не дропать, а отправлять в клиентский лесспецифик (if any) что это значит ? заставить железку сделать еще один lookup ? или направить в определенный интерфейс или ip ? Если направлять в клиентский интерфейс, то надо для каждого клиента помечать сетки и выделять DCU вопрос по какому критерию ? по АС ?, что-то мне не нравиться этот вариант. Этот фильтр будет расти пропорционально количеству клиентов + надо предусмотреть трафик от клиента к клиенту, чтобы не ушел через ix. И при наличии таких фильтров какой смысл от more specific ot ix в РТ если трафик туда не пойдет ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tec1 Опубликовано 6 декабря, 2018 · Жалоба 6 часов назад, evd сказал: Правильно кажется :) Механизм ровно тот же, что описан в статье. Надо только поменять цель: не дропать, а отправлять в клиентский лесспецифик (if any) Евгений, в очередной раз спасибо за подсказку! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 6 декабря, 2018 · Жалоба 21 час назад, BanZ4y сказал: что это значит ? заставить железку сделать еще один lookup ? А есть альтернатива? 21 час назад, BanZ4y сказал: Этот фильтр будет расти пропорционально количеству клиентов + надо предусмотреть трафик от клиента к клиенту, чтобы не ушел через ix. И при наличии таких фильтров какой смысл от more specific ot ix в РТ если трафик туда не пойдет ? Вообще-то речь изначально о кросс-пиринговом трафике. Клиентов эти ограничения не затрагивают ни разу, их исходящий трафик отправляется ровно туда, куда показывает bgp. Если по морспецифику в ix или в аплинк, значит так тому и быть, это их святое право Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ugluck Опубликовано 9 декабря, 2018 · Жалоба В 06.12.2018 в 22:28, evd сказал: ... А есть альтернатива? ... Есть. Не слишком просто, но идеологически, кмк, более верно: https://gul-tech.livejournal.com/3790.html К сожалению, исходный текст Гигзбурга overcoming-peer-fraud, похоже, затерялся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexmern Опубликовано 9 декабря, 2018 · Жалоба Самое красивое решение - разносить по VRF. 1. VRF#1 - в нем живут только маршруты на клиентов и апстримы 2. VRF#2 - в нем живут только маршруты на IX и на клиентов 3. VRF#3 - в нем уже стыки на клиентов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 10 декабря, 2018 · Жалоба 15 часов назад, ugluck сказал: Есть. Не слишком просто, но идеологически, кмк, более верно: https://gul-tech.livejournal.com/3790.html Завернуть пакет в vrf - это разве не "заставить железку сделать еще один lookup"? Альтернатива ихде? ;) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 10 декабря, 2018 · Жалоба 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-таблица этому никак не способствует Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BanZ4y Опубликовано 10 декабря, 2018 · Жалоба Цитата А есть альтернатива? Смысл от lookup и как вы его сделаете, если вы никакие маршруты не фильтруете. Или я чего то не понимаю ? Цитата Вообще-то речь изначально о кросс-пиринговом трафике. Клиентов эти ограничения не затрагивают ни разу, их исходящий трафик отправляется ровно туда, куда показывает bgp. Если по морспецифику в ix или в аплинк, значит так тому и быть, это их святое право В общето речь идет о ликвидации транзитного трафика и универсального решения для него. Если у вас 2 клиента и исходящий одного является входящим другого, который уйдет по мореспецифик через ix хорошего тут мало. Цитата Самое красивое решение - разносить по VRF. 1. VRF#1 - в нем живут только маршруты на клиентов и апстримы 2. VRF#2 - в нем живут только маршруты на IX и на клиентов 3. VRF#3 - в нем уже стыки на клиентов По мне так себе решение, дублировать маршрутов в разных врфах.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...