от 24 вольт это будет работать?

от 24 вольт это будет работать?

Не должно. Но можете попробовать

https://www.nix.ru/autocatalog/networking_tp_link/TP-LINK-TL-POE10R-PoE-Splitter-5V-12V_117998.html#pid=2258

https://www.nix.ru/autocatalog/networking_tp_link/TP-LINK-TL-POE10R-PoE-Splitter-5V-12V_117998.html#pid=2258

то же самое. это не будет работать от 24 вольт

а что за устройство у вас питает, модель MT?

Вроде разговор был про hAP ac

модель не упоминалась, но hap ac умеет питаться до 57В, т.е. достаточно просто заменить блок питания и ставить сплиттер

Приветствую, Кто-нибудь сталкивался с таким багом, multi area OSPF, на ABR делаю summarization нескольких префиксов, к примеру 172.16.16/24-172.16.31/24, OSPF генерирует LSA type 3 172.16.16.0/20. После отключаю объединение и ABR больше не генерирует LSA type 3 для префикса 172.16.16.0/24, а для остальных входящих в объединение генерирует.🤔 И так пока не перезапустишь процесс OSPF.

И ещё, я правильно понимаю, исходя из документации, что OSPF LSA type 3 filtering на ABR не поддерживается на текущий момент? Или я что-то пропустил route filter/ospf разделах?

И ещё, я правильно понимаю, исходя из документации, что OSPF LSA type 3 filtering на ABR не поддерживается на текущий момент? Или я что-то пропустил route filter/ospf разделах?

Всё правильно, на out фильтруются только external на asbr. С суммаризацией смиритесь, есть там такой глюк.

Всё правильно, на out фильтруются только external на asbr. С суммаризацией смиритесь, есть там такой глюк.

А не слышали, есть ли планы по расширению возможностей фильтрации в будущем? Или может нужно запросить эту функциональную возможность дружно всем?

А не слышали, есть ли планы по расширению возможностей фильтрации в будущем? Или может нужно запросить эту функциональную возможность дружно всем?

Проблема там не ваша, но суть не меняется.

Уже что-то, если новая реализация будет учитывать недостатки текущей, то здорово!

А не слышали, есть ли планы по расширению возможностей фильтрации в будущем? Или может нужно запросить эту функциональную возможность дружно всем?

Могу предложить вариант решения. Если вам какую-то сеть не нужно передавать через абр, сделайте nssa area и распространяйте в ней маршруты через редистрибьюцию, отключив на ABR трансляцию lsa7 в lsa5

Хм, тоже вариант, хотя и выглядит сложнее, чем просто area range not advertise lsa на ABR, для нужных LSA type 3. Просто оба варианта трудно сопровождать. 🤔

Хм, тоже вариант, хотя и выглядит сложнее, чем просто area range not advertise lsa на ABR, для нужных LSA type 3. Просто оба варианта трудно сопровождать. 🤔

Погодите, в area ranges есть опция advertise, посмотрите внимательно и проверьте

Да есть, она позволяет не генерировать LSA для заданого префикса

Но она к сожалению не позволяет задевать префиксы через prefix-list

Я ещё пытаюсь понять: зачем в igp фильтрация префиксов? Это же igp

Транзитные префиксы, используемые на стыках между маршрутизаторами для маршрутизации совершенно не нужны. Но, они провоцируют генерацию LSA type 3 для каждого такого префикса и в случае OSPFv2 это по одному LSA на каждый префикс. Поэтому для уменьшения размера LSDB и улучшения времени сходимости сети, применяют технику Prefix Suppression RFC 6860 или фильтрацию на ABR, если первая не доступна.

Prefix supression, к сожалению, нет, согласен

Доброго дня комрады !!! подскажите или поделитесь файликом, как то находил фаил универсальный файл конфигурации .rsc .. В нем правишь под себя настройки роутера . Найти не могу

Доброго дня комрады !!! подскажите или поделитесь файликом, как то находил фаил универсальный файл конфигурации .rsc .. В нем правишь под себя настройки роутера . Найти не могу

sys default-configuration pr Это?

Да это !

Есть такой плиз )) дайте

отправил в личку

отправил в личку

🤝👍 Спасибо

всем привет. можно ли в микротике забирать src-адрес который ломится, к примеру. но порт 3389 и засовывать его к примеру не в блэк лист а добавлять его в новый маршрут с типом blackhole ? Вопрос сугубо академического характера.

Эм, это ж какого размера у вас будет RIB при такой конфигурации?! 😳

всем привет. можно ли в микротике забирать src-адрес который ломится, к примеру. но порт 3389 и засовывать его к примеру не в блэк лист а добавлять его в новый маршрут с типом blackhole ? Вопрос сугубо академического характера.

Вы про проброс порта?

Вы про проброс порта?

Нет.

Нет.

Можно.

Можно.

У меня не получилось в правиле указать blackhole

У меня не получилось в правиле указать blackhole

Вы в мангле соединению с нужным соурсом вешайте роутмарк и уже на основании роутмарка отправляете в черную дыру.

Вы в мангле соединению с нужным соурсом вешайте роутмарк и уже на основании роутмарка отправляете в черную дыру.

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

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

Лучше не пробуйте. Это же костыль в разрезе академического интереса. )

Это не сильно затратно будет по цпушке? Не дешевле будет дропать в RAW блэклист?

Лучше не пробуйте. Это же костыль в разрезе академического интереса. )

👍

Это не сильно затратно будет по цпушке? Не дешевле будет дропать в RAW блэклист?

Затратно, конечно. Но это же вопрос из разряда "а можно ли?" А где дешевле дропать в РАВе или в фильтре - надо смотреть по количеству дропаемого трафика.

может быть так, что в фильтре дешевле?

может быть так, что в фильтре дешевле?

Технически, если вредного трафика меньше, чем полезного и фильтр не особо загроможден, то фильтр может оказаться дешевле.

а за счет чего?

а за счет чего?

За счет того, что через матчер правила в RAW будет проходить весь трафик и полезный и вредный. Т.е. сама проверка "легче" (емнип втречал цифру 30%), но она не выборочна, а всеобъемлюща, потому выгода от нее есть при ДОС атаке или прочей ситуации, когда вредного овермного, а если вредного мало, то это двойная работа для фильтра.

не пони, почему двойная

к нам пришло 1000 пакетов

не пони, почему двойная

траффик не сматченный в рав идет дальше в фильтр

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

в одном случае 1000 проверок и в другом 1000 проверок

к нам пришло 1000 пакетов

И РАВ проверит всю 1000. а дропнуть надо, к примеру 10.

а фильтр как-то иначе проверки делает, не все пакеты проверяет?

(ну, кроме дропнутых)

в одном случае 1000 проверок и в другом 1000 проверок

А если в РАВ ничего нет, то 950 пакетов акцептнутся раньше и только 10 дропнутся фильтром. На мой взгляд 10 дропов фильтром дешевле 950 матчей РАВом.

не понимаю

почему 950 акцептов + 50? дропов в фильтре дешевле 950 акцептов и 50? дропов в раве

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

а фильтр как-то иначе проверки делает, не все пакеты проверяет?

Смею предположить, что filter, connection state aware, если соединение для данного flow установлено, оно не проходит всю цепочку filter, а сразу полуает accept. А RAW проверяет каждый пакет, который попал под его match, даже, если это один и тот же packet flow

не понимаю

1. Вариант. Полезный пакет НЕ будет проверяться РАвом, если в РАВ ничего нет. Он зайдет в фильтр, скажем, инпута и акцептнется там. Вредный - дропнется закрывающим правилом. 2. Вариант. Полезный пакет проверится в РАВ(если вредный то дропнется) , и акцептнется в в фильтре. Если полезного много, а вредного мало, то РАВ просто будет выполнтять дополнительную не нужную проверку.

Смею предположить, что filter, connection state aware, если соединение для данного flow установлено, оно не проходит всю цепочку filter, а сразу полуает accept. А RAW проверяет каждый пакет, который попал под его match, даже, если это один и тот же packet flow

+1

Не успел написать идею Владимира, как я её вижу, он сам уже всё подробно расписал. 👍

На картинке наглядно видно, о чём говорит Владимир. 🙌

не, дело не в картинке

не, дело не в картинке

+1

raw: This table is used mainly for configuring exemptions from connection tracking in combination with the NOTRACK target. It registers at the netfilter hooks with higher priority and is thus called before ip_conntrack, or any other IP tables.

если таблица рав пустая, она не вешает хук

следовательно, пакет в цепочку просто не входит

raw: This table is used mainly for configuring exemptions from connection tracking in combination with the NOTRACK target. It registers at the netfilter hooks with higher priority and is thus called before ip_conntrack, or any other IP tables.

вот в этом разрезе его очень полезно использовать. Поскольку контрак "тяжелый".

правильно?

правильно?

Да. Именно это я и имел ввиду.

Даже на вики пишется, что его полезно юзать, например при ДОС атаках. Банальный дроп в РАВ, имхо излишество.

и наша потенциальная экономия получается не за счет того, что проверка в раве дешевле/дороже сама по себе, а за счет экономии на цепочке

и наша потенциальная экономия получается не за счет того, что проверка в раве дешевле/дороже сама по себе, а за счет экономии на цепочке

Она, по идее и дешевле сама по себе, т.к. в ней гораздо меньше условий матчинга. Но это только предположение.

Экономия на connection tracking фазе, не нужно создавать объект, зная, что пакет будет отброшен всё равно.

Экономия на connection tracking фазе, не нужно создавать объект, зная, что пакет будет отброшен всё равно.

вы покупаете или продаете?) мы обсуждаем сценарий, когда с коннтраком выходит дешевле

Она, по идее и дешевле сама по себе, т.к. в ней гораздо меньше условий матчинга. Но это только предположение.

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

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

Я не знаю. Это надо разработчиков расспрашивать. Но самих условий изрядно поменьше.

вы покупаете или продаете?) мы обсуждаем сценарий, когда с коннтраком выходит дешевле

Дешевле, если большинство flow будет в итоге принято.

так-то интуиция подсказывает, что дроп в раве должн быть дешевле

Я не знаю. Это надо разработчиков расспрашивать. Но самих условий изрядно поменьше.

Так можно же код ядра посмотреть просто

так-то интуиция подсказывает, что дроп в раве должн быть дешевле

Я встречал где-то, что на 30% дешевле.