Хорошо, но завтра, наверное

Всем привет. Ткните плиз инструкцией, как настроить vlan на swos свитче, чтобы к нему правильно подключить точки cap ax.

https://help.mikrotik.com/docs/spaces/SWOS/pages/328415/SwOS

Спасибо. Оказалось, если ничего на свитче не менять, оно тоже работает 😊

Ну так не интересно, управляемый свитч юзать без управления... 😂

Согласен. Просто везде пугали, что если капы включать не в сам роутер, а через свитч, то на нем надо прописывать те же vlan'ы из datapath. При этом, если ничего не прописывать, они вполне себе передаются как надо 🤷‍♂️

Подскажите, можно ли как-то задать таймаут соединению OpenVPN на ovpn-сервере микротика? Сейчас если со стороны клиента оборвать сессию, скажем, выключением интернета, то сессия остаётся висеть на микротике, и я не могу подключиться, пока сессию не удалить руками, а это надо подключаться, а я подключиться не могу, потому что сессия висит ))

Можно скрипт заюзать, который будет сбрасывать неактивные (зависшие) соединения

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

Благодарю 😌

Или вот для сервера (мне надо бы тоже интегрировать сие) https://forummikrotik.ru/viewtopic.php?t=13980 Для клиента я уже интегрировал скрипт, перезапускает зависшего клиента: В Netwatch-Down разместить /interface sstp-client disable sstp-one :delay 15; /interface sstp-client enable sstp-one

есть нюанс: по умолчанию Windows брандмауэр блокирует icmp. Соответственно пинга не будет изначально ) Ну ладно, idle timeout тоже лучше, чем ничего. Не хотелось бы дропать клиентские ПК из-за их же брандмауэра

Подскажите, как лучше заблокировать телеметрию Adobe. У меня есть автообновляемый список с адресами телеметрии: https://a.dove.isdumb.one/list.txt Сначала я просто добавил эти адреса в адрес-лист и создал правило блокировки. Но задумался: не будет ли проще добавить этот список в DNS Adlist, чтобы он автоматически обновлялся и блокировался?

Подскажите, как лучше заблокировать телеметрию Adobe. У меня есть автообновляемый список с адресами телеметрии: https://a.dove.isdumb.one/list.txt Сначала я просто добавил эти адреса в адрес-лист и создал правило блокировки. Но задумался: не будет ли проще добавить этот список в DNS Adlist, чтобы он автоматически обновлялся и блокировался?

Добавить статические днс с нолями Либо добавить в адрес лист имена доменов, они сами будут резолвиться и обновляться

Подскажите, как лучше заблокировать телеметрию Adobe. У меня есть автообновляемый список с адресами телеметрии: https://a.dove.isdumb.one/list.txt Сначала я просто добавил эти адреса в адрес-лист и создал правило блокировки. Но задумался: не будет ли проще добавить этот список в DNS Adlist, чтобы он автоматически обновлялся и блокировался?

Если комп пойдёт мимо микротиковского DNS - будет некомильфо. Учитывайте этот нюанс.

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

вот схема

А в чём таки радость этой схемы? Не могу осознать в понедельник после обеда видимо... Два провайдера у головного офиса, два провайдера в филиале. Каждый подключен к каждому. Разные косты. Линк между маршрутизаторами

вот схема

опечатка в схеме, crop.ru на маршруторе бранча

1) в динамической маршрутизации - добавляешь в филиале сетку в OSPF - она тут же распространяется везде; 2) при падении одного из оперторов время переключения на другой составляет 3-и потерянных ping-а 3) можно выключить один из маршрутизаторов в голове и никто ничего не заметит

У меня схема с GRE, ISP1 филиала, смотрит в сторону ISP1 главного офиса, со вторыми аналогично. Падение одного канала филиал не замечает, по пингам не проверял. Но видимо перестроится также быстро. Добавление сети филиала аналогично увидит вся сеть. Увидел, что у головы два маршрутизатора. Тут конечно плюс в отказоустойчивости несомненный есть.

в этой схеме у меня их 55 - рисовать GRE туннели, я устаю примерно на 3-м туннеле + это ж еще и адресацию выделять /30 - короче одни страдания.

ааа... если вопрос только в этом))) у меня есть концепция именования туннелей и политик, порядок адресации, инструкции для подчинённых и ТП. Просто, доступно понятно. Работает. P.S. Сейчас 55 GRE туннелей на голове)

а еще в вашем GRE не ходит full-size MTU 1500 bytes - а у меня ходит ...

у вас туннели l2tp, верно? в них же тоже не 1500 МТУ

а еще в вашем GRE не ходит full-size MTU 1500 bytes - а у меня ходит ...

а еще в вашем GRE не ходит full-size MTU 1500 bytes - а у меня ходит ...

ну как ходит… все равно фрагментится, просто с конским оверхедом

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

кстати, чот пришло в голову, что конский оверхед там будет не всегда, а иногда (в очень экзотических сценариях) и вовсе будет выигрыш по трафику

в этой схеме у меня их 55 - рисовать GRE туннели, я устаю примерно на 3-м туннеле + это ж еще и адресацию выделять /30 - короче одни страдания.

Хотел уточнить, в вашем случае OSPF не использует PTP-линки?

Использует - это даже на схеме подписано.

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

/30 - ?? Нету на моей схеме такого :)

еще можно adjust-mss сделать, чтобы немного облегчить жизнь tcp

Под этим механизмом видимо понимается отсутствие фильтрации ICMP fragmentation needed, верно?

Да, я обычно так и делаю, для уменьшения вероятности фрагментации.

Скажите, а не доводилось ли вам сталкиваться с такой проблемой когда в процессе IPsec шифрования GRE трафика на CCR появлялся TCP reordering?

это правильно, но вообще современные стеки tcp обычно заказывают do not fragment, и если возвращается fragmentation needed, то отправитель откручивает мсс вниз

Да, но это тоже бы очень давно.

То есть сейчас проблема оказалась решена, или на загруженных линках люди отказываются от использования EoIP+IPSec с более чем одним ядром? У меня не так давно на старом CCR1009 пользователи жаловались на более частую потерю связности SQL сессий после включения hardware IPsec. Честно признаюсь, что у меня не нашлось пока времени посмотреть проблему внимательно, но помню, что при каких-то простых тестах вроде быстрого ping, я обнаружил, что получаю ответ далеко не в том порядке каком отправляю ICMP echo-requests. При отключении шифрования проблема вроде бы минимизировалась.

кстати, чот пришло в голову, что конский оверхед там будет не всегда, а иногда (в очень экзотических сценариях) и вовсе будет выигрыш по трафику

При перегрузке происходит reorder IPSec - что тащит за собой все, что внутри. Мне это не мешает на tcp - ну будет там reorder и что?

При перегрузке это имеется в виду, что работа чаще передаётся на другие ядра? По поводу tcp-reorder'инга наверное лишь бы в окно уложиться.

Проблема вроде бы была решена на момент появления long-term 6.x

@sa_drug Вопрос немного не про микротики… Можно узнать бэст практис? Хочу мониторинг поменять на заббикс, там есть дефолтные профили, где каждый порт опрашивается каждую минуту. Вот про этот таймер и хотел спросить, какой тайминг лучше? Есть старые управляемые длинки, которые не сильно любят, когда из по снмп опрашивают и тихонько начинают чудить. Либо рстп перестраивается, либо в ребут уходят.