+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

CAPSMAN разрывает соединение с интерфейсами, которые время от времени работают только в верхнем регистре.

CAPSMAN разрывает соединение с интерфейсами, которые время от времени работают только в верхнем регистре., RouterOS

Gunpowder

Guest

12.03.2016 07:17:00

У меня есть контроллер CAPSMAN, работающий на CCR1036-12G. Подключено до 324 клиентов на 74 беспроводных интерфейсах. Большинство — это CRS Desktop Switches, использующие диапазон 2.4 ГГц. Периодически все интерфейсы caps из таблицы регистрации отключают всех моих клиентов. Через пару минут все клиенты снова подключаются. Это очень неприятная ситуация. Я использую версию v6.33.5. В логах показан только процесс отключения. Пожалуйста, подскажите, что это может быть?

georchri Guest	#2 0 05.07.2016 15:26:00 Та же проблема с настройкой Layer 2 Caps: много раз в день все капы отключаются и снова подключаются на CCR1016 с 180 удалёнными капами. Есть идеи???

bimowidhi Guest	#3 0 26.07.2016 09:13:00 Всем привет, у вас уже есть решения? Потому что у нас здесь такая же проблема.

drpater

Guest

13.09.2016 14:37:00

Похоже, CAPsMAN — одно поточное приложение, поэтому при высокой скорости подключения-отключения нагрузка ложится на производительность одного ядра. Вот два способа избежать отключений CAP: поднять частоту одного ядра — использовать 3011 или CHR в роли одного контроллера. Настроить несколько контроллеров: 2011 может обслуживать 300–400 одновременных подключений, CCR (использует одно ядро, подходит любая модель) с частотой 1200 МГц — 300–700 подключений, в зависимости от скорости подключения и отключения. Остаётся ждать, когда Mikrotik(и) добавят многопоточную поддержку Manager (чтобы события CAP-интерфейсов распределялись по ядрам), или дадут возможность настроить несколько экземпляров Manager на одной плате для нагрузки на несколько ядер)))

liaotiaozi

Guest

22.09.2017 10:56:00

У меня была такая же проблема. Я использовал 1036 для управления 220 CAP, и CAPsMAN зависал и перезагружался. Мое временное решение — добавить 1016 для управления второй половиной CAP, и тогда всё работает нормально. Если это действительно так, стоит попробовать на X86. Но надеюсь, что MT сможет дать мне объяснение, потому что сложно принять такие сбои от продуктов, которым я так доверяю.

petterg Guest	#6 0 23.09.2017 15:35:00 Возможно, это проблема с конфигурацией ®STP?

liaotiaozi Guest	#7 0 24.09.2017 11:16:00 Я выключил ® STP, а потом включил — бесполезно, но с двумя CCR управление может работать нормально.

petterg

Guest

24.09.2017 11:47:00

Возможно, в вашей сети есть компьютер, на котором мостом связаны Wi-Fi и проводные сетевые интерфейсы? Когда этот пользователь подключает свой ноутбук к проводной сети, возникает петля, из-за чего всё на какое-то время перестаёт работать, включая ваше соединение с CAPS через CAPSMAN.

liaotiaozi

Guest

25.09.2017 14:58:00

Возможно? CAPsMAN настроен так, чтобы установить изоляцию пользователей и изоляцию в настройках моста, поэтому сложно создать петлю. Также есть STP, так что даже если произойдет переподключение с петлей, переключатель не зависнет, потому что я тоже делаю изоляцию переключателя. Так что…

petterg Guest	#10 0 26.09.2017 20:32:00 Думаю, можно подключить устройство, которое создаст петлю. Попробуй в разных местах вашей сети. Если из-за этого ваши коммутаторы отключатся, возможно, это будет полезной зацепкой.

liaotiaozi Guest	#11 0 28.09.2017 17:23:00 Я сам проверил петлю, но ничего не произошло.

liaotiaozi Guest	#12 0 28.09.2017 17:24:00 Если это цикл, почему тогда для меня нормально использовать два CCR?

anuser Guest	#13 0 16.01.2018 19:35:00 Похоже, у меня такие же проблемы. Ты нашёл решение?

uldis

Guest

#14

17.01.2018 08:40:00

Какая у вас конкретно проблема? Мы уже исправили это в последних версиях 6.42RC, где интерфейсы CAP удалялись и добавлялись заново, если связь пропадала и пыталась восстановиться для нескольких CAP одновременно.

anuser

Guest

#15

17.01.2018 17:12:00

Давайте посмотрим на контроллер: это происходит время от времени, иногда через несколько часов, снова и снова со всеми моими точками доступа (текущие версии 6.41), сеть работает нормально. Моё предположение — новая реализация моста с версии 6.41 на точках доступа — проблема, из-за которой контроллер разрывает соединение со всеми точками доступа за считанные секунды.

При проверке некоторых точек доступа я нашёл странные настройки: даже после перезагрузки и отключения одной из них появлялись «призрачные» настройки, например, в интерфейсах старые записи «dynamic wlan», хотя клиентов не было, а в списке /interface появлялись «dynamic» записи без интерфейсов. Возможно, я слишком часто обновлял и откатывал версии этих точек доступа между 6.39.*, 6.40.* и 6.41 в прошлом…

mdinisoae

Guest

#16

31.12.2020 22:02:00

У меня была такая же проблема с cAP Gi-5acD2nD и RouteOS 6.46.7 / 6.46.8: «CAP sent max keepalives without response», «CAP failed to join CRS210 (XX:XX:XX:XX:XX:XX/10//0)». В свойствах моста на вкладке STP в опции «Protocol Mode» было установлено «None». После полного отключения питания я перезагрузил CAP и переключил режим протокола на «STP». Теперь оба CAP работают стабильно.

amcrs Guest	#17 0 27.05.2022 05:41:00 Нашёл это, когда пытался решить свою проблему. У меня тоже были «призрачные» записи wlan на мосту, которые появились ещё до того, как я настроил capsman. Capsman создавал новые дополнительные записи wlan на мосту, в то время как старые «неизвестные» записи с периодом capsman так и остались на мосту. Удаление этих неизвестных записей с моста и последующая перезагрузка hAPac (в моём случае) остановили бесконечный поток предупреждений в логах с сообщением «CAP sent max keepalives without response». 6.49.6

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры