kayot Опубликовано 12 сентября, 2011 · Жалоба Если кратко - после набора ~700 ppppoe сессий и 450-500мбит трафика сервера доступа начинают 'тупить' - однопоточная закачка не разгоняется выше нескольких мбит(у пользователя нет ограничений вообще, должно быть 100мбит). Linux 2.6.31, core 2 quad Q9550, сетевка на 82576(ET dual port). Сервер терминирует pppoe и шейпит с HTB(хеш-таблицы, u32), раньше использовался IMQ для заворота трафика с ppp-интерфейсов, сегодня наконец-то от него избавился заменив на IFB, стало пролезать немного больше трафика, но полностью проблема не исчезла. Сетевки привязаны к ядрам, загрузка не превышает 50%, потерь пакетов нет, и скорости нет. Стоит отключить шейпер - начинает пролезать трафика сколько в интерфейсы влезет, т.е. проблема в самом шейпере. Где может быть узкое место? Устранять проблемы собирая очередной БРАС как-то не интересно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 12 сентября, 2011 · Жалоба для заворота трафика с ppp-интерфейсов, сегодня наконец-то от него избавился заменив на IFB Т.е. шейпера вешаются не на ppp? А какая цель заворота через IFB? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 12 сентября, 2011 · Жалоба для заворота трафика с ppp-интерфейсов, сегодня наконец-то от него избавился заменив на IFB Т.е. шейпера вешаются не на ppp? А какая цель заворота через IFB? Цель - динамическое изменение скоростей в зависимости от времени суток/скачанного объема/загрузки каналов. В принципе избавиться от лишних прослоек было бы и не плохо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 12 сентября, 2011 · Жалоба Цель - динамическое изменение скоростей в зависимости от времени суток/скачанного объема/загрузки каналов. И каким образом IFB это позволяет решить-то? :) У меня исход на IFB, вход на PPP - все прекрасно шейпится, с переменной скоростью. Даже рулится по CoA. Хеш-шейпер на 3к адресов (на каждый адрес по 3 класса!) на IFB, с недавнего времени - еще и дополнительно на 2 вланах (один - на мир, второй - UA-IX) для организации раздельной скорости некоторым пользователям. Никаких проблем не замечено. Нагрузка на каждый брас - порядка 300-400 сессий и 300+ мбит траффика. Кстати, какова загрузка проца при этом? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 13 сентября, 2011 (изменено) · Жалоба Я вешаю на ppp+ простой HTB внешка/свои_сети с парой фильтров. Описанной проблемы нет. Изменено 13 сентября, 2011 пользователем disappointed Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 13 сентября, 2011 (изменено) · Жалоба У меня тоже на PPP интерфейсах. TBF+PRIO (по сути тот же HTB). Тоже делю на классы (интернет/локалка). По 1200 сессий. CoA. accel-pppd. Проблем нет. Изменено 13 сентября, 2011 пользователем Ivan Rostovikov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 сентября, 2011 · Жалоба Цель - динамическое изменение скоростей в зависимости от времени суток/скачанного объема/загрузки каналов. И каким образом IFB это позволяет решить-то? :) У меня исход на IFB, вход на PPP - все прекрасно шейпится, с переменной скоростью. Даже рулится по CoA. Хеш-шейпер на 3к адресов (на каждый адрес по 3 класса!) на IFB, с недавнего времени - еще и дополнительно на 2 вланах (один - на мир, второй - UA-IX) для организации раздельной скорости некоторым пользователям. Никаких проблем не замечено. Нагрузка на каждый брас - порядка 300-400 сессий и 300+ мбит траффика. Кстати, какова загрузка проца при этом? Биллинг по крону генерирует готовую болванку управления шейпером(файл с набором tc qdisc/tc filter для всех клиентов), на НАСах файл запускается и обновляет лимиты скорости, для такого подхода проще шейпить на стационарных интерфейсах. Плюс у клиентов может быть несколько ip адресов, все они шейпятся сообща, плюс лимиты строятся гибко в зависимости от текущей загрузки канала(ceil всегда тарифный, rate в зависимости от свободной полосы). 500 сессий машины обслуживают легко, а вот после ~600 начинаются тормоза. Загрузка процессора по ядрам пиково 0/0/30/40, если affitiny поставить для пары ядер - по 15% на ядро, ресурсов CPU полно. Или буфера где-то нужно увеличить, или настройки самого шейпера крутить.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 сентября, 2011 · Жалоба Есть ли смысл поднять на интерфейсе смотрящем в мир 2 очереди, а интерфейсов на которые поднимаются клиентские pppoe сессии сделать два? И есть ли смысл пытаться переделать все на accel-ppp с его шейпером? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 сентября, 2011 · Жалоба Я бы для начала ядро обновил, до 2.6.35.14 к примеру (более свежие - были грабли с туннелями/шейперами, как в 3.0 - не знаю). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 сентября, 2011 · Жалоба Ядро обновить не так просто, биллинг для подсчета трафика используется патчи ipt_acct которых я под новые ядра не встречал.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 сентября, 2011 · Жалоба http://www.intra2net.com/en/developer/ipt_ACCOUNT/index.php - вплоть до 2.6.37 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 сентября, 2011 · Жалоба NiTr0 Вот так спасибо, я от них обновления ждал с 2009ого и думал что проект давно заброшен. Буду обновлять софт, а там посмотрим. Проблема кстати проясняется, тормоза скорее не от большого числа сессий, а от банального перегруза по трафику(точнее по pps). Пока трафика меньше полугига, все ок даже при 800 сессий. Если 500+ мбит - тормозит. Осталось понять почему оно тормозит при 50% загрузке.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 сентября, 2011 · Жалоба Какое ядро лучше ставить для NAS'a терминирующего pppoe и шейпящего трафик? Как-то лениво проверять все версии подряд. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
wtyd Опубликовано 14 сентября, 2011 · Жалоба Какое ядро лучше ставить для NAS'a терминирующего pppoe и шейпящего трафик? Как-то лениво проверять все версии подряд. Наверное какие-либо из так называемых lts ядер. Напрмиер, в archlinux это 2.6.32.46, но я видел и 2.6.34.х вроде бы. Сейчас kernel.org не работает по известным причинам, так что решайте сами. Вообще попробуйте 3.0.4 и, если с ним не будет глюков, то юзайте его. Если будут - смотрите на lts. Тут просто в соседней теме написано про страЩные глюки с igb. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 14 сентября, 2011 · Жалоба Стоковое ядро из дебиана прекрасно "лопатит" трафик. И стабильно как камень. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
cpulink Опубликовано 14 сентября, 2011 · Жалоба Скорее всего дело не совсем только в ядре. Тоже пытаюсь сделать общую полосу по ifb на HTB. После поиска стабильных ядер и igb дошел до 3.rc(3-4) брал и гита davem в августе. Так вот про бараны - упорно повторяется ситуация с общим htb и когда юзеров более 700 начинает зажимать полосу. Доводил до 2100 юзеров, ситуация еще хуже становится. Игрался размерами очередей, задирал общую полосу шейпера под 5 гигабит, увеличивал берсты - толку мало. Единственно что еще не проверил это тики (по умолчанию HZ=250) ну и вариант создания своего ifb на каждую группу по 700-800 юзерей. Да и конечно забыл уточнить, тарифы - мегабиты 5-55, безлимиты... Запас процев есть, сетевые - интел igb. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 14 сентября, 2011 (изменено) · Жалоба Собрал пока новый мускулистый NAS на i5-2500@3.6Ггц, 630 сессий и 450/200мбит трафика полет отличный, загрузка 3-4%. По идее в час пик отберет под 1к сессий и метров 700 трафика, поглядим на его здоровье. Изменено 14 сентября, 2011 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 14 сентября, 2011 · Жалоба upd: 800 сессий, 500-600мбит трафика. Загрузка 5-6%, тормозов нет и в помине(99мбит/с спидтест говорит). Значит сама операция копирования трафика с eth/ppp интерфейса на виртуальные imq/ifb кривая и ресурсоемкая, более мощное железо сместило планку тормозов подальше. Надо перестраивать все на шейпинг на юзерских ppp'шках, осталось придумать как в онлайне менять скорость для сессии. Может подскажете простое решение? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 15 сентября, 2011 · Жалоба Как раз для этого придумали CoA. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 15 сентября, 2011 · Жалоба Тыкните где почитать если не сложно, наш биллинг и с радиусом то работает с помощью костылей, все придется прикручивать ручками. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 16 сентября, 2011 · Жалоба осталось придумать как в онлайне менять скорость для сессии. Может подскажете простое решение? У меня простым перебором ppp+ делается, грохается старый шейпер и заново конфигурится новый. Но я это не использовал, написал для себя и отложил как недоделку, т.к. последовательный реконфигур занимает некоторое время, а за него может кто-то отключится / подключится и кому-то неверно встанет шейпер. По идее нужно ещё сразу перед моментом удаления структур tc делать проверку тот ли это ppp* который получен в результате запроса в БД в начале скрипта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 16 сентября, 2011 · Жалоба Тыкните где почитать если не сложно, наш биллинг и с радиусом то работает с помощью костылей, все придется прикручивать ручками. RFC3576 Его реализация для pppd - radcoad (тута постил тему), живет на моих брасах собссно с год без приключений. Хоть и выглядит коряво ввиду отсутствия времени и острой необходимости чистки кода. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 16 сентября, 2011 (изменено) · Жалоба Использую с классами и хэш-фильтрами htb на ifb-интерфейсах (по два на каждом роутере в зависимости от dscp-бита, допустим, 0x80 на ifb0, а 0x84 на ifb1) промежуточных роутеров, на которые асимметрично исходящему роутится с помощью bgp_local_pref входящий трафик на абонентские /32 с бордера. Примерно 16000 фильтров и классов, трафик до 300-400 Mbps (FD), роутера два, на каждом из них loadavg и использование памяти практически нулевые (второе достигнуто отключением conntrack с -j NOTRACK в таблице raw). Ядро стоковое дебиановское, 2.6.32-5. При отключении одного из роутеров нагрузка не меняется, второй роутер просто для redundancy. Обновляется это из Cron раз в сутки скриптом на Python, использующим XMLRPC-интерфейс самописной вещи, постепенно заменяющей UTM5, сначала строятся классы для каждого ifb, потом строятся с помощью найденной где-то в Интернете программки на C фильтры с использованием хэш-таблиц, а потом всё это обновляется с tc -b. PPPoE и других туннелей на сети практически нет, так что немножко не в тему :) Изменено 16 сентября, 2011 пользователем GFORGX Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 16 сентября, 2011 · Жалоба Трафика мало и интерфейсов 4 вместо тыщи, не тот случай. Для себя решил - буду все-таки пилить accel-ppp и шейпинг на интерфейсах + COA. Надоели подобные неуловимые проблемы, хочу как у всех - тупит, значит или 100% загрузка CPU, или ошибки на интерфейсе :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GFORGX Опубликовано 17 сентября, 2011 · Жалоба Трафика мало и интерфейсов 4 вместо тыщи, не тот случай. Это я всё к тому, что, на мой взгляд, неправильно шейпить прямо на BRAS на Линуксе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...