Abills, не получается подружить с RIP

[masters 126]

Стоит Abills (0.59) на Centos 6, и несколько НАСов на FreeBSD 11, mpd5.

Белые IP распределяются динамически по протоколу RIP (на фре - quagga).

 

Проблема в том, что когда у пользователя некорректно завершается PPPoE сессия (обрыв, роутер перегрузили), маршрут по RIP не подымается, соответственно интернета нет.

 

Есть подозрение - что это происходит из-за того, что биллинг разрешает клиенту вторую сессию параллельно. Когда пользователь поднимает 2ю сессию, первая рубится - и соответственно, с ней Quagga дропает и маршрут. Если потом завершить сессию корректно, то маршрут подымается и работает нормально.

 

Есть ли возможность запретить поднимать вторую сессию? Пусть например пользователь ждет пока не выйдет таймаут, и первая не дропнется.

[Dimkers 1,615]

может лучше выделить по подсети на каждый НАС?

[zulu_Radist 856]

в тарифных планах по-моему это делается.  у меня так. 

[sanyadnepr 305]

1 час назад, masters сказал:

Есть ли возможность запретить поднимать вторую сессию?

В конфиге мпд5. И радист дело говорит.

Edited 2018-06-04 12:18:29 by sanyadnepr

[masters 126]

6 часов назад, sanyadnepr сказал:

В конфиге мпд5. И радист дело говорит.

У меня в биллинге и стоит одновременно - 1. Но вторая сессия подымается, при этом рубит первую.

Вот помню на очень старых версиях абилса такого не было, пользователю надо было выждать таймаут, иначе НАС давал отлуп.

А по мпд - подробней?

7 часов назад, Dimkers сказал:

может лучше выделить по подсети на каждый НАС?

Сильный перекос по белым IP. На одном НАСе может быть 3, а на другом - 50. Не выгодно получается столько IP держать.

И есть НАСы которые работают параллельно. Клиент может подключиться на один или на второй рандомно.

Edited 2018-06-04 19:07:47 by masters

[АНТИдемпинг 31]

чтоб не плодить темы...

abills 0.75. + НАТ mikrotik CCR

онлайн <400 абон. Периодически биллинг перестает принимать сессии.

CCR пишет "user xxx authentecatuin failed - radius timeout"

клиентский МТ пишет: "failed to authenticate ourselves to peer "

 

помогает "service freeradius restart" не сервере - все мгновенно поднимается. 

Раньше такое бывало при перезагрузке МТ, сервера, обрыве линка,... Когда "очередь" большая, приходится несколько раз делать "service freeradius restart"

 

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

 

Где копать?

Edited 2018-06-04 21:38:14 by АНТИдемпинг

[KaYot 3,731]

Тюнить базу под фрирудиусом на предмет одновременных коннектов.

[Kiano 616]

7 часов назад, АНТИдемпинг сказал:

чтоб не плодить темы...

abills 0.75. + НАТ mikrotik CCR

онлайн <400 абон. Периодически биллинг перестает принимать сессии.

CCR пишет "user xxx authentecatuin failed - radius timeout"

клиентский МТ пишет: "failed to authenticate ourselves to peer "

 

помогает "service freeradius restart" не сервере - все мгновенно поднимается. 

Раньше такое бывало при перезагрузке МТ, сервера, обрыве линка,... Когда "очередь" большая, приходится несколько раз делать "service freeradius restart"

 

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

 

Где копать?

Смотреть при этом логи радиуса, мускуля

[masters 126]

8 часов назад, АНТИдемпинг сказал:

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

Тюнить MySQL. Нам пришлось вынести БД на ССД, правда сессий в десятки раз больше чем у Вас.

Увеличить таймаут запроса к БД.

[~AsmodeuS~ 34]

18 часов назад, masters сказал:

Стоит Abills (0.59) на Centos 6, и несколько НАСов на FreeBSD 11, mpd5.

Белые IP распределяются динамически по протоколу RIP (на фре - quagga).

 

Проблема в том, что когда у пользователя некорректно завершается PPPoE сессия (обрыв, роутер перегрузили), маршрут по RIP не подымается, соответственно интернета нет.

 

Есть подозрение - что это происходит из-за того, что биллинг разрешает клиенту вторую сессию параллельно. Когда пользователь поднимает 2ю сессию, первая рубится - и соответственно, с ней Quagga дропает и маршрут. Если потом завершить сессию корректно, то маршрут подымается и работает нормально.

 

Есть ли возможность запретить поднимать вторую сессию? Пусть например пользователь ждет пока не выйдет таймаут, и первая не дропнется.

 

 

попробуйте это в mpd

 

set iface idle 1800

8 часов назад, АНТИдемпинг сказал:

чтоб не плодить темы...

abills 0.75. + НАТ mikrotik CCR

онлайн <400 абон. Периодически биллинг перестает принимать сессии.

CCR пишет "user xxx authentecatuin failed - radius timeout"

клиентский МТ пишет: "failed to authenticate ourselves to peer "

 

помогает "service freeradius restart" не сервере - все мгновенно поднимается. 

Раньше такое бывало при перезагрузке МТ, сервера, обрыве линка,... Когда "очередь" большая, приходится несколько раз делать "service freeradius restart"

 

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

 

Где копать?

 

 

radius set timeout=5000

[АНТИдемпинг 31]

8 часов назад, ~AsmodeuS~ сказал:

radius set timeout=5000

может freeradius set timeout?

[~AsmodeuS~ 34]

2 часа назад, АНТИдемпинг сказал:

может freeradius set timeout?

 

radius set timeout=5000

 

это команда для mikrotik

[KaYot 3,731]

2 часа назад, ~AsmodeuS~ сказал:

radius set timeout=5000

 

это команда для mikrotik

В любом случае это ненужный костыль. Лечить нужно базу что б принимала больше соединений, а не клиента чтоб дольше ждал ответа..

[zulu_Radist 856]

mysql> set global max_connections = 500;

 

ставить количество по вкусу и количества озу в серваке

[KaYot 3,731]

16 минут назад, zulu_Radist сказал:

mysql> set global max_connections = 500;

 

ставить количество по вкусу и количества озу в серваке

Это правильно, но недостаточно. Изначальный затык в самом freeradius который не умеет создавать больше 5(!!) дефолтных соединений.

/etc/raddb/sql.conf

      # number of sql connections to make to server
      num_sql_socks = 30
 

[mixtery 123]

10 часов назад, KaYot сказал:

Это правильно, но недостаточно. Изначальный затык в самом freeradius который не умеет создавать больше 5(!!) дефолтных соединений.

/etc/raddb/sql.conf

      # number of sql connections to make to server
      num_sql_socks = 30
 

давным давно уже 
 

        # number of sql connections to make to server
        #
        # Setting this to LESS than the number of threads means
        # that some threads may starve, and you will see errors
        # like "No connections available and at max connection limit"
        #
        # Setting this to MORE than the number of threads means
        # that there are more connections than necessary.
        #
        num_sql_socks = ${thread[pool].max_servers}

 

 

[~AsmodeuS~ 34]

12 часов назад, KaYot сказал:

Это правильно, но недостаточно. Изначальный затык в самом freeradius который не умеет создавать больше 5(!!) дефолтных соединений.

/etc/raddb/sql.conf

      # number of sql connections to make to server
      num_sql_socks = 30
 

 

не очень понятно зачем это, если модуль используется только для читки NAS  при старте радиус

 

13 часов назад, KaYot сказал:

В любом случае это ненужный костыль. Лечить нужно базу что б принимала больше соединений, а не клиента чтоб дольше ждал ответа..

 

но с этим параметром лучше очередь формируется, и замедляет постоянную долбежку на сервер