Очередной вопрос из разряда бреда (пожелание заказчика). Сети 0.x и 8.x скомутированы через один bridge. Скорость работ с сетвым сканером (сканер находится в 8ой подсети) напорядок ниже когда адрес клиента из 0ой. Я так полагаю ресурсы уходят на отработку маршрутизации и бриджа. Обработка пакетов из локальных сетей друг в друга в нате и мангле отсекается первым правилом.

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

Бухгалтеру не нравится что ждать прихходиться 30 секунд вместо привычных 2-3 перед началом сканирования

Всем привет, с дефолтными настройками роутера ни одно из устройст не получает ip, кроме моего компа который соеденил на прямую в мт. Что это может быть ?

Подскажите пожалуйста, имеется классический сетап "роутер на палочке", где бридж через влан фильтеринг распилен на вланы и в нем порты со 2 по N, а первый порт не в бридже, на него приходит интернет и на нем висит статический адрес. Договорились с провайдером, теперь он на порт в одном влане будет отдавать интернет и в другом влане будет телевидение. Как лучше(грамотней) принять эти вланы от провайдера? Добавить в общий бридж первый порт и через влан фильтеринг получить и отдать аксессом на тв-приставки или просто на первый порт повесить вланы от провайдера?

Через общий бридж и влан фильтеринг

Коллеги, есть некоторая странность с тем, что в 6.45.7 GRE трафик не отображается в ConnTrack. Он кому-то чем-то не угодил?)

Вы его в raw не вводите сами в такое состояние?

Добрый день, может кто сталкивался с такой ситуацией. Хотел прочитать со всех своих маршрутизаторов информацию о том, что они скачали себе пакеты и прислали информацию на почту о том, что эти файлы есть. и вот что выходит. Если запустить команды через API :global Identity ([/system identity get name]) /file print detail file=package.txt where type=package :delay 4 :global Files [/file get package.txt] /tool e-mail send to=*** subject=upgrade body=$Files file=package.txt :delay 10 /file remove package.txt то они присылают пустое сообщение .id=*43c38;contents=;creation-time=oct/30/2019 14:22:21;name=package.txt;size=0;type=.txt file но если же, эти же команды использовать, зайдя через winbox, то все проходит штатно. .id=*43c2e;contents=# oct/30/2019 14:21: 9 by RouterOS 6.45.3 # software id = 4R1M-GL6C # 0 name="routeros-mmips-6.45.7.npk" type="package" size=10.0MiB creation-time=oct/30/2019 13:00:53 package-name="routeros-mmips" package-version="6.45.7" package-build-time=oct/24/2019 08:44:35 package-architecture="mmips" 1 name="ntp-6.45.7-mmips.npk" type="package" size=236.1KiB creation-time=oct/30/2019 13:00:54 package-name="ntp" package-version="6.45.7" package-build-time=oct/24/2019 08:44:35 package-architecture="mmips" ;creation-time=oct/30/2019 14:21:09;name=package.txt;size=528;type=.txt file Заметил вот еще что, при попытке через api использовать немного измененный скрипт, на то, чтобы просто высылался txt файл, то заметно, что через api этот файл очищается, а в случае с winbox файл отправляется неизмененный как думаете, это баг, или Mikrotik просто таким образом себя обезопасил от получения информации наружу с помощью API?

Пустой мессидж без вложения или вложение внутри пустое?

Народ! Кто использовал симки билайна в ЛТЕ микротиках - можете поделиться настройками АПН?

Вы его в raw не вводите сами в такое состояние?

вложение пустое (сам текстовый файл без данных)

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

авторизация ЧАП или ПАП в АПН профиле?

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

авторизация ЧАП или ПАП в АПН профиле?

Добрый день, может кто сталкивался с такой ситуацией. Хотел прочитать со всех своих маршрутизаторов информацию о том, что они скачали себе пакеты и прислали информацию на почту о том, что эти файлы есть. и вот что выходит. Если запустить команды через API :global Identity ([/system identity get name]) /file print detail file=package.txt where type=package :delay 4 :global Files [/file get package.txt] /tool e-mail send to=*** subject=upgrade body=$Files file=package.txt :delay 10 /file remove package.txt то они присылают пустое сообщение .id=*43c38;contents=;creation-time=oct/30/2019 14:22:21;name=package.txt;size=0;type=.txt file но если же, эти же команды использовать, зайдя через winbox, то все проходит штатно. .id=*43c2e;contents=# oct/30/2019 14:21: 9 by RouterOS 6.45.3 # software id = 4R1M-GL6C # 0 name="routeros-mmips-6.45.7.npk" type="package" size=10.0MiB creation-time=oct/30/2019 13:00:53 package-name="routeros-mmips" package-version="6.45.7" package-build-time=oct/24/2019 08:44:35 package-architecture="mmips" 1 name="ntp-6.45.7-mmips.npk" type="package" size=236.1KiB creation-time=oct/30/2019 13:00:54 package-name="ntp" package-version="6.45.7" package-build-time=oct/24/2019 08:44:35 package-architecture="mmips" ;creation-time=oct/30/2019 14:21:09;name=package.txt;size=528;type=.txt file Заметил вот еще что, при попытке через api использовать немного измененный скрипт, на то, чтобы просто высылался txt файл, то заметно, что через api этот файл очищается, а в случае с winbox файл отправляется неизмененный как думаете, это баг, или Mikrotik просто таким образом себя обезопасил от получения информации наружу с помощью API?

Почитайте примеры тут. Может станет ясно https://wiki.mikrotik.com/wiki/Send_Backup_email

оставьте все по умолчанию - и заработает

Подтверждаю, на 6.45.7 gre трафика нет в conntrack (раньше был с теми же настройками)

А вы до инвалидов его явно разрешали? Было как-то обновление которое делало gre invalid если явно не разрешить. Может теперь они его просто noconntrack сделали?

Он работает, просто не видно его

Я понимаю. Поэтому и спрашиваю

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

Да, разрешал gre, ipsec Потом дроп инвалид

А вы до инвалидов его явно разрешали? Было как-то обновление которое делало gre invalid если явно не разрешить. Может теперь они его просто noconntrack сделали?

Сейчас разрешил, явно, туннель поднялся, трафик даде пошёл, но в трекере пусто

Но раньше я точно видел ipsec и gre в коннтреке, сейчас только IPsec

Коллеги, есть некоторая странность с тем, что в 6.45.7 GRE трафик не отображается в ConnTrack. Он кому-то чем-то не угодил?)

Вот, проверил, работает

Вот, проверил, работает

В общем трекер считает это это инвалиды, поэтому почему-то в трекер они теперь не попадают

Я же написал. Смотрите 6.45.1 security - fixed vulnerabilities CVE-2019-11477, CVE-2019-11478, CVE-2019-11479; !) security - fixed vulnerability CVE-2019-13074;

Я же написал. Смотрите 6.45.1 security - fixed vulnerabilities CVE-2019-11477, CVE-2019-11478, CVE-2019-11479; !) security - fixed vulnerability CVE-2019-13074;

Фото выше

Какая у вас версия ROS? 6.45.7?

6.44.6

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

У меня последняя stable 6.45.7 - в ней видимо косяк есть

Кратко. До инвалидов нужно явно разрешать gre.

Почему он считает их инвалидом тогда?

🤔 интересно

А что в интерфейсах стоит слева от GRE?

R - running?

R - running?

Наведите и будет расшифровка

Должно все работать

Ребята, я знаю что это за буковка) не паникуйте вы так)

Что у Вас в RAW, касаемо GRE?