MikroTik.by

CCR1036-8G-2S+ Используется как PPTP Server c simple queue (статистика собирается по Netflow). Прошивка 6.43.4 (stable).

При поднятии порядка 650-750 очередей (вне зависимости от нагрузки на сеть) CCR скидывает очереди в двое, начинаются потери пакетов, возрастает нагрузка на CPU (после отвала очередей держится в районе 40-50%). И так каждый раз при достижении значения ~700 очередей.
При работе ~550 очередей ведет себя отлично, CPU в максимальной нагрузке ~20%.

О каком трафике речь? 50% ЦПУ для машины с тридцатью шестью процессорными ядрами - это многовато... Tools -> Profile что показывает?

Что вы имеете в виду под "скидывает очереди в двое"?

Используются ли правила NAT Masquerade?

И что вы хотели показать двумя скриншотами логов? А то с наскоку я там ничего подозрительного не вижу.

Chupaka писал(а): ↑26 ноя 2018, 10:56 О каком трафике речь? 50% ЦПУ для машины с тридцатью шестью процессорными ядрами - это многовато... Tools -> Profile что показывает?

Что вы имеете в виду под "скидывает очереди в двое"?

Используются ли правила NAT Masquerade?

И что вы хотели показать двумя скриншотами логов? А то с наскоку я там ничего подозрительного не вижу.

1. Трафик я имел ввиду юзеров (Инет. PPTP поднят для доступа юзеров в Инет);
2. "Скидывает очереди вдвое" -> имел в виду то, что кол-во очередей = кол-во юзеров, когда поднимают VPN определенное кол-во юзеров (~750), часть сессий дисконектится. (Отключается VPN соединение).
3. NAT не используется.
4. По логам кроме дисконекта и нет ничего.

5. Обратили внимание, что management грузит одно ядро (были мысли грешить на Netflow)/

Под трафиком я имел в виду объём. Мегабиты в секунду, гигабиты?

Connection Tracking тоже выключен?

Management проверьте, когда все другие окошки в WinBox'е закрыты, мало ли...

В Firewall Mangle нет кучи динамических правил?

Chupaka писал(а): ↑26 ноя 2018, 13:16 Под трафиком я имел в виду объём. Мегабиты в секунду, гигабиты?

Connection Tracking тоже выключен?

Management проверьте, когда все другие окошки в WinBox'е закрыты, мало ли...

В Firewall Mangle нет кучи динамических правил?

1. Пока, на тесте, ~550/~250Мбит/сек (через SFP+) в пике, обычно ~250/150;
2. Connection Tracking - auto;
3. Да так и делал (от 50% до 85%) выдает.
4. Mangle - пустой

> 2. Connection Tracking - auto;

Так он авто включен или авто выключен? В самом Connection Tracking записи есть или пусто? Если есть - оно там надо? Для чего?

Chupaka писал(а): ↑26 ноя 2018, 13:41 > 2. Connection Tracking - auto;

Так он авто включен или авто выключен? В самом Connection Tracking записи есть или пусто? Если есть - оно там надо? Для чего?

Включен и есть записи. Используется, для отслеживания должников. Для работы dst-nat (в теории можно реализовать и без него).

Попробуйте выключить или добавьте в RAW правило NOTRACK для трафика, который не dst-nat'ится, проверить, не в нём ли дело.

Chupaka писал(а): ↑26 ноя 2018, 16:50 Попробуйте выключить или добавьте в RAW правило NOTRACK для трафика, который не dst-nat'ится, проверить, не в нём ли дело.

Отключили Connection Tracking (т.к. можно обойтись без него), пока что 1120 очередей, при загрузке CPU от 7% до 23%.
Будем смотреть в течении дня, как начнут узеры более активно пользоваться Интернетом + проверим ночью сколько может еще держать.

UDP: Максимум ~1770 юзеров подключилось (по нагрузке нормально ему было), но больше уже не нагружали.

Ну, я бы сказал, нормальный результат для PPTP Сами, помню, сражались с ним (на платформе x86). Доходило до смешного: абонентов перенастраивали с PPTP на L2TP (на тот же сервер), потому что он нормально работал и пинги ниже выдавал

Chupaka писал(а): ↑30 ноя 2018, 17:40 Ну, я бы сказал, нормальный результат для PPTP Сами, помню, сражались с ним (на платформе x86). Доходило до смешного: абонентов перенастраивали с PPTP на L2TP (на тот же сервер), потому что он нормально работал и пинги ниже выдавал

На x86 замечал потери пакетов, появляющиеся в любое время, но чаще в определенное; да и более 1000 очередей сносили ему крышу.
А CCRка ~2500 и по нагрузке еще столько же, минимум, потянула бы.

Пытались с L2TP, но так же были свои проблемы на x86. Хотя x86 и есть одна большая проблема)

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

Начиная с 6.43.x балуюсь с каждой прошивкой То переключаю на l2tp, то на pptp, иногда и на sstp приходится. Иначе никак

да блин у нас то pppoe...