может где-то долгий резолв DNS, может таймаут соединений... не обязательно это проверки сертификатов

но когда весь инет открыт работает без проблем

1 тоннель = 1 адрес 2 тоннеля = 2 адреса

#define нормальный вид

а можно еще вопросик по резервированию 🤭 1. главный офис: два провайдера 2. филиал(клиент к главному) создаю два l2tp подключения добавляю маршруты: для l2tp-1 (айпи 1) для l2tp-2 (айпи 2) тот же маршрут только Дистанс 2 это верное решение или по другому лучше?

или дистанс у обоих оставить 1 , при тесте и так и так работало по сути 🤭

Евгений, вот сейчас сделали такую же ситуацию, а именно микротик подключен по l2tp с этого же микротика по wifi подключен ноут, с ноута тот же l2tp подключен к серверу. Сеть не упала, оба клиента работают, вот вот теперь не понимаю логики

или дистанс у обоих оставить 1 , при тесте и так и так работало по сути 🤭

ospf

наверно это пока сложно для моего ума

Ну тогда ваш вариант тоже будет работать ;)

Всем спасибо) а тогда какой смысл в distance ???

Своего рода вес маршрута

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

Если 2 тонеля то надо 2 маршрута с разными дистанс и желательно шлюзами в л2тп тунеле

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

Ну у меня так же. В ЦО 2 канала и филиал цепляется 2 тунелями. Между роутерами у меня 2 разных подсети 68.0 69.0 и 2 маршрута в сети филиала и цо с разными гейтами и дистанс но до одних и тех же сетей. В центральном активен только 1 пров второй как резерв через рекурсивный

вот только про дистанс не понимаю, если l2tp уходит в статус не работает и к нему маршрут автоматом не применим идёт он по второму подключению, тогда дистанс тут роли не играет, так получается?

спасибо, правда сейчас попробовал сделать так, два подключения есть в статусе R, взял в фаерволе заблочил output на IP основной (сервера), сеть упала, дистанс не помог увы..... даже спустя 2 минуты. странно конечно, что само соединение из статуса R не выключилось

Зачем? Я ранее говорил про форвард

неее Евгений, это уже другая тема )))) я про резервный канал) сегодня день весёлый был) столкнулся со всеми прелестями )

неее Евгений, это уже другая тема )))) я про резервный канал) сегодня день весёлый был) столкнулся со всеми прелестями )

И тогда маршрут прыгнет быстрее

включил ping вообще не работает с ним ) отключил чек гетвей, канал поднялся... интересно

Смотрите на втором хосте у вас активно оба прова? Или только 1 актив второй не активен при работающем первом?

это я из дома тестирую, дома тоже микрот, подключился по двум разным ip, т.е. два подключения активно, add default route галку не ставил, маршруты сам прописываю

/ip route add comment="Marked via isp1" distance=1 gateway=‘gate1’ pref-src=‘белый адрес_1’ routing-mark=to_isp1 add comment="Marked via isp2" distance=1 gateway=‘gate2’ pref-src=‘белый адрес_2’ routing-mark=to_isp2 /ip route rule add action=lookup-only-in-table src-address=‘белый адрес_1’ table=to_isp1 add action=lookup-only-in-table src-address=‘белый адрес_2’ table=to_isp2

спасибо, только нужно переварить это 🤭

Это нужно вписать на «сервере» и по идее должно все заработать

вланы разруливаются локально на капах

вероятно, у вас на том девайсе, где запущен капсман, есть также и контролируемый ах-интерфейс?

Третья минорная версия семёрки, которая дожила до четвёртого билда. Первые две были 7.1.4 и 7.13.4. Не ждём пятницы, обновляемся ) RouterOS 7.19.4 [stable] What's new in 7.19.4 (2025-Jul-28 13:00): *) arm - improved system stability when processing encrypted traffic; *) arm64 - increased maximum number of CPU cores to 128; *) ethernet - improved ethernet stability when handling invalid packets on Alpine CPUs; *) iot - fixed incorrectly set LoRa channel plan behavior; *) ipv6 - fixed policy routing; *) leds - fixed issues after changing "dark-mode" configuration (introduced in v7.19); *) license - updated URL for "libcroco" package in the license notice; *) log - output PoE-Out LLDP negotiation to poe,info topic; *) net - ensure packet sockets from containers do not disable RouterOS fastpath/fasttrack; *) netinstall-cli - recognize RouterOS v6 system package; *) port - give "gps" prefix for R11e-LR8G and R11e-LR9G GPS ports; *) ptp - allow priority1 value of 0 (improves stability when receiving announce messages with priority1 set to 0); *) routing-filter - fixed route origin matcher; *) system - improved system stability for CCR2216 device; *) system - improved system stability when using fasttrack;

Третья минорная версия семёрки, которая дожила до четвёртого билда. Первые две были 7.1.4 и 7.13.4. Не ждём пятницы, обновляемся ) RouterOS 7.19.4 [stable] What's new in 7.19.4 (2025-Jul-28 13:00): *) arm - improved system stability when processing encrypted traffic; *) arm64 - increased maximum number of CPU cores to 128; *) ethernet - improved ethernet stability when handling invalid packets on Alpine CPUs; *) iot - fixed incorrectly set LoRa channel plan behavior; *) ipv6 - fixed policy routing; *) leds - fixed issues after changing "dark-mode" configuration (introduced in v7.19); *) license - updated URL for "libcroco" package in the license notice; *) log - output PoE-Out LLDP negotiation to poe,info topic; *) net - ensure packet sockets from containers do not disable RouterOS fastpath/fasttrack; *) netinstall-cli - recognize RouterOS v6 system package; *) port - give "gps" prefix for R11e-LR8G and R11e-LR9G GPS ports; *) ptp - allow priority1 value of 0 (improves stability when receiving announce messages with priority1 set to 0); *) routing-filter - fixed route origin matcher; *) system - improved system stability for CCR2216 device; *) system - improved system stability when using fasttrack;

what?

На этой прошивке снова +60 Кб занятого места для arm 😃 Видимо, слишком уменьшили занимаемое место в прошлый раз

Кто-то, кстати, проблвал на ас2 ставить вместо wireless qcom-ac? Сколько разница в занимаемом месте?

У меня свободного места ~ 444 KiB(настроек минимум). Зависит от мусора с прошлых обновлений и от размера настроек микрота.

На этой прошивке снова +60 Кб занятого места для arm 😃 Видимо, слишком уменьшили занимаемое место в прошлый раз

Это с qcom-ac?

Да

Дратуте! Есть знакомые по WG хорошо шарюшие? Нужно не мне, я в отпуске, человечку помочь бы. WG на микроте разумеется)

У меня свободного места ~ 444 KiB(настроек минимум). Зависит от мусора с прошлых обновлений и от размера настроек микрота.

А было 530 на 7.19.3

Я к тому, что у всех по разному, у меня наоборот стало, чуть больше свободного места

Могу, если актуально еще

У меня есть cap ac и hap ac2, - они почти одинаковые по железу, но в обоих случаях свободное место уменьшилось на 60 кбайт Причем, обе железки в минимально возможной конфигурации - точка доступа, управляемая капсманом - больше настроек нет

Коллеги, уже как-то раз спрашивал, но к сожалению не пришли ни к какому решению, предлагаю обсудить вновь. Есть два офиса, две серверные площадки, разные сети. Объединены gre-каналами c OSPF маршрутизацией. На одной из площадок есть сеть серверов 10.0.17.0/26. В ней есть десяток-другой серверов. У меня есть необходимость в оперативном перемещении их на другую площадку, которое может затянуться на продолжительное время) Я бы не хотел менять адреса серверов! (пусть это будет основным условием) Как можно настроить маршрутизацию (или что-то ещё) чтобы были доступны узлы на разных площадках? К примеру 10.0.17.3/26 в одном офисе и 10.0.17.15/26 в другом. Может добавить узкие статические маршруты /32 и редистрибьютить их? Но как тогда серверу до шлюза добираться... в общем вопросов больше чем ответов и каких-то мыслей

придётся одинаковые адреса на интерфейсах маршрутизаторов иметь

тогда серверы на разных площадках в сети /26 между собой общаться не смогут... он будет искать соседа рядом, а он чрез пару маршрутизаторов от него

Коллеги, уже как-то раз спрашивал, но к сожалению не пришли ни к какому решению, предлагаю обсудить вновь. Есть два офиса, две серверные площадки, разные сети. Объединены gre-каналами c OSPF маршрутизацией. На одной из площадок есть сеть серверов 10.0.17.0/26. В ней есть десяток-другой серверов. У меня есть необходимость в оперативном перемещении их на другую площадку, которое может затянуться на продолжительное время) Я бы не хотел менять адреса серверов! (пусть это будет основным условием) Как можно настроить маршрутизацию (или что-то ещё) чтобы были доступны узлы на разных площадках? К примеру 10.0.17.3/26 в одном офисе и 10.0.17.15/26 в другом. Может добавить узкие статические маршруты /32 и редистрибьютить их? Но как тогда серверу до шлюза добираться... в общем вопросов больше чем ответов и каких-то мыслей

Или, двойной нат сделать

или выдать им каждому /32 маску

Виндовый сервер схавает? 10.0.17.2/255.255.255.255 Что ему шлюзом отдавать?