[heap]

Имееться сервачок Debian 3.1 - на не собраны poptop 1.3.2 и pppd 2.4.4

Клиенты подключаются, работают, но есть одно НО....

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

Второе - пронаблюдал пинги в этот момент - пинги на какой-то промежуток времени пропадают.

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

 

Пробовал играться с mtu/mru. На данный момент стоит 750 - но ситуация не решилась.

 

Может кто сталкивался с подобной проблемой? Куда еще можно покопать?

[Kirya]

Poptop обнови.

[heap]

Poptop обнови.

Дык итак уже сегодня с 1.3.0 на 1.3.2 обновил. 1.3.2 итак числиться как testing/current. Хотя на 1.3.0 и на 1.3.2 проблема идентична.

 

Пробую собрать ванильное ядро 2.6.16.39 - на данный момент стоит ванильное 2.6.16.35.

 

Какие еще варианты?

 

PS: только что нашел на sf.net версию 1.3.4. Странно, что она не висит на оффсайте. Собираю - пробую.

Изменено 7 июля, 2007 пользователем heap

[heap]

Poptop обнови.

Поставил 1.3.4 - вроде бы помогло :) Спасибо.

[Kirya]

C версии 1.3.3 сменился маинтейнер.

Так что http://poptop.sf.net - это сейчас и есть официальный сайт.

[Илья Дмитриевич]

на 2.6.19.1 стабильно работает на 2.6.16.X затыки были

[heap]

на 2.6.19.1 стабильно работает на 2.6.16.X затыки были

Собсно сама пересборка ядра из ванильных сорцов в свое время затевалась ради патча IMQ. А так как он почти не развивается, а ветку 2.6.16.х объявили стабильной - вот и собираю из нее ядрышки.

В ченджлоге poptop 1.3.4, по-моему, описана как раз моя проблема - связанная с порядком прихода пакетов и отбросом их. Пока все работает - норм.

[Kirya]

А это тогда что ?

 

http://www.kernel.org/

The latest stable version of the Linux kernel is: 2.6.21.6

:)

 

Да и по IMQ со времен 2.6.16 вообще-то изменения были, например работа с iptables 1.3.7 начиная с 2.6.19, недавно вышел патч для iptables 1.3.8.

 

[В ченджлоге poptop 1.3.4, по-моему, описана как раз моя проблема - связанная с порядком прихода пакетов и отбросом их. Пока все работает - норм.

Эта проблема была решена в 1.3.3.

1.3.4 - minor fix.

Изменено 7 июля, 2007 пользователем Kirya

[heap]

А это тогда что ?

 

http://www.kernel.org/

The latest stable version of the Linux kernel is: 2.6.21.6

:)

 

Да и по IMQ со времен 2.6.16 вообще-то изменения были, например работа с iptables 1.3.7 начиная с 2.6.19, недавно вышел патч для iptables 1.3.8.

 

[В ченджлоге poptop 1.3.4, по-моему, описана как раз моя проблема - связанная с порядком прихода пакетов и отбросом их. Пока все работает - норм.

Эта проблема была решена в 1.3.3.

1.3.4 - minor fix.

Вопрос не в том, что есть более свежие ядра, или что IMQ все-таки черепашьими шажками получает в код изменения от энтузиастов слева, а не от мэйнтейнеров, а в том - что шагая по ядрам вверх - есть шанс где-то упереться в несовместимость API/ABI (не спроста шапка в RHEL версию ядра вообще не меняет). Кроме того с ядра 2.6.18 уже в ядро запихали IFB, поэтому ИМХО IMQ пришел конец - к нему еще больше потеряют интерес. Но мну в короткий срок перелизать сервант под IFB нет времени, поэтому будет крутиться под 2.6.16.х, до тех пор пока с Дебиана не перекочует под какой-нить CentOS. Хотя после словленного бага в Fedora4-Fedora8(видно не поправят и в 8) включая RHEL5 с rp-pppoe+sysklogd (я тут заводил другой топик) - чую будут сервачки с Debian'a переползать под FreeBSD. Благо там шейпинг трафика это наименее геморное занятие, да и таких глупых траблов, кочующих из года в год из релиза в релиз нет. Шапки в багзилле копят баги на эту тему и не чешуться. :(

[Kirya]

Про IFB я знаю, но лично мне например его заставить коректно не удалось. Пока не будет нормальной документации по-моему он мертв. Это не iproute2, где можно спокойно жить без неё.

 

По rp-pppoe ?

Я не вижу проблем пересобрать pppd. Так как идущий в RPM все-равно собирается без радиуса, т.е в большинстве маштабируемых систем его все-равно придется пересобирать.

 

По шейпингу и фрюшке ?

Pipe это конечно клево, но попробуй, сделать на нем полноценный HTB.

А про mpd уж и говорить нечего, 6 лет уже отлаживают, а конца и края не видно.

[heap]

Про IFB я знаю, но лично мне например его заставить коректно не удалось. Пока не будет нормальной документации по-моему он мертв. Это не iproute2, где можно спокойно жить без неё.

 

По rp-pppoe ?

Я не вижу проблем пересобрать pppd. Так как идущий в RPM все-равно собирается без радиуса, т.е в большинстве маштабируемых систем его все-равно придется пересобирать.

 

По шейпингу и фрюшке ?

Pipe это конечно клево, но попробуй, сделать на нем полноценный HTB.

А про mpd уж и говорить нечего, 6 лет уже отлаживают, а конца и края не видно.

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

 

Пересобрать pppd честно говоря не пробовал - пробовал только сам rp-pppoe. Не помогло. Ставил syslog-ng - тож не помогло. А вот качнул из инета pppd 2.4.2 в rpm собранный уже с радиусом и прочим - помогло. Только вот потом yum и другие пакеты начинают кричать, что не хотят в зависимостях видеть такой старый pppd. Кстати в CentOS 5 pppd 2.4.4 собран уже с поддержкой радиуса. В ручной пересборке pppd сомневаюсь - я думаю, что если б все было так банально - у красной шапки не висело б несколько копий этого бага так долго без реакции. Мой баг постигла реакция - сменили RHEL5 на Fedora-devel. И вот уже больше недели глухо.

 

Не совсем понял я про "Pipe это конечно клево, но попробуй, сделать на нем полноценный HTB."?

У меня в обороте имеется сервачок FreeBSD 6.1. Отлично шейпит трафик - и сетку в сумме, и отдельный клиентов и т.д. Что имелось в виду про полноценный HTB?

 

mpd тож там крутит pptp. По дефолту создается 300 линков, но пока в нагрузке одновременно более 160 не наблюдал. Кроме того не проблема на бсд-шный ppp сверху накрутить poptop. Правда у меня с ним однажды такой казус был - что ой-ой-ой. Все работало, в радиус стат возвращался, только обнаружился прикол: если клиент подключался на впн с Apple ноутбука под MacOSX, то почему-то стат радиус не получал (или получал нули). Точно не помню что именно - но трабл наблюдался у нескольких независимых клиентов. :-O

 

Так что я пока на распутье на тему что мне делать с сервантов для pppoe. То ли плюнуть и накатать работающую у меня под FreeBSD схему. То ли продолжить пляски с бубнами. Ведь еще также не решена проблема ограничения скорости клиенту на pppX. Я пока вижу одно решение: завести один ifb девайс. Затем в скрипте ip-up вешать цепочки htb на сам pppX, а входящий от клиента траф в том же скрипте воротить на ifb и шейпить там. Только вот после аккуратненько записанных, недергающихся туда-сюда пайпов в ipfw это кажется жуткими костылями. (почему нужен ifb - потому что клиенты проходят SNAT и на исходящем интерфейсе шейпить можно разве что по меткам, а если исходящих несколько - то вообще прелесть).

[Kirya]

Про IFB я знаю, но лично мне например его заставить коректно не удалось. Пока не будет нормальной документации по-моему он мертв. Это не iproute2, где можно спокойно жить без неё.

 

По rp-pppoe ?

Я не вижу проблем пересобрать pppd. Так как идущий в RPM все-равно собирается без радиуса, т.е в большинстве маштабируемых систем его все-равно придется пересобирать.

 

По шейпингу и фрюшке ?

Pipe это конечно клево, но попробуй, сделать на нем полноценный HTB.

А про mpd уж и говорить нечего, 6 лет уже отлаживают, а конца и края не видно.

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

А зачем на роутере со статическими интерфейсами IFB ?

Шейпишь на исходящем и все.

 

Пересобрать pppd честно говоря не пробовал - пробовал только сам rp-pppoe. Не помогло. Ставил syslog-ng - тож не помогло. А вот качнул из инета pppd 2.4.2 в rpm собранный уже с радиусом и прочим - помогло. Только вот потом yum и другие пакеты начинают кричать, что не хотят в зависимостях видеть такой старый pppd.

package: rp-pppoe.i386 3.5-32.1

dependency: libc.so.6(GLIBC_2.3)

provider: glibc.i686 2.5-3

provider: glibc.i386 2.5-3

provider: glibc.i386 2.5-10.fc6

provider: glibc.i686 2.5-10.fc6

dependency: /sbin/service

provider: initscripts.i386 8.45.3-1

provider: initscripts.i386 8.45.7-1

dependency: /bin/bash

provider: bash.i386 3.1-16.1

dependency: libc.so.6(GLIBC_2.0)

provider: glibc.i686 2.5-3

provider: glibc.i386 2.5-3

provider: glibc.i386 2.5-10.fc6

provider: glibc.i686 2.5-10.fc6

dependency: libc.so.6(GLIBC_2.1)

provider: glibc.i686 2.5-3

provider: glibc.i386 2.5-3

provider: glibc.i386 2.5-10.fc6

provider: glibc.i686 2.5-10.fc6

dependency: rtld(GNU_HASH)

provider: glibc.i686 2.5-3

provider: glibc.i386 2.5-3

provider: glibc.i386 2.5-10.fc6

provider: glibc.i686 2.5-10.fc6

dependency: libc.so.6

provider: glibc.i686 2.5-3

provider: glibc.i386 2.5-3

provider: glibc.i386 2.5-10.fc6

provider: glibc.i686 2.5-10.fc6

dependency: mktemp

provider: mktemp.i386 3:1.5-23.2.2

dependency: iproute >= 2.6

provider: iproute.i386 2.6.16-6.fc6

provider: iproute.i386 2.6.19-1.fc6

dependency: /sbin/chkconfig

provider: chkconfig.i386 1.3.30-1

dependency: fileutils

provider: coreutils.i386 5.97-11

provider: coreutils.i386 5.97-12.5.fc6

dependency: config(rp-pppoe) = 3.5-32.1

provider: rp-pppoe.i386 3.5-32.1

dependency: /bin/sh

provider: bash.i386 3.1-16.1

dependency: initscripts >= 5.92

provider: initscripts.i386 8.45.3-1

provider: initscripts.i386 8.45.7-1

dependency: ppp >= 2.4.2

provider: ppp.i386 2.4.4-1

provider: ppp.i386 2.4.4-1.fc6

[root@phone dnetc496-linux-x86-elf-uclibc]# uname -a

Linux phone.hackers 2.6.20-1.2962.fc6 #1 SMP Tue Jun 19 19:27:14 EDT 2007 i686 athlon i386 GNU/Linux

 

Не совсем понял я про "Pipe это конечно клево, но попробуй, сделать на нем полноценный HTB."?

У меня в обороте имеется сервачок FreeBSD 6.1. Отлично шейпит трафик - и сетку в сумме, и отдельный клиентов и т.д. Что имелось в виду про полноценный HTB?

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

 

mpd тож там крутит pptp. По дефолту создается 300 линков, но пока в нагрузке одновременно более 160 не наблюдал. Кроме того не проблема на бсд-шный ppp сверху накрутить poptop. Правда у меня с ним однажды такой казус был - что ой-ой-ой. Все работало, в радиус стат возвращался, только обнаружился прикол: если клиент подключался на впн с Apple ноутбука под MacOSX, то почему-то стат радиус не получал (или получал нули). Точно не помню что именно - но трабл наблюдался у нескольких независимых клиентов. :-O

 

Так что я пока на распутье на тему что мне делать с сервантов для pppoe. То ли плюнуть и накатать работающую у меня под FreeBSD схему. То ли продолжить пляски с бубнами. Ведь еще также не решена проблема ограничения скорости клиенту на pppX. Я пока вижу одно решение: завести один ifb девайс. Затем в скрипте ip-up вешать цепочки htb на сам pppX, а входящий от клиента траф в том же скрипте воротить на ifb и шейпить там. Только вот после аккуратненько записанных, недергающихся туда-сюда пайпов в ipfw это кажется жуткими костылями. (почему нужен ifb - потому что клиенты проходят SNAT и на исходящем интерфейсе шейпить можно разве что по меткам, а если исходящих несколько - то вообще прелесть).

Сразу б сказал, что у тебя столько клиентов...

Тут вообще чем угодно можно делать.

У меня просто на сервере в пике под 5000 пакетов правил и 900 ppp и поэтому все не совсем просто.

u32 например на таком кол-ве убивает любую машину.

Only fwmark.

Я правда не пользуюсь pppoe.

Также хочу отметить, что htb вешать на pppx смысла нет. Напрямую sfq работает намного быстрее, а двухуровневый шейпер тебе не получится сделать, так как htb умеет строить суммы только на одном интерфейсе.

Изменено 8 июля, 2007 пользователем Kirya

[heap]

А зачем на роутере со статическими интерфейсами IFB ?

Шейпишь на исходящем и все.

На исходящем - если он один , а если предположим исход дует в 2 канала?

 

package: rp-pppoe.i386 3.5-32.1

...

provider: ppp.i386 2.4.4-1.fc6

[root@phone dnetc496-linux-x86-elf-uclibc]# uname -a

Linux phone.hackers 2.6.20-1.2962.fc6 #1 SMP Tue Jun 19 19:27:14 EDT 2007 i686 athlon i386 GNU/Linux

Дело даже не только в этом пакете - сейчас уже не помню, но завтра на работе могу глянуть. Там чуть ли не кернел ругается на ppp. А править спеки полдистру - вопрос интересный :)

 

Сразу б сказал, что у тебя столько клиентов...

Тут вообще чем угодно можно делать.

У меня просто на сервере в пике под 5000 пакетов правил и 900 ppp и поэтому все не совсем просто.

u32 например на таком кол-ве убивает любую машину.

Only fwmark.

Я правда не пользуюсь pppoe.

Также хочу отметить, что htb вешать на pppx смысла нет. Напрямую sfq работает намного быстрее, а двухуровневый шейпер тебе не получится сделать, так как htb умеет строить суммы только на одном интерфейсе.

Сервачок пока P4 3GHz с HT. А вот про sfq - можно поподробнее? Я не совсем понял почему с sfq проще и быстрее? Можно ли пару строчек примера команд подъема sfq?

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

 

Заодно раз уже идет речь про pppoe - маленький оффтоп в тему железа:

на свичике L2 хотелось бы как-то разделить клиентов по принципу, чтобы они могли дойти только до pppoe сервера и даже при желании не смогли увидеть друг друга. port-based vlan не катит (может быть несколько свичей в цепочке - и тогда схема становиться не очень прозрачной), а 802.1q слишком уж на недорогих свичах ограничен сверху количеством 255.

[Kirya]

Сразу б сказал, что у тебя столько клиентов...

Тут вообще чем угодно можно делать.

У меня просто на сервере в пике под 5000 пакетов правил и 900 ppp и поэтому все не совсем просто.

u32 например на таком кол-ве убивает любую машину.

Only fwmark.

Я правда не пользуюсь pppoe.

Также хочу отметить, что htb вешать на pppx смысла нет. Напрямую sfq работает намного быстрее, а двухуровневый шейпер тебе не получится сделать, так как htb умеет строить суммы только на одном интерфейсе.

Сервачок пока P4 3GHz с HT. А вот про sfq - можно поподробнее? Я не совсем понял почему с sfq проще и быстрее? Можно ли пару строчек примера команд подъема sfq?

http://gazette.linux.ru.net/rus/articles/taleLinuxTC.html

 

Заодно раз уже идет речь про pppoe - маленький оффтоп в тему железа:

на свичике L2 хотелось бы как-то разделить клиентов по принципу, чтобы они могли дойти только до pppoe сервера и даже при желании не смогли увидеть друг друга. port-based vlan не катит (может быть несколько свичей в цепочке - и тогда схема становиться не очень прозрачной), а 802.1q слишком уж на недорогих свичах ограничен сверху количеством 255.

Сделай комбинированную :).

Правда, с другой стороны если все поддерживает 802.1q - а зачем вообще становится нужен pppoe ?

Изменено 9 июля, 2007 пользователем Kirya

[heap]

Сделай комбинированную :).

Правда, с другой стороны если все поддерживает 802.1q - а зачем вообще становится нужен pppoe ?

Ну собственно проблема очевидна - первое, это возможность красиво считать трафик, получая его от pppd в radius - можно просто разрулить авторизацию и т.д. Во-вторых, нет ограничения на 255 VLANов. Остается только разделить трафик так, чтобы на сервер он приходил с одного порта, но при этом не пучком VLANов, а клиенты чувствовали себя в отдельных сетках. Конечно, самый просто вариант не поднимать IP на интерфейсе, но как известно - найдуться уникалы, которые таки рано или поздно набородят в настройке и у них случайно уведут "очень важные бух. документы".

 

PS: И все-таки вопрос шейпинга остается открытым. Правильно ли я вижу решение проблемы - навешивать шейпер на интерфейс в ip-up? А шейп входящего через опять же заворот в IFB?

Где-то 1-1,5 года назад, когда я впервые плотно столкнулся с данной проблемой - решения практически не было (IMQ не в счет - он нем я узнал позже). Тогда FreeBSD довольно неплохо решила эту проблему. Сегодня, чисто из соображений удобства настройки, мне практически все равно под чем ставить сервер - будь то Linux или FreeBSD. Просто вижу преимущество некоторых дистров Linux в длительности поддержки. Вот CentOS собственно был бы неплох, если бы не выкидывал таких фокусов :(.

Изменено 9 июля, 2007 пользователем heap

[deep_admin]

а чем не подходит такой вот способ шейпинга на ppp? http://www.opennet.ru/tips/info/811.shtml

 

при правильном расчете burst очень даже неплохо работает

[heap]

а чем не подходит такой вот способ шейпинга на ppp? http://www.opennet.ru/tips/info/811.shtml

 

при правильном расчете burst очень даже неплохо работает

О. Спасибо. Пример избавил меня от плясок с бубнами в процессе написания этого повторно :)

Теперь осталось либо побороть rp-pppoe в CentOS красивым образом, либо скачать Ubuntu 6.06 TLS сервер и получить счастье.

 

/me боится, что в Ubunt'е тот же баг :-S

[deep_admin]

а чем не подходит такой вот способ шейпинга на ppp? http://www.opennet.ru/tips/info/811.shtml

 

при правильном расчете burst очень даже неплохо работает

О. Спасибо. Пример избавил меня от плясок с бубнами в процессе написания этого повторно :)

Теперь осталось либо побороть rp-pppoe в CentOS красивым образом, либо скачать Ubuntu 6.06 TLS сервер и получить счастье.

 

/me боится, что в Ubunt'е тот же баг :-S

ftp://ftp.samba.org/pub/ppp/ppp-2.4.4b1.tar.gz

ставится,собирается,работает как часики и кернел-мод пппое и радиусклиент

[Ruslan U.TRONIN]

Может кто подскажет как решается проблема одновременного online более 256 человек на одном сервере NAS (linux)?

[Kirya]

Может кто подскажет как решается проблема одновременного online более 256 человек на одном сервере NAS (linux)?

Опция connections правильно выставлена ?

Ip адресов хватает ?

[heap]

Может кто подскажет как решается проблема одновременного online более 256 человек на одном сервере NAS (linux)?

Опция connections правильно выставлена ?

Ip адресов хватает ?

ИМХО проблему с адресами лучше решать раздавая их статически из radius. Так и стат потом вести проще.

[Kirya]

Может кто подскажет как решается проблема одновременного online более 256 человек на одном сервере NAS (linux)?

Опция connections правильно выставлена ?

Ip адресов хватает ?

ИМХО проблему с адресами лучше решать раздавая их статически из radius. Так и стат потом вести проще.

Если страбатывает одно из перечисленных выше ограничений, есть радиус или нет, pptpd вс-равно даст отлуп.

[DemYaN]

Вопрос не в том, что есть более свежие ядра, или что IMQ все-таки черепашьими шажками получает в код изменения от энтузиастов слева, а не от мэйнтейнеров, а в том - что шагая по ядрам вверх - есть шанс где-то упереться в несовместимость API/ABI (не спроста шапка в RHEL версию ядра вообще не меняет). Кроме того с ядра 2.6.18 уже в ядро запихали IFB, поэтому ИМХО IMQ пришел конец - к нему еще больше потеряют интерес. Но мну в короткий срок перелизать сервант под IFB нет времени, поэтому будет крутиться под 2.6.16.x.....

ИМХО IFB еще более сырой нежели IMQ, да и людьми он пока мало обкатан, все только описано красиво. В ядрах до 2.6.20.x в коде IFB был неприятный баг, результат которого - kernel panic :

[<>]  ri_tasklet+0xc1/0x19f [ifb]
[<>]  tasklet_action+0x55/oxaf
[<>]  __do_sofirq+0x5a/oxbb
[<>]  do_softirq+0x36/0x3a
[<>]  apic_timer_interrupt+0x1f/0x
[<>]  mwait_idle+0x25/0x38
[<>]  cpu_idle+0x9f/0xb9
[<>]  start_kernel+0x379/0x380

Месяца 2 назад сам хотел перелезть с IMQ на IFB. Использовался для загона ppp-интерфейсов в один ifb0, на который вешалась HTB-дисциплина. В результате Этх (ядро 2.6.18) превратился в паникера :) - 1-2 раза в день выпадал kernel panic. Видимо что-то неладное происходило когда отключался ppp-интерфейс.

.....до тех пор пока с Дебиана не перекочует под какой-нить CentOS. Хотя после словленного бага в Fedora4-Fedora8(видно не поправят и в 8) включая RHEL5 с rp-pppoe+sysklogd (я тут заводил другой топик) - чую будут сервачки с Debian'a переползать под FreeBSD. Благо там шейпинг трафика это наименее геморное занятие, да и таких глупых траблов, кочующих из года в год из релиза в релиз нет. Шапки в багзилле копят баги на эту тему и не чешуться. :(

три сервера проапдейтил с саржа до етха за полчаса каждый, без каких либо проблем....а c CentOS 4 (RHEL4) до CentOS 5 (RHEL5) так можно? ;)

Может кто подскажет как решается проблема одновременного online более 256 человек на одном сервере NAS (linux)?

1. если 256, то скорее всего забит пул

2. если 100, то pptpd должен быть собран с опцией --with-pppd-ip-alloc (старые версии) или в конфиге включена опция delegate (новые версии)

3. в старых ядрах количество интерфейсов зависело от параметра в ядре, который определял максимальное количество pty

[heap]

ИМХО IFB еще более сырой нежели IMQ, да и людьми он пока мало обкатан, все только описано красиво. В ядрах до 2.6.20.x в коде IFB был неприятный баг, результат которого - kernel panic :

[<>]  ri_tasklet+0xc1/0x19f [ifb]
[<>]  tasklet_action+0x55/oxaf
[<>]  __do_sofirq+0x5a/oxbb
[<>]  do_softirq+0x36/0x3a
[<>]  apic_timer_interrupt+0x1f/0x
[<>]  mwait_idle+0x25/0x38
[<>]  cpu_idle+0x9f/0xb9
[<>]  start_kernel+0x379/0x380

Тьфу-тьфу-тьфу... у меня стоит под FC6 сервачок уже пол года где-то - на нем несколько каналов жметься на IFB, но там нет ppp. Там просто транзитный трафик.

То ли патчи красной шапки, то ли еще что - пока чего уж не было, а паники точно не было.

 

Месяца 2 назад сам хотел перелезть с IMQ на IFB. Использовался для загона ppp-интерфейсов в один ifb0, на который вешалась HTB-дисциплина. В результате Этх (ядро 2.6.18) превратился в паникера :) - 1-2 раза в день выпадал kernel panic. Видимо что-то неладное происходило когда отключался ppp-интерфейс.

Правда такая статистика мне не по душе. Ведь неоспоримое преимущество IFB - это то, что оно уже в ядре. Вот насчет ifb+ppp - обязательно проверю - а то как бы не было потом поздно, когда сервант в продакшн станет.

 

три сервера проапдейтил с саржа до етха за полчаса каждый, без каких либо проблем....а c CentOS 4 (RHEL4) до CentOS 5 (RHEL5) так можно? ;)

Я думаю можно при желании и прямости рук - все сведеться к тому, чтобы обновить коре, потом пакеты, а потом разрулить изменившиеся или убранные пакеты. Шапка в этом плане довольно стабильная и как правило поддается пляскам. Но вот не лучше ли в таком деле реинсталл сделать?

 

1. если 256, то скорее всего забит пул

2. если 100, то pptpd должен быть собран с опцией --with-pppd-ip-alloc (старые версии) или в конфиге включена опция delegate (новые версии)

3. в старых ядрах количество интерфейсов зависело от параметра в ядре, который определял максимальное количество pty

Я собирал pptp с --with...... . А что это за опция такая delegate?

 

Сейчас качаю Ubuntu server 6.06.1 LTS - посмотрим что за зверь - саппортиться будет до 2011 года.

[heap]

Посидел, подумал. И вот что надумал. Рассматриваемые тут выше в постах способы обжимки сводятся к тому, что на ppp вешается шейпер, который жмет именно этот канал. Зрим в корень - а если нужно обжать, например, 3 логина (т.е. сразу 3 ppp должны быть суммарно обжаты на скорости N).

Попробую сейчас крутить ifb, но может кто уже решал что-то подобное?