abills.net.ua

Когда Cisco включается и сотни PPPoE пользователей пытаются авторизоваться через RADIUS сервер, в логе последнего сыпется шторм ошибок вроде этих:

Thu Nov 27 12:44:06 2008 : Error: Received conflicting packet from client x.y.31.1 port 1646 - ID: 93 due to unfinished request 54538. Giving up on old request.
Thu Nov 27 12:44:06 2008 : Error: Received conflicting packet from client x.y.31.1 port 1646 - ID: 96 due to unfinished request 54541. Giving up on old request.
Thu Nov 27 12:44:06 2008 : Error: Received conflicting packet from client x.y.31.1 port 1646 - ID: 97 due to unfinished request 54542. Giving up on old request.
Thu Nov 27 12:44:06 2008 : Error: Received conflicting packet from client x.y.31.1 port 1646 - ID: 101 due to unfinished request 54545. Giving up on old request.

и их сотни за 2-3 секунды. В результате многие каким-то образом получают дублированные адреса, многие пользователи садятся в онлайн с IP адресом, отличным от зарегистрированного в таблице онлайнов Абиллса, а некоторых сидящих пользователей вобще нет в таблице. Вобщем кошмар. Кто реально сталкивался с таким и знает, как побороть? Может как-то перенастроить Cisco IOS?

Замечу, что в рутинных условиях ошибка не появляется. Методом тыка установлено, что она возникает в двух случаях: а) перезагрузка Cisco, влечащая за собой одновременный заход сотен pppoe клиентов; б) кик всех сидящих (командой clear pppoe sess all) с их последующим заходом. Как было установлено CPU на Cisco в таких случаях бывает загружен на 100%.

Методом тыка установлено всё правильно, оно так и получается.
Радиус и авторизационные скрипты неуспевают за наплывом клиентов.

Варианта решения 2:
1. (Зависит от топологии сети) Выключить порты на центральном каталисте и поэтапно включать, дабы юзеры не ломились одновременно все.
2. Тупо ждать пока оно устаканится, я выбираю этот вариант.

1. (Зависит от топологии сети) Выключить порты на центральном каталисте и поэтапно включать, дабы юзеры не ломились одновременно все.

Это вариант, но очень через одно место. Вланов у нас больше 50-ти. Тем более в момент аварии как правило никого не бывает рядом.

Я вот что думаю: может можно какие-то таймауты увеличить на радиус клиенте, чтобы подождал ответа хотя бы 5 секунд перед тем, как попытаться заново? Есть здесь цисководы?

2. Тупо ждать пока оно устаканится, я выбираю этот вариант.

Телефоны саппорта разрываются, здесь тупо не подождешь. Вот, наваял скриптик для ускорения получения юзерами уникальных айпи. Логика такая: юзер все равно потычется и перезагрузит модем + комп, перед этим позвонив и обругав сапппорт на чем свет стоит. Так почему бы им не помочь получить новый адрес побыстрей? Для работы требует на cisco IOS включенных сервисов finger на 79 и pod server на 1700 порту. Алгоритм таков:

Для начала в пункте 0 узнаем кол-во дублированных айпей:
0) nc 10.11.12.13 79 | awk '{print $5}' | sort | uniq -c | awk '$1 > 1' | wc -l
Получаем количество дублированных IP.

Кикаем обидчиков, используя POD:
1) n=12; nc 10.11.12.13 79 | awk '{print $5}' | sort | uniq -c | sort -k1,1 -n -r | head -n $n | awk '{print $2}' | while read ip; do echo "Framed-IP-Address = $ip" | radclient -d /usr/local/share/freeradius -t3 -r3 10.11.12.13:1700 disconnect 'MyCoolSecret'; done; unset n
вместо 12 просто пишем число, полученное в 0-м пункте (например, 12 .
вместо MyCoolSecret просто пишем username для радиус POD.

2) Идем на пункт 0-й и продолжаем цикл, пока дубли не исчезнут.

3) не судите строго, было написано быстро быстро пока юзеры шумели под ухом

4. а) правильно планируем и строим топологию сети в соответствии с предъявлямыми требованиями (необходимое количество и типы NAS и их месторасположение, необходимое количество серверов авторизации и их месторасположение etc)
б) забиваем на это и выбираем

2. Тупо ждать пока оно устаканится, я выбираю этот вариант.

ну можно ещё на время устаканивания автоматизировать отключение телефонов саппорта

чьтито2 писал(а):Увеличили radius-server timeout 40, как-нибудь проверим в этом ли было дело.

Так и есть. Теперь после кика ок. 700 онлайн юзеров дублированных IP было всего 7-8 (т.е. проблемы были у 2-3% сидящих) и стало допустимым оставить проблему решаться самой собой.