[Dimka88]

Zohan, подскажите как тогда быть с dummynet, если в панику уходит. Писал Luigi Rizzo, он не ответил. Вы мне помогали в соответствующей теме. Вы лично на ipfw/dummynet работаете? Сколько трафика бегает, сколько пакетов в секунду обслуживает сервер?

Изменено 3 марта, 2012 пользователем Dimka88

[lan-viper]

Проверил нет никаких багов всё нормально отрабатывает, и шейпиться.

Внимательно читай моё сообщение, нужно вручную изменить скорость, тогда проявится то, о чём я написал.

Если я будучи в time-range=2,01:00-13:00 даю команду shaper change ppp16 20480

Изменено 3 марта, 2012 пользователем lan-viper

[=-Sky-=]

commit 0144238b8e364dac353797368fe45cda5426d88d
Author: Kozlov Dmitry <xeb@mail.ru>
Date:   Mon Feb 27 16:51:04 2012 +0400

shaper: move thread local variables to stack

commit 8a8680bfb817a25fdc04b6ce5e55605b1ac63d3d
Author: Kozlov Dmitry <xeb@mail.ru>
Date:   Mon Feb 27 16:50:21 2012 +0400

core: increase stack size

пробуйте

Помогло. Уже 30 часов аптайма accel-pppd. Спасибо!!!

Изменено 3 марта, 2012 пользователем =-Sky-=

[andretty]

Проблемы с radius :( Версия последняя, из гита cf40442a413d04379711bd73a52372d3a3264ea4 падает практически сразу же после запуска, в dmesg сыпет

accel-pppd[16932]: segfault at 58 ip b735566a sp b46ff1f0 error 4 in libradius.so[b734e000+e000]
accel-pppd[28263]: segfault at 58 ip b73a266a sp aecf81f0 error 4 in libradius.so[b739b000+e000]
accel-pppd[16176]: segfault at 0 ip b75a0d58 sp b06fb21c error 4 in libc-2.13.so[b7482000+159000]
accel-pppd[7619]: segfault at 58 ip b751b66a sp ad6f51f0 error 4 in libradius.so[b7514000+e000]
accel-pppd[12649]: segfault at 58 ip b74fc66a sp b18fd1f0 error 4 in libradius.so[b74f5000+e000]
accel-pppd[13669]: segfault at 0 ip b76add58 sp 896ad21c error 4 in libc-2.13.so[b758f000+159000]

Подозрения вызывает ключ req-limit: поставил ограничение на 5 одновременных запросов - поднялось 5 сессий, поставил на 7 запросов - поднялось 7 сессий... Похоже, работает не так, как надо... Когда установил на 0 все пошло как надо, но я не могу оставить 0, т.к. в "часы пик" от перебора запросов авторизации валится уже radius :D Можно как нибудь поправить?

[alexaaa]

Хеb нет ли мыслей по созданию IPOE на accel-ppp или добавления функции dhcp-relay option 82?

 

Как задействовать snmp, accel пишет в логах net-snmp not found, хотя snmp работает.

 

net-snmp

 

[snmp]

master=1

agent-name=accel-ppp

[xeb]

Хеb нет ли мыслей по созданию IPOE на accel-ppp или добавления функции dhcp-relay option 82?

ну это как-бы не относится к ппп

 

Как задействовать snmp, accel пишет в логах net-snmp not found, хотя snmp работает.

что конкретно пишет ?

[alexaaa]

Хеb нет ли мыслей по созданию IPOE на accel-ppp или добавления функции dhcp-relay option 82?

ну это как-бы не относится к ппп

 

Как задействовать snmp, accel пишет в логах net-snmp not found, хотя snmp работает.

что конкретно пишет ?

в лог файле пишет net-snmp not found.

[xeb]

Хеb нет ли мыслей по созданию IPOE на accel-ppp или добавления функции dhcp-relay option 82?

в принципе я этим вопросом начинал заниматься, есть кое-какие наработки, просто не имею опыта внедрения, поэтому хотелось бы услышать список требований к функционалу (можно в асю или лс)

 

в логах net-snmp not found

что прям так и пишет ?

ладно, не буду гадать на кофейной гуще, вобщем даже если accel-ppp выступает мастером ему нужен полноценный конфиг net-smp, он его будет искать примерно в /etc/snmp/accel-ppp.conf (каталог может варироваться в различных дистрах, имя файла - имя агента из конфига), поэтому нужно начать с изучения конфига net-snmp

[Cramac]

Хеb нет ли мыслей по созданию IPOE на accel-ppp или добавления функции dhcp-relay option 82?

в принципе я этим вопросом начинал заниматься, есть кое-какие наработки, просто не имею опыта внедрения, поэтому хотелось бы услышать список требований к функционалу (можно в асю или лс)

тоже был бы интересен данный вопрос

[alexaaa]

Хм, тестовый сервер лег в панику... при 600+ коннектах, хотя до этого умирал на 200

 

с одной стороны приятно что 600, с другой паника... )

 

Проц на нем был (и есть)

Да, паники время от времени вылазят, причем я не заметил никакой закономерности, непонятно, accel-pptp ли виноват =(

Создайте жёсткие правила фаервола, закройте всё лишнее, отключите шифрование если оно вам не нужно, используйте ipt_netflow коллектор, сетевые intel 82576 с прерываниями обязательно, шейпер tc или встроенный шейпер, и оперативной памяти не меньше 4Гбайт, мы так воевали ещё начиная со старых версий accel, сейчас ежедневно 700-900 конектов работает, падение есть конечно раз в месяц, когда на сервере остаётся минимум памяти, причём все логи на сервере не показывают ни одной причины с чём это связано.

[Lynx10]

Хеb нет ли мыслей по созданию IPOE на accel-ppp или добавления функции dhcp-relay option 82?

в принципе я этим вопросом начинал заниматься, есть кое-какие наработки, просто не имею опыта внедрения, поэтому хотелось бы услышать список требований к функционалу (можно в асю или лс)

есть основные варианты

1 старт сессии по некласифицированному IP (L3) - брас стартует сессию когда приходит от клиента первый пакет и ещё нет сессии связаной с таким источником IP

2 старт сесси по DHCP запросу (L2) - брас является или DHCP сервером или релеем - сессия стартует когда приходит от клиента DHCP запрос

 

при старте сессии брас отправляет запрос радиус серверу с информацией о клиенте (IP,MAC+opt82 и тд) - тот решает. Это в 2 словах

Изменено 6 марта, 2012 пользователем Lynx10

[taf_321]

А если вот так (для vlan-per-user):

 

- на брасе имеем пачку интерфейсов, на которые приходят q-in-q супервланы (?)

- демон браса умеет распознавать vlan, и принимает с них DHCP-запросы клиентов

- на основании номера supervlan'а q-in-q + номер vlan'а внутри q-in-q формируется запрос к радиусу (примеры связки DHCP+radius есть в асортименте), либо DHCP запрос с добавлением opt82 релеится на настоящий DHCP-сервер.

[lagman]

демон браса, ужасы какие >:-(=~ )

[lan-viper]

Интереснее вариант вынести редактирование cburst из конфига в сторону RADIUS атрибутов, а-ля cisco, там как раз всё очевидно получается и зависит от тарифа. Ну либо как-то доработать в конфиге. А так, как сейчас реализовано - ни куда не годится... Не может cburst быть одинаковым для 512Кбит и для 12288Кбит.

xeb, заметил незначительный баг:

time-range=1,13:00-01:00
time-range=2,01:00-13:00

атрибуты для входящего шейпа:

lcp:interface-config#1=rate-limit input access-group 1 4096000 256000 256000 conform-action transmit exceed-action drop
lcp:interface-config#1=rate-limit input access-group 2 12288000 768000 768000 conform-action transmit exceed-action drop

Если я будучи в time-range=2,01:00-13:00 даю команду shaper change ppp16 20480, то

root@nas:/etc# tc class show dev ppp16
class htb 1:1 root prio 0 rate 20480Kbit ceil 20480Kbit burst 250Kb cburst 31997b

Обращаю внимание на значение burst - оно из первого time-range=1,13:00-01:00.

Просьба перепроверить.

xeb, что скажешь по этим двум вопросам?

 

PS

Память больше не утекает.

[=-Sky-=]

Помогло. Уже 30 часов аптайма accel-pppd. Спасибо!!!

Всё равно упал, часов через 17....(((((( Причем сервер повис наглухо, ни клавиатура, ни монитор не отвечают, и естесственно, kdump файл не создался. Перезагрузился, в логах, как обычно, ничего.

Единственное, что есть, это вывод show stat за несколько часов до падения:

 

mem(rss/virt): 19480/670532 kB
Core:
mempool_allocated: 1971712
mempool_available: 264818
thread_count: 4
thread_active: 1
context_count: 599
context_sleeping: 0
context_pending: 0
timer_count: 585
timer_pending: 0
ppp:
starting: 1
active: 577
finishing: 0
pptp:
starting: 0
active: 545
l2tp:
starting: 0
active: 6
pppoe:
active: 27
delayed PADO: 0
recv PADI: 100
drop PADI: 0
sent PADO: 100
recv PADR:(dup): 60(0)
sent PADS: 60

[xeb]

я сейчас в командировке, времени мало, как приеду посмотрю...

[sinoptik]

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

[NiTr0]

А если вот так (для vlan-per-user):

 

- на брасе имеем пачку интерфейсов, на которые приходят q-in-q супервланы (?)

- демон браса умеет распознавать vlan, и принимает с них DHCP-запросы клиентов

- на основании номера supervlan'а q-in-q + номер vlan'а внутри q-in-q формируется запрос к радиусу (примеры связки DHCP+radius есть в асортименте), либо DHCP запрос с добавлением opt82 релеится на настоящий DHCP-сервер.

+ назначение гейтвея на интерфейсе автоматом из запроса, + желательно подъем при старте всей пачки вланов поверх супервлана (хотя это можно и скриптом сторонним реализовать в принципе), + некий файл лиз для того, чтобы при перезапуске демона не вставало все колом до следующего обновления лизы. + какой-то failover реализовать бы в перспективе...

Изменено 6 марта, 2012 пользователем NiTr0

[alexaaa]

По поводу падения сервера, чтобы он сам на перезагрузку ушёл после падения, добавьте в sysctl.conf запись kernel.panic=1, и сервер сам уйдёт на перезагрузку, где-то 2-3 минуты это займёт.

 

По поводу IPOE тоже хороший вариант Vlan на обонента, в принцепе все к этому стремяться, да и IPOE уже будет работать по ID VLAN, и можно тоже использовать dhcp_relay option 82.

У нас например Vlan на дом, dhcp_relay option 82 работает по vlan id, можем и перейти и на vlan на абонента, только как контролировать абонента и трафик? тут нужно взаимодействие и биллинга и dhcp_relay.

Изменено 6 марта, 2012 пользователем alexaaa

[taf_321]

можем и перейти и на vlan на абонента, только как контролировать абонента и трафик?

 

В случае vlan-per-user контроль трафика получается абсолюто таким же, как и в случае с PPPoE, даже жестче - клиенты не смогут поснифить соседский трафик в принципе (не сталкивались с особо умными клиентами, запускающими у себя PPPoE сервер с требованием PAP-авторизации и последующим вытягиванием логинов-паролей у попавшихся? Мы сталкивались).

[NiTr0]

можем и перейти и на vlan на абонента, только как контролировать абонента и трафик?

Привязка ip-port фактически получается. Контроллировать соответственно элементарно.

Пришел дхцп запрос, сервер ответил на него - создался маршрут на абона через интерфейс. Кончилась лиза, нет обновления - маршрут убрали, и все, трафик кончился. Чужой трафик в влане - невозможен.

[alexaaa]

можем и перейти и на vlan на абонента, только как контролировать абонента и трафик?

Привязка ip-port фактически получается. Контроллировать соответственно элементарно.

Пришел дхцп запрос, сервер ответил на него - создался маршрут на абона через интерфейс. Кончилась лиза, нет обновления - маршрут убрали, и все, трафик кончился. Чужой трафик в влане - невозможен.

а как контролировать адреса и учётки абонентов, как биллинг считать будет, если в биллинге контроль только по ip или логину клиента, тут надо наладить обмен биллинга (радиуса) и сервера с применением dhcp_relay, а второе это шейпирование каждого интерфейса, ISG работает по принципу разрешать или запрешать ходить интерфейсу или ip адресу в интернет, данные беруться из биллинга, и плюс шейпируется скорость этого интерфейса (по радиус атрибутам), но терминирование vlan работает на L3 уровне, поэтому accel-ppp сможет только авторизовывать и шейпировать, и это будет большой плюс, а терминирование vlan и dhcp_relay на L3 релизовывать.

[NiTr0]

Не осилил этот поток сознания. Что конкретно неясно-то? Как древнему недоделанному биллингу прикрутить опцию 82? Так это проблема его автора, все биллинговые системы с опцией 82 дружат. И в чем с ешйпером проблема-то? Шейпить можно где угодно, хоть на бордюре. И с какой радости терминирование вланов на л3...

Изменено 6 марта, 2012 пользователем NiTr0

[desperado]

запускающими у себя PPPoE сервер с требованием PAP-авторизации и последующим вытягиванием логинов-паролей у попавшихся? Мы сталкивались).

если на акцессе железка не глупее длинк-3526, то не проблема, имхо.

[Lynx10]

а как контролировать адреса и учётки абонентов, как биллинг считать будет, если в биллинге контроль только по ip или логину клиента, тут надо наладить обмен биллинга (радиуса) и сервера с применением dhcp_relay, а второе это шейпирование каждого интерфейса, ISG работает по принципу разрешать или запрешать ходить интерфейсу или ip адресу в интернет, данные беруться из биллинга, и плюс шейпируется скорость этого интерфейса (по радиус атрибутам), но терминирование vlan работает на L3 уровне, поэтому accel-ppp сможет только авторизовывать и шейпировать, и это будет большой плюс, а терминирование vlan и dhcp_relay на L3 релизовывать.

опт82 будет передавать софт который обсуждаем в Access-Request вместе с влан-ид. Билинг анализирует - если проходит связка мак+влан - пускаем Access-Accept - нет Access-Reject

Access-Accept - возвращает скорость. софтинка принимает - настраивает шейпер

софтинка должна быть или дхцп сервером или релеем. дхцп запрос будет отрабатываться и выдаваться адрес только после получения от радиуса Access-Accept.

Шейпит считает она же - софтинка

Биллинг получает счётчики байтов по Interim Update Account-Stop который передает софтинка

но это вариант с Л2

 

иногда очееень неплохо иметь вариант через Л3 - когда адреса выдаются другими средствами - а софтинка стоит на шлюзе и вылавливает ip сессии - отправляет в радиус запрос - может ли ходить с такого ip если может тогда Access-Accept и скорость - если нет - то Access-REject - и в нул