evd Опубликовано 10 декабря, 2018 · Жалоба 18 минут назад, BanZ4y сказал: В общето речь идет о ликвидации транзитного трафика и универсального решения для него. Если у вас 2 клиента и исходящий одного является входящим другого, который уйдет по мореспецифик через ix хорошего тут мало. Буквально первый пост в обсуждении статьи - ваш. Цитирую: В 30.11.2018 в 23:43, BanZ4y сказал: Насколько я понимаю, основная идея просто дропать транзитный трафик upstream-upstream ix-ix upstream-ix Что случилось с этим вашим пониманием? Трафик от клиентов куда бы то ни было вовне не является предметом обсуждаемой статьи Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BanZ4y Опубликовано 10 декабря, 2018 · Жалоба То, что описано в статья уже выяснили, что устарело и не оптимально. Я пытаюсь найти оптимальное решение для ликвидации транзитного трафика и перенаправлении клиентского трафика по оптимальному пути, с точки зрения ISP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexmern Опубликовано 11 декабря, 2018 · Жалоба 10 hours ago, BanZ4y said: По мне так себе решение, дублировать маршрутов в разных врфах.. С удовольствием выслушаю другие варианты кроме как "давайте дропнем нафиг". Мое видение - пришел пакет через аплинк - должен уйти клиенту на прямой стык. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tec1 Опубликовано 11 декабря, 2018 · Жалоба Никто не говорит, что дропать трафик - хорошее решение. Но бороться с нежелательным трафиком - необходимость. То, что more specific отправляются через IX неосознанно, не соглашусь в корне. Каков мотив? Могут отдаваться и less, и more specifics одновременно и аплинкам и в обменники. Но и здесь можно наступить на грабли. А чем не нравится решение, подсказанное здесь @evd , не дропать клиентский транзитный трафик, а отправлять его по less specific, более гибко используя классы в отличие от vrf? Механизм отправки во всех случаях один и тот же - PBR/FBF (здесь @evd прав, альтернативы нет, в статье 2009 года, где автор трактовал решение Гинсбурга для Cisco, использовался тоже PBR). Различие только в разделении трафика. И здесь явно выигрывают классы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 11 декабря, 2018 (изменено) · Жалоба 13 часов назад, BanZ4y сказал: То, что описано в статья уже выяснили, что устарело и не оптимально. Я пытаюсь найти оптимальное решение для ликвидации транзитного трафика и перенаправлении клиентского трафика по оптимальному пути, с точки зрения ISP. Ok. Уточним предмет разговора. Пир или апстрим отправляет к Вам трафик на клиентский лесспецифик, потому что морспецификов он не видит. Причина не имеет значения. То ли это клиент намеренно или случайно криворук, то ли, скажем, пир экономит на памяти для full view на своём бордере, не суть. Вы следуете логике пира/апстрима и отправляете трафик к клиенту по его лесспецифику. Обманутых и обиженных нет. Пакеты улетают ровно тем маршрутом, который предполагался их источником Ваша "оптимизация" неявно предполагает нечто обратное: светить клиенту морспецифики в составе full view, а влетевший от него трафик отправлять по лесспецифику. К затронутой в этом топике теме оно не имеет никакого отношения Изменено 11 декабря, 2018 пользователем evd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BanZ4y Опубликовано 11 декабря, 2018 · Жалоба Цитата Ваша "оптимизация" неявно предполагает нечто обратное: светить клиенту морспецифики в составе full view, а влетевший от него трафик отправлять по лесспецифику. К затронутой в этом топике теме оно не имеет никакого отношения Ну да все верно! Мы явно по разному понимаем смысл статьи. На мой взгляд не важно от куда и куда идет трафик, если он не идет по оптимальному пути с точки зрения ISP он паразитный! и смысл стать - как избавиться от паразитного трафика. Что хорошего получить трафик от клиента1 и отправить в ix и на клиента2 , хотя есть прямой стык с клиентом2 ? А так у нас в РТ будут морспецифики клиента2, что поможет отжать часть трафика, ну и направим по оптимальному пути к клиенту2. Цитата С удовольствием выслушаю другие варианты кроме как "давайте дропнем нафиг". Мое видение - пришел пакет через аплинк - должен уйти клиенту на прямой стык. А есть полное описание решения с врфами ? А я то его не понял в чем соль ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evd Опубликовано 12 декабря, 2018 · Жалоба 13 часов назад, BanZ4y сказал: На мой взгляд не важно от куда и куда идет трафик, если он не идет по оптимальному пути с точки зрения ISP он паразитный! Ok. Тогда вопрос: что есть "оптимальный путь" и куда он ведёт? :) Морспецифик - это частный случай. Более обще оно формулируется так: клиент отдаёт Вам не все те свои маршруты, которые светит вовне. Какие-то префиксы (не обязательно морспецифики) по каким-то причинам он, нехороший, анонсит только вашему конкуренту. Далеко не экзотический случай. А другие ваши клиенты, которым Вы обязаны обеспечить полную связность, шлют, негодяи, пакетики и на эти префиксы тоже. Этот трафик - паразитный или как? А оптимально - это когда за один и тот же трафик Вы берёте денюжку дважды, и с отправителя, и с получателя? ;) 13 часов назад, BanZ4y сказал: Ну да все верно! Мы явно по разному понимаем смысл статьи Смысл статьи - как избавиться от кросс-пирингового трафика. Смею утверждать, что других смыслов там нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BanZ4y Опубликовано 13 декабря, 2018 · Жалоба В 12.12.2018 в 12:39, evd сказал: Морспецифик - это частный случай. Более обще оно формулируется так: клиент отдаёт Вам не все те свои маршруты, которые светит вовне. Какие-то префиксы (не обязательно морспецифики) по каким-то причинам он, нехороший, анонсит только вашему конкуренту. Далеко не экзотический случай. А другие ваши клиенты, которым Вы обязаны обеспечить полную связность, шлют, негодяи, пакетики и на эти префиксы тоже. Этот трафик - паразитный или как? А оптимально - это когда за один и тот же трафик Вы берёте денюжку дважды, и с отправителя, и с получателя? ;) Ну да, как то не красиво выходит. Оптимальный путь- очевидно же, что трафик клиента должен отправляться на прямой стык с клиентом, но вот если клиент этого не хочет... Изгаляться с анонсами - это право клиента, но почему Оператор не может так же изгаляться с перенаправлением трафика ? и брать денежку дважды, что в этом плохого ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ogion Опубликовано 19 декабря, 2018 (изменено) · Жалоба 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? Изменено 19 декабря, 2018 пользователем Ogion Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...