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

_dx

Пользователи
  • Content Count

    32
  • Joined

  • Last visited

About _dx

  • Rank
    Абитуриент
  • Birthday 05/08/1986

Контакты

  • Сайт
    http://
  • ICQ
    300309333

Информация

  • Пол
    Мужчина
  • Интересы
    networks, embedded systems programming, linux

Город

  • Город
    Украина, Крым, Ялта
  1. Я тут на ЛОРе задал тот-же вопрос https://www.linux.org.ru/forum/admin/10897061 И там товарищ под ником Pinkbyte утверждает, что шейпер входящего траффика на IFB это вроде как и не шейпер вовсе, а просто дропалка. На что я заявил, что в конечном итоге любой шейпинг входящего это в конце концов дропалка пакетов... В общем там не много, кому не лень может перечитает нашу переписку, но вкратце суть такова Получается вот тут он уже видит полисинг eval tc qdisc add dev "${iface}" ingress eval tc filter add dev "${iface}" parent ffff: protocol ip \ u32 match u32 0 0 action mirred egress redirect dev "${lan_ingress_ifb}" При этом человек осознает, что дальше на egress ifb цепляется HTB со SFQ по краям, всё как положено. Я предположил, что дело в длине очереди, чем она длиннее - тем на дольше можно задержать пакет. В общем мне теперь стало интересно, товарищ что-то не то курил и спорит не о чем или действительно такое может быть и я чего-то не понимаю??
  2. ip на netns ругнулся. Там в Debian 6 чё-то доставить надо или обновляться на седьмую/убунту? LXC это как раз оно ж? https://linuxcontainers.org/ https://wiki.debian.org/LXC Кстати IMQ по ходу жив еще https://github.com/imq/linuximq/tree/master/latest
  3. На самом деле я немного погуглил и уже начал понимать, что IMQ по ходу заброшен.... Потом я ооочень хорошо подумал реально надо ли мне, чтобы роутер что-то качал и учитывая объем заморочек я подумал, что ну его в болото )))
  4. Юзеров не много, 10 машин. Скорость инета до 20мбит. Честно сказать, на хэщах я сделал больше из соображений перфекционизма, но нагрузка на проц снизилась и скорость скачивания файла через гигабитный линк возросла ) Уже понял, что придется заморочиться с IMQ. netns наверно будет более затратно по ресурсам, хотя идея прикольная, спасибо за наводку!
  5. Всем привет! Заранее пардон, если тут строго провайдерское применение линукса обсуждают..У меня применение не провайдерское, но знаю, что адекватный ответ от хороших спецов получить здесь проще всего. В общем есть очень дохлый роутер/файлопомойка на Debian 6(VIA C3 700MHZ, 512RAM, 1TB RAID1, Intel 82546GB), ну нравится мне выжимать всё из старого железа :) Весь траффик LAN части аггеригуется на двух ifb(для ingress и egress шейпинга) и делится между юзерами(HTB), фильтры на хэшах(ибо смотри пункт первый про дохлость сервера). Весь шейпинг получается на этих двух ifb. Роутер связан с внешним миром через интерфейс ppp0, который естественно NATится, поэтому шейпить на ppp0 не получается. Ах да, там еще весь LAN на squid transparent загоняется. Для LAN юзеров всё прекрасно шейпится, но хотелось бы, чтобы и сам роутер выходил в инет через те-же ifb и его трафик шейпился наравне с LANовскими юзерами. А то сейчас если роутер что-то качает - все курят бамбук. Даже наверное лучше не так сформулировать, через какой интерфейс всё это пройдет наверно не важно - важно, чтобы траффик самого роутера отъедал кусок пирога от того-же HTB класса что и LAN юзеры, очень хотелось бы, чтобы он постоянно что-то качал с низким приоритетом и никому не мешал. Идеи по этому поводу у меня такие: 1. как-то накрутить source routing и направлять пакеты не сразу через ppp0,а каким-то образом сделать так, чтобы роутер сам себя обманывал и свои пакеты считал транзитными, пришедшими с LAN стороны...далее бы эти пакеты попадали в те-же ifb и прекрасно шейпились... это только идея, пока не представляю можно ли реализовать это дело на практике 2. поговаривают, что IMQ в тесном сотрудничестве в iptables мог бы выручить меня, но во-первых там патчить придется дофига, а во-вторых многое из того что есть придется переделывать, в третьих по скорости всё это будет явно хуже фильтров на хэшах. пока в общем с IMQ связываться не хотелось бы. 3. возможно еще какие-то извращения придумать.. допустим всех юзеров(включая сам роутер) подключить через openvpn к одному tun и шейпить уже там всё это дело... но тут снова куча дополнительного гемора получается, может даже лучше тогда с IMQ заморочиться.. Интересно узнать что кто думает по этому вопросу? Что же делать как же быть?
  6. class htb 1:2 root rate 1000Kbit ceil 1000Kbit burst 1600b cburst 1600b class htb 1:30 parent 1:2 rate 256000bit ceil 1000Kbit burst 1600b cburst 1600b class htb 1:31 parent 1:30 leaf 31: prio 0 rate 128000bit ceil 1000Kbit burst 1600b cburst 1600b class htb 1:32 parent 1:30 leaf 32: prio 0 rate 128000bit ceil 1000Kbit burst 1600b cburst 1600b Linux blablabla 2.6.32-5-486 #1 Sun Sep 23 09:17:35 UTC 2012 i686 GNU/Linux Debian 6.0.6 При создании класса 1:30 был указан prio 2! У класса 1:2 больше одного потомка(показано не всё), т.е. prio в принципе имеет смысл. А именно (из мануала) The rule is that classes with higher priority are offered excess bandwidth first. Здесь класс 1:30 представляет хост, а :31 и :32 это UDP и TCP в пределах этого хоста. Задача сделать некоторые хосты с бОльшим приоритетом. Я конечно могу сделать приоритет краевых классов 1:31 и 1:32 больше чем у соответствующих классов остальных хостов, но тогда получается, что prio работает как-бы глобально.... Позволит ли это сделать хосты более приоритетными относительно остальных потомков класса 1:2 или же они будут меряться приоритетом со всеми краевыми классами HTB?Просто есть ещё класс 1:1 в который вообще загоняется локальный траффик и там должна быть отдельная кухня. Помню когда-то давно prio без проблем ставился на любой класс. Никак не удаётся нагуглить внятного ответа на вопрос.
  7. Прочитал вот http://habrahabr.ru/blogs/linux/127184/ Интересно, как опытные коллеги отзовутся об этом инструменте?
  8. Да вот напрягает меня, что 2 и более pptp клиента за одним натом бывает не очень уживаются... openvpn ещё делает роутинг(по своей внутренней таблице) и общается(опять таки из юзерспейса) с интерфейсом tun, что тоже не добавляет ему быстродействия. Так что оно там одно на одно и набежит, если всё вместе посчитать..
  9. да вроде и там и там свежие версии есть...http://www.strongswan.org/download.html http://www.openswan.org/code/ чем strong лучше open? по сравнительной таблице вроде как open более продвинутый получается... http://wiki.openswan.org/index.php/Openswan/FeatureComparison
  10. Да, тут фишка именно в шифровании. Биллинг не нужен. Я так понимаю, что придётся делать и pptp и ipsec\l2tp (openvpn уже есть), а потому действительно accel-pptp выходит на передний план ввиду своей универсальности... Главный вопрос какую версию аццела юзать? Важнее всего стабильность.
  11. Ну вот я и не знаю просто надо он мне или нет... Тем более, что сервак будет арендован где-нибудь в германии и оно как-то по-моему не очень удобно будет даже просто багрепорт генерить... Может быть несколько веских аргументов за и против подкините?
  12. В общем расчитывается всё где-то на сотню-другую(не больше) 3G road warrior'ов и в общем то вроде как самое правильное решение получается на IPSEС/L2TP с NAT-T. С PPTP вроде как будут проблемы если два клиента окажутся за одним натом, да и секурити ни к чёрту. А такие вездеходные вещи как openvpn в таком случае отпадают ибо смартфоны/планшеты и прочие айфоны из коробки его не поддерживают(а жаль) :( Поправтие, если не прав. Пока вроде как прикинул, что OpenSWAN(на netkey) + xl2tpd вроде как является достаточно типовым, испытанным решением, но достаточно громоздким и тормозным. Потом нагуглил, что accel-pptp тоже вроде как умеет l2tp, но наткнулся на кернел паники и прочие упсы...стало страшно. Думаю, от всех клиентов можно ожидать около 20kpps, что не так то много... Правильно ли я мыслю, что OpenSWAN(на netkey) + xl2tpd в такой задаче является оптимальным решением?
  13. Почему-то думал, что стандартная таблица 800 и так всегда существует... нет? Поэкспериментирую...
  14. зачем делатся рутовый фильтр?