HawK

На OVPN сервере должен быть маршрут 192.168.1.2 с шлюзом 10.8.0.6. На MikroTik в firewall не должно быть правил запрещающих этот проходящий трафик.

В общем виде это должно быть организовано примерно так:
- Поднят и функционирует туннель между роутерами;
- Поверх туннеля на обоих концах поднят EoIP-туннель;
- Локальные интерейсы и EoIP туннели объединяются в bridge на каждом роутере;
- Настраивается 2 DHCP-сервера на обоих роутерах, в качестве интерфейса DHCP нужно указать ваш bridge-интерфейс. DHCP network должна быть единой 192.168.0.0/16 в вашем случае указана в настройках обоих DHCP-серверов, а вот диапазоны (pool) выдачи адресов должны быть непересекающимися, входящие в обозначенную подсеть. Например, 192.168.0.2-192.168.0.255 на одном роутере и 192.168.1.2-192.168.1.255 на втором, в вашем случае.
- Создавать один DHCP на локальную и удаленную подсеть неправильно и опрометчиво - в случае разрыва туннеля между роутерами - на стороне, где нет DHCP истекут сроки аренды, со всеми вытекающими.
- Лишний broadcast можно заблокировать с помощью /interface bridge filter.
- Обязательно нужно создать правило, блокирующее DHCP-запросы между удаленными сетями, например так:
/interface bribge filter
add action=drop chain=forward comment="Drop DHCP requests over EoIP bridge" disabled=no in-interface=eoip-tunnel1 ip-protocol=udp mac-protocol=ip src-port=68

Таким способом можно объединить и больше чем две удаленные сети, выстраивая оптимальную топологию. Работает без проблем, щироковещательный трафик незначительный.

P.S. Вместо EoIP-туннеля предпочтительнее использовать VPLS. В своих настройках отталкивался от презентации Дмитрия Кузнецова, на деле все оказалось немного проще, приведу отличия моих настроек:
- Необходимо настроить маршрутизацию между удаленными интерфейсами lo, при этом в качестве шлюза на стороне впн-сервера предпочтительнее указать remote address впн-клиента, а не сам впн-интерфейс, либо создать bind для впн-клиента, чтобы в маршруте интерфейс не заменялся на unknow при переподключении.
- В список LDP-интерфейсов достаточно добавить только "пустые" bridge, впн-интерфейсы добавлять не нужно.

После перехода на VPLS заметил некоторое "оживление" сети и прирост максимальной скорости при скачивании файлов.

Ваша задача с помощью RouterOS решается очень просто без использования скриптов.
В настройках интерфейсов ISP нужно убрать автоназначение маршрута по-умолчанию (add default route), вместо них создайте вручную маршруты по-умолчанию с маршрутными метками (routing mark). Для маршрута к ISP1 метку можно не указывать (по-умолчанию используется метка "main", которая не отображается). Для маршрута ISP2 укажите, например, routing mark = isp2.
Для того чтобы трафик LAN2 пошел через маршрут с меткой isp2 - нужно добавить правило маршрутизации:
/ip route rule
add action=lookup disabled=no src-address=192.168.88.0/24 table=isp2.
Для резервирования канала ISP2 для LAN1 - добавьте еще один маршрут по-умолчанию, указав в качестве gateway шлюз ISP2 и указав значение distance большее чем в основных маршрутах (по-умолчанию distance=1). Для резервирования ISP1 для LAN2 - дополнительных настроек не нужно, трафик пойдет через основной маршрут по-умолчанию, в случае недоступности маршрута по метке, указанной в /ip route rules.
Этих настроек достаточно для решения вашей задачи, но резервирование будет работать только в случае, если соответствующий шлюз окажется недоступен. Для более глубокой проверки канала на доступность интернета настройте рекурсивную маршрутизацию, это подробно описано в презентации Александра Романова.
Также должны быть настроены соответствующие правила маскарадинга в /ip firewall nat.

Можно написать отдельный скрипт, но проще в netwatch настроить дополнительную проверку. Для повышения точности проверки доступности интернета, для исключения ложных переключений, например, при возможных проблемах на опрашиваемой стороне или кратковременных сбоях в сети, потерянных пакетах и т.п. — используется 2 независимых проверочных адреса (можно использовать адреса различных публичных dns, например Google и Yandex) — x.x.x.x и y.y.y.y Адрес x.x.x.x — указывается в настройках хоста Netwatch, если пинга нет — начинает работать «down», который делает 5 попыток пинга к y.y.y.y и если все 5 попыток также неудачны — скрипт продолжает работу и активирует/деактивирует маршруты в соответствии с comments в таблицах маршрутизации. Первая удачная попытка прерывает дальнейшее выполнение скрипта, при этом никаких изменений маршрутов или других действий не происходит. К этим проверочным ип-адресам прописаны статические маршруты через шлюзы соответствующих провайдеров, а в фаерволе добавлены правила, запрещающие исходящий пинг на эти адреса через другие интерфейсы.
В скрипт добавлен вывод сообщений в лог, а также отправка СМС с информацией о том с каким провайдером и в какое время возникла проблема. Отправка СМС реализована с помощью сайта sms.ru.
api_id=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX — уникальный id — выдаваемый при регистрации на sms.ru
to=79********* — номер телефона, на который осуществляется отправка СМС. Если в качестве номера указывается тот же, что и при регистрации на сайте — 5 СМС в сутки бесплатно.
Вот мой вариант конфига:

«down»:

/log warning "server x.x.x.x fail…"
:local time [/sys clock get time]
:local checkip [/ping y.y.y.y count=5]
:if (checkip = 0) do={
/log error «ISP1 IS DOWN»
/ip route set [find comment="main"] disabled=yes
/ip route set [find comment="reserve"] disabled=no
:delay 1
/tool fetch url="http://sms.ru/sms/send?api_id=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX&to=79*********&text=ISP1_IS_DOWN_$time" keep-result=no
}

«up»:

/log warning «ISP1 IS UP»
/ip route set [find comment="main"] disabled=no
/ip route set [find comment="reserve"] disabled=yes

Попробуйте action=netmap, вместо action=dst-nat.

Добавьте правило маршрутизации:
/ip route rule
add action=lookup disabled=no src-address=192.168.88.100 table=tv
RouterOS умеет маршрутизировать на основе source-адресов и интерфейсов, это предпочтительнее, чем mangle.
Если основной шлюз окажется недоступен - весь трафик пойдет через reserve с более высоким значением distanse. Такое резервирование вполне работоспособно без дополнительных скриптов. Однако бывает так, что провайдерский шлюз доступен, а дальше него трафик не ходит из-за каких-либо проблем у провайдера. Я когда-то давно реализовал через netwatch, который периодически пингует "безотказные" ип-адреса в интернете (8.8.8.8, 8.8.4.4 и т.п.) через определенные шлюзы и в случае отсутствия или появления отклика - активирует и деактивирует нужные маршруты, меняет адреса днс-серверов, отправляет СМС о том что доступ в интернет через такого-то провайдера исчез или появился в такое-то время и т.д. При этом необходимо создать для этих проверочных адресов отдельные маршруты и в фаерволе запретить исходящий пинг к этим адресам через другие шлюзы.

Вместо маркировки в mangle - можно создать правила маршрутизации в /ip routes rules. RouterOS умеет принимать решение о маршрутизации через определенные таблицы для определенных source-адресов и интерфейсов.

Как один из вариантов, сконфигурировать SXT Lite5 в беспроводные мосты и на RB1100AHx2 централизованно управлять сетью. При необходимости, изолировать клиентов друг от друга и ограничить броадкаст-трафик.
Не вижу особых проблем в схеме с каскадным NAT, незначительно увеличивается нагрузка на процессоры клиентских SXT Lite5, но вряд ли это проблема в данном случае.

Задать маршруты по-умолчанию для каждого провайдерского шлюза, поместив их в разные таблицы маршрутизации, указав разные routing mark (по-умолчанию все маршруты находятся в таблице main) и создать правила маршрутизации - /ip routes rules - для локальных подсетей, направив таким образом трафик с определенных локальных source-адресов через соответствующие таблицы маршрутизации. В данном конкретном случае этот вариант предпочтительнее, чем маркировка трафика через mangle.