Периодическая потеря связи у юзеров

[chtito2]

Видел, думаю нет. У чела там есть симптомы:

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

и

на выводе ifconfig на те ip у которых не идет выход наружу
по нескольку ppp интерфейсов...

а у нас пока удалось собрать только жалобы Т.е. мы даже проблему не нашли. Точнее я в биллинге/радиусе/фрибсд не нашел, а нетворк гай - в кисках и сетях.

У нас проблема проявляется даже при 20-30 в онлайн.

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

[chtito2]

Единственное что: вещь в логах на которую я не обращал внимания т.к. она сопровождает _каждый_ запрос, а проблемы не сразу и не у всех:

rlm_perl: ERROR: Failed to create pair FRAMED_PROTOCOL = PPP
rlm_perl: ERROR: Failed to create pair SERVICE_TYPE = Framed-User
rlm_perl: ERROR: Failed to create pair CISCO_NAS_PORT = 2/0/0/12
rlm_perl: ERROR: Failed to create pair NAS_PORT_TYPE = Virtual
rlm_perl: ERROR: Failed to create pair NAS_PORT = 0
rlm_perl: ERROR: Failed to create pair CALLING_STATION_ID = 0017.9axx.xxxx
rlm_perl: ERROR: Failed to create pair USER_NAME = xxx
rlm_perl: ERROR: Failed to create pair CISCO_AVPAIR = client-mac-address=0017.9axx.xxxx
rlm_perl: ERROR: Failed to create pair USER_PASSWORD = xxx
rlm_perl: ERROR: Failed to create pair NAS_IP_ADDRESS = 10.10.70.100

и так далее и так далее. Может быть это? По указанным выше причинам ошибка имхо безобидная поэтому я не занялся ее решением.

[ran]

Видел, думаю нет. У чела там есть симптомы

та чё там думать... посмотреть на наличие дубликатных ип на туннелях киски кокгда начинается лажа - не?

[chtito2]

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

[ran]

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

если ещё и учесть, что ты там сам чевось ковырял... и если мне не изменяет мой склероз - как раз с адресами...

[chtito2]

А чего? Там все просто. По умолчанию как занятые считаются адреса в таблице онлайнов (dv_calls) и обработчик авторизации вычитывает их когда решает какой адрес дать юзеру. Я своими изменениями не сократил, а _увеличил_ список занятых адресов, пометив как занятые еще и только что освобожденные (не больше чем на минуту, после чего они рисайклятся). Простыми словами юзеру выдается максимум то же самое что и раньше.

[chtito2]

У меня такой глупый вопрос к Асмодеусу: я посмотрел в коде всю цепочку принятия запроса и далее к функции dv_auth (в Abills/mysql/Auth.pm) и get_ip() выделяющей новый IP пользователю: нигде нет намека на локинг. Где защита от совместного доступа или хотя бы документование этого риска? Это значит, что если два пакета авторизации придут одновременно, клиенты могут получить один и тот же айпи? Проясните пожалуйста.

p.s.: жалобы юзеров, описанные в этой теме бывают даже при radiusd -X (когда в одном потоке выполняется), так что описанная проблема не из-за отсутствия синхронизации доступа. Но в будущем вполне может быть.

[ran]

я посмотрел в коде всю цепочку принятия запроса и далее к функции dv_auth (в Abills/mysql/Auth.pm) и get_ip() выделяющей новый IP пользователю: нигде нет намека на локинг.

если это действительно так - Автору есть информация к размышлению

[chtito2]

Кажется автор снова забил на баг Ничего, сами полочим.

Тем временем проблема описанная в теме все еще стоит. На днях попробуем промониторить киско на предмет дублированных айпишников.

[chtito2]

Насчет багфикса на предмет дублированных IP оказалось чуть сложнее, чем хотелось бы: IP отмечается как занятый только при RADIUS Start пакете, а ради этого фикса отмечать в Auth выданный IP где-нибудь как занятый до прихода Start'а мне лень (хотя... когда я буду в лучшем настроении духа может и суну их в уже созданную ради корректного подсчет трафика Ipn таблицу dirty_ip, ведь ее цель идеально подходит под текущую проблему: она хранит IP, которые нельзя выдывать новым юзерам. Впрочем, без локинга мне в get_ip() все равно не обойтись...). А пока что НАСТОЯТЕЛЬНО рекомендую всем внести некоторые коррективы в конфиг радиуса, пускай и засчет потенциально более медленного обслуживания запросов:

start_servers = 1
max_servers = 1
min_spare_servers = 0
max_spare_servers = 1
max_requests_per_server = 0

Еще можно конфиг оставить как есть, и просто запускать radiusd с параметром -s (single-server mode). Кому как комфортней.

[ran]

Еще можно конфиг оставить как есть, и просто запускать radiusd с параметром -s (single-server mode). Кому как комфортней.

а мне комфортней статические ипы назначать, при этом запускать радиус многопоточно и не лезть в весь этот маргарин

[chtito2]

Вы же прекрасно знаете, что выделение всем статики IPv4 ужасно масштабируется с ростом клиентов, но все равно засорили тему Просьба не флудить! Давайте придержимся темы.

[ran]

Вы же прекрасно знаете, что выделение всем статики IPv4 ужасно масштабируется с ростом клиентов

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

Просьба не флудить! Давайте придержимся темы.

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

На днях попробуем промониторить киско на предмет дублированных айпишников

та зачем так спешить? месяц туды - месяц сюды...

[chtito2]

Дык не все от меня или моих желаний зависит Командный дух и п.х.

прекрасно масштабируется...

Значит мы о разном говорим Дай бог у вас когда-нибудь будет свыше тысячи абонентов и тогда вы осознаете, что а) раздавать всем статику неграмотно, учитывая что в онлайне обычно не больше половины абонентов, у этих адресов есть лучшее применение; и что эту фичу можно продавать отдельно по желанию клиента; б) с бесплатными rfc-шными (левыми, серыми, занатенными, нужное подчеркнуть) адресами, коих мильён, каждый второй клиент будет жаловаться на то, что у него не работают какие-то сервисы или что его забанили на каком-нибудь сайте. Продолжать бессмысленно

[ran]

Продолжать бессмысленно

конечно бессмысленно... потому что:

1. те, кому это действительно надо, могут без проблем:
а) арендовать у меня статический публичный адрес или подсеть нужного размера;
б) сделать то же самое у кого им больше нравится - для этого существует динамическая маршрутизация.

2. все остальные получат приватные, но статические адреса, потому как раздавать всем поголовно публичные - это маразм

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

если у админа рутера на котором всё маскарадится голова и руки растут откуда надо - не будет

или что его забанили на каком-нибудь сайте

Вау! а если забанят ип из твоего динамического пула - тада как? Кому повезёт? Смею тебя заверить - в этом случае по прошествии нек времени у тебя будет забанен весь пул Не веришь? К сведению - 90% динамического пула укртелекома - давно в блэклистах каких только можно серверов