Russian Users MikroTik | Форум пользователей MikroTik

Есть ли разница в нагрузке ?
то есть имеет ли смысл
заменить несколько однотипных правил
вида
/ip firewall filter add chain=input src-address=1.1.1.1/32 action=accept
/ip firewall filter add chain=input src-address=1.2.1.1/32 action=accept
/ip firewall filter add chain=input src-address=1.3.1.1/32 action=accept
/ip firewall filter add chain=input src-address=1.4.1.1/32 action=accept
на
ip firewall address-list add address=1.1.1.1/32 list=permit_t
ip firewall address-list add address=1.2.1.1/32 list=permit_t
ip firewall address-list add address=1.3.1.1/32 list=permit_t
ip firewall address-list add address=1.4.1.1/32 list=permit_t
/ip firewall filter add chain=input src-list=permit_t action=accept

Для второго нагрузка будет слегка больше, но выглядеть будет проще. Если правил много, то второй вариант вполне хорош, так как упрощает понимание.

SergeyZ писал(а): ↑14 окт 2018, 21:09 Для второго нагрузка будет слегка больше, но выглядеть будет проще. Если правил много, то второй вариант вполне хорош, так как упрощает понимание.

Спасибо.
про читаемость понятно, но в данном случае я ищу как бы облегчить жизнь 962му роутеру на 150 мегабитах и с 500 правилами (куча пробросов портов, хотспот, Hairpin NAT, толпы пользоветельских UpNP правил) .. :( , профайлер показывает что 25% кушает фаервол, вот подумал может немного поможет снижение количества правил.. . Надеялся что оно как во фряхе с таблицами ARG сильно снизит нагрузку.
В пиках у роутера 90%, в ЧНН стабильные 60, что очень много..
Попытка перевести всех проводных клиентов в свитч с одним хвостом в микротик не дала ничего .. весь трафик в Интернет, локального почти нет.

Вам бы тогда роутер помощнее)

Во втором случае нагрузка будет чуть больше за счет того, что появится задача по запросу адресов из permit_t, и только потом он начнет по ним проверять. То есть он будет проходить сначала по всем адрес-листам в целью проверки "не permit_t ли он". И если в первом случае пакет мог бы уже отвалиться на первых правилах, то во втором случае он сначала сформирует это правило.

По крайней мере, это логически так должно происходить..

SergeyZ писал(а): ↑15 окт 2018, 13:07 Во втором случае нагрузка будет чуть больше за счет того, что появится задача по запросу адресов из permit_t, и только потом он начнет по ним проверять. То есть он будет проходить сначала по всем адрес-листам в целью проверки "не permit_t ли он". И если в первом случае пакет мог бы уже отвалиться на первых правилах, то во втором случае он сначала сформирует это правило.

По крайней мере, это логически так должно происходить..

Интересное утверждение.
Но хотелось бы услышать товарищей прошедших курсы, мне кажется им там наверняка объясняли этот вопрос.

KARaS'b писал(а): ↑15 окт 2018, 16:09

SergeyZ писал(а): ↑15 окт 2018, 13:07 Во втором случае нагрузка будет чуть больше за счет того, что появится задача по запросу адресов из permit_t, и только потом он начнет по ним проверять. То есть он будет проходить сначала по всем адрес-листам в целью проверки "не permit_t ли он". И если в первом случае пакет мог бы уже отвалиться на первых правилах, то во втором случае он сначала сформирует это правило.

По крайней мере, это логически так должно происходить..

Интересное утверждение.
Но хотелось бы услышать товарищей прошедших курсы, мне кажется им там наверняка объясняли этот вопрос.

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

Я бы сказал, что товарищам на курсах это не объясняют вовсе, ибо о том, как это реализовано, знают только разработчики.

Да и разница в нагрузке в любом случае практически не ощутима. Но вопрос принципиальный, и принципиально - во втором случае нагрузка выше.

Ну и в записи курсов MTCNA и MTCTCE такого не говорили. Может и сказали что-то в MTCINE, но увы, доступа к этим лекциям не имею. Остальные тренинги вообще на другие темы. Ну или память подводит.

Чем меньше будет правил в firewall - тем меньше будет нагрузка на проц. Потому как идёт разбор правил.
А поиск в списке - обычный XOR, который выполняется максимум за такт проца.
Ещё, для оптимизации firewall можно использовать списки интерфейсов (типа LAN WAN) для однотипных правил.
На недавнем муме в Москве https://mum.mikrotik.com/2018/RUM/agenda/RU
рассматривали оптимизацию firewall, но что-то я там про списки не услышал ничего.
Смотрел вики по этому поводу, но там ни слова о загрузке/разгрузке проца списками.

Для разгрузки проца можно Raw использовать, даже лабораторку делали - проц разгружается хорошо.
Попробую спросить Тренера на этот счёт, письмо закину.
Или что-то тестовое надо сварганить, посмотреть на загрузку

На форуме микротик написали что быстрее таки ip list, проверил на своей шкуре, сделал сегодня, заметно упала нагрузка от фаервола.

vbsev писал(а): ↑17 окт 2018, 10:59 Чем меньше будет правил в firewall - тем меньше будет нагрузка на проц. Потому как идёт разбор правил.
А поиск в списке - обычный XOR, который выполняется максимум за такт проца.

Для того чтобы это утверждать надо быть уверенным что лист " у ней внутре" не превращается в список из правил. Таки да, не превращается.

vbsev писал(а): ↑17 окт 2018, 10:59 Ещё, для оптимизации firewall можно использовать списки интерфейсов (типа LAN WAN) для однотипных правил.
На недавнем муме в Москве https://mum.mikrotik.com/2018/RUM/agenda/RU
рассматривали оптимизацию firewall, но что-то я там про списки не услышал ничего.
Смотрел вики по этому поводу, но там ни слова о загрузке/разгрузке проца списками.

Для разгрузки проца можно Raw использовать, даже лабораторку делали - проц разгружается хорошо.
Попробую спросить Тренера на этот счёт, письмо закину.
Или что-то тестовое надо сварганить, посмотреть на загрузку

За ссылку спасибо - погляжу ( вообще учитывая что с микротика сейчас все больше, надо бы пойти учиться и начать просмотривать профильное) . а WAN/LAN оно ясно, ну и RAW - не там много можно на прероутинге сделать. В этом случае почти все записи живут в таблице NAT и соотв RAW не спасет.

anad писал(а): ↑17 окт 2018, 11:46 Для того чтобы это утверждать надо быть уверенным что лист " у ней внутре" не превращается в список из правил. Таки да, не превращается.

Не, там жешь iptables, читал по нему руководство на предмет работы списков. Используется модуль дополнительный
ipset http://ipset.netfilter.org/ipset.man.html
Что оттуда выдрали микротиковцы сказать не могу, но там используются разные типы хэш, а никак не правила firewall.

anad писал(а): ↑17 окт 2018, 11:46 За ссылку спасибо - погляжу ( вообще учитывая что с микротика сейчас все больше, надо бы пойти учиться и начать просмотривать профильное) . а WAN/LAN оно ясно, ну и RAW - не там много можно на прероутинге сделать. В этом случае почти все записи живут в таблице NAT и соотв RAW не спасет.

В том выступлении Кирила на муме я подчерпнул для себя, что если используются тунели, то т.к. в тунеле меняется src ip, то натить пакет не обязательно - тем самым можно пускать мимо ната, снимая нагрузку на проц.