ну, у меня вот так как на скрине сработало, только что проверил

если что - команда на добавление такого шедулера
бот и чат ид надо свои
интервал меньше 2 секунд ставить не рекомендую
https://pastebin.com/Bh2b7M7Q

ну я и говорю - если переменная не касается других символов(кроме пробела) то проблем нет

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

расписывать добавление шедулера-то?)

не, за что каждая переменная отвечает и т.д. ну и саму идею 😊

:global telegramMessage "$user connected to \"$[/system identity get name]\" at $[/system clock get time]"

если в тексте есть кавычки - их достаточно отэкранировать, и такой вариант тоже пашет

да там, блин, всё же и так видно)
если конструировать что-то сложное (например, очередь сообщений, если их за один цикл отправки образовалось несколько штук), то такое - да, можно было бы и расписать
но мне пока лень

подскажите если роутер за NATом, то к нему никак не настроить доступ извне? Попробовал IP - Cloud, не работает

В общем случае напрямую на него никак, только через какой-то промежуточный узел с реальным ip - роутер туда впном подключается, и тот, кто хочет на роутер, тоже туда впном подключается

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

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

попробую, спасибо

Коллеги, добрый вечер! А какое сейчас лучшее решение по агрегации нескольких аплинков? Понятно, что на второй стороне стоит CHR. Мой вопрос про стек протоколов между офисом и CHR. Пока вижу варианты:
1) L2 bonding на обеих сторонах и между ними L2TP + MLPPP + BCP;
2) L2 bonding на обеих сторонах и между ними EoIP.

И еще вопрос: как справиться с ситуацией, когда каналы с негарантированной bandwidth (LTE)?

L2 поверх L3 это так себе затея. Хотя, конечно, там достаточно удобно балансить, но оверхэд лишний же...
Если не стоит задачи обеспечить доступ к удалённой сети, то проще всего поднять по разным аплинкам туннели, сунуть их в разные VRF, манглом отклассифицировать траифк и загнать в нужный врф, где повесить нат на туннели.
Если же нужно без ната и двунаправленной доступностью, то тут можно попробовать поднять по туннелям OSPF с равным костом на туннелях - тогда будет по ECMP балансироваться по идее (а если нужно не 1:1, то можно разное колличество туннелей на аплинки поднять).
Но опять же - это решение не идеально точно работает.
Если хочется прям полного контроля, коса и прочего фарша, то это надо поднимать MPLS по туннелям и пилить TE...

Нет вменяемого решения. Можно удариться в скриптинг и анализировать качество соединения по пингам, но это не панацея и пинги не всегда показательны (очень частая проблема на LTE - никакая производительность в однопоток TCP, но пинги этого вообще никак не покажут).
Есть всякие достаточно профильные решения за овердорого (на самом деле даже у циски было что-то такое в контексте анализа качества соединения в DMVPN), но непонятно на сколько они будут нормально работать.

Задача: сложить 4 канала по 10Mbps и получить на выходе 40Mbps.

Вариант с раскидывание  соединений по каждому аплинку не подходит, т.к. тогда мы упираемся в потолок 10Mbps.

Чем вас ecmp не устраивает?