MikroTik + UTM

Cupitor

А у меня на 5.20 проблема осталась. Причем не такая как на 5.18 На ней мог зайти в консоль но команды автоматом не исполнялись. А на 5.20 происходит как бы затык при первоначальном массовом добавлении команд. Если не делать массового добавления все как бы работает. Проверьте у себя.

Point · Сообщение **Point** » Вт сен 04, 2012 06:04

да, действительно, в 5.18/19/20 при отправке большого количества команд SSH отваливается

. В 5.17 такой проблемы не наблюдаю. Надо пинать разрабов МТ.

Cupitor

Пинаю http://forum.mikrotik.com/viewtopic.php?f=2&t=65239
Тишина. Напишите и вы пост может если увидят что проблема существует не единичная что-нибудь сделают.

Point · Сообщение **Point** » Вт сен 04, 2012 12:25

Надо траблтикет поднимать по данной проблеме. к сожалению все nas-ы сейчас в работе и supout.rif снять нет возможности.

Point · Сообщение **Point** » Чт сен 06, 2012 12:14

по данной проблеме в саппорте микротика поднят тикет: [Ticket#2012090566000507] фризинг SSH сессии в MT ROS 5.18/5.19/5.20

вот что ответил саппорт:

connect to router using winbox (as you have already done as can be seen in forum
screenshots) and check if you have all the packages from same version, if you have
some older/newer packages installed - disable/uninstall them, and the reinstall
corresponding package on the router. Best way to do that is - upload all the
required packages and then reboot or run /system package downgrade command.

Only record we have for this problem is that conflicting packages are used, so
please try that out and then we will check further.

Regards,
Janis Krumins

Соответственно старых пакетов после апгрейда МТ у меня нет.

жаждующих прошу присоединиться к пинанию разработчиков MT по данной проблеме

saint_oloff

Sederik писал(а):У меня на винде пишет
FWCntl: Error executing FW rule, errcode = 2

конф

rfw_name=127.0.0.1
core_host=127.0.0.1
core_port=12758
rfw_login=init
rfw_password=init
firewall_type=local
firewall_path=ssh UTM@10.1.2.2
log_level=3
log_file_main=log\rfw.log
log_file_debug=log\rfw.log
log_file_critical=log\rfw.log
-- пробывал уже и так
(firewall_path=c:\windows\plink.exe -ssh UTM@10.1.2.2 )
и по другому

ЧТО Делать, помогите !!!!

Добрый день! Подскажите как решился вопрос по данной теме...

Point · Сообщение **Point** » Пт янв 25, 2013 08:15

похоже никто не хочет экспериментировать на живых хомячках...
у меня работает на 5.15/5.17, большего вроде не надо.

ukilan · Сообщение **ukilan** » Вт апр 02, 2013 22:11

Может поднять тему.
Решил разбавить серверную микротиками.
Queue tree & types
В принципе всё работает. Но может кто поделиться своими наработками, так сказать опробованные "годами"?

doctoraugust

ukilan писал(а):Может поднять тему.
Решил разбавить серверную микротиками.
Queue tree & types
В принципе всё работает. Но может кто поделиться своими наработками, так сказать опробованные "годами"?

Была данная проблема, частично ее решили.
Дело все в том что микротик разные команды выполняет за разное время (это понятно), а команды ему отсылались без ожидания выполнения. У нас УТМ стоит на винде, написал для него демона, который через консольную утилиту формировал очередь команд для микротика, и уже демон следил за точной очередностью выполнения команд и следил за отваливанием SSH. Но в итоге при обслуживании более ~ 500 клиентов, вылазили разного рода проблемы, зависания роутера. Понимаю, что данная связка все-таки лучше работает под линуксом, но выбора не имею. Окончательно реализовали свой функционал по шейпированию через передачу с радиус атрибутами микротику названия пула клиентов, и на самом микротике все остальное. Клиентов раз в сутки разрываем, трафик не тарифицируем.

Была идея управления микротиком через SNMP, но не все реализуемо, у микротика также есть какой-то управляющий протокол, можно реализовать через него.
Вот что я нашел:
http://yadi.sk/d/4rAy41lm3kkE4

ukilan · Сообщение **ukilan** » Пт апр 05, 2013 18:33

Меня больше интересуют правила firewall, mangle и PCQ
Управление МТ вполне через ssh

Point · Сообщение **Point** » Чт ноя 28, 2013 10:21

Point писал(а):похоже никто не хочет экспериментировать на живых хомячках...
у меня работает на 5.15/5.17, большего вроде не надо.

Вновь взялся за данную проблему, потому как много воды утекло (много версий поменялось)...

вроде как решилась эта проблема следующим образом:
на микротике выполняем команду /ip ssh regenerate-host-key, в результате чего генерится новый ключ хоста, перезагружаем MT.
На биллинге удаляем старый ключ (лежит в файле /root/ssh/known_hosts), заходим на микротик по ssh (ssh user@ip_mt), отвечаем yes на вопрос сохранения ключика, выходим с микротика и получаем вновь работающую систему с MT>5.17
проверено на тестовом стенде, пробую перенести на один из серверов доступа на живых хомячков...

UPD
MT V6.6 трое суток, полет нормальный