Menu
▾
▴
#66 Баг с множеством коннектов одного и того же клиента
Сегодня вечером словил странный глюк на следующей связке.
FreeBSD 11.2-RELEASE-p9
MPD version: 5.8
Клиенты подключаются по PPPOE.
Онлайна на машине в районе 1600 абонентов
Стали звонить под вечер клиенты с проблемой на неработающий интернет. Причем некоторые.
Стали разбираться
В результате выяснился странный глюк
[] show sessions ip 10.10.0.9
ng1865 10.10.0.9 C-1866 7956732-C-1866 vlan60-1137 1137 7956732-vlan60-1137 vova 54:e6:fc:fe:5d:53
ng2233 10.10.0.9 C-2234 7959914-C-2234 vlan60-2290 2290 7959914-vlan60-2290 vova 54:e6:fc:fe:5d:53
ng2151 10.10.0.9 C-2152 7960268-C-2152 vlan60-2298 2298 7960268-vlan60-2298 vova 54:e6:fc:fe:5d:53
ng2112 10.10.0.9 C-2113 7960073-C-2113 vlan60-2299 2299 7960073-vlan60-2299 vova 54:e6:fc:fe:5d:53
[] show sessions ip 10.10.51.184
ng1710 10.10.51.184 C-1711 7933915-C-1711 vlan63-468 468 7933915-vlan63-468 051184 00:30:67:f9:8b:87
ng608 10.10.51.184 C-609 7879576-C-609 vlan63-727 727 7879576-vlan63-727 051184 00:30:67:f9:8b:87
ng883 10.10.51.184 C-884 7933023-C-884 vlan63-1028 1028 7933023-vlan63-1028 051184 00:30:67:f9:8b:87
ng1071 10.10.51.184 C-1072 7932679-C-1072 vlan63-1177 1177 7932679-vlan63-1177 051184 00:30:67:f9:8b:87
ng1643 10.10.51.184 C-1644 7933515-C-1644 vlan63-1714 1714 7933515-vlan63-1714 051184 00:30:67:f9:8b:87
ng1671 10.10.51.184 C-1672 7928866-C-1672 vlan63-1751 1751 7928866-vlan63-1751 051184 00:30:67:f9:8b:87
ng1701 10.10.51.184 C-1702 7931011-C-1702 vlan63-1769 1769 7931011-vlan63-1769 051184 00:30:67:f9:8b:87
ng1709 10.10.51.184 C-1710 7932364-C-1710 vlan63-1777 1777 7932364-vlan63-1777 051184 00:30:67:f9:8b:87
ng2269 10.10.51.184 C-2270 7961076-C-2270 vlan63-2050 2050 7961076-vlan63-2050 051184 00:30:67:f9:8b:87
ng2229 10.10.51.184 C-2230 7960448-C-2230 vlan63-2273 2273 7960448-vlan63-2273 051184 00:30:67:f9:8b:87
ng1425 10.10.51.184 C-1426 7959795-C-1426 vlan63-2280 2280 7959795-vlan63-2280 051184 00:30:67:f9:8b:87
ng2216 10.10.51.184 C-2217 7960721-C-2217 vlan63-2287 2287 7960721-vlan63-2287 051184 00:30:67:f9:8b:87
ng2252 10.10.51.184 C-2253 7960944-C-2253 vlan63-2301 2301 7960944-vlan63-2301 051184 00:30:67:f9:8b:87
ng2236 10.10.51.184 C-2237 7960217-C-2237 vlan63-2302 2302 7960217-vlan63-2302 051184 00:30:67:f9:8b:87
ng2270 10.10.51.184 C-2271 7961240-C-2271 vlan63-2313 2313 7961240-vlan63-2313 051184 00:30:67:f9:8b:87
ng2248 10.10.51.184 C-2249 7960285-C-2249 vlan63-2318 2318 7960285-vlan63-2318 051184 00:30:67:f9:8b:87
ng1899 10.10.51.184 C-1900 7962171-C-1900 vlan63-2347 2347 7962171-vlan63-2347 051184 00:30:67:f9:8b:87
ng2299 10.10.51.184 C-2300 7962389-C-2300 vlan63-2363 2363 7962389-vlan63-2363 051184 00:30:67:f9:8b:87
ng194 10.10.51.184 C-195 7962428-C-195 vlan63-2373 2373 7962428-vlan63-2373 051184 00:30:67:f9:8b:87
ng2260 10.10.51.184 C-2261 7960890-C-2261 vlan63-2378 2378 7960890-vlan63-2378 051184 00:30:67:f9:8b:87
и так далее
Почему-то перестали удаляться старые неактивные сессии клиентов. Руками удаляю все сессии - клиент подключается и работает но я так думаю это до следующего реконнекта.
Вот конфиг мпд (может там что-то довписать надо, хотя конфиг переносится от сервака к серваку уже долгие годы)
pppoe_server:
create bundle template C
set bundle disable encryption
set bundle disable compression
set ccp disable mppc
set ipcp dns 8.8.8.8 1.1.1.1
set ipcp range a.b.c.d/32 0.0.0.0/0
set iface enable tcpmssfix
create link template oe pppoe
set link action bundle C
set link disable chap pap eap
set link enable pap chap
set link enable peer-as-calling
load radius
create link template vlan2 oe
set link max-children 1000
set pppoe iface vlan2
set pppoe service "*"
set link enable incoming
......
Почему мпд создает ng интерфейс с тем же ип если уже такой существует? Ну и почему не удаляются старые сессии?
Аналогичная схема работает годами на уйме серверов. Это впервые такой глюк
В вашей конфигурации сессиями рулит RADIUS-сервер, а не сам MPD. И авторизация создания сессии (как и отличение пользователей друг от друга), и назначение сессии адресов IP, и удаление сессии - ответственность RADIUS-сервера в данном случае.
В техническом смысле нет никаких препятствий созданию нескольких интефрейсов PPPoE с одинаковыми локальными IP, как вы уже и сами убедились. MPD может препятствовать подключению одного пользователя более одного раза, когда сам управляет сессиями по собственному списку логинов/паролей, но в вашем случае нужно разбираться с RADIUS/базой.
Теоретически также возможны проблемы и на стороне MPD, но без изучения его логов нет шансов их обнаружить.
Спасибо за ответы Евгений. Смотрите, данный сервер работал прекрасно в течении 3-х месяцев после запуска. Вчера вечером начались проблемы. Аналогичная установка (установка делалась на один жесткий диск с него делались копии на разные сервера) работает и дальше счастливо, просто на нем меньше онлайна. MPD должно тушить линки когда LCP запросы с них не возвращаются но почему-то этого не делает. Аналогичная схема настроена на уйме других серверов и разных версиях FreeBSD, за долгие годы никогда не было такой ошибки.
В логах ничего особого необычного нет.
Если есть подозрение, что MPD неправильно себя ведёт с LCP, то надо включать log +lcp +lcp2 и смотреть, что там с LCP Echo.
А то, что раньше проблем не было - ровно ничего не значит.
На всякий случай прошу поискать в логах MPD строчки с такими словами: "can't create" во время непосредственно перед началом проблемы. Если есть, показать.
Last edit: Eugene Grosbein 2019-09-09
Sep 8 02:18:07 shir mpd: NgFuncSendQuery: can't send message: No error: 0
Sep 8 02:18:07 shir mpd: [C-794] can't get stats, link=0: No error: 0
Единственное что нашел по "can't"
Проблема как раз началась вчера но клиенты стали звонит уже ближе к вечеру.
Но это только две строки в логе больше не было.
Этого достаточно и это причина проблемы скорее всего. Это баг в системной библиотеке libnetgraph. Он исправлен в 12.0 и новее. Для 11.x есть патч (библиотека в 11.x ничем не отличается), который пока туда не добавлен из-за недостатка тестирования. Применять так:
cd /usr/src/lib/libnetgraph
fetch -o libnetgraph.diff https://svnweb.freebsd.org/base/stable/12/lib/libnetgraph/msg.c?view=patch&r1=348827&r2=348826&pathrev=348827
patch -p4 < libnetgraph.diff
make obj depend && make all install
После этого перезагрузить систему для очистки структур netgraph в ядре, которые mpd5 сам почистить не сможет (можно обойтись без ребута, если вручную чистить при помощи ngctl). Но лучше совместить с обновлением до 11.3.
Сам mpd5 тоже очень желательно иметь версии как минимум 5.8_6, а лучше последней из портов.
Last edit: Eugene Grosbein 2019-09-09
Что-то не качает....
<title>ViewVC Exception</title>An Exception Has Occurred
Python Traceback
Можно прямую ссылку на файл?
Обновить на 11.3 сейчас нет возможности :(
Это и есть прямая ссылка на первоисточник. Firefox качает. Есть ещё ссылка на тот же патч из Bugzilla: https://bz-attachments.freebsd.org/attachment.cgi?id=200960
Только тогда прикладывать через patch -p3 вместо patch -p4
Забыл отметить, что URL нужно взять в одинарные кавычки (апострофы), так как внутри есть &, а это спец-символ и он завершает команду:
fetch -o libnetgraph.diff 'https://svnweb.freebsd.org/base/stable/12/lib/libnetgraph/msg.c?view=patch&r1=348827&r2=348826&pathrev=348827'
В 11.3 этот патч уже "запилен" и нет такой проблемы в библиотеке netgraph?
Да, в 11-STABLE этот патч уже есть
Но лучше ставить сразу 12-STABLE
Last edit: Dmitry S. Lukhtionov 2019-09-10
Патч на libnetgraph ещё не был смержен в 11-ю ветку, поэтому его нет ни в 11.3-RELEASE, ни пока в 11.3-STABLE и нужно прикладывать.
Сорри, я уже год как сижу на 12-й ветке, поэтому не в курсе.
Мне посоветовали поставить патч
https://reviews.freebsd.org/D12457
И пересобрать ядро. Вот пробую. Это может помочь?
Это против паники. Лучше обновить систему до 11.3, где все известные патчи на эту тему уже содержатся.
Исправлено в текущих версиях системы и mpd5.