[fozz]

Уважаемые господа, подскажите пожалуйста каким образом можно запретить обмен torrent DHT (Distributed Hash Table) между пользователями на Linux роутере.

 

Заранее спасибо.

Во первых нафига? Чем он вам помешал то?

А во вторых вы UDP с DHT не перепутали? :) Здесь обсуждается именно UDP.

Существует локальный трекер и хочется отдавать в списке пиров только соседей по кластеру, а этот DHT все портит :)

 

Вот и хочется прибить его на корню.

пожалуйста, не надо. DHT это Хорошее Дело. Погуглите про pirate bay и magnet-links

[m0xf]

Существует локальный трекер и хочется отдавать в списке пиров только соседей по кластеру, а этот DHT все портит :)

 

Вот и хочется прибить его на корню.

Флаг private=1 в торрент файле отключает DHT.

[starina]

Существует локальный трекер и хочется отдавать в списке пиров только соседей по кластеру, а этот DHT все портит :)

 

Вот и хочется прибить его на корню.

Если вам на раздачах с вашего локального трекера надо DHT прибить то это можно легко сделать: флаг privat=1

 

Или DHT хотите придушить на ВСЕХ закачках со ВСЕХ трекеров???

[_INF_]

хочется прибить DHT только для локального трекера

[antong]

Я же не призываю покупать МХ240 с модулем на 16 десяток с полной л3 лицензией и брас-функционалом, чтобы делать на нем все.

Если не секрет - то сколько сессий висит и какой трафик идет через эту железку?

Вы реально решили, что у меня это в продакшне уже стоит? =))))))))

Интересно, с чего.

Наверное имелся ввиду график с 76 циской

Изменено 1 марта, 2010 пользователем antong

[pvb]

Здесь статейка

может комуто поможет, хотя на локале вызвала только смех.

Там, В ПРЕДЫСТОРИИ статьи, немножко другая завязка была и повод, почему она вызвала .. мм.. скажем так, не совсем адекватную реакцию.

Если бы Вы немножко ВНИМАТЕЛЬНЕЕ излагали свои мысли, то никаких детских обидок и криков "а ты кто такой" у Вас не возникло бы.

 

п.с. с другой стороны, такая занимательная статейка осталась бы ненаписаной ))

Да предисторией как этой ветки, так и той на которую указал, был вопрос - mtorrent как-то обходит pipe FreeBSD

Но, еще даже до этого вопроса, изначально возник вопрос о большом перерасходе входящего трафика,

По статистике, у првайдеров реально продавалось 60-70% от закачаных объемов.

То есть при покупке 100метров, 60% уходило на клиентов, а 40% расходовалось на дропы.

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

То что трафика расходуется чрезмено много, некоторые провайдеры знали давно и банили протокол на корню,

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

уменьшение размера пакета, действительно разгрузило полосу, но вылезла другая проблема,

сесию стало проще обслуживать появилось меньше срывов, увеличилось плотность количества сесий на секунду,

а это привело к лавинообразному увеличению ппс.

То есть увеличение ппс, это вершина айсберга и результат какойто работы,

а вот завышение входящего трафика это и есть та работа которой вызвано увеличение ппс,

даже на старом торент протоколе.

Новый торент протокол не изменил размер перерасхода, потому как уменьшение размера пакета,

привело к большей плотности сесий в секунду, что привело к тоиу же результату.

Уменьшение нагрузки на процы, путем включения полинга, полько увеличивают перерасход.

Перерасход трафика и есть невидимая часть айсберга.

 

Протокол TCP стар как мир, и предназначен для обработки в один поток, если выставлять 400 потоков, то входящая полоса выходит из под контроля,

потому как TCP не предусмотрена взаимосвязь между сесиями.

 

Но тем не менее даже по нагу, не вижу развития темы перерасхода трафика.

Наверно вызвано тем что крупные провайдеры которые имеют более квалифицированый штат,

получают львиную долю трафика с точек обмена, а на районы имеют свои каналы.

А провайдеры районного маштаба, не имеют достаточной квалификации, хотя страдают от этого больше всех.

 

По поводу внимательней излагать мысли, для человека который понимает проблему и ищет выход, достаточно намека куда рыть,

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

Изменено 1 марта, 2010 пользователем pvb

[Jugernault]

Но тем не менее даже по нагу, не вижу развития темы перерасхода трафика.

Ну а что тут развить то можно? - Ответ на вопрос "кто виноват?" известен, а вот "что делать" - вопрос открыт...

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

А вот как как минимизировать и стоит ли игра свеч - это стоит обсудить.

[Гость Trinidad]

У "сознательного" хомяка следующий вопрос:

Какие настройки я могу произвести в торренте, дабы снизить генерируемый торрентом pps?

bt.transp_disposition 5 ?

Что ещё?

 

 

Осилил 21 страницу.

[mikevlz]

перезапустить торрент еще :)

[Гость Trinidad]

Ну разовая инъекция тут погоды не сделает.

В виду имелся клиент 2.0

[vIv]

Оно сохраняется в настройках.

[Igor Diakonov]

http://forum.utorrent.com/viewtopic.php?pid=460104

Что-то не видно энтузиазма со стороны разработчиков....

[Paul Argentoff]

FPM для 3700 есть в 12.4 ветках

А как думаете/наблюдаете, включение этого правила на бордере облегчит рекурсивно pps на BRAS-ах? Или придется фильтровать вусмерть на всех клиентских интерфейсах?

Изменено 1 марта, 2010 пользователем Paul Argentoff

[Гость UkrTechInfo]

Хм, видать на Украине проблема не очень актуальна. Судя по реакции на блог в "Компьютерном Обозрении" http://ko.com.ua/node/48257

[goletsa]

Чота у меня сервер после добавления bpf правил вывалился с паникой.

 

Mar  1 18:51:47 router1 kernel: Fatal trap 12: page fault while in kernel mode
Mar  1 18:51:47 router1 kernel: cpuid = 3; apic id = 03
Mar  1 18:51:47 router1 kernel: fault virtual address   = 0x18
Mar  1 18:51:47 router1 kernel: fault code              = supervisor write, page not present
Mar  1 18:51:47 router1 kernel: instruction pointer     = 0x20:0xc08327c0
Mar  1 18:51:47 router1 kernel: stack pointer           = 0x28:0xe79a8c04
Mar  1 18:51:47 router1 kernel: frame pointer           = 0x28:0xe79a8c10
Mar  1 18:51:47 router1 kernel: code segment            = base 0x0, limit 0xfffff, type 0x1b
Mar  1 18:51:47 router1 kernel: = DPL 0, pres 1, def32 1, gran 1
Mar  1 18:51:47 router1 kernel: processor eflags        = interrupt enabled, resume, IOPL = 0
Mar  1 18:51:47 router1 kernel: current process         = 48 (dummynet)
Mar  1 18:51:47 router1 kernel: trap number             = 12
Mar  1 18:51:47 router1 kernel: panic: page fault
Mar  1 18:51:47 router1 kernel: cpuid = 3
Mar  1 18:51:47 router1 kernel: Uptime: 13h46m48s
Mar  1 18:51:47 router1 kernel: Physical memory: 2031 MB
Mar  1 18:51:47 router1 kernel: Dumping 217 MB: 202 186 170 154 138 122
Mar  1 18:51:47 router1 kernel:
Mar  1 18:51:47 router1 kernel: Fatal trap 12: page fault while in kernel mode
Mar  1 18:51:47 router1 kernel: cpuid = 2; apic id = 02
Mar  1 18:51:47 router1 kernel: fault virtual address   = 0x2c
Mar  1 18:51:47 router1 kernel: fault code              = supervisor read, page not present
Mar  1 18:51:47 router1 kernel: instruction pointer     = 0x20:0xc0676b7f
Mar  1 18:51:47 router1 kernel: stack pointer           = 0x28:0xc5973c3c
Mar  1 18:51:47 router1 kernel: frame pointer           = 0x28:0xc5973c50
Mar  1 18:51:47 router1 kernel: code segment            = base 0x0, limit 0xfffff, type 0x1b
Mar  1 18:51:47 router1 kernel: = DPL 0, pres 1, def32 1, gran 1
Mar  1 18:51:47 router1 kernel: processor eflags        = interrupt enabled, resume, IOPL = 0
Mar  1 18:51:47 router1 kernel: current process         = 32 (irq21: uhci1+)
Mar  1 18:51:47 router1 kernel: trap number             = 12
Mar  1 18:51:47 router1 kernel: 106 90 74 58 42 26 10
Mar  1 18:51:47 router1 kernel: Dump complete
Mar  1 18:51:47 router1 kernel: Automatic reboot in 15 seconds - press a key on the console to abort
Mar  1 18:51:47 router1 kernel: Rebooting...

[Paul Argentoff]

А на 72-х (бордер и 3 терминатора PPPoE&PPTP на них ) можно подрезать что-то ?

можно если у вас ios 12.4

тогда или сами создайте файл протокола

или

class-map type access-control match-any No_Torrent
match start l3-start offset 40 size 5 regex "\x7F\xFF\xFF\xFF\xAB"

policy-map type access-control No_Torrent_PM
  class No_Torrent
   drop

interface GigabitEthernet XXXX
service-policy type access-control input No_Torrent_PM

Не могу заставить работать это на 7206. Для проверки поднял означенные полиси в обе стороны на 3845 и 7206, подключенных интерфейс в интерфейс. Вот конфиги:

 

3845:

cis-3845#sh ver
Cisco IOS Software, 3800 Software (C3845-ADVIPSERVICESK9-M), Version 12.4(6)T2, RELEASE SOFTWARE (fc1)

cis-3845#sh run | sect class-map
class-map type access-control match-any cm_uTP
description classify uTP control packets
match start l3-start offset 40 size 5 regex "\x7F\xFF\xFF\xFF\xAB"

cis-3845#sh run | sect policy-map
policy-map type access-control no_uTP
class cm_uTP
   drop

cis-3845#sh run | sect GigabitEthernet0/0
interface GigabitEthernet0/0
description Link to Core c7206 g0/3
ip address 217.146.40.221 255.255.255.252
no ip mroute-cache
duplex auto
speed auto
media-type rj45
negotiation auto
service-policy type access-control input no_uTP
service-policy type access-control output no_uTP
logging source-interface GigabitEthernet0/0

cis-3845#sh policy-map type access-control interface GigabitEthernet0/0
      drop
      drop
GigabitEthernet0/0

  Service-policy access-control input: no_uTP

    Class-map: cm_uTP (match-any)
      450026 packets, 33759190 bytes
      5 minute offered rate 151000 bps, drop rate 151000 bps
      Match: start l3-start offset 40 size 5 regex "\x7F\xFF\xFF\xFF\xAB"
        450026 packets, 33759190 bytes
        5 minute rate 151000 bps

    Class-map: class-default (match-any)
      46947667 packets, 25777508056 bytes
      5 minute offered rate 111095000 bps, drop rate 0 bps
      Match: any

  Service-policy access-control output: no_uTP

    Class-map: cm_uTP (match-any)
      294168 packets, 23314466 bytes
      5 minute offered rate 95000 bps, drop rate 95000 bps
      Match: start l3-start offset 40 size 5 regex "\x7F\xFF\xFF\xFF\xAB"
        294168 packets, 23314466 bytes
        5 minute rate 95000 bps

    Class-map: class-default (match-any)
      35285160 packets, 24112820404 bytes
      5 minute offered rate 96317000 bps, drop rate 0 bps
      Match: any

 

На 7206 конфиг отличается только интерфейсом (полиси и класс приводить не буду):

c7206#sh ver
Cisco IOS Software, 7200 Software (C7200P-ADVIPSERVICESK9-M), Version 12.4(15)T1, RELEASE SOFTWARE (fc2)

c7206#sh run | sect 0/3
interface GigabitEthernet0/3
description Link to Border cis-3845-g0/0
ip address 217.146.40.222 255.255.255.252
ip route-cache flow
duplex auto
speed auto
media-type rj45
negotiation auto
service-policy input mark_our_as
service-policy type access-control input no_uTP
service-policy type access-control output no_uTP

c7206#sh policy-map type access-control interface g0/3
GigabitEthernet0/3

  Service-policy access-control input: no_uTP

    Class-map: cm_uTP (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: start l3-start offset 40 size 5 regex "\x7F\xFF\xFF\xFF\xAB"
      drop

    Class-map: class-default (match-any)
      115574331 packets, 60958812381 bytes
      5 minute offered rate 99765000 bps, drop rate 0 bps
      Match: any

  Service-policy access-control output: no_uTP

    Class-map: cm_uTP (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps
      Match: start l3-start offset 40 size 5 regex "\x7F\xFF\xFF\xFF\xAB"
      drop

    Class-map: class-default (match-any)
      96655566 packets, 48429025251 bytes
      5 minute offered rate 114720000 bps, drop rate 0 bps
      Match: any

 

Видно, что 3845 отлавливает бяку в обе стороны, а вот 7206 -- ни в одну. Интерфейсы подключены друг в друга напрямую. В чем может быть дело?

[Ivan_83]

По статистике, у првайдеров реально продавалось 60-70% от закачаных объемов.

То есть при покупке 100метров, 60% уходило на клиентов, а 40% расходовалось на дропы.

Местные провайдеры покупают полосу а не объёмы.

Вся эта арифметика смахивает на то что вы трафик продаёте помегабайтно и считаете только количество переданных данных в IP пакетах, без учёта заголовков самих пакетов. Отсюда и увеличение "потерь" с уменьшением пакетов.

Может всё ещё хуже и речь о работе через прокси, где считаются данные переданные по хттп.

 

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

Обычно "избыточный" включают в стоимость/лимиты.

 

 

Помню когда я этим занимался ещё на винде тоже репу чесал откуда накапало )

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

Потом всех запустил по впн и подсчёт стал учитывать все байты в пакете.

 

 

http://forum.utorrent.com/viewtopic.php?pid=460104

Что-то не видно энтузиазма со стороны разработчиков....

На предпоследнем скрине, где статистика по размерам пакетов при передаче по TCP мелких пакетов тоже довольно много и это никак не лечится.

Думаю разработчики сейчас думают и тестируют что и как лучше сделать.

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

С другой uTP всё равно лучше TCP, выше я писал что можно слать большие аски - даже аски не нужны, просто запрос на нужные куски.

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

 

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

 

 

Чота у меня сервер после добавления bpf правил вывалился с паникой.

Где то памяти походу не хватает.

 

в лоадер конф попробовать такое:

kern.ipc.maxpipekva="32000000" #

net.graph.maxdata="512" #

net.graph.maxalloc="4096" # Maximum number of queue items to allocate

net.graph.maxdgram="128000" #

net.graph.recvspace="128000" #

 

[dmitry1970]

Вот такая вот жопа...

Кирилл, поделись, как SCE реагирует на это?

Хоть я и не Кирилл, но отвечу SCE классифицирует этот протокол как P2P-Non-Encrypted Bittorrent, т.е. все как надо. Другое дело что отделить его от TCP на данный момент невозможно. Таким образом можно наложить ограничение только на весь Bittorrent трафик.

Друзья, а у меня на SCE2020 с PP#20 и версиями 3.5.5 uTP раcпознается как "Bittorrent Event Based over UDP" с номером сигнатуры 118095888.

 

Я его перенес в отдельный сервис, да и заблокировал в пакетах.

 

работает.

 

Правда тут другие проблемы есть...

 

[max1976]

Друзья, а у меня на SCE2020 с PP#20 и версиями 3.5.5 uTP раcпознается как "Bittorrent Event Based over UDP" с номером сигнатуры 118095888.

 

Я его перенес в отдельный сервис, да и заблокировал в пакетах.

 

работает.

 

Правда тут другие проблемы есть...

Странно, но на SCE 8000 есть только Bittorrent протокол.

[cmhungry]

Друзья, а у меня на SCE2020 с PP#20 и версиями 3.5.5 uTP раcпознается как "Bittorrent Event Based over UDP" с номером сигнатуры 118095888.

Я его перенес в отдельный сервис, да и заблокировал в пакетах.

Странно, но на SCE 8000 есть только Bittorrent протокол.

А внутри него - уже оно самое.

[vitalyb]

Небольшой оффтоп, но зато об uTP.

 

Линк, последний пост.

 

Если в uTorrent'ном swarm'е появляется другой клиент с "неограниченной" возможностью к аплоаду - он всех забивает и никто вообще не может сидировать кроме него. "Другой" клиент есстессно работает по TCP.

 

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

 

ИМХО можно сделать вывод, что без набора костылей (в том числе и политических вроде ограничений на трекерах или ярко выраженной нелюбви uTorrent'а к другим клиентам) или без доведения протокола до более агрессивного поведения, до уровня TCP, а это, в свою очередь, ломает всю идею, протокол не приживется.

 

Думаю, стоит ожидать "продолжения банкета" от авторов.

 

Изменено 2 марта, 2010 пользователем vitalyb

[halver]

Вот такая вот жопа...

Кирилл, поделись, как SCE реагирует на это?

Хоть я и не Кирилл, но отвечу SCE классифицирует этот протокол как P2P-Non-Encrypted Bittorrent, т.е. все как надо. Другое дело что отделить его от TCP на данный момент невозможно. Таким образом можно наложить ограничение только на весь Bittorrent трафик.

Вроде получилось на SCE отделить UDP торрент-траффик от TCP по сигнатуре из стандартного protocol-pack'a, а затем вынести в отдельный сервис. Завтра будет видно, сработало или нет.

[sirmax]

С Длинком более-мнее ясно, а на каталистах удалось кому-то что то подобное сделать? ИМХО, тут есть проблема...

И вообще, на цисках все плохо пока с PCF похоже ...

[cmhungry]

Отделение на SCE сигнатуры 118095888 (bittorent event-driven UDP) в отдельный сервис и блок этого сервиса к падению PPS не привело.

[sirmax]

Судя по доке

http://www.cisco.com/en/US/prod/collateral...cd80633b0a.html

что то порезать можно только на софтовых роутерах...

свитчи (в том числе и 7600-е) как бэ в пролете...блин.

Или я что то недосмотрел?