evd Posted December 10, 2018 · Report post 18 минут назад, BanZ4y сказал: В общето речь идет о ликвидации транзитного трафика и универсального решения для него. Если у вас 2 клиента и исходящий одного является входящим другого, который уйдет по мореспецифик через ix хорошего тут мало. Буквально первый пост в обсуждении статьи - ваш. Цитирую: В 30.11.2018 в 23:43, BanZ4y сказал: Насколько я понимаю, основная идея просто дропать транзитный трафик upstream-upstream ix-ix upstream-ix Что случилось с этим вашим пониманием? Трафик от клиентов куда бы то ни было вовне не является предметом обсуждаемой статьи Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
BanZ4y Posted December 10, 2018 · Report post То, что описано в статья уже выяснили, что устарело и не оптимально. Я пытаюсь найти оптимальное решение для ликвидации транзитного трафика и перенаправлении клиентского трафика по оптимальному пути, с точки зрения ISP. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
alexmern Posted December 11, 2018 · Report post 10 hours ago, BanZ4y said: По мне так себе решение, дублировать маршрутов в разных врфах.. С удовольствием выслушаю другие варианты кроме как "давайте дропнем нафиг". Мое видение - пришел пакет через аплинк - должен уйти клиенту на прямой стык. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tec1 Posted December 11, 2018 · Report post Никто не говорит, что дропать трафик - хорошее решение. Но бороться с нежелательным трафиком - необходимость. То, что more specific отправляются через IX неосознанно, не соглашусь в корне. Каков мотив? Могут отдаваться и less, и more specifics одновременно и аплинкам и в обменники. Но и здесь можно наступить на грабли. А чем не нравится решение, подсказанное здесь @evd , не дропать клиентский транзитный трафик, а отправлять его по less specific, более гибко используя классы в отличие от vrf? Механизм отправки во всех случаях один и тот же - PBR/FBF (здесь @evd прав, альтернативы нет, в статье 2009 года, где автор трактовал решение Гинсбурга для Cisco, использовался тоже PBR). Различие только в разделении трафика. И здесь явно выигрывают классы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
evd Posted December 11, 2018 (edited) · Report post 13 часов назад, BanZ4y сказал: То, что описано в статья уже выяснили, что устарело и не оптимально. Я пытаюсь найти оптимальное решение для ликвидации транзитного трафика и перенаправлении клиентского трафика по оптимальному пути, с точки зрения ISP. Ok. Уточним предмет разговора. Пир или апстрим отправляет к Вам трафик на клиентский лесспецифик, потому что морспецификов он не видит. Причина не имеет значения. То ли это клиент намеренно или случайно криворук, то ли, скажем, пир экономит на памяти для full view на своём бордере, не суть. Вы следуете логике пира/апстрима и отправляете трафик к клиенту по его лесспецифику. Обманутых и обиженных нет. Пакеты улетают ровно тем маршрутом, который предполагался их источником Ваша "оптимизация" неявно предполагает нечто обратное: светить клиенту морспецифики в составе full view, а влетевший от него трафик отправлять по лесспецифику. К затронутой в этом топике теме оно не имеет никакого отношения Edited December 11, 2018 by evd Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
BanZ4y Posted December 11, 2018 · Report post Цитата Ваша "оптимизация" неявно предполагает нечто обратное: светить клиенту морспецифики в составе full view, а влетевший от него трафик отправлять по лесспецифику. К затронутой в этом топике теме оно не имеет никакого отношения Ну да все верно! Мы явно по разному понимаем смысл статьи. На мой взгляд не важно от куда и куда идет трафик, если он не идет по оптимальному пути с точки зрения ISP он паразитный! и смысл стать - как избавиться от паразитного трафика. Что хорошего получить трафик от клиента1 и отправить в ix и на клиента2 , хотя есть прямой стык с клиентом2 ? А так у нас в РТ будут морспецифики клиента2, что поможет отжать часть трафика, ну и направим по оптимальному пути к клиенту2. Цитата С удовольствием выслушаю другие варианты кроме как "давайте дропнем нафиг". Мое видение - пришел пакет через аплинк - должен уйти клиенту на прямой стык. А есть полное описание решения с врфами ? А я то его не понял в чем соль ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
evd Posted December 12, 2018 · Report post 13 часов назад, BanZ4y сказал: На мой взгляд не важно от куда и куда идет трафик, если он не идет по оптимальному пути с точки зрения ISP он паразитный! Ok. Тогда вопрос: что есть "оптимальный путь" и куда он ведёт? :) Морспецифик - это частный случай. Более обще оно формулируется так: клиент отдаёт Вам не все те свои маршруты, которые светит вовне. Какие-то префиксы (не обязательно морспецифики) по каким-то причинам он, нехороший, анонсит только вашему конкуренту. Далеко не экзотический случай. А другие ваши клиенты, которым Вы обязаны обеспечить полную связность, шлют, негодяи, пакетики и на эти префиксы тоже. Этот трафик - паразитный или как? А оптимально - это когда за один и тот же трафик Вы берёте денюжку дважды, и с отправителя, и с получателя? ;) 13 часов назад, BanZ4y сказал: Ну да все верно! Мы явно по разному понимаем смысл статьи Смысл статьи - как избавиться от кросс-пирингового трафика. Смею утверждать, что других смыслов там нет Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
BanZ4y Posted December 13, 2018 · Report post В 12.12.2018 в 12:39, evd сказал: Морспецифик - это частный случай. Более обще оно формулируется так: клиент отдаёт Вам не все те свои маршруты, которые светит вовне. Какие-то префиксы (не обязательно морспецифики) по каким-то причинам он, нехороший, анонсит только вашему конкуренту. Далеко не экзотический случай. А другие ваши клиенты, которым Вы обязаны обеспечить полную связность, шлют, негодяи, пакетики и на эти префиксы тоже. Этот трафик - паразитный или как? А оптимально - это когда за один и тот же трафик Вы берёте денюжку дважды, и с отправителя, и с получателя? ;) Ну да, как то не красиво выходит. Оптимальный путь- очевидно же, что трафик клиента должен отправляться на прямой стык с клиентом, но вот если клиент этого не хочет... Изгаляться с анонсами - это право клиента, но почему Оператор не может так же изгаляться с перенаправлением трафика ? и брать денежку дважды, что в этом плохого ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ogion Posted December 19, 2018 (edited) · Report post On 12/11/2018 at 11:24 AM, tec1 said: Никто не говорит, что дропать трафик - хорошее решение. Но бороться с нежелательным трафиком - необходимость. То, что more specific отправляются через IX неосознанно, не соглашусь в корне. Каков мотив? Могут отдаваться и less, и more specifics одновременно и аплинкам и в обменники. Но и здесь можно наступить на грабли. А чем не нравится решение, подсказанное здесь @evd , не дропать клиентский транзитный трафик, а отправлять его по less specific, более гибко используя классы в отличие от vrf? Механизм отправки во всех случаях один и тот же - PBR/FBF (здесь @evd прав, альтернативы нет, в статье 2009 года, где автор трактовал решение Гинсбурга для Cisco, использовался тоже PBR). Различие только в разделении трафика. И здесь явно выигрывают классы. А как это проще реализуется в джуниперах в случае нескольких роутеров, когда трафик принимается на одном, а клиент сидит на другом? В статье пишут про вторую таблицу с клиентами с дефолтом с основную, но как тогда сделать маршрутизацию клиентского трафика по more specific? Edited December 19, 2018 by Ogion Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
