_dx

Я тут на ЛОРе задал тот-же вопрос 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 по краям, всё как положено. Я предположил, что дело в длине очереди, чем она длиннее - тем на дольше можно задержать пакет. В общем мне теперь стало интересно, товарищ что-то не то курил и спорит не о чем или действительно такое может быть и я чего-то не понимаю??

ip на netns ругнулся. Там в Debian 6 чё-то доставить надо или обновляться на седьмую/убунту? LXC это как раз оно ж? https://linuxcontainers.org/ https://wiki.debian.org/LXC Кстати IMQ по ходу жив еще https://github.com/imq/linuximq/tree/master/latest

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

Я правда не очень понял, жуткий - это про IMQ?

Юзеров не много, 10 машин. Скорость инета до 20мбит. Честно сказать, на хэщах я сделал больше из соображений перфекционизма, но нагрузка на проц снизилась и скорость скачивания файла через гигабитный линк возросла ) Уже понял, что придется заморочиться с IMQ. netns наверно будет более затратно по ресурсам, хотя идея прикольная, спасибо за наводку!

Всем привет! Заранее пардон, если тут строго провайдерское применение линукса обсуждают..У меня применение не провайдерское, но знаю, что адекватный ответ от хороших спецов получить здесь проще всего. В общем есть очень дохлый роутер/файлопомойка на 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 заморочиться.. Интересно узнать что кто думает по этому вопросу? Что же делать как же быть?

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 без проблем ставился на любой класс. Никак не удаётся нагуглить внятного ответа на вопрос.

Прочитал вот http://habrahabr.ru/blogs/linux/127184/ Интересно, как опытные коллеги отзовутся об этом инструменте?

Да вот напрягает меня, что 2 и более pptp клиента за одним натом бывает не очень уживаются... openvpn ещё делает роутинг(по своей внутренней таблице) и общается(опять таки из юзерспейса) с интерфейсом tun, что тоже не добавляет ему быстродействия. Так что оно там одно на одно и набежит, если всё вместе посчитать..

да вроде и там и там свежие версии есть...http://www.strongswan.org/download.html http://www.openswan.org/code/ чем strong лучше open? по сравнительной таблице вроде как open более продвинутый получается... http://wiki.openswan.org/index.php/Openswan/FeatureComparison

Да, тут фишка именно в шифровании. Биллинг не нужен. Я так понимаю, что придётся делать и pptp и ipsec\l2tp (openvpn уже есть), а потому действительно accel-pptp выходит на передний план ввиду своей универсальности... Главный вопрос какую версию аццела юзать? Важнее всего стабильность.

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

В общем расчитывается всё где-то на сотню-другую(не больше) 3G road warrior'ов и в общем то вроде как самое правильное решение получается на IPSEС/L2TP с NAT-T. С PPTP вроде как будут проблемы если два клиента окажутся за одним натом, да и секурити ни к чёрту. А такие вездеходные вещи как openvpn в таком случае отпадают ибо смартфоны/планшеты и прочие айфоны из коробки его не поддерживают(а жаль) :( Поправтие, если не прав. Пока вроде как прикинул, что OpenSWAN(на netkey) + xl2tpd вроде как является достаточно типовым, испытанным решением, но достаточно громоздким и тормозным. Потом нагуглил, что accel-pptp тоже вроде как умеет l2tp, но наткнулся на кернел паники и прочие упсы...стало страшно. Думаю, от всех клиентов можно ожидать около 20kpps, что не так то много... Правильно ли я мыслю, что OpenSWAN(на netkey) + xl2tpd в такой задаче является оптимальным решением?

Почему-то думал, что стандартная таблица 800 и так всегда существует... нет? Поэкспериментирую...

зачем делатся рутовый фильтр?

Заработало, но меня смутило это

Нет, ну это просто жесть какая-то, а! Я себе весь моск вынес с этим tc! В тексте не точность, но не shift 6, а выше. Там где Автору стоило бы обратить внимание на то, что на самом то деле offset в БАЙТАХ, а не в вордах. Да, в принципе он написал всё правильно - оффсет определяет какой именно ворд будет взят на матч, но ведь на такие моменты нужно обращать внимание! Я часа 4 эту тему мусолил в голове перед тем как запостил сюда вопрос и только сейчас пришло просветление: Дело всё в том, что в поле IHL IP заголовка значение хранится как раз в 32битных ВОРДАХ! т.е. к offset нужно прибавить IHL*4 И делая shift 6, вместо shift 8 мы как раз и делаем результат в 4 раза больше! Там то нули в младшем байте(после маски 0f00), а значит их не страшно оставить и получаем в аккурат IHL*4!

ну в общем стало понятно, что без link не обойтись... ладно.. Накурился этого рецепт такой: Всё понятно, но почему shift 6, а не 8????? Ведь нам нужно получить длину заголовка, а она в старшем байте, точнее даже в полубайте(что и видно по маске), но младший байт по любому нужно шифтить нафиг! А это же 8, а не 6. Чего-то я явно не догоняю.... Или это как раз тот случай, когда автор намеренно допускает ошибку?

Нужно чтобы UDP пакеты с sport 1194 попадали в класс 1:10 хотел написать tc filter add dev "${wan_iface}" protocol ip parent 1:0 prio 1 \ u32 match ip sport 1194 0xffff flowid 1:10 но потом прочитал это Естественно я не уверен насчёт ip header contains no options.. читаю дальше Честно говоря я пока не очень понял как пропустить ip заголовок(ибо длина то его может меняться) Хочется попроще как-нибудь... Никак? P.S. У меня уже возникло желание разобраться во всем этом детально и либо конкретно пропатчить tc, либо как минимум написать нормальную обёртку для всех этих дел. Ну не должен быть match по sport таким сложным! Ну не нормально же это!

читаю http://computerlib.narod.ru/html/adslmanagement.htm Как же так? Всё реально так плохо? Может быть ограничение скорости(дроппер)является самым правильным решением? Но на какую велечину тогда ограничивать скорость? У меня через роутер(Linux) будет ходить ~100 Skype переговоров одновременно, как мне лучше обрабатывать входящий траффик? И ещё вопрос: как правильно выбрать qlen на интерфейсах? Спсибо.

Ну с 1000 я ещё могу согласиться. Но 3 - 6... Интересно мнение более опытных коллег.

Вседа думал, что на сервере такие большие значения не только не нужны, но ещё и вредны... Чем объясняется необходиомсть такого повышния частоты? Не внесет ли это больше оверхеда, чем пользы??

Всё вроде верно, но пока только не понял про затык по CPU...как одно с другим связано то? Ну так к sfq прилагается же flow hash keys dst/src(смотря в какую сторону шейпер). Полчуается в точности тоже самое, что и ESFQ(кстати deprecated вроде как). И всё-же: какой-то эффект в качестве обслуживания будет от sfq на ingress? мы говорим сейчас о voip траффике же, т.е. задержка важна и я почему-то думаю, что если роутер будет создавать "эффект параллельности", раздавая пакеты из очереди всем по порядку - будет лучше... Как оно на практике то будет? Ну и ворос с ограничением скорости интерфейсов остаётся пока для меня открытым...

Разобрался практичеси со всеми интересующими вопросами.. Сейчас уже работает "объединение" ingress и egress всех tun в два разных ifb, на которых успешно работает sfq с flow hash keys, а также испытал в комбинации с htb. У меня вопрос по WAN интерфейсу(eth0). Какую дисциплину там лучше использовать? Кому отдать приоритет? Напомню топологию: (к примеру клиент передаёт данные на nag.ru) vpn_client->{INTERNET}->eth0->ovpn->tun0->(nat)eth0->{INTERNET}->nag.ru Таким образом на eth0 присутствуют как пакеты openvpn так и остальной траффик идущий туда/сюда по запросам клиентов. С одной стороны была идея жестко разделить полосу 50/50 для openvpn пакетов и остальных и обрабатывать эти две очереди по очереди(round robin). Потом подумал, что sfq было бы правильнее, но видимо нужно дать больший приоритет openvpn пакетам, т.к. vpn соединений может быть 10, а остальных коннектов 100... И главный вопрос: где ограничивать скорость интерфейса? на eth или на ifb. А скорее и там и там(точнее везде, где хотим обрабатывать очередь)? Т.е. везде цеплять в root htb?(или есть что-то более оптимальное для таких случаев? может быт red? им вообще кто-то пользуется? ) )

На сервере будет одна сетевуха и я хотел прибить openvpn демоны к 127.0.0.1 а с eth0 форвардить порт для распределения нагрузки по разным демонам(потому что openvpn однопоточный и тормозной). Но DNAT не хочет перекидывать пакеты на 127.0.0.1 Тупо фильтровать на INPUTe тоже получается как-то не весело ибо как отличить пакеты, пробравшиеся прямо с eth0 на конкретный порт и перекинутые по DNAT? Получается маркировать надо, а потом по меткам разбирать.. ерунда всё это... лишние правила ещё и в достаточно нагруженной таблице filter...не оптимально совсем.. Может какой виртуальный интерфейс поднять тогда? но тоже как-то слишком жирно выходит.. Что в таких случаях делают? Куда забиндить openvpn чтобы к нему доступа не было без форвардинга?