Перейти до

Отваливаются PPPoE юзеры

veca16

Автор: veca16,
в Софт

 Share Подписчики 1

Рекомендованные сообщения

veca16

veca16 1

Опубликовано:
Опубликовано: (відредаговано)

Доброе утро! Прошу помощи у знатоков. Проблема такая: есть биллинг (Nodeny 50.33) и 3 наса которые терминируют PPPoE, на них заведены параллельно все вланы (сеть сегментирована). Каждую ночь, а бывает уже и днем по несколько раз происходят массовые одновременные дисконекты всех пользователей, после этого они свободно могут переконектиться. Что может на это так влиять? Какими пакетами можно положить насы ( Freebsd 9.2 mpd5 ), на даный момент правила в ipfw add allow ip from any to any. Насы агрегируются на D-Link DGS 3120-24SC. Прошу не пинать если что :)

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

Archy_k 14

Опубліковано:
Опубліковано: (відредаговано)

3 наса...

А отваливаются юзеры с 1 наса одновременно или со всех 3 насов все юзеры одновременно?

А билинг на отдельностоящем серваке или один из насов - "сервак все в одном флаконе: билинг, нас, веб..." ???

*******

Первая мысль:

РРРоЕ отваливается если пропадает линк на каком-то промежуточном звене или электропитание, например от наса идет на какую-то железку, а с нее на коммутаторы доступа... Так вот например эта железка по питанию или линку отвалилась на секунды и включилась, а юзеры тем временем посыпались.

Может кто Вам такую каку вручную делает... и т.д. Может это из-за сосисочной топологии сети? )))

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

veca16 1

Опубліковано:
  • Автор
Опубліковано:

Отваливается сразу на 3 насах, биллинг на отдельно стоящем серваке, топология звезда с этим все норм, питание норм, свич в ядре не ребутается, а дисконнект в течении 5-10 секунд.

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

John_Doe 301

Опубліковано:
Опубліковано:

Отваливается сразу на 3 насах, биллинг на отдельно стоящем серваке, топология звезда с этим все норм, питание норм, свич в ядре не ребутается, а дисконнект в течении 5-10 секунд.

Для этого существуют логи. Смотрите логи на мпд и на радиус сервере

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

veca16 1

Опубліковано:
  • Автор
Опубліковано:

Логи проверялись, в них вот это: radius.log

Sun Sep 20 00:00:03 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 00:04:34 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 00:12:41 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 00:24:47 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 00:30:50 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 00:36:03 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 01:03:01 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 01:03:02 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 01:06:47 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 01:09:03 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 01:09:04 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 01:30:01 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 01:36:19 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 01:39:19 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 01:45:20 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 01:51:21 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:03:24 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:09:26 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:17:32 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:23:34 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:29:34 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:29:35 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:35:34 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:35:35 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:41:37 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:47:37 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:53:37 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:54:18 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0
Sun Sep 20 02:59:40 2015 : Error: rlm_sql (sql): There are no DB handles to use! skipped 0, tried to connect 0

mpd.log

Sep 20 15:00:07 bras1 mpd: Incoming PPPoE connection request via vlan35: for service "" from 00:26:18:d6:27:f8
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] Accepting PPPoE connection
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] Link: OPEN event
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: Open event
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: state change Initial --> Starting
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: LayerStart
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] PPPoE: connection successful
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] Link: UP event
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: Up event
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: state change Starting --> Req-Sent
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: SendConfigReq #1
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   PROTOCOMP
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   MRU 1492
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   MAGICNUM 5d6a684e
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   AUTHPROTO PAP
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   MP MRRU 2048
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   MP SHORTSEQ
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   ENDPOINTDISC [802.1] 00 15 17 35 cf 7a
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: rec'd Configure Request #0 (Req-Sent)
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   MRU 1480
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   MAGICNUM 66024fc5
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   PROTOCOMP
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   ACFCOMP
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   CALLBACK 6
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: SendConfigRej #0
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   ACFCOMP
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   CALLBACK 6
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: rec'd Configure Request #1 (Req-Sent)
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   MRU 1480
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   MAGICNUM 66024fc5
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   PROTOCOMP
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: SendConfigAck #1
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   MRU 1480
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   MAGICNUM 66024fc5
Sep 20 15:00:07 bras1 mpd: [vlan35-2042]   PROTOCOMP
Sep 20 15:00:07 bras1 mpd: [vlan35-2042] LCP: state change Req-Sent --> Ack-Sent
Sep 20 15:00:08 bras1 kernel: Limiting closed port RST response from 421 to 200 packets/sec
Sep 20 15:00:08 bras1 kernel: Limiting icmp unreach response from 404 to 200 packets/sec
Sep 20 15:00:09 bras1 mpd: Incoming PPPoE connection request via vlan7: for service "" from ac:f1:df:d0:30:71
Sep 20 15:00:09 bras1 mpd: [vlan7-2289] Accepting PPPoE connection
Sep 20 15:00:09 bras1 mpd: [vlan7-2289] Link: OPEN event
Sep 20 15:00:09 bras1 mpd: [vlan7-2289] LCP: Open event
Sep 20 15:00:09 bras1 mpd: [vlan7-2289] LCP: state change Initial --> Starting
Sep 20 15:00:09 bras1 mpd: [vlan7-2289] LCP: LayerStart
Sep 20 15:00:09 bras1 mpd: [vlan7-2289] PPPoE: connection successful
Sep 20 15:00:09 bras1 mpd: [vlan7-2289] Link: UP event
Sep 20 15:00:09 bras1 mpd: [vlan7-2289] LCP: Up event
Sep 20 15:00:09 bras1 mpd: [vlan7-2289] LCP: state change Starting --> Req-Sent
Sep 20 15:00:09 bras1 mpd: [vlan7-2289] LCP: SendConfigReq #1
Sep 20 15:00:09 bras1 mpd: [vlan7-2289]   PROTOCOMP
Sep 20 15:00:09 bras1 mpd: [vlan7-2289]   MRU 1492

тоже самое было и до этого, а больше ничего не обнаружили!

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

KaYot 3 708

Опубліковано:
Опубліковано:

Ну как и следовало ожидать, у вас радиус время от времени от базы отваливается.

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

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

YuSHa 59

Опубліковано:
Опубліковано:

Лечилось тюнингом мускула. Подробней ищите на форуме нодени.  Уж не помню чего менял, давно это было)))

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

sov 66

Опубліковано:
Опубліковано:

Самое простое, как временное решение - попробовать в настройках MySQL увеличить параметр max_connections.

 

На форуме Нодени про эти симптомы много написано, лучше там почитать/поспрашивать.

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

veca16 1

Опубліковано:
  • Автор
Опубліковано: (відредаговано)

я по началу тоже думал что из за радиуса, просто такие сообщения в радиусе были и месяц назад до этого! И на сколько я знаю проверялось не один раз все сесии которые были приконнекчены  если в фаерволе прописать правилом ipfw add 10 allow ip from any to any то хоть и полностью туши комп с базой даных то все клиенты остаются работать, pppoe сесии не рвутся, новые конечно не приконектятся!

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

DmitriyK 0

Опубліковано:
Опубліковано:

 

20 сен 2015 - 3:30 PM DmitriyK писал:

snapback.png

А разве радиус может влиять на отключение абонента(дисконект сессии) ? )

Да может

 как? интересно без сарказма. ткните ссылкой или растолкуйте если есть время )

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

John_Doe 301

Опубліковано:
Опубліковано: (відредаговано)

 

20 сен 2015 - 3:30 PM DmitriyK писал:

snapback.png

А разве радиус может влиять на отключение абонента(дисконект сессии) ? )

Да может

 

 как? интересно без сарказма. ткните ссылкой или растолкуйте если есть время )

 

Ну погуглите про аккаунтинг,CоA и радиус вообще Відредаговано John_Doe
Ссылка на сообщение
Поделиться на других сайтах
DmitriyK

DmitriyK 0

Опубліковано:
Опубліковано:

 

20 сен 2015 - 7:38 PM DmitriyK писал:

snapback.png

Ну погуглите про аккаунтинг,

 

Цитата

20 сен 2015 - 3:30 PM DmitriyK писал:

snapback.png

20 сен 2015 - 3:30 PM DmitriyK писал:snapback.png

А разве радиус может влиять на отключение абонента(дисконект сессии) ? )

Да может

 

 как? интересно без сарказма. ткните ссылкой или растолкуйте если есть время )

 

CоA и радиус вообще 

спасибо ) Но судя по всему у топикастера это не реализовано....

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

veca16 1

Опубліковано:
  • Автор
Опубліковано: (відредаговано)

 

 

20 сен 2015 - 7:38 PM DmitriyK писал:

snapback.png

Ну погуглите про аккаунтинг,

 

Цитата

20 сен 2015 - 3:30 PM DmitriyK писал:

snapback.png

20 сен 2015 - 3:30 PM DmitriyK писал:snapback.png

А разве радиус может влиять на отключение абонента(дисконект сессии) ? )

Да может

 

 как? интересно без сарказма. ткните ссылкой или растолкуйте если есть время )

 

CоA и радиус вообще 

спасибо ) Но судя по всему у топикастера это не реализовано....

 

Да это у меня не реализовано. А вопрос еще такой если будет допустим флуд изнутри сети то каким видом трафика можно заставить mpd рвать сесии? Или это невозможно?

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

veca16 1

Опубліковано:
  • Автор
Опубліковано:

радиус может отдавать параметр Session-Timeout который будет рвать сессии через какое-то количество секунд

а этот параметр радиус должен отдавать каждой сесии или можно и одним запросом оборвать все сесии? И я пока не откидаю идею что ктото флудит в сети только немогу понять каким образом!

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

veca16 1

Опубліковано:
  • Автор
Опубліковано:

ок, спасибо попробую. Только что странно дисконекты случаются в основном после 1.00 чаще всего с 3.00 до 6.00 ночью, только один день был что пару раз днем случился дисконект, а то в основном под утро. Я думаю это дожно случаться когда мускул больше всего нагружен а ночью как раз в это время нагрузка минимальная! Может конечно я ошибаюсь!

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

veca16 1

Опубліковано:
  • Автор
Опубліковано:

да выхлоп всех трех на свич D-Link DGS3120-24SC, за свич тоже думал, просто у клиентов которые подключены мимо сервера по статике но через свич дисконектов нету, и мне странно что дисконекты случаются в основном под утро, когда нагрузка минимальная а свич если подглючивает то при максимальной нагрузке я так думаю.

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

John_Doe 301

Опубліковано:
Опубліковано:

Проведите простой експеримент остановите мускуль и подождите минутку

Если сессии отвалятся значит проблема в связке радиуса с базой

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

Такие вещи просто происходят или с подачи радиуса или нет аливе пакетов на мпд и он ложит сессии сам.

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

veca16 1

Опубліковано:
  • Автор
Опубліковано:

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

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

veca16 1

Опубліковано:
  • Автор
Опубліковано:

Проведите простой експеримент остановите мускуль и подождите минутку

Если сессии отвалятся значит проблема в связке радиуса с базой

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

Такие вещи просто происходят или с подачи радиуса или нет аливе пакетов на мпд и он ложит сессии сам.

Проверку на базу делал неоднократно только немного в другом виде, на насах вкидывались правила ipfw add 10 allow ip from any to any  и комп с базой полностью тушился на обслуживание гдето на полчаса на час, но все кто были приконекчены оставались с инетом и сесии не отваливались, а только новые клиенты не могли подключиться!

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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
 Share
Подписчики 1
Перейти до переліку тем

  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

×
×
  • Створити нове...