[Dimka88]

Ну у меня например в /etc/network/interfaces описаны разные подключения к провайдерам там же vlan. Иногда приходится делать рестарт.

 

А корректно будет если я в /etc/init.d/networking укажу - service accel-ppp stop в начале скрипта, а в конце service accel-ppp start ?

Во навыдумывали. Что именно вы добиваетесь перезапуском сети? Не могу въехать.

Спасибо за пример. А что значит (\d+)$?

Ну это типичные регулярные выражения, \d значит цифра (digit) аналог [0-9]; + означает, что может повторяться один или более раз.

Изменено 30 июля, 2014 пользователем Dimka88

[xeb]

Ну у меня например в /etc/network/interfaces описаны разные подключения к провайдерам там же vlan. Иногда приходится делать рестарт.

будет проще если настройку ethernet интерфейсов и вланов вынести куда-то в rc.local, чтобы их не дёргать перезапуском

[emp]

/usr/sbin/accel-pppd: error while loading shared libraries: libtriton.so: cannot open shared object file: No such file or directory

версия последняя из git clone git://git.code.sf.net/p/accel-ppp/code accel-ppp-code

собирал так: cmake -DCPACK_BINARY_TZ=OFF -DCPACK_BINARY_TGZ=OFF -DCPACK_BINARY_STGZ=OFF -DCPACK_BINARY_DEB=TRUE -DCPACK_TYPE=Debian7 ..

$ readelf -d libtriton.so

Dynamic section at offset 0x9020 contains 28 entries:
 Tag        Type                         Name/Value
0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
0x000000000000000e (SONAME)             Library soname: [libtriton.so]
0x000000000000000c (INIT)               0x2588
0x000000000000000d (FINI)               0x7618
0x0000000000000019 (INIT_ARRAY)         0x209000
0x000000000000001b (INIT_ARRAYSZ)       16 (bytes)
0x000000000000001a (FINI_ARRAY)         0x209010
0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
0x0000000000000004 (HASH)               0x1f0
0x000000006ffffef5 (GNU_HASH)           0x560
0x0000000000000005 (STRTAB)             0x1200
0x0000000000000006 (SYMTAB)             0x6c0
0x000000000000000a (STRSZ)              1677 (bytes)
0x000000000000000b (SYMENT)             24 (bytes)
0x0000000000000003 (PLTGOT)             0x209278
0x0000000000000002 (PLTRELSZ)           2016 (bytes)
0x0000000000000014 (PLTREL)             RELA
0x0000000000000017 (JMPREL)             0x1da8
0x0000000000000007 (RELA)               0x1a00
0x0000000000000008 (RELASZ)             936 (bytes)
0x0000000000000009 (RELAENT)            24 (bytes)
0x000000006ffffffe (VERNEED)            0x1980
0x000000006fffffff (VERNEEDNUM)         3
0x000000006ffffff0 (VERSYM)             0x188e
0x000000006ffffff9 (RELACOUNT)          31
0x0000000000000000 (NULL)               0x0

[ichthyandr]

Привет, всем, вопрос по акселю такой

если раздавать инет влан на абонента, абоненту на эзернет ифейс буду отдавать адрес A.B.C.D/22, как аксель будет отдавать маршрут наружу через ospf/bgp/rip, как A.B.C.D/32 ?

[xeb]

emp, cmake -DCMAKE_INSTALL_PREFIX=/usr

 

если раздавать инет влан на абонента, абоненту на эзернет ифейс буду отдавать адрес A.B.C.D/22, как аксель будет отдавать маршрут наружу через ospf/bgp/rip, как A.B.C.D/32 ?

зависит от опцции ip-unnumbered

если 1, то /32, иначе какая маска выдаётся клиенту

[NiTr0]

Ну у меня например в /etc/network/interfaces описаны разные подключения к провайдерам там же vlan. Иногда приходится делать рестарт.

ifdown/ifup одного-единственного интерфейса чем не нравится-то??? Накой всю сетевую подсистему дергать? А хотите все дергать - рестартуйте аксель. Все равно сессии порвутся...

[ichthyandr]

emp, cmake -DCMAKE_INSTALL_PREFIX=/usr

 

если раздавать инет влан на абонента, абоненту на эзернет ифейс буду отдавать адрес A.B.C.D/22, как аксель будет отдавать маршрут наружу через ospf/bgp/rip, как A.B.C.D/32 ?

зависит от опцции ip-unnumbered

если 1, то /32, иначе какая маска выдаётся клиенту

спасибо :) действительно, вика нужна

[emp]

emp, cmake -DCMAKE_INSTALL_PREFIX=/usr

спасибо, помогло. сейчас попробую нагрузку дать.

[emp]

~300 сессий поднялось. начал ругаться [2014-07-31 16:20:45]: warn: ipoe332: radius: no available servers и упал.

[nik247]

~300 сессий поднялось. начал ругаться [2014-07-31 16:20:45]: warn: ipoe332: radius: no available servers и упал.

Мало логов для понимания проблемы.

Версия точно последняя?

В настройках для radius server стоит у Вас req-limit?

Что радиус пишет у себя в логах?

У самого она (последняя) версия работает сейчас с более чем 500 клиентами.

Мое предложение - соберите accel-ppp c -DMEMDEBUG=TRUE -DCMAKE_BUILD_TYPE=Debug.

Запускайте демон с ключами для корки:

 

start)

log_daemon_msg "Starting PPtP/L2TP/PPPoE/IPoE server" $ACCEL_PPP_NAME

#set ulimit for debugging

ulimit -Hc unlimited

ulimit -Sc unlimited

#set ulimit for debugging

if start-stop-daemon --start --quiet --oknodo --exec /usr/sbin/accel-pppd -n $ACCEL_PPP_NAME -- -d --dump /tmp $ACCEL_PPP_PID $ACCEL_PPPD_OPTS; then

log_end_msg 0

 

# sysctl.conf

kernel.core_pattern = core

kernel.core_pipe_limit = 0

kernel.core_uses_pid = 1

 

И ловите корку.

Потом она поможет xeb найти причину падения.

Изменено 31 июля, 2014 пользователем nik247

[emp]

поторопился и собрал с -DCMAKE_BUILD_TYPE=Debug

запускал с ulimit -c unlimited

версия aa53abbed4e1f833ee64e2a4d4b36e9b4175775a

 

вот что получил:

 

req-limit=100 (пробовал 1000). вообще что обозначает этот параметр ?

 

[New Thread 0x7fffdf5b5700 (LWP 22346)]
[Thread 0x7fffdf5b5700 (LWP 22346) exited]
[Thread 0x7fffe32f2700 (LWP 21928) exited]
[Thread 0x7fffe24e4700 (LWP 21946) exited]
[Thread 0x7fffe3bfb700 (LWP 21857) exited]
[Thread 0x7fffd2ced700 (LWP 21779) exited]
[Thread 0x7fffe1ede700 (LWP 21967) exited]
[Thread 0x7fffe38f8700 (LWP 21878) exited]
[Thread 0x7fffe26e6700 (LWP 21780) exited]
[Thread 0x7fffea8e8700 (LWP 22009) exited]
[Thread 0x7fffe09c9700 (LWP 22091) exited]
[Thread 0x7fffe36f6700 (LWP 22102) exited]
accel-pppd: /home/emp/accel-ppp/accel-ppp-code/accel-pppd/radius/serv.c:157: rad_server_req_exit: Assertion `req->serv->req_cnt >= 0' failed.

Program received signal SIGABRT, Aborted.
[switching to Thread 0x7ffff0902700 (LWP 18993)]
0x00007ffff69bd545 in raise () from /lib/x86_64-linux-gnu/libc.so.6

(gdb) info locals
No symbol table info available.
(gdb) bt
#0  0x00007ffff69bd545 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff69c07c0 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff69b66f1 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff6151be5 in rad_server_req_exit (req=0x7fffe407dbc0) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/radius/serv.c:157
#4  0x00007ffff6150b4e in rad_acct_start (rpd=0x792b98) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/radius/acct.c:335
#5  0x00007ffff61551fc in ses_acct_start (ses=0x88d140) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/radius/radius.c:321
#6  0x00007ffff7bda5eb in triton_event_fire (ev_id=10, arg=0x88d140) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/triton/event.c:103
#7  0x00000000004072c1 in ap_session_ifup (ses=0x88d140) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/ifcfg.c:77
#8  0x0000000000406336 in ap_session_activate (ses=0x88d140) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/session.c:124
#9  0x00007ffff635f963 in __ipoe_session_activate (ses=0x88d088) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/ctrl/ipoe/ipoe.c:823
#10 0x00007ffff635f298 in __ipoe_session_start (ses=0x88d088) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/ctrl/ipoe/ipoe.c:688
#11 0x00007ffff635ecfe in ipoe_session_start (ses=0x88d088) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/ctrl/ipoe/ipoe.c:579
#12 0x00007ffff7bd77ee in ctx_thread (ctx=0x7fffe40895f8) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/triton/triton.c:233
#13 0x00007ffff7bd7519 in triton_thread (thread=0x709fc0) at /home/emp/accel-ppp/accel-ppp-code/accel-pppd/triton/triton.c:159
#14 0x00007ffff77b5b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#15 0x00007ffff6a6720d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#16 0x0000000000000000 in ?? ()

 

radius

Thu Jul 31 17:54:47 2014 : Error: Discarding duplicate request from client bras01 port 48051 - ID: 1 due to unfinished request 5917
Thu Jul 31 17:54:47 2014 : Error: Discarding duplicate request from client bras01 port 39547 - ID: 1 due to unfinished request 5918
Thu Jul 31 17:54:47 2014 : Error: Discarding duplicate request from client bras01 port 34617 - ID: 1 due to unfinished request 5919
Thu Jul 31 17:54:47 2014 : Error: Discarding duplicate request from client bras01 port 48669 - ID: 1 due to unfinished request 5920

[nik247]

to emp

Это не корка.

Сам файл корки называется core.ХХХХ или core и в итоге может оказаться и в /tmp и в / и размер его может быть от 100М до 300М.

Включите еще уровень логирования debug:

[log]

log-debug=/var/log/accel-ppp/accel-debug.log

level=5

Изменено 31 июля, 2014 пользователем nik247

[emp]

to emp

Это не корка.

Сам файл корки называется core.ХХХХ или core и в итоге может оказаться и в /tmp и в / и размер его может быть от 100М до 300М.

Включите еще уровень логирования debug:

[log]

log-debug=/var/log/accel-ppp/accel-debug.log

level=5

 

действительно. сейчас ещё раз попробую.

[nik247]

to emp

По поводу req-limit.

Да с докой сейчас не совсем хорошо, но есть же man accel-ppp.conf, в кторой есть все на 90%.

req-limit - number of simultaneous requests to server (0 - unlimited).

То есть req-limit устанавливает ограничений на скорость работы с радиусом.

Например req-limit=100 - значит не более 100 одновременных запросов, остальные в очередь.

Таким образом мы защищаем радиус от штормов.

[emp]

чото gdb корка не нравится: "/core.24584": not in executable format: File format not recognized

 

to emp

По поводу req-limit.

Да с докой сейчас не совсем хорошо, но есть же man accel-ppp.conf, в кторой есть все на 90%.

req-limit - number of simultaneous requests to server (0 - unlimited).

То есть req-limit устанавливает ограничений на скорость работы с радиусом.

Например req-limit=100 - значит не более 100 одновременных запросов, остальные в очередь.

Таким образом мы защищаем радиус от штормов.

теперь понятно. что при этом с клиентами происходит ? в моём случае l3 без dhcp. клиентский трафик мимо бежит как я понимаю. но тогда не получается ли так что будут в очередь становиться запросы на каждый новый пакет ?

 

чтото не похоже на то что надо

 

 

 

# gdb -c core.24584

GNU gdb (GDB) 7.4.1-debian

Copyright © 2012 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

and "show warranty" for details.

This GDB was configured as "x86_64-linux-gnu".

For bug reporting instructions, please see:

<http://www.gnu.org/software/gdb/bugs/>.

[New LWP 27482]

[New LWP 24589]

[New LWP 24682]

[New LWP 27425]

[New LWP 24584]

[New LWP 24609]

[New LWP 24608]

[New LWP 25415]

[New LWP 27589]

[New LWP 24587]

Core was generated by `/usr/sbin/accel-pppd -d --dump /tmp -p /var/run/accel-pppd.pid -c /etc/accel-pp'.

Program terminated with signal 6, Aborted.

#0 0x00007f034fb65545 in ?? ()

(gdb) info locals

No symbol table info available.

(gdb) bt

#0 0x00007f034fb65545 in ?? ()

#1 0x00007f034fb687c0 in ?? ()

#2 0x00007f034f2fbd04 in ?? ()

#3 0x00007f034fc813ab in ?? ()

#4 0x00007f03392d1990 in ?? ()

#5 0x000000000000009d in ?? ()

#6 0x00007f03392d1a80 in ?? ()

#7 0x00007f034fb9a416 in ?? ()

#8 0x0000003000000018 in ?? ()

#9 0x00007f03392d1a90 in ?? ()

#10 0x00007f03392d19b0 in ?? ()

#11 0x00007f034fb81708 in ?? ()

#12 0x0000003000000030 in ?? ()

#13 0x00007f03392d1aa8 in ?? ()

#14 0x0000000001128530 in ?? ()

#15 0x00000000000037e0 in ?? ()

#16 0x71657260206e6f69 in ?? ()

#17 0x3e2d767265733e2d in ?? ()

#18 0x00007fffd76b6e39 in ?? ()

#19 0x00007f034fc7f3f1 in ?? ()

#20 0x00007f034f2fbcc8 in ?? ()

#21 0x000000000000009d in ?? ()

#22 0x0000000000000020 in ?? ()

#23 0x0000000000000000 in ?? ()

 

 

[emp]

в debug.log

 

 

[2014-07-31 19:06:40.342] ipoe124: 4403c23315f872a4: radius(1): req_exit 6

[2014-07-31 19:06:40.342] ipoe162: 4403c23315f872ca: radius:acct_start: no servers available

[2014-07-31 19:06:40.342] ipoe161: 4403c23315f872c9: radius:acct_start: no servers available

[2014-07-31 19:06:40.434] ipoe4: 4403c23315f8722c: radius(1): req_exit 5

[2014-07-31 19:06:40.434] ipoe272: 4403c23315f87338: radius: no available servers

[2014-07-31 19:06:40.434] ipoe5: 4403c23315f8722d: radius(1): req_exit 4

[2014-07-31 19:06:40.434] ipoe163: 4403c23315f872cb: radius:acct_start: no servers available

[2014-07-31 19:06:40.530] ipoe30: 4403c23315f87247: radius(1): req_exit 3

[2014-07-31 19:06:40.530] ipoe164: 4403c23315f872cc: radius:acct_start: no servers available

[2014-07-31 19:06:40.574] ipoe97: 4403c23315f87289: radius(1): req_exit 2

[2014-07-31 19:06:40.574] ipoe248: 4403c23315f87320: radius(1): req_exit 1

[2014-07-31 19:06:40.574] ipoe166: 4403c23315f872ce: radius:acct_start: no servers available

[2014-07-31 19:06:40.574] ipoe97: 4403c23315f87289: radius: server(1) not responding

[2014-07-31 19:06:40.574] radius: server(1) not responding

[2014-07-31 19:06:40.574] ipoe97: 4403c23315f87289: radius:acct_start: no servers available

[2014-07-31 19:06:40.574] ipoe165: 4403c23315f872cd: radius:acct_start: no servers available

[2014-07-31 19:06:40.574] ipoe112: 4403c23315f87298: radius(1): req_exit 0

[2014-07-31 19:06:40.574] ipoe167: 4403c23315f872cf: radius:acct_start: no servers available

[2014-07-31 19:06:40.790] ipoe111: 4403c23315f87297: radius(1): req_exit -1

 

 

 

и между строчками корректные ответы радиуса. я их отфильтровал.

[nik247]

в debug.log

 

 

[2014-07-31 19:06:40.342] ipoe124: 4403c23315f872a4: radius(1): req_exit 6

[2014-07-31 19:06:40.342] ipoe162: 4403c23315f872ca: radius:acct_start: no servers available

[2014-07-31 19:06:40.342] ipoe161: 4403c23315f872c9: radius:acct_start: no servers available

[2014-07-31 19:06:40.434] ipoe4: 4403c23315f8722c: radius(1): req_exit 5

[2014-07-31 19:06:40.434] ipoe272: 4403c23315f87338: radius: no available servers

[2014-07-31 19:06:40.434] ipoe5: 4403c23315f8722d: radius(1): req_exit 4

[2014-07-31 19:06:40.434] ipoe163: 4403c23315f872cb: radius:acct_start: no servers available

[2014-07-31 19:06:40.530] ipoe30: 4403c23315f87247: radius(1): req_exit 3

[2014-07-31 19:06:40.530] ipoe164: 4403c23315f872cc: radius:acct_start: no servers available

[2014-07-31 19:06:40.574] ipoe97: 4403c23315f87289: radius(1): req_exit 2

[2014-07-31 19:06:40.574] ipoe248: 4403c23315f87320: radius(1): req_exit 1

[2014-07-31 19:06:40.574] ipoe166: 4403c23315f872ce: radius:acct_start: no servers available

[2014-07-31 19:06:40.574] ipoe97: 4403c23315f87289: radius: server(1) not responding

[2014-07-31 19:06:40.574] radius: server(1) not responding

[2014-07-31 19:06:40.574] ipoe97: 4403c23315f87289: radius:acct_start: no servers available

[2014-07-31 19:06:40.574] ipoe165: 4403c23315f872cd: radius:acct_start: no servers available

[2014-07-31 19:06:40.574] ipoe112: 4403c23315f87298: radius(1): req_exit 0

[2014-07-31 19:06:40.574] ipoe167: 4403c23315f872cf: radius:acct_start: no servers available

[2014-07-31 19:06:40.790] ipoe111: 4403c23315f87297: radius(1): req_exit -1

 

 

 

и между строчками корректные ответы радиуса. я их отфильтровал.

1) У меня такое ощущение, что радиус не успевает обрабатывать запросы, или долго отвечает.

2) Что у Вас стоит в [radius]

timeout=n (Timeout to wait response from server (sec))
max-try=n (Specifies number of tries to send Access-Request/Accounting-Request queries)

3) Пробовали играться с req-limit?

4) xeb в последних всерсиях ввел дополнительное логирование для разборок с радиусом, которое Вы видите (radius(1): req_exit ХХ). Но, что оно значит знает только он.

[xeb]

emp

мне нужен полный debug.log как-нибудь, пожалуйста

[kayot]

emp

Тюньте радиус, он у вас не тянет большие нагрузки. Ну и базу в которой он находится.

Временно поставьте req-limit поменьше, 10 например.

[emp]

1) У меня такое ощущение, что радиус не успевает обрабатывать запросы, или долго отвечает.

2) Что у Вас стоит в [radius]

timeout=n (Timeout to wait response from server (sec))
max-try=n (Specifies number of tries to send Access-Request/Accounting-Request queries)

3) Пробовали играться с req-limit?

4) xeb в последних всерсиях ввел дополнительное логирование для разборок с радиусом, которое Вы видите (radius(1): req_exit ХХ). Но, что оно значит знает только он.

он конечно может не справляться, но это не повод падать. по мне так лучше чтобы очередь росла. политики можно и потом навешать. услуга клиенту должна предоставляться.

вот что у меня по поводу радиуса в конфиге:

 

[radius]

dictionary=/usr/share/accel-ppp/radius/dictionary

nas-identifier=accel-ppp

nas-ip-address=x.x.x.x

#gw-ip-address=192.168.100.1

server=x.x.x.x,xxxxxxxx,auth-port=1812,acct-port=1813,req-limit=100,fail-time=0

dae-server=x.x.x.x:3799,xxxxxxxxxx

verbose=1

#timeout=3

#max-try=3

acct-timeout=120

#acct-delay-time=0

#acct-on=0

 

req-limit не менял. подозреваю надо max-try=0 сделать чтобы ждал радиус до посинения. тогда не будет делать повторных попыток и пропадут "Error: Discarding duplicate request from client bras01 port 52493 - ID: 1 due to unfinished request 6914"

 

кстати версия которая была до этого не падала (deb-пакеты с sf.net), но имела специфичные глюки типа нерабочего REDIRECT и падающих ospf-линков. последнее может тут и непричём, но уже пару дней ospf не падал, пока я играюсь с accel-ppp из git.

 

emp

мне нужен полный debug.log как-нибудь, пожалуйста

в ЛС скинул ссылку на debug.log

 

emp

Тюньте радиус, он у вас не тянет большие нагрузки. Ну и базу в которой он находится.

Временно поставьте req-limit поменьше, 10 например.

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

[nik247]

to emp

Плохо, конечно, что падает, но понимаете, версия в git - это верися в разработке.

Туда xeb вносит много хотелок/свистелок, которые могут в определнных ситуациях вылазить боком.

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

Последнюю версию с git усиленно тестировали по проблеме именно с radius - точнее с последствиями, к которым приводило недоступность радиуса.

И у нас на стендах и в работе эту проблему побороли и не смогли больше завалить accel-ppp из-за радиуса.

Если у Вас падает - делайте корки, дебаг-логи и отправляйте xeb.

Так Вы сами сможете помочь проекту стать более стабильным.

По вышей ситуации (с ваших логов) - 99% процентов, что радиус (или его база) не успевает обрабатывать запросы.

- уменьшите req-limit до 10, 30, 50

- увеличьте timeout до 3,5 (время ожидания ответа от радиуса)

 

А насчет падения - xeb посмотрит логи и я думаю найдет причину падения.

[emp]

to emp

Плохо, конечно, что падает, но понимаете, версия в git - это верися в разработке.

Туда xeb вносит много хотелок/свистелок, которые могут в определнных ситуациях вылазить боком.

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

Последнюю версию с git усиленно тестировали по проблеме именно с radius - точнее с последствиями, к которым приводило недоступность радиуса.

И у нас на стендах и в работе эту проблему побороли и не смогли больше завалить accel-ppp из-за радиуса.

Если у Вас падает - делайте корки, дебаг-логи и отправляйте xeb.

Так Вы сами сможете помочь проекту стать более стабильным.

По вышей ситуации (с ваших логов) - 99% процентов, что радиус (или его база) не успевает обрабатывать запросы.

- уменьшите req-limit до 10, 30, 50

- увеличьте timeout до 3,5 (время ожидания ответа от радиуса)

 

А насчет падения - xeb посмотрит логи и я думаю найдет причину падения.

 

я всё прекрасно понимаю и ни в чём автора не виню :)

req-limit=15. столько коннектов к базе.

timeout=3

пока живёт

[xeb]

падение исправил

[emp]

падение исправил

вот спасибо! полёт нормальный.

[emp]

не падает но всёже проблемы бывают. подозреваю не справляется радиус. не знаю что именно происходит но в момент когда радиус не отвечает в логи ошибки про то что радиус не доступен и начинают отваливаться ospf-линки в кваге. не понимаю как это связано. особой нагрузки на процессор при этом не видно. возможно ли отключить radius-аккаунтинг ?