RB1000 закрывает десятки PPPoE-соединений одновременно.

Пир не отвечает с десятками PPPoE-сессий, и иногда все сессии, которые периодически отключаются, всё ещё вызывают у меня проблемы. Я однажды видел это вживую: было около 100 подключенных пользователей, и вдруг все отключились с упоминанием в логе “Terminating… disconnected”. PPPoe-сервис сошёл с ума... коллапс, RB оставался в живых. Затем прошло около 30 секунд, прежде чем все снова подключились. У меня эта проблема может возникать три раза в день или раз в неделю, зависит от чего-то, чего я не знаю, и это очень раздражает. Клиенты жалуются, у меня примерно 250 пользователей на RB1000. Сначала думал, что это проблема моста, поэтому разделил PPPoE-сервис через Ethernet-интерфейс, но проблема осталась. Поискал на форуме, но ничего не нашёл. Кто-нибудь нашёл решение или придётся переходить на другое решение, отличное от Mikrotik?
С уважением.

Лучший способ решить эту проблему — свяжитесь со службой поддержки (support@mikrotik.com) и подробно опишите проблему.

Нашёл это (http://forum.mikrotik.com/t/routeros-radius-client-timeout-pppoe-pcq/34479/1). Удалил всё, что касалось PCQ, в моих очередях, и вроде как всё в порядке уже 24 часа. Надеюсь, так и будет. Но комбинацию PCQ и PPPoE стоит пересмотреть производителям Mikrotik.

Тут та же проблема. У нас около 100 пользователей на RB1000 PPPoE сервере. Все сессии отключаются одновременно. RB1000 подключен к двум провайдерам через два разных PPPoE соединения, тоже. И PPPoE сессии на аплинках отключаются время от времени. Две недели всё было нормально, никаких отключений – а сегодня все PPPoE сессии (входящие и исходящие) пропали в течение 3 часов. Это ужасно… 100 пользователей находятся на одном физическом интерфейсе и разделены между двумя VLAN. Каждая из двух PPPoE сессий на аплинках проходит через отдельный физический интерфейс. Мы перепробовали каждую прошивку от 3.22 до 4.6. Тот же самый результат… мы даже полностью заменили RB1000, но безрезультатно.

Как и советовал SergeJS, я открыл заявку @mikrotik. После изучения моего supout-файла, их рекомендация была: заменить все твои правила динамического изменения mss одним глобальным правилом изменения mss. Убедись, что ты используешь последнюю версию Winbox loader (очисти кэш после обновления). Подумай о переходе от динамических простых очередей к динамическим спискам адресов и деревьям очередей с PCQ. #1 было относительно легко сделать. #2 я сделал, как просили. Пока что проблема сохраняется, я даже попробовал распределить пользователей между двумя RB, примерно 100+ на 600 и 180+ остались в RB1000. Реже, но обе RB имели массовые отключения. #3 я не понимаю, что от меня требуется. У меня сотни пользователей, и я полагаюсь на RADIUS для передачи параметров полосы пропускания клиентов PPPoE concentrators. Могу ли я передавать список адресов вместо атрибутов “Mikrotik-Rate-Limit”? Как это сделать? Есть “Mikrotik-Mark-Id”. Это для этого? Если да, то как его использовать? Спасибо. Хавьер

У меня та же проблема с x86, частично решилось, если отключить простые очереди. Можно также обратиться в поддержку Mikrotik, если вы приобрели лицензию у стороннего поставщика.

Что это? Где его настраивать? Спасибо, Хавьер.

Сергей, я уже несколько раз обращался в поддержку… последний совет был обновить до 5.0 beta. Но я боюсь это делать, так как роутербоард находится в рабочей сети, обслуживающей около 120 PPPoE-клиентов. Поразмыслив, мои последние мысли вчера были, использует ли кто-нибудь, у кого есть эта проблема, внешний RADIUS-сервер? Если это так, думаю, большинство пользователей будут использовать FreeRADIUS (как и мы). Конфигурация FreeRADIUS по умолчанию гласит следующее: # max_requests: Максимальное количество запросов, которое отслеживает сервер. Это должно быть 256, умноженное на количество клиентов. # Например, при 4 клиентах это число должно составлять 1024. # Если это число слишком низкое, то когда сервер станет загруженным, # он не будет отвечать на новые запросы, пока не пройдет время 'cleanup_delay' # и он не удалит старые запросы. # Если это число установлено слишком высоким, то сервер будет использовать немного больше # памяти без реальной выгоды. # Если вы не уверены, какое значение ему присвоить, лучше установить его # слишком высоким, чем слишком низким. Установка его на 1000 на клиента, вероятно, # является самым высоким значением, которое следует использовать. # Полезный диапазон значений: 256 до бесконечности max_requests = 1024 Возможно, вместе с промежуточными обновлениями это значение может быть слишком низким… возможно, это связано с проблемой. Но в моем случае с примерно 120 PPPoE-клиентами и примерно 4 SIP-аккаунтами на клиента это может привести к 600 одновременных запросов (в худшем случае). Что касается этого, возможно, это не имеет никакого отношения к обрывам соединений… просто мои два цента… EDIT: Иногда у нас бывают brute-force атаки примерно по 500 запросов в секунду против наших SIP-шлюзов… и каждая попытка регистрации/входа также приводит к RADIUS-запросу. Теперь выше становится более разумным… Итак, главный вопрос: Обрывает ли PPPoE-сервер на MikroTik соединения, если есть таймауты в промежуточных обновлениях…? EDIT: Ок, несколько минут назад - все мои PPPoE-сессии пропали снова… поэтому в этот раз я проверил все логи - нет brute force или чего-то подобного, приводящего к DoS на RADIUS-сервере. Так что это, должно быть, другая проблема…