Перейти к содержимому
Калькуляторы

Капец, помогло, спасибо огромное)))) Хотя смотрел ethtool -k eth*, все было выключено.

А как зафиксировать эти значения при загрузке? Или тупо через rc.local командами?

У меня именно так - через /etc/rc.local:

/sbin/ethtool -K eth2 rx off

/sbin/ethtool -K eth3 rx off

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

сколько максимально сессий терминировали? если не секрет....

Пока перевели около 160 пользователей на 40 свитчах.

Текущие:

sessions:
 starting: 0
 active: 568
 finishing: 0
pppoe:
 starting: 0
 active: 434
 delayed PADO: 0
 recv PADI: 25890
 drop PADI: 0
 sent PADO: 25890
 recv PADR(dup): 22970(132)
 sent PADS: 22638
 filtered: 0
ipoe:
 starting: 0
 active: 134
 delayed: 0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вопрос по потреблению ресурсов самим accel-ppp для ipoe.

[root@ipoe1 src]# accel-cmd show stat
uptime: 11.07:40:45
cpu: 0%
mem(rss/virt): 55332/2137072 kB
core:
 mempool_allocated: 24257785
 mempool_available: 373521
 thread_count: 6
 thread_active: 1
 context_count: 5010
 context_sleeping: 0
 context_pending: 0
 md_handler_count: 8693
 md_handler_pending: 0
 timer_count: 2633
 timer_pending: 0
sessions:
 starting: 0
 active: 1319
 finishing: 0
ipoe:
 starting: 0
 active: 1319
 delayed: 0

[root@ipoe1 src]# top
top - 20:21:43 up 11 days,  7:43,  1 user,  load average: 0.40, 0.77, 0.75
Tasks: 123 total,   2 running, 121 sleeping,   0 stopped,   0 zombie
Cpu0  :  3.7%us,  1.6%sy,  0.0%ni, 70.2%id,  0.0%wa,  0.0%hi, 24.6%si,  0.0%st
Cpu1  :  0.5%us,  2.2%sy,  0.0%ni, 70.3%id,  0.0%wa,  0.0%hi, 27.0%si,  0.0%st
Cpu2  :  1.0%us,  2.1%sy,  0.0%ni, 66.0%id,  0.0%wa,  0.0%hi, 30.9%si,  0.0%st
Cpu3  :  0.5%us,  3.1%sy,  0.0%ni, 64.4%id,  0.0%wa,  0.0%hi, 31.9%si,  0.0%st
Cpu4  :  1.1%us,  0.5%sy,  0.0%ni, 70.3%id,  0.0%wa,  0.0%hi, 28.0%si,  0.0%st
Cpu5  :  1.1%us,  2.3%sy,  0.0%ni, 69.3%id,  0.0%wa,  0.0%hi, 27.3%si,  0.0%st
Mem:   6105300k total,  2219376k used,  3885924k free,   269800k buffers
Swap:  8191992k total,        0k used,  8191992k free,  1127748k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27641 root      20   0 2086m  54m 1928 S 28.9  0.9   3466:47 accel-pppd
1913 named     20   0  555m 225m 3040 S  7.0  3.8 637:35.27 named

[root@ipoe1 src]# opreport -l /usr/local/sbin/accel-pppd
warning: [vdso] (tgid:27641 range:0x7fffa4dff000-0x7fffa4e00000) could not be found.
CPU: Intel Westmere microarchitecture, speed 2132.8 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
samples  %        image name               symbol name
273      53.8462  accel-pppd               log_ppp_info2
58       11.4398  accel-pppd               rtnl_talk
50        9.8619  accel-pppd               log_switch
42        8.2840  [vdso] (tgid:27641 range:0x7fffa4dff000-0x7fffa4e00000) [vdso] (tgid:27641 range:0x7fffa4dff000-0x7fffa4e00000)
36        7.1006  accel-pppd               ap_session_read_stats
28        5.5227  accel-pppd               parse_rtattr
12        2.3669  accel-pppd               iplink_get_stats

Accel при 1300 сессий потребляет ~30% CPU. В принципе вполне нормально.

Но.. Я правильно понимаю, что функции log_ppp_info2 и log_switch(вызываемые в коде по каждому чиху) потребляют 63% ресурсов? :)

Log level стоит 3, в лог практически ничего не пишется(старт-стоп сессий раз в минуту).

 

UPD: убрал опцию verbose=1, потребление ресурсов визуально не изменилось(те же 30%), но в профайлере log_ppp_info2 из топа исчез.

Как определить что именно потребляет ресурсы в accel?

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Здравствуйте!

 

На роутер ASUS RT-N16 установил accel-ppp 1.8.0, взял конфиг-минимум с SF.

При загрузке, в syslog поступает сообщение об успешности загрузки, по факту - никаких изменений в выводе "netstat -an" не происходит, процесс забирает 100%CPU.

В логи ничего не выводится.

 

Последняя версия, которая работает исправно -- 1.7.2

 

Подскажите пожалуйста, в чём может быть проблема?

Изменено пользователем Relexey

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет авторизации. На радиус не приходят запросы.

 

request count: 0

queue length: 0

auth sent: 63

auth lost(total/5m/1m): 0/0/0

auth avg query time(5m/1m): 0/0 ms

acct sent: 0

acct lost(total/5m/1m): 0/0/0

acct avg query time(5m/1m): 0/0 ms

interim sent: 0

interim lost(total/5m/1m): 0/0/0

interim avg query time(5m/1m): 0/0 ms

 

Фаерволов нет. radtest проходит успешно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как определить что именно потребляет ресурсы в accel?
судя по приведённому выше топу, основная нагрузка идёт на %si, т.е. это прерывания, т.е. сетевой трафик, accel поедает совсем не много, максимум %us я вижу 4%

основную нагрузку как я вижу создаёт ap_session_read_stats, оно вызывается при каждом обновлении аккаунтинга и старте/стопе сессий

 

Нет авторизации. На радиус не приходят запросы.
конфиг и логи уровня 5 с verbose=1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите пожалуйста, как при подключении клиента выдаеть ему "route ADD"?

Сеть на роутере 192.168.1.1/22 (mask: 255.255.252.0).

Клиентам выдаётся 192.168.2.2-254 (у клиента в настройках сброшена галка Use default gateway on remote network). Нужно чтобы запросы на 192.168.1.x всё же шли через мой VPN-сервер, а на 192.168.58.x через гейтвей по-умолчанию.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите пожалуйста, как при подключении клиента выдаеть ему "route ADD"?
в ppp нет такой возможности

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сегодня ровно через месяц обновления упал 3fc000aa67ee38002ec97419a760f23cccd87210 :(

Корка сохранилась. Слать?

UPD

Ровно через час accel упал снова.

ps -e | grep acc

22457 ? 00:13:56 accel-pppd

Демон есть в списке, но на запросы пользователей не отвечает. Корка есть.

Изменено пользователем purecopper

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поскажите пожалуйста, как сбросить соединение l2tp через radius Session-Timeout. Сервер гасит ppp соединение, закрывает сессию, но клиенту (win7) по всей видимости не приходит уведомление, и он только через пару минут сбрасывает по таймауту.

pptp сбрасывается сразу, что в принципе логично (из-за tcp)

accel-ppp версия из git-a (01fcf87fe35502f6745137d79f56e618368872eb)

Хотя Call-Disconnect-Notify отправляется

Изменено пользователем it1804

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

purecopper

Если уж ровно через месяц.. logrotate некорректно сработал?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да вроде как нет. Логи в этот момент не ротировались.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поскажите пожалуйста, как сбросить соединение l2tp через radius Session-Timeout. Сервер гасит ppp соединение, закрывает сессию, но клиенту (win7) по всей видимости не приходит уведомление, и он только через пару минут сбрасывает по таймауту.

pptp сбрасывается сразу, что в принципе логично (из-за tcp)

accel-ppp версия из git-a (01fcf87fe35502f6745137d79f56e618368872eb)

Хотя Call-Disconnect-Notify отправляется

 

Мне кажется такой disconnect более корректен, т.к CDN пакет вроде должен отправляться раньше закрытия PPP туннеля.

По крайней мере клиент теперь получает это уведомление при radius Session-Timeout (или terminate if ppp0 из telnet), и сразу разрывает соединение, а не ждет таймаута, чтобы отвалиться с ошибкой.

--- l2tp.c.orig 2014-01-15 00:57:50.000000000 +0600
+++ l2tp.c      2014-01-15 01:40:41.879940918 +0600
@@ -763,6 +763,21 @@
       return 0;
}

+static void l2tp_ppp_terminate(struct ap_session *ses, int hard)
+{
+    struct l2tp_sess_t *sess = l2tp_session_self();
+    switch (sess->state1) {
+       case STATE_PPP:
+           if (l2tp_send_CDN(sess, 2, 0) < 0)
+               log_session(log_error, sess,
+                   "impossible to notify peer of session"
+                   " disconnection, disconnecting anyway\n");
+               break;
+    }
+    ppp_terminate(ses,hard);
+}
+
+
static void l2tp_ppp_finished(struct ap_session *ses)
{
       struct l2tp_sess_t *sess = l2tp_session_self();
@@ -774,10 +789,6 @@
                           " disconnecting session\n",
                           ses->ifname, ses->username ? ses->username : "");
               sess->state1 = STATE_CLOSE;
-               if (l2tp_send_CDN(sess, 2, 0) < 0)
-                       log_session(log_error, sess,
-                                   "impossible to notify peer of session"
-                                   " disconnection, disconnecting anyway\n");
               if (l2tp_session_free(sess) < 0)
                       log_session(log_error, sess,
                                   "impossible to free session,"
@@ -890,7 +901,7 @@
       sess->ctrl.name = "l2tp";
       sess->ctrl.started = l2tp_ppp_started;
       sess->ctrl.finished = l2tp_ppp_finished;
-       sess->ctrl.terminate = ppp_terminate;
+       sess->ctrl.terminate = l2tp_ppp_terminate;
       sess->ctrl.max_mtu = conf_ppp_max_mtu;
       sess->ctrl.mppe = conf_mppe;
       sess->ctrl.calling_station_id = _malloc(17);


Изменено пользователем it1804

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Мне кажется такой disconnect более корректен
ну не знаю, пересмотрел rfc, явно последовательность не указана, но если отправлять CDN, то LCP "мягко" останавливать уже нет смысла, т.е. надо вызывать ppp_terminate(ses, 1)

можешь запостить патч в мыло лист на сорцфорже ? л2тп часть курирует Guillaume Nault, пусть выскажет своё мнение

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну не знаю, пересмотрел rfc, явно последовательность не указана, но если отправлять CDN, то LCP "мягко" останавливать уже нет смысла, т.е. надо вызывать ppp_terminate(ses, 1)

можешь запостить патч в мыло лист на сорцфорже ? л2тп часть курирует Guillaume Nault, пусть выскажет своё мнение

Явного указания тоже не нашел. Посмотрел сейчас в какой последовательности дисконнектит cisco. Первым также CDN, потом lcp term-request. Я перебирал разные варианты, получилось что отработал только этот. Клиент win7 тут же выдал окно о прерывании сессии. А до этого было видно в tcpdump что клиент явно не понимал что от него потребовали, продолжал слать ещё какое-то время запросы, сервер на которые уже не отвечал. И так до таймаута.

diff отправил.

Изменено пользователем it1804

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Явного указания тоже не нашел. Посмотрел сейчас в какой последовательности дисконнектит cisco. Первым также CDN, потом lcp term-request. Я перебирал разные варианты, получилось что отработал только этот. Клиент win7 тут же выдал окно о прерывании сессии. А до этого было видно в tcpdump что клиент явно не понимал что от него потребовали, продолжал слать ещё какое-то время запросы, сервер на которые уже не отвечал. И так до таймаута.

diff отправил.

 

Подтверждаю аналогичное поведение и для pppoe-соединений.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Посмотрел сейчас в какой последовательности дисконнектит cisco. Первым также CDN, потом lcp term-request. Я перебирал разные варианты, получилось что отработал только этот. Клиент win7 тут же выдал окно о прерывании сессии. А до этого было видно в tcpdump что клиент явно не понимал что от него потребовали, продолжал слать ещё какое-то время запросы, сервер на которые уже не отвечал. И так до таймаута.

Мне кажется я нашел реальную причину такого поведения клиента в l2tp. Сервер закрывает туннельное соединение раньше, чем происходит окончательный обмен запрос-подтверджение по управляющему туннелю. И клиент не может узнать, отключать соединение, шлёт запросы на уже закрытое сервером соединение. Теперь сервер принимает ответный stopCCN от клиента, и отправляет финальный ZLB, на ожидании которого клиент и зависает.

И порядок CDN, потом lcp term-request вроде как действительно не имеет значения.

Отправил новый патч на проверку в список рассылки.

P.S. После этого пропали сообщения про invalid tid при финализации туннеля.

 

--- l2tp.c.orig 2014-01-15 00:57:50.000000000 +0600
+++ l2tp.c      2014-01-15 23:59:07.025954894 +0600
@@ -663,9 +663,12 @@
{
       struct l2tp_packet_t *pack;

-       if (conn->state != STATE_CLOSE)
-               conn->state = STATE_CLOSE;
-
+        if (conn->state == STATE_ESTB) {
+            conn->state= STATE_CLOSE;
+            return;
+        } else
+            conn->state= STATE_CLOSE;
+
       if (conn->sess_count != 0) {
               /*
                * There are still sessions in this tunnel: remove the ones

Изменено пользователем it1804

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

Возникла парочка вопросов:

1.Прочитал, что иногда процесс работает, но начинает без причины отказывать l2tp/pptp в подключении. Это можно где-то увидеть/определить, чтобы сразу перезагрузить его?

2. В продакшн всё-таки stable ветку использовать, или git уже достаточно стабилен?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всем привет, а есть ли необходимость пересобирать accel после обновления ядра? Так как при сборке мы указываем путь к исходникам -DKDIR=/usr/src/linux.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день!

Собрал из гита. Сервер стартует, но при попытке подключения к нему сегфолтится. Логи:

[2014-01-17 14:22:02]:   msg: accel-ppp version 42b8eaa35951e5381a7963d6bded7fa28b9b1713
[2014-01-17 14:22:16]:  info: recv [PPPoE PADI 00:15:f2:7d:7f:c8 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 070000000c000000>]
[2014-01-17 14:22:16]:  info: send [PPPoE PADO 00:1b:21:5b:99:08 => 00:15:f2:7d:7f:c8 sid=0000 <AC-Name pppoe> <Service-Name pppoe> <Service-Name > <AC-Cookie 7a2fb87dbab7092529aa3e8b8da3bfa6bb9fdde44078329f> <Host-Uniq 070000000c000000>]
[2014-01-17 14:22:16]:  info: recv [PPPoE PADR 00:15:f2:7d:7f:c8 => 00:1b:21:5b:99:08 sid=0000 <Service-Name > <Host-Uniq 070000000d000000> <AC-Cookie 7a2fb87dbab7092529aa3e8b8da3bfa6bb9fdde44078329f>]
[2014-01-17 14:22:16]:  info: send [PPPoE PADS 00:1b:21:5b:99:08 => 00:15:f2:7d:7f:c8 sid=0001 <AC-Name pppoe> <Service-Name > <Host-Uniq 070000000d000000>]
[2014-01-17 14:22:16]:  info: ppp0: connect: ppp0 <--> pppoe(00:15:f2:7d:7f:c8)
[2014-01-17 14:22:16]: debug: ppp0: lcp_layer_init
[2014-01-17 14:22:16]: debug: ppp0: auth_layer_init
[2014-01-17 14:22:16]: debug: ppp0: ccp_layer_init
[2014-01-17 14:22:16]: debug: ppp0: ipcp_layer_init
[2014-01-17 14:22:16]: debug: ppp0: ipv6cp_layer_init
[2014-01-17 14:22:16]: debug: ppp0: ppp established

gdb --args /usr/local/sbin/accel-pppd -p /var/run/accel-pppd.pid -c /etc/accel-ppp.conf
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 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/>...
Reading symbols from /usr/local/sbin/accel-pppd...done.
(gdb) run
Starting program: /usr/local/sbin/accel-pppd -p /var/run/accel-pppd.pid -c /etc/accel-ppp.conf
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff5b6a700 (LWP 21450)]
[New Thread 0x7ffff7ff5700 (LWP 21451)]
[New Thread 0x7ffff3022700 (LWP 21452)]
[New Thread 0x7ffff2f21700 (LWP 21453)]
[New Thread 0x7ffff2e20700 (LWP 21454)]
[New Thread 0x7ffff2d1f700 (LWP 21455)]
[New Thread 0x7ffff2c1e700 (LWP 21456)]
[New Thread 0x7ffff241d700 (LWP 21457)]
[Thread 0x7ffff7ff5700 (LWP 21451) exited]
[New Thread 0x7ffff7ff5700 (LWP 21458)]

Program received signal SIGSEGV, Segmentation fault.
[switching to Thread 0x7ffff2e20700 (LWP 21454)]
0x000000000041f3cf in iplink_get_stats (ifindex=140, stats=0x7ffff2e1fc90) at /usr/src/accel-ppp.git/accel-pppd/libnetlink/iputils.c:163
163}

 

uname -a
Linux pppoe 3.12-0.bpo.1-amd64 #1 SMP Debian 3.12.6-2~bpo70+1 (2014-01-07) x86_64 GNU/Linux

 

Методом научного тыка поменял в /usr/src/accel-ppp.git/accel-pppd/libnetlink/iputils.c

Было:

int __export iplink_get_stats(int ifindex, struct rtnl_link_stats *stats)
{
       struct iplink_req {
               struct nlmsghdr n;
               struct ifinfomsg i;
               char buf[1024];
       } req;

Стало:

int __export iplink_get_stats(int ifindex, struct rtnl_link_stats *stats)
{
       struct iplink_req {
               struct nlmsghdr n;
               struct ifinfomsg i;
               char buf[4096];
       } req;

Теперь сессия подымается, с виду всё работает нормально. Посмотрите, пожалуйста, можно ли ставить в продакшн.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

muchacho,

СильнО!

xeb,

А не пофиксил ли muchacho случайным образом работу на ядрах 3.11-3.12? :)

Вполне похоже.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А не пофиксил ли muchacho случайным образом работу на ядрах 3.11-3.12? :)

Вполне похоже.

Буквально пару дней назад на тоже самое наткнулся.

На 3.12.7 валился при создании интерфейса, после дебага выяснилось, что размер nlmsg, приходящего из ядра, 1188 байт,

и в при копировании в буфер в 1024 байта ломает стек. После увеличения размера все заработало.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

muchacho, спасибо я сам не допёр

 

Всем привет, а есть ли необходимость пересобирать accel после обновления ядра? Так как при сборке мы указываем путь к исходникам -DKDIR=/usr/src/linux.
если используете ipoe.ko, то - да

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.