Гайджин

Опа - динамические шейперы... Здравствуй ЕвропаОнЛайн - новое это хорошо забытое старое...

а в чем проблема? Так в том то и оно, что нет проблем... а это как правило так и есть - еще не привыкли? Нет - не привык, у нас не так...

Хм... Ну тут я если честно диву даюсь, тут похоже одно из: 1. Либо вы сквозь натилки более 4Г пускаете. (Можно в личку объем внешних каналов?) 2. Либо Коры2Дуо у Вас какие то детские. 3. Либо админы чего то недоадминивают. Так на "сотке" выдается 300Г в месяц (суммарного?) и на дни трафик не режется? Т.е. пока не выбереш скорость не понижается? Маркетологи отдельной жизнью живут что ли?

Живых - это имеется ввиду абонентское ядро? - Т.е. Живых в течении месяца. Или же разговор идет о 8К онлайновых абонентов в текущий момент времени? У вас сеть IPoE или IP other чего то? Т.е. сервера - "резалки" и "натилки", или же они еще ppp терминируют? Насколько я понял, пара гигабитов вверх и пара вниз? - агрегируете как? C2D какие? Если не секрет - то какие? Т.е. какие скорости и как "пациентская" база по тарифам размазалась. p.s. пишу не из праздного любопытства, самому такое сделать предстоит буквально в этом месяце. Но настоящий момент пока проблем с NATом не вижу, но у ме

А о каком кол-ве абонентов, канальной емкости и серверах идет речь (плюс минус килограмм)?

ip-up.local спасет отца Русской демократии.

3 Гбит/с суммарно? Или 3 туда и 3 оттуда?

Как показывает практика, в Украине не прецедентное право...

Вот тут на тему микротиков показательно... Насколько видно из постов, ТС не будет делать тюнинг. Хм... В и где это видно? - я как то не заметил... Ну для того что бы выжать из сервера все до суха, женту как раз бы и сгодилось. Что же касается mppe и mppc - на nas-е оно нах?

почему? в чем отличие от взрослого? В размерах... Ставить микротик на могопроцессорный многояерный сервер смысла нет... Я думаю что ничем, что там что там - poptop. Хотя конечно может быть и accel-pptp - но не факт. Но не про pptp речь. Я четко вопросы задал - ответов 0... Причем тут версии? 1. Почему фрю? 2. Микротик для таких задач выход для тех кто этот самый тюнинг сделать не может.

Это почему же? Легко и непринужденно - шейпить на тунельном интерфейсе, там ip есть. p.s. Такой впечатление, что Вы pptp собрались по "несущей" сети шейпить...

Ну pptd vs pppoe понятно - производительность. А вот что волшебного даст связка freebsd+mpd vs linux+rp-pppoe+pppd? Микротик не в счет - он только для "детского" NASа годиться...

Ну это смотря сколько просить и где просить... 6 лет назад отключились - до сих про в кошмарах снится...

Очереди были совмещенные? Ядро было какое? Похоже что все же совмещенные очереди - потому как мне не удалось равномерно загрузить TX-овые очереди на интерфейсе смотрящем в сторону ядра. Ну тут я пожалуй не соглашусь - выше она не была, но вот цель не была достигнута. Пошли по аналогичной схеме - два гигабита в ядро, два в сторону клиентов. По сути проблему решили - но неудовлетворенность осталась. Может быть кто то добивался положительных результатов при помощи VMQ?

Так и я про что (Вы кстати через RSS заводить ее пытались?) - не понятно нах на микротик поддержку 82576 если в условиях задачи pppoe. p.s. Кто нибудь добивался он новомодных интеловских карт распределения нагрузки (pppoe) по очередям?

А что вам даст Intel 1000ET (под linux+igb) в разрезе PPPoE BRAS? - Насколько я понял, то pppoe там хрен распаралелиш по ядрам.

Господа, что то у меня полный ступор - не едут лыжи, хоть ты убейся. Может кто чего подскажет? Ситуация следующая: В наличии имеется софтовый PPPoE BRAS - CentOS 5.4, ядро ванильное 2.6.31.13, четыре гигабитных интерфейса (два в сторону ядра - Intel 82574L, два в сторону клиентов - Intel 82576, на всех по две раздельных очереди rx и tx). На BRASе zebra+ospfd (quagga-0.99.15-2009082801), в сторону ядра еqual-cost multi-path routing: К BRASу коннектиться клиент (PPPoE сервера живут на интерфейсах eth2 и eth3, IP адресов интерфейсы не имеют) и живет себе припеваючи: Однако при пристал

Какой Вы однако прямолинейный - Можно даже сказать не гибкий... А если поглядеть вот с этой точки зрения: ... Что прослеживается? - Верно! Они знают что такое прокси-сервер! А если знают в минобразования, то и в нацкомиссии тоже... Вывод: задрочат они нас фильтрацией на L7 - как пить задрочат... Ну и кто они после этого? p.s. не знаю как Вам, но мне как то в голову ничего умного не приходит, на тему, чем можно профильтровать на L7 (заглядывая внутрь пакета) несколько Г/с не за дорого (5-10К$)...

Ну а как Вы думаете? - Если у них есть "squid:x:23:23::/var/spool/squid:/sbin/nologin", то кто они?

Нет не решают... Единственное что может как то разнообразить жизнь это поставить rate=9Mbit/s... Но в случае если провайдер недольет, получится казус.

Вот в этом и западло...

Все верное, тольно не стоит забывать, что в приведенном примере (при отсутствии пиринга) УТ нагрузит нисходящую составляющую своих внешних каналов, в вот РЕТН - восходящую. А это все же разные вещи. Из этого следует - перетоки трафика должны быть взаимными, что бы пиринг был интересен.

Засада в том, что с вероятностью 99% данная комиссия не в курсе что такое IP-адреса. В лучшем случае их хватит на URL. В вот получить "официальный список урлов" сильно бы не хотелось - напрягать железо на тему анализа http трафика как то не сильно хочется...

В регионах скорее вот так: [xxx@xxx ~]$ ping mail.ru -A -c 10 PING mail.ru (217.69.128.43) 56(84) bytes of data. 64 bytes from mail.ru (217.69.128.43): icmp_seq=1 ttl=115 time=33.5 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=2 ttl=115 time=33.5 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=3 ttl=115 time=34.1 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=4 ttl=115 time=33.5 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=5 ttl=115 time=33.6 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=6 ttl=115 time=33.4 ms 64 bytes from mail.ru (217.69.128.43): icmp_seq=7 ttl=115

Позвольте усомниться. - Или у Вас там сплошные синфлудеры, или Вы его как то странно храните.