Jump to content
Калькуляторы

photon

Активный участник
  • Content Count

    886
  • Joined

  • Last visited

Everything posted by photon


  1. sc: скрипт для управления провайдерским шейпером на основе Linux Реализована простейшая схема: один IP на класс обслуживания с фиксированной полосой пропускания. В качестве источника данных может быть использована любая SQL-база, поддерживаемая Perl DBI. Для классификации трафика используются наиболее оптимальные методы: фильтр flow в связке с ipset или хэширующие фильтры u32 (по выбору). Для u32 реализованы шейпинг и полисинг. Загрузка и синхронизация правил для тысяч IP-адресов происходит за секунды благодаря использованию пакетных режимов tc и ipset. Страница проекта на Sourceforge: http://sourceforge.net/projects/sc-tool/ Зеркало проекта на Bitbucket: http://bitbucket.org/sky/sc/src
  2. Для этого уже есть опции bypass_int и bypass_ext. Надо будет по умолчанию туда добавить 224.0.0.0/24.
  3. Нет, шейпится только unicast traffic, потому что классификация идет по адресам источника и назначения. Однако, можно создать специальную подсеть для multicast traffic и добавить правила для нее.
  4. Как раз сегодня закоммитил такой патч, можете скачать из репозитория и потестировать. Имена нескольких интерфейсов разделяются пробелами: out_if = eth1 eth2 eth3 ... Если есть возможность, то лучше сделать interface bonding и работать с одним интерфейсом, чтобы не нагружать ядро лишними копиями правил.
  5. Я реализовал это дело без псевдоустройств, с помощью полисинга входящего трафика и шейпинга исходящего: https://sourceforge.net/projects/sc-tool . Если используются только IPv4-адреса, то ipset и iptables из ссылки в предыдущем посте не нужны, все делается правилами tc и поэтому работает быстрее. Да и IPv6 вообще говоря можно точно так же побайтово хэшировать, просто это никому не надо.
  6. "HTB: quantum of class 10001 is big. Consider r2q change." означает, что значение quantum слишком велико, но это не объясняет почему клиенты не добавлялись. Нужен хотя бы конфигурационный файл и копия сломанной базы, чтобы воспроизвести проблему. Почему не пользуетесь новой версией?
  7. Не поможет. Либо расширяйте внешний канал, либо надо резать скорость наиболее активным качальщикам. Можно ловить их как в реальном времени, так и постфактум с помощью Netflow.
  8. Один из последних заказов на доработку как раз был по поводу полисинга 10-гигабитного канала на много пользователей. Приоритезацию по портам можно делать оптом для всех на пограничном маршрутизаторе, после шейпера. Совмещать это с шейпером не советую. Я высылаю ее после оплаты. Там есть деление одной полосы на несколько IP. Если использовать htb для приоритезации разных видов трафика внутри пользовательских классов, то очень быстро исчерпаются доступные номера, которых всего 2^16-2. Когда у вас теряются пакеты из-за потолка на внешнем канале никакой QoS все равно не спасет.
  9. Краевые дисциплины можно использовать какие угодно, изменив значение параметра leaf_qdisc на "esfq perturb 10". sc предназначен для шейпинга трафика, т.е. нарезки полос для нескольких десятков тысяч клиентов при минимальном расходе процессорного времени. Поэтому там нет приоритезации трафика по портам и маркам. ESFQ тоже потребляет процессор, поэтому по умолчанию стоит pfifo. Такие вещи дешевле делать на стороне пользователя, продав ему роутер с настройками QoS. Несколько IP на одну очередь и какие-то дополнительные возможности есть в коммерческой версии.
  10. Если эти два интерфейса не для балансировки, то в локальных сетях будут разные IP. Соответственно, базы аккаунтов и экземпляры sc для каждой из сетей должны быть разными. А если интерфейсы используются для балансировки, то их проще объединить в один виртуальный (LACP bonding) и повесить sc уже на него.
  11. Да, именно так. Иначе бы не было смысла вводить отдельную команду.
  12. Вы пытаетесь сделать хэширование по всем четырем октетам IP-адреса. Это довольно избыточно и сложно. Я делаю максимум по двум последним октетам, и на двух гигабитах все летает.
  13. Вся информация об изменениях есть в истории коммитов, пользуйтесь системами контроля версий.
  14. Вот этот коммит: https://bitbucket.org/sky/sc/commits/5ff17f4581d463e11d5755d3662890e31d7354cf?at=default Начиная с каких-то версий от 2013 года, tc -batch не читал данные из пайпа без этого дефиса, поэтому пришлось добавить. А вы с какой целью интересуетесь? С последним iproute2 все работает.
  15. Сделал так. Параметр default_policy теперь может принимать три значения: block-all (блокировать строго все, чего нет в базе), block (блокировать все, кроме самого шейпера), pass (пропускать все).
  16. Стоит ли добавить автоматический bypass для IP-адресов сетевух шейпера, чтобы его не вырубало при загрузке правил из базы, где нет его адресов?
  17. Маршрутизацией занимается маршрутизатор, а не мост.
  18. Нет, в sc так делать нельзя. Это сожрет классы, которых всего 2^16-2, и их не хватит на всех клиентов. Приоритеты внутри очереди лучше делать на стороне клиента, например, продав ему пренастроенный маршрутизатор или услуги по такой настройке. В Винде оно настраивается через консоль Local Group Policy Editor. Для совсем тупых некоторые игровые материнки уже из коробки имеют софт для управления сетевым трафиком.
  19. Это хорошо, что линейная зависимость сохраняется даже при высоких скоростях. Поставлю 0.2 как значение по умолчанию.
  20. Это известная особенность полисинга. По большому счету, им можно регулировать только пакетрейт, а не битрейт. Надо эмпирически настраивать burst и полосу для того, чтобы скорость соответствовала номиналу, и контролировать это дело iperf'ом. Если у вас полоса до 2 Гбит/с, то можно спокойно сидеть на шейпинге. У знакомого процессор уходил в потолок из-за глобального лока в HTB начиная где-то с 4-х Гбит/с.
  21. Задача поставлено неправильно. Что делать: 1. Избавиться от Mikrotik в пользу Linux. 2. Избавиться от PPTP в пользу IPoE. 3. Делать приоритезацию на border gateway для всего трафика по его типу (номера портов), а не внутри клиентских классов.
  22. Был у меня похожий вопрос к программистам ядра несколько лет назад. Сказали, что нужно всегда указывать handle и лучше использовать replace вместо add. tc filter replace dev em2 parent 1: handle 10:d8:800 u32 ht 10:d8: match ip dst 10.0.10.216/32 flowid 1:1772
  23. Это какой-то баг в конвертации единиц, который может быть в вашей версии tc. Используйте единицы IEC, кратные 1024: Mibit и kibit, тогда разночтений не будет.
  24. Какая у вас СУБД и тип данных у поля скорости? Я тестирую на SQLite с типом "UNSIGNED INTEGER NOT NULL", там такого нет.
  25. Коммутация теоретически быстрее, чем маршрутизация, но если в том и другом случае задействован CPU, то разница невелика. Оптимальные настройки зависят от того, насколько загружен канал и каков пакетрейт в часы пиковой нагрузки. Если нагрузка до 3 Гбит/с, то при таком числе пользователей еще можно использовать шейпинг: limit_method = shaping root_qdisc = htb default_rate = 10gibit quantum = 30000 leaf_qdisc = "pfifo limit 1000" Если нагрузка от 3.5 Гбит/с и более, то следует перейти на полисинг: limit_method = policing Для полисинга близко к номинальной скорости нужно найти правильные размеры приемных буферов, т.е. подвигать параметр policer_burst_ratio, а если это не поможет, то подобрать их эмпирически и прописать в коде.