BanZ4y

Ну да, как то не красиво выходит. Оптимальный путь- очевидно же, что трафик клиента должен отправляться на прямой стык с клиентом, но вот если клиент этого не хочет... Изгаляться с анонсами - это право клиента, но почему Оператор не может так же изгаляться с перенаправлением трафика ? и брать денежку дважды, что в этом плохого ?

Ну да все верно! Мы явно по разному понимаем смысл статьи. На мой взгляд не важно от куда и куда идет трафик, если он не идет по оптимальному пути с точки зрения ISP он паразитный! и смысл стать - как избавиться от паразитного трафика. Что хорошего получить трафик от клиента1 и отправить в ix и на клиента2 , хотя есть прямой стык с клиентом2 ? А так у нас в РТ будут морспецифики клиента2, что поможет отжать часть трафика, ну и направим по оптимальному пути к клиенту2. А есть полное описание решения с врфами ? А я то его не понял в чем соль ?

То, что описано в статья уже выяснили, что устарело и не оптимально. Я пытаюсь найти оптимальное решение для ликвидации транзитного трафика и перенаправлении клиентского трафика по оптимальному пути, с точки зрения ISP.

Смысл от lookup и как вы его сделаете, если вы никакие маршруты не фильтруете. Или я чего то не понимаю ? В общето речь идет о ликвидации транзитного трафика и универсального решения для него. Если у вас 2 клиента и исходящий одного является входящим другого, который уйдет по мореспецифик через ix хорошего тут мало. По мне так себе решение, дублировать маршрутов в разных врфах..

что это значит ? заставить железку сделать еще один lookup ? или направить в определенный интерфейс или ip ? Если направлять в клиентский интерфейс, то надо для каждого клиента помечать сетки и выделять DCU вопрос по какому критерию ? по АС ?, что-то мне не нравиться этот вариант. Этот фильтр будет расти пропорционально количеству клиентов + надо предусмотреть трафик от клиента к клиенту, чтобы не ушел через ix. И при наличии таких фильтров какой смысл от more specific ot ix в РТ если трафик туда не пойдет ?

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

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

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

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

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