[agabekov]

В результате, третий оператор вынужден трафик, прилетевший к нему от public-пира, отправлять не к своему клиенту (i.e. получить с него дополнительную денюжку), а на свой аплинк (i.e. дополнительно раскошелиться). С какой стати ему это делать? Он что, своему пиру за так обязан транзит в мир предоставлять?

Ну и слал бы на клиентский агрегат, и денежку бы заработал и связность сохранил.

[visir]

В результате, третий оператор вынужден трафик, прилетевший к нему от public-пира, отправлять не к своему клиенту (i.e. получить с него дополнительную денюжку), а на свой аплинк (i.e. дополнительно раскошелиться). С какой стати ему это делать? Он что, своему пиру за так обязан транзит в мир предоставлять?

Ну и слал бы на клиентский агрегат, и денежку бы заработал и связность сохранил.

Не все так просто, как хочется.

[agabekov]

А что будет, если магистралы начнут отфильтровывать клиентские специфики на пирах и аплинках?

[visir]

А что будет, если магистралы начнут отфильтровывать клиентские специфики на пирах и аплинках?

А с чего бы им начинать это делать ?

Если начнут, то в пределе получится, что балансировка спецификами вообще перестанет работать. Потому что перекосы при "дефолтных анонсах" вызваны по большей части не разной зарубежной связностью, а местными контенщиками и проплаченнымиповышенными локалпрефами к ним (клиентскими например, специфики которых вы и предлагаете отфильтровывать с аплинков и пиров).

Изменено 26 октября, 2009 пользователем visir

[dsk]

А ведь иногда это единственный способ не насолить себе и клиенту. РЕТН же предпочитает включить в этом случае rp фильтр, и е***сь связность конем.

[evd]

А что будет, если магистралы начнут отфильтровывать клиентские специфики на пирах и аплинках?

Транзитные операторы обязаны отдавать своим клиентам full view, а не ту часть таблички, которая им больше нравится :)

 

И потом, как Вы себе это представляете технически? Размеры фильтров, которые придётся выставлять (и обновлять) на всех внешних стыках? И немаловажный побочный эффект - потеря связности с клиентом, у которого вдруг по техническим (или не очень) причинам отвалилась сессия

 

А ведь иногда это единственный способ не насолить себе и клиенту. РЕТН же предпочитает включить в этом случае rp фильтр, и е***сь связность конем.

И кому же в данном конкретном конкретном случае помешал ReTN? Напомню: КТ совместно с ВГТРК незатейливо (скажем, "случайно") залезли в карман Ростелекому. И тому это не понравилось. (А Вам бы на месте РТ это понравилось?). ReTN же честно форвардил (и форвардит) тот трафик

 

И к слову: ReTN пока подобные утечки у себя лишь фиксирует (и подсчитывает), но не более. До тех пор, пока не сочтёт, что они наносят существенный урон

Изменено 26 октября, 2009 пользователем evd

[visir]

А ведь иногда это единственный способ не насолить себе и клиенту.

Да ломайте себе связность на здоровье. Только не жалуйтесь потом, что от вас до близзардовских серверов лаги или ЖЖ недоступен :D

 

На европейских IX-ах в описании пиринговой политики часто участники вписывают, что они фильтруют несанкционированный транзит. Так что не сломаете vesti.ru, неработоспособность которого юзера сразу замечают - сломаете что-нибудь другое, менее популярное... и ваши юзера даже через первую линию саппорта с этой проблемой не пробьются.

[pety]

....

 

В результате, третий оператор вынужден трафик, прилетевший к нему от public-пира, отправлять не к своему клиенту (i.e. получить с него дополнительную денюжку), а на свой аплинк (i.e. дополнительно раскошелиться). С какой стати ему это делать? Он что, своему пиру за так обязан транзит в мир предоставлять?

 

....

А почему эти "третие операторы" как-то не особо хотят решать эту проблему? Так, чтобы этот трафик все-таки отдавать клиенту? Иными словами, например, игнорировать (в самом прямом смысле) те специфики, трафик в сторону которых заведомо будет дропнут? Уж совсем крупные могли бы заказать себе такую фичу у производителей роутеров. ;)

[evd]

А почему эти "третие операторы" как-то не особо хотят решать эту проблему? Так, чтобы этот трафик все-таки отдавать клиенту? Иными словами, например, игнорировать (в самом прямом смысле) те специфики, трафик в сторону которых заведомо будет дропнут? Уж совсем крупные могли бы заказать себе такую фичу у производителей роутеров. ;)

А эти морспецифики заранее известны и вывешены где-то на видном месте? ;)

И вообще, существует ли доступный софт для динамического обнаружения (клиентских) морспецификов, светящихся извне? Вопрос не праздный

 

РТ, насколько я понимаю, фильтровал не трафик вообще в сторону "внешних" морспецификов, а трафик ВГТРК->РТ->(пиры,апстримы). Очень частный случай

Изменено 26 октября, 2009 пользователем evd

[visir]

РТ фильтрует трафик (пиры,апстримы)->РТ->(пиры,апстримы). Давно. Потому что еще с год назад счет там шел на гигабиты.

[evd]

РТ фильтрует трафик (пиры,апстримы)->РТ->(пиры,апстримы). Давно. Потому что еще с год назад счет там шел на гигабиты.

Под раздачу могут попасть ни в чём не повинные :)

Например, агрегат принадлежит клиенту X, а специфик - не-клиенту Y

[pety]

А почему эти "третие операторы" как-то не особо хотят решать эту проблему? Так, чтобы этот трафик все-таки отдавать клиенту? Иными словами, например, игнорировать (в самом прямом смысле) те специфики, трафик в сторону которых заведомо будет дропнут? Уж совсем крупные могли бы заказать себе такую фичу у производителей роутеров. ;)

А эти морспецифики заранее известны и вывешены где-то на видном месте? ;)

Ну зачем так иронизировать. Ведь по сути роутер, в целом, вполне обладает такой информацией, и именно в динамике.

 

И вообще, существует ли доступный софт для динамического обнаружения (клиентских) морспецификов, светящихся извне? Вопрос не праздный

Вот вот. Была бы весьма неплохая фича. Но, боюсь, нет потребности в колбасе...

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

 

РТ, насколько я понимаю, фильтровал не трафик вообще в сторону "внешних" морспецификов, а трафик ВГТРК->РТ->(пиры,апстримы). Очень частный случай

Но этого уже вполне достаточно, чтобы доставлять. Радости от того, что Ретн будет поступать также только тогда, когда сочтет нужным, тоже как-то немного. Уж лучше как-то заранее знать, дроп или не дроп. ;)

 

[pety]

РТ фильтрует трафик (пиры,апстримы)->РТ->(пиры,апстримы). Давно. Потому что еще с год назад счет там шел на гигабиты.

Под раздачу могут попасть ни в чём не повинные :)

Например, агрегат принадлежит клиенту X, а специфик - не-клиенту Y

И с Вашей точки зрения это в корне меняет дело?

[evd]

РТ фильтрует трафик (пиры,апстримы)->РТ->(пиры,апстримы). Давно. Потому что еще с год назад счет там шел на гигабиты.

Под раздачу могут попасть ни в чём не повинные :)

Например, агрегат принадлежит клиенту X, а специфик - не-клиенту Y

И с Вашей точки зрения это в корне меняет дело?

Sure. Именно поэтому трафик считается/анализируется, но не дропается. За тем редким исключением, когда кому-то вздумается односторонне использовать public-пира в качестве full-transit оператора. Но и в этом случае клиенты связности с данным пиром не теряют

Изменено 26 октября, 2009 пользователем evd

[evd]

Ну зачем так иронизировать. Ведь по сути роутер, в целом, вполне обладает такой информацией, и именно в динамике.

А толку? Для железки агрегат и специфик - разные маршруты. Для каждого из которых best path выбирается независимо. Что в Циске, что в Джуне - синтаксис динамических фильтров не предусматривает конструкции типа 'from morespecific of customer_route then reject'

Изменено 26 октября, 2009 пользователем evd

[pety]

Ну зачем так иронизировать. Ведь по сути роутер, в целом, вполне обладает такой информацией, и именно в динамике.

А толку? Для железки агрегат и специфик - разные маршруты. Для каждого из которых best path выбирается независимо. Что в Циске, что в Джуне - синтаксис динамических фильтров не предусматривает конструкции типа 'from morespecific of customer_route then discard'

Ну так я и говорю, была бы хорошая фича. Но заказывать ее реализацию скорее должны/(и могли бы) только крупные операторы. А про колбасу я уже писал.

[visir]

Ну так я и говорю, была бы хорошая фича. Но заказывать ее реализацию скорее должны/(и могли бы) только крупные операторы. А про колбасу я уже писал.

И зачем им скрывать проблему с помощью этой фичи, когда ее можно демонстрировать виновникам ? :P

[pety]

РТ фильтрует трафик (пиры,апстримы)->РТ->(пиры,апстримы). Давно. Потому что еще с год назад счет там шел на гигабиты.

Под раздачу могут попасть ни в чём не повинные :)

Например, агрегат принадлежит клиенту X, а специфик - не-клиенту Y

И с Вашей точки зрения это в корне меняет дело?

Sure. Именно поэтому трафик считается/анализируется, но не дропается. За тем редким исключением, когда кому-то вздумается односторонне использовать public-пира в качестве full-transit оператора. Но и в этом случае клиенты связности с данным пиром не теряют

А я вот не уверен. Зачем предоставлять ресурсы своей сети бесплатно, только по тому, что так уж вышло? ;)

А эти редкие (и не очень) исключения надо еще найти, и потом еще каким-то магическим образом определить, это было сделано специально или нет, то есть провести расследование и принять решение по собственному усмотрению (что уже несколько не объективно). И что, даже в масштабах Ретн это не требует никакого особого труда? А если требует, то может стоит попытаться искать другие решения, в том числе и новых фич софта? А какова будет политика Ретн со спецификами в IPv6? ;)

 

[pety]

Ну так я и говорю, была бы хорошая фича. Но заказывать ее реализацию скорее должны/(и могли бы) только крупные операторы. А про колбасу я уже писал.

И зачем им скрывать проблему с помощью этой фичи, когда ее можно демонстрировать виновникам ? :P

Почему именно "скрывать проблему"? Я все-таки имел в виду попытку найти решение.

А "демонстрируя" проблему виновникам, "они", таким образом, показывают другую фичу. А если бы ее не было? ;)

К тому же формулировка понятия "виновник", как уже показало обсуждение, из разных уст будет звучать по-разному. А кто определит, чье определение верно?

[evd]

А я вот не уверен. Зачем предоставлять ресурсы своей сети бесплатно, только по тому, что так уж вышло? ;)

Потому что альтернативы нет :)

И нет преднамеренной попытки раздеть ближнего. В отличие от манипуляций с морспецификами

 

А эти редкие (и не очень) исключения надо еще найти, и потом еще каким-то магическим образом определить, это было сделано специально или нет, то есть провести расследование и принять решение по собственному усмотрению (что уже несколько не объективно). И что, даже в масштабах Ретн это не требует никакого особого труда? А если требует, то может стоит попытаться искать другие решения, в том числе и новых фич софта?

Pety, вычисляются на раз, и закрывается лишь транзит peer->(peers,upstreams). То, что РТ делает автоматом, и для всех без исключения

 

А какова будет политика Ретн со спецификами в IPv6? ;)

А там пока в игры с преднамеренной асимметрией никто не играет. Потому что а) не за деньги, но и без гарантий полной связности, увы; б) трафка всё равно ещё мало

[pety]

А я вот не уверен. Зачем предоставлять ресурсы своей сети бесплатно, только по тому, что так уж вышло? ;)

Потому что альтернативы нет :)

В контексте данной проблемы - могла бы и быть (в смысле даже без ручного вмешательства со стороны оператора транзита). Технически реализовать это вполне реально.

Главное чтобы кто-то захотел. ;)

 

И нет преднамеренной попытки раздеть ближнего. В отличие от манипуляций с морспецификами

Манипуляции с морспецификами тоже иногда делаются отнюдь не для того, чтобы раздеть ближнего или даже дальнего, если "проблема" всплывает через пару или более AS хопов. К сожалению чем дальше - тем сложнее ее заметить.

Тот же Казахтелеком врядли делает это специально (хотя да, несколько, на первый взгляд, странным образом). Тут ведь понятно, что анонс всех его спецификов на MSK-IX скорее всего просто кладет ему тот канал, через который он делает эти анонсы (причины отсутствия расширения в сторону таких операторов тут все же рассматривать не будем ;) ), а GLDN'а на публичном MSK-IX нет. А что может выйти в итоге? Казахтелеком может просто "забить" на такую проблему. Как и сами vesti.ru - типа несущественная. И таких аналогичных случаев может быть сколь угодно много. Нет, уж лучше без дропов (ведь есть же альтернативный маршрут прямо к клиенту!).

 

Кстати, Ретн, перед тем как поставить фильтр (тоже ручная работа!), заранее предупреждает участников процесса об этом?

 

А эти редкие (и не очень) исключения надо еще найти, и потом еще каким-то магическим образом определить, это было сделано специально или нет, то есть провести расследование и принять решение по собственному усмотрению (что уже несколько не объективно). И что, даже в масштабах Ретн это не требует никакого особого труда? А если требует, то может стоит попытаться искать другие решения, в том числе и новых фич софта?

Pety, вычисляются на раз, и закрывается лишь транзит peer->(peers,upstreams). То, что РТ делает автоматом, и для всех без исключения

А если те кто устроил это все же невиновны? Делаете попытки вручную поработать с фильтрами BGP (например игнорирование заранее оговоренного специфика), или просто ставите фильтр по IP и точка?

 

А какова будет политика Ретн со спецификами в IPv6? ;)

А там пока в игры с преднамеренной асимметрией никто не играет. Потому что а) не за деньги, но и без гарантий полной связности, увы; б) трафка всё равно ещё мало

А там ассиметрия может получиться и без всяких игр. И, в принципе, даже при одном аплинке, и отсутсвии пиров. И превед ;).

 

 

[visir]

Почему именно "скрывать проблему"? Я все-таки имел в виду попытку найти решение.

А "демонстрируя" проблему виновникам, "они", таким образом, показывают другую фичу. А если бы ее не было? ;)

К тому же формулировка понятия "виновник", как уже показало обсуждение, из разных уст будет звучать по-разному. А кто определит, чье определение верно?

Вероятность не сломать себе связность анонсируя разные специфики в разные аплинки невысока, на уровне везения. В мире много фильтрующих несанкционированный транзит.

Поэтому не "дропать здесь" не приведет ни к какому решению, оно только скроет проблему, отложит ее обнаружение - ведь где-то там кто-то тоже дропает. А даже если не дропает, то возникает дополнительная петля.

[bitbucket]

Кстати, обнаружил сегодня следующую картину:

* 87.226.128.0/17 193.232.245.14 10 0 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 i

* 87.226.128.0/17 193.232.247.14 10 0 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 12389 i

 

видимо рт.ру более с ix трафик не принимает, даже для своей AS.

[evd]

Манипуляции с морспецификами тоже иногда делаются отнюдь не для того, чтобы раздеть ближнего или даже дальнего

Pety, давайте называть вещи своими именами. В подавляющем большинстве случаев морспецифики есть проявление наплевательского отношения одного ко всем остальным, включая и собственных клиентов. И с какой стати остальные должны "входить в его положение"? Разбираться с петлями, которые он наворотил. Объясняться с его end-users. Короче, выполнять ту работу, за которую адепт морспецификов исправно собирает мзду со своих клиентов. Это ли не раздевание ближнего?

 

Кстати, Ретн, перед тем как поставить фильтр (тоже ручная работа!), заранее предупреждает участников процесса об этом?

Предупреждает о чём? И какого процесса? На процессе пиринга оно никак не сказывается

 

А там ассиметрия может получиться и без всяких игр. И, в принципе, даже при одном аплинке, и отсутсвии пиров. И превед ;).

В native IPv6 петли случаются не чаще, чем в IPv4

Изменено 26 октября, 2009 пользователем evd

[agabekov]

Пофиксили - и префиксы с MSK-IX пропали.