Разберитесь с этим ) :local tmpdate [/system clock get date] :local months ("jan","feb","mar","apr","may","jun","jul","aug","sep","oct","nov","dec") :local month [ :pick $tmpdate 0 3 ] :local mm ([ :find $months $month -1 ] + 1) :if ($mm < 10) do={ :set mm ("0" . $mm); }; :local d "" :local t [/sys clock get time] :if ($ver < 710) do={ :set d ([:pick $tmpdate 7 11] ."-" . $mm ."-" . [:pick $tmpdate 4 6]); } else={ :set d [/sys clock get date]; } :local timestamp (([:pick $d 0 4]) . ([:pick $d 5 7]) . ([:pick $d 8 10]) ."-". ([:pick $t 0 2]) . ([:pick $t 3 5])) :log info $timestamp

спасибо, этот способ понятен конечно :) думал может есть простые способы форматирования)

спасибо, этот способ понятен конечно :) думал может есть простые способы форматирования)

не так все сложно на самом деле ) $ver - переменная с версией ROS (до 7,10 и после), в этой версии поменяли формат.

решил я отказаться от даты)

А ведь я вам готовый скрипт дал "plug & play"(с) 😂

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

Если только сохранять прям в шару. 🤔 Tool Fetch поддерживает уплоад только на FTP https://help.mikrotik.com/docs/spaces/ROS/pages/8978514/Fetch

да сохранять в шару, но не в ручную конечно)

Добрый день, можете навести на правильную схему имеем: Офис 1 - два белых IP 192.168.0.1 192.168.0.2 Офис 2 - два белых IP 192.168.10.1 192.168.10.2 Офис 3 - два белых IP 192.168.20.1 192.168.20.2 задача соединить все офисы l2tp, В качестве центрального выбираю офис 1 Из каждого офиса создаю два туннеля VPN к каждому белому IP к 192.168.0.1 192.168.0.2 1й вопрос на сколько это правильно, что будет если один туннель в одном офисе упадёт? если машрут указан для каждого тонеля одинаковый, т.е. на удалённый l2tp сервер. Или лучше использовать схему: с офиса 1 соединяемся со всеми остальными, т.е. клиент для всех офисов

Добрый день, можете навести на правильную схему имеем: Офис 1 - два белых IP 192.168.0.1 192.168.0.2 Офис 2 - два белых IP 192.168.10.1 192.168.10.2 Офис 3 - два белых IP 192.168.20.1 192.168.20.2 задача соединить все офисы l2tp, В качестве центрального выбираю офис 1 Из каждого офиса создаю два туннеля VPN к каждому белому IP к 192.168.0.1 192.168.0.2 1й вопрос на сколько это правильно, что будет если один туннель в одном офисе упадёт? если машрут указан для каждого тонеля одинаковый, т.е. на удалённый l2tp сервер. Или лучше использовать схему: с офиса 1 соединяемся со всеми остальными, т.е. клиент для всех офисов

Начнем с того что адреса не белые

От конфигурации веет каким-то белым расизмом. 😁 Одна из классических схем может быть следующей: Между тремя маршрутизаторами поднимите туннели, получится всего 6 tunnel endpoints. Затем настройте динамичную маршрутизацию, например с помощью OSPF и выставьте соответствующие OSPF costs на интерфейсах.

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

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

Добрый день, можете навести на правильную схему имеем: Офис 1 - два белых IP 192.168.0.1 192.168.0.2 Офис 2 - два белых IP 192.168.10.1 192.168.10.2 Офис 3 - два белых IP 192.168.20.1 192.168.20.2 задача соединить все офисы l2tp, В качестве центрального выбираю офис 1 Из каждого офиса создаю два туннеля VPN к каждому белому IP к 192.168.0.1 192.168.0.2 1й вопрос на сколько это правильно, что будет если один туннель в одном офисе упадёт? если машрут указан для каждого тонеля одинаковый, т.е. на удалённый l2tp сервер. Или лучше использовать схему: с офиса 1 соединяемся со всеми остальными, т.е. клиент для всех офисов

а в какую сторону лучше подключатся, из офиса 1 ( в нём я нахожусь) к другим, или другие ко мне? по практике как лучше?

а в какую сторону лучше подключатся, из офиса 1 ( в нём я нахожусь) к другим, или другие ко мне? по практике как лучше?

Будто бы без разницы. Обычно ЦО сервер, но это не принципиально

кто сказал? я как пример

RFC1918

ну началось ))))) не хотел свой белые айпи сюда выкладывать)

ну началось ))))) не хотел свой белые айпи сюда выкладывать)

Доя этого есть rfc5737: 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3)

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

маршрут /32 к l2tp-server ISP 1 центральный офис через ISP 1 филиал маршрут /32 к l2tp-server ISP 2 центральный офис через ISP 2 филиал --- OSPF с cost или статическая маршрутизация

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

а обратно он из центрального офиса как пойдет ?

я просто на виртуалках пробовал такое делать, трафик шёл, просто два маршрута прописывал одинаковых для обоих l2tp

dst 192.168.0.1/24 gtw 10.0.0.1 (l2tp1) dst 192.168.0.1/24 gtw 10.0.0.2 (l2tp2) я как пример

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

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

ну и ок ... значит вы все протестировали, в моей задаче, скорость upload по одному каналу была значительно выше, чем при балансировке.

Хммм, если у всех белые адреса, то зачем городить l2tp, когда есть GRE? Или это вопрос исключительно конфессиональный внутри МТ-религии?

я сам некогда топил за статические туннели, но с выходом bgp dynamic neighbors перековался

нинада оспф

есть ли причина выбрать оспф вместо бжп с dynamic neighbors?

но если уже сделано и работает, то, конечно, переделывать незачем

Хммм, если у всех белые адреса, то зачем городить l2tp, когда есть GRE? Или это вопрос исключительно конфессиональный внутри МТ-религии?

А зачем городить gre — когда есть l2tp?

Ну то есть я понимаю, что это будет что-то peer-group - но все равно очень интересно.

/routing bgp connection add as=65003 connect=no listen=yes local.address=192.168.78.1 .role=ebgp .ttl=1 multihop=yes name=bgp-vpn-incoming-78 remote.address=192.168.78.0/24 router-id=192.168.78.1 use-bfd=yes

Я сделал это на ospf ещё когда это не было мэнстримом :) Не умоляя достоинств bgp. Если кто-то здесь хочет - я могу нарисовать тут схему - мне её все равно рисовать....

Я за нарисовать, если все равно рисовать)