ну перед этим пароли забекапь

кеш винбокса в %appdata% удали

помогло. а с чем это связано есть разумное обьяснение?

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

Доброго дня всем. Помогите разобраться с ingress-filtering Суть кейса. /interface bridge add name=bridge vlan-filtering=yes /interface bridge port add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes interface=ether1 /interface bridge port add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=ether2 pvid=3 /interface bridge vlan add bridge=bridge tagged=ether1,bridge vlan-ids=2 /interface bridge vlan add bridge=bridge tagged=ether1 untagged=ether2 vlan-ids=3 1) Если сейчас на бридже включить ingress-filtering=yes и установить frame-types=admit-only-vlan-tagged. Пропадет ли связь для vlan #3 между портами ether1 и ether2? 2) Если при добавлении портов не указывать ingress-filtering, но включить на бридже. ingress-filtering будет работать на портах автоматом или нет? Ни как не могу разобраться.

Ингресс-фильтринг на бридже – это фильтрация на так называемом cpu-port

то есть Ингресс-фильтринг на бридже, не повлияет на Ингресс-фильтринг на портах которые в этом бридже?

Правильно

совершенно тупой вопрос: шо не так тут:

совершенно тупой вопрос: шо не так тут:

Масок на адресах нет

Точна! Но почему тогда работает 1.1 ???

Добрый день. настроил ospf на GRE туннели между головным офисом и филиалами - по 4 туннеля до каждого подразделения. туннели работают, линк не падает, но оспф в логах периодически пишет: OSPFv2 neighbor x.x.x.x state change from Full to Down

по 2)

Добрый день. настроил ospf на GRE туннели между головным офисом и филиалами - по 4 туннеля до каждого подразделения. туннели работают, линк не падает, но оспф в логах периодически пишет: OSPFv2 neighbor x.x.x.x state change from Full to Down

MTU снижать пробовал

Wire speed

Его не снижать надо, а выравнивать, если разный. BFD используете?

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

Ребята, а кто то знает как эффективно обрабатывать ip accounting?

Что Вы имеете в виду?

У меня удалённая точка через спутник и там хомячки качают много. Включил ip accounting и хочу анализировать данные

Через аккаунтинг не видно протокол и характер соединений. Теоретически да, можно при помощи perl/python скрипта разбирать этот аккаунтинг и вести статистику

да мне и не нужны протоколы. нужена сумма переданного трафика в разрезе внутренних адресов. я так понимаю что это и предлагает ip accounting. Не хочется самому погружаться в парсинг, думал уже кто-то страдал

Столкнулся с результатом изменения механизма обработки GRE пакетов Микротиком. Обновил один роутер с 6.43 до 6.44 и GRE трафик пропал из conntrack. А на этом роутере 2 провайдера, на каждый приходят PPTP туннели. На 6.43 маркировались входящие соединения и затем манглом в output кидались в соответствующую таблицу маршрутизации для каждого провайдера. А теперь, получается, это не работает. Есть какие-то варианты?

При этом у вас работают pptp?

нет. не поднимаются

Разрешите явно гре выше инвалидов

Разрешено! Но GRE даже в коннекшен трекере нет, соотв-но GRE не маркируется

А счётчик тикает ?

А потом уже посмотрел в conntrack, и там gre нет

Вот у человека также эта проблема. Но после добавления в firewall туннели поднялись. Хоть conntrack и не показывал. Но все это странно. Потому как у других все ок. https://t.me/mikrotikclub/135498

Вот у человека также эта проблема. Но после добавления в firewall туннели поднялись. Хоть conntrack и не показывал. Но все это странно. Потому как у других все ок. https://t.me/mikrotikclub/135498

/ip firewall mangle add action=mark-connection chain=prerouting comment=ISP1 connection-state=new dst-address=1.1.1.1 in-interface=eth1 new-connection-mark=ISP1_conn passthrough=yes /ip firewall mangle add action=mark-routing chain=output comment=ISP1 connection-mark=ISP1_conn new-routing-mark=ISP1 passthrough=yes /ip firewall mangle add action=mark-connection chain=prerouting comment=ISP2 connection-state=new dst-address=2.2.2.2 in-interface=eth2 new-connection-mark=ISP2_conn passthrough=no /ip firewall mangle add action=mark-routing chain=output comment=ISP2 connection-mark=ISP2_conn new-routing-mark=ISP2 passthrough=no /ip route add comment=ISP1 distance=1 gateway=1.1.1.2 routing-mark=ISP1 /ip route add comment=ISP2 distance=1 gateway=2.2.2.3 routing-mark=ISP2 /ip route add distance=3 gateway=192.168.88.2 /ip route rule add action=lookup-only-in-table routing-mark=ISP1 table=ISP1 /ip route rule add action=lookup-only-in-table routing-mark=ISP2 table=ISP2 Вот кратко конфиг данного роутера. Дефолтный маршрут в локалку на другой роутер, а для провайдеров 1 и 2 в мангле созданы соответсвующие правила, чтобы возвращать трафик для VPN соединений, которые приходят по ним. И после обновления до 6.44, насколько я понимаю, как раз роутер перестал маркировать GRE-соединения, соответственно ответные GRE пакеты полетели по неверному маршруту (в локалку)

Погодите вы с манглами. Покажите как вы разрешили гре?

/ip firewall mangle add action=mark-connection chain=prerouting comment=ISP1 connection-state=new dst-address=1.1.1.1 in-interface=eth1 new-connection-mark=ISP1_conn passthrough=yes /ip firewall mangle add action=mark-routing chain=output comment=ISP1 connection-mark=ISP1_conn new-routing-mark=ISP1 passthrough=yes /ip firewall mangle add action=mark-connection chain=prerouting comment=ISP2 connection-state=new dst-address=2.2.2.2 in-interface=eth2 new-connection-mark=ISP2_conn passthrough=no /ip firewall mangle add action=mark-routing chain=output comment=ISP2 connection-mark=ISP2_conn new-routing-mark=ISP2 passthrough=no /ip route add comment=ISP1 distance=1 gateway=1.1.1.2 routing-mark=ISP1 /ip route add comment=ISP2 distance=1 gateway=2.2.2.3 routing-mark=ISP2 /ip route add distance=3 gateway=192.168.88.2 /ip route rule add action=lookup-only-in-table routing-mark=ISP1 table=ISP1 /ip route rule add action=lookup-only-in-table routing-mark=ISP2 table=ISP2 Вот кратко конфиг данного роутера. Дефолтный маршрут в локалку на другой роутер, а для провайдеров 1 и 2 в мангле созданы соответсвующие правила, чтобы возвращать трафик для VPN соединений, которые приходят по ним. И после обновления до 6.44, насколько я понимаю, как раз роутер перестал маркировать GRE-соединения, соответственно ответные GRE пакеты полетели по неверному маршруту (в локалку)

А зачем вам тут и манглы на инпут и Route rule? Не проще только роут рул оставить для src адресов на внешних интерфейсах. Без всякой маркировки?

Ну кстати это идея. Типа вот так? /ip route rule add action=lookup-only-in-table src-address=1.1.1.1/32 table=ISP1

Это все даже с голым файерволлом. А для GRE создано правило /ip firewall filter add action=accept chain=input comment="GRE from WAN" in-interface-list=WAN protocol=gre И оно тикает

На output нет фильтрации? В raw ещё посмотрите.

господа, нужна подсказка, куда копать: роутер MikroTik совершенно не желает видеть ПК на другом конце кабеля LAN. ПК был проверен - порт работает, другой микротик успешно мигает лампочкой с этим же самым кабелем, шнур от провайдера с pppoe на ПК также определяется и работает. сам роутер тоже при тестах пишет link ok и мигает лампочкой, что всё хорошо, успешно работает с pppoe. что может быть не так между ПК и роутером?

пишет, что кабель не подключен, хотя он подключен. кабель я тоже менял и ОС на ПК на всякий случай тоже уже менял