тегированный трафик принимаете где 2 паблик адреса? Или все под одной маской у вас?

и микротик начинает ронять сеть на всех портах RB962UiGS-5HacT2HnT

Просто отваливается и все.

Мониторинг наше всё...

А что мониторинг даст? Ошибок передачи 0. В логах полных 0.

загрузка процессора, доступность устройства, состояние портов.. Дальше перечислять, что делает нормальный мониторинг? Обычно когда порт отваливается на самом микротике в статистике порта появляется количество состояний Down\Up, но судя по всему - не ваш случай. Поэтому - мониторинг - наше всё..

маркировать трафик

Нет счетчик тикает падений. Но из всего перечисленого в норме. Нагрузка 10% все в рамках портов тика общается без правил файрвола.

Вот не верю... Сам давно в деле. У меня в стоматологической клинике у одного из заказчиков и 30 ip камер в постоянном состоянии on line и backkup через vpn канал льётся виртуальных машин с трёх серверов и ничего не падает никогда.

Вот не верю... Сам давно в деле. У меня в стоматологической клинике у одного из заказчиков и 30 ip камер в постоянном состоянии on line и backkup через vpn канал льётся виртуальных машин с трёх серверов и ничего не падает никогда.

Сеть в автосогласовании на сервере 1gb порты. Но почему начинает ронять все порты для меня загадка

Оборудование включено напрямую в микрот. Нет вланов нет пересылок. Только впн но пока из порта 2 в порт 3 не попрет 998мб/с все работает идеально. Железки общаются между портами рамках бриджа

Ну думаю для начала стоит протестить

/ip/firewall/mangle> print 0 chain=prerouting action=mark-connection new-connection-mark=conn_sbb passthrough=no dst-address=xx.xx.xx.5 connection-mark=no-mark in-interface=sfp-sfpplus4 log=no log-prefix="" 1 chain=prerouting action=mark-connection new-connection-mark=conn_vrrp_sbb passthrough=no dst-address=xx.xx.xx.2 connection-mark=no-mark in-interface=sfp-sfpplus4 log=no log-prefix="" 2 chain=prerouting action=mark-routing new-routing-mark=to_sbb passthrough=no dst-address-type=!local connection-mark=conn_sbb in-interface-list=!WAN log=no log-prefix="" 3 chain=prerouting action=mark-routing new-routing-mark=to_vrrp_sbb passthrough=no dst-address-type=!local connection-mark=conn_vrrp_sbb in-interface-list=!WAN log=no log-prefix="" 4 chain=output action=mark-routing new-routing-mark=to_sbb passthrough=no dst-address-type=!local connection-mark=conn_sbb log=no log-prefix="" 5 chain=output action=mark-routing new-routing-mark=to_vrrp_sbb passthrough=no dst-address-type=!local connection-mark=conn_vrrp_sbb log=no log-prefix="" 6 chain=prerouting action=mark-routing new-routing-mark=to_vrrp_sbb passthrough=no src-address-list=via_vrrp_sbb dst-address-list=!BOGONS log=no log-prefix="" 7 chain=prerouting action=mark-routing new-routing-mark=to_sbb passthrough=no dst-address-list=dst_via_sbb log=no log-prefix="" локалка выходит как надо, а роутер чет не хочет выходить как надо

https://habr.com/ru/articles/463813/ маршруты

по статье делали?

https://t.me/mikrotikclub/302457 вот тут еще ответ предложили

мультиван делал по ней да, и сейчас отталкивался от ее логики

да, с срц-нат работает, но если хочешь из локалки попасть в адрес по которому ходит роутер с другим src-nat то выползает no route и я не очень понимаю почему для трафика роутера нужен src-nat. разве унего src не просто паблик айпи?

dst-address=xx.xx.xx.5 Это разве не ваш адрес ? почему не src

dst-address=xx.xx.xx.5 Это разве не ваш адрес ? почему не src

ммм незнаю) ему же надо и отвечать в тот же интерфейс в который придет запрос снаружи

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

2 адреса на 1 sfp висит под одной маской?

да, с срц-нат работает, но если хочешь из локалки попасть в адрес по которому ходит роутер с другим src-nat то выползает no route и я не очень понимаю почему для трафика роутера нужен src-nat. разве унего src не просто паблик айпи?

да, с срц-нат работает, но если хочешь из локалки попасть в адрес по которому ходит роутер с другим src-nat то выползает no route и я не очень понимаю почему для трафика роутера нужен src-nat. разве унего src не просто паблик айпи?

Всем привет! Подскажите пожалуйста... Отключился на удаленном роутере2 интернет (был сбой у провайдера), уже несколько часов все работает, а туннель к другому роутеру1 не поднимается. Хотя другие клиенты к этому роутеру1 подключаются без проблем в данный момент. Протокол l2tp

сбрось сессии на роутере1

Сбросил все connections, не помогло

а ipsec с l2tp используется?

Да

попробуй отключить ipsec на время в настройках подключения

Помогло отключение ipsec на роутере2

а у вас dpd включен в дефолтном профиле (или какой вы используете для l2tp/ipsec)?

по дефолту 120

тогда ipsec sa должен протухать за 10 минут максимум

Для роутера указываешь pref source

типа в роутинге делаю дст - нужный адрес и преф сорс адрес с которого роутер должен ходить на него?

А в src nat укажи адрес локальной сети (src adr) и делай нат в нужный тебе адрес.

Да.

Кто нибудь обновлялся до ROS? Нашел статью одну и там пишет что маршрутизация vlan осуществляется на коммутаторе. Так ли это?

С опенврт на рос?)

c 6 до 7

были прецеденты когда unifi свитчи срали в сеть и dhcp микротиком не выдавался , вот что к примеру отделить основные сегменты друг от друга

добрый день Есть небольшая проблема касаемо скорости передачи по локальной сети между vlan. Общая загрузка 250-300мбит. Причиной всему большое кол-во правил nat,mangle,row,ipsec на ccr. После ccr стоит src317. Для облегчения работы ccr принято решение передать маршруты на crs. А теперь собственно вопрос, crs настраивается идентично ccr или же все таки есть какие то исключения? Сейчас на данный момент я все так же настроил но нет связи между vlan. Как то поднимался данный вопрос но не смог найти решение здесь.

ну вообще 317 отличный тазик для л3хв

СRS317 - это свитч ?? Что вы на нем собрались маршрутизировать :)