Есть ли разница в нагрузке ?
то есть имеет ли смысл
заменить несколько однотипных правил
вида
/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
ip list или портянка правил разница в нагрузке
-
- Сообщения: 111
- Зарегистрирован: 10 сен 2018, 09:07
- Откуда: Санкт-Петербург
Для второго нагрузка будет слегка больше, но выглядеть будет проще. Если правил много, то второй вариант вполне хорош, так как упрощает понимание.
-
- Сообщения: 185
- Зарегистрирован: 24 ноя 2016, 21:14
Спасибо.
про читаемость понятно, но в данном случае я ищу как бы облегчить жизнь 962му роутеру на 150 мегабитах и с 500 правилами (куча пробросов портов, хотспот, Hairpin NAT, толпы пользоветельских UpNP правил) .. :( , профайлер показывает что 25% кушает фаервол, вот подумал может немного поможет снижение количества правил.. . Надеялся что оно как во фряхе с таблицами ARG сильно снизит нагрузку.
В пиках у роутера 90%, в ЧНН стабильные 60, что очень много..
Попытка перевести всех проводных клиентов в свитч с одним хвостом в микротик не дала ничего .. весь трафик в Интернет, локального почти нет.
-
- Сообщения: 111
- Зарегистрирован: 10 сен 2018, 09:07
- Откуда: Санкт-Петербург
Вам бы тогда роутер помощнее)
Во втором случае нагрузка будет чуть больше за счет того, что появится задача по запросу адресов из permit_t, и только потом он начнет по ним проверять. То есть он будет проходить сначала по всем адрес-листам в целью проверки "не permit_t ли он". И если в первом случае пакет мог бы уже отвалиться на первых правилах, то во втором случае он сначала сформирует это правило.
По крайней мере, это логически так должно происходить..
Во втором случае нагрузка будет чуть больше за счет того, что появится задача по запросу адресов из permit_t, и только потом он начнет по ним проверять. То есть он будет проходить сначала по всем адрес-листам в целью проверки "не permit_t ли он". И если в первом случае пакет мог бы уже отвалиться на первых правилах, то во втором случае он сначала сформирует это правило.
По крайней мере, это логически так должно происходить..
-
- Сообщения: 1199
- Зарегистрирован: 29 сен 2011, 09:16
Интересное утверждение.SergeyZ писал(а): ↑15 окт 2018, 13:07 Во втором случае нагрузка будет чуть больше за счет того, что появится задача по запросу адресов из permit_t, и только потом он начнет по ним проверять. То есть он будет проходить сначала по всем адрес-листам в целью проверки "не permit_t ли он". И если в первом случае пакет мог бы уже отвалиться на первых правилах, то во втором случае он сначала сформирует это правило.
По крайней мере, это логически так должно происходить..
Но хотелось бы услышать товарищей прошедших курсы, мне кажется им там наверняка объясняли этот вопрос.
- Kato
- Сообщения: 271
- Зарегистрирован: 17 май 2016, 04:23
- Откуда: Primorye
Что-то сомневаюсь, что на курсах это объясняют, тем более это в большей степени зависит от модели роутера (его характеристик)KARaS'b писал(а): ↑15 окт 2018, 16:09Интересное утверждение.SergeyZ писал(а): ↑15 окт 2018, 13:07 Во втором случае нагрузка будет чуть больше за счет того, что появится задача по запросу адресов из permit_t, и только потом он начнет по ним проверять. То есть он будет проходить сначала по всем адрес-листам в целью проверки "не permit_t ли он". И если в первом случае пакет мог бы уже отвалиться на первых правилах, то во втором случае он сначала сформирует это правило.
По крайней мере, это логически так должно происходить..
Но хотелось бы услышать товарищей прошедших курсы, мне кажется им там наверняка объясняли этот вопрос.
-
- Сообщения: 111
- Зарегистрирован: 10 сен 2018, 09:07
- Откуда: Санкт-Петербург
Я бы сказал, что товарищам на курсах это не объясняют вовсе, ибо о том, как это реализовано, знают только разработчики.
Да и разница в нагрузке в любом случае практически не ощутима. Но вопрос принципиальный, и принципиально - во втором случае нагрузка выше.
Ну и в записи курсов MTCNA и MTCTCE такого не говорили. Может и сказали что-то в MTCINE, но увы, доступа к этим лекциям не имею. Остальные тренинги вообще на другие темы. Ну или память подводит.
Да и разница в нагрузке в любом случае практически не ощутима. Но вопрос принципиальный, и принципиально - во втором случае нагрузка выше.
Ну и в записи курсов MTCNA и MTCTCE такого не говорили. Может и сказали что-то в MTCINE, но увы, доступа к этим лекциям не имею. Остальные тренинги вообще на другие темы. Ну или память подводит.
-
- Сообщения: 84
- Зарегистрирован: 19 авг 2018, 09:35
Чем меньше будет правил в firewall - тем меньше будет нагрузка на проц. Потому как идёт разбор правил.
А поиск в списке - обычный XOR, который выполняется максимум за такт проца.
Ещё, для оптимизации firewall можно использовать списки интерфейсов (типа LAN WAN) для однотипных правил.
На недавнем муме в Москве https://mum.mikrotik.com/2018/RUM/agenda/RU
рассматривали оптимизацию firewall, но что-то я там про списки не услышал ничего.
Смотрел вики по этому поводу, но там ни слова о загрузке/разгрузке проца списками.
Для разгрузки проца можно Raw использовать, даже лабораторку делали - проц разгружается хорошо.
Попробую спросить Тренера на этот счёт, письмо закину.
Или что-то тестовое надо сварганить, посмотреть на загрузку
А поиск в списке - обычный XOR, который выполняется максимум за такт проца.
Ещё, для оптимизации firewall можно использовать списки интерфейсов (типа LAN WAN) для однотипных правил.
На недавнем муме в Москве https://mum.mikrotik.com/2018/RUM/agenda/RU
рассматривали оптимизацию firewall, но что-то я там про списки не услышал ничего.
Смотрел вики по этому поводу, но там ни слова о загрузке/разгрузке проца списками.
Для разгрузки проца можно Raw использовать, даже лабораторку делали - проц разгружается хорошо.
Попробую спросить Тренера на этот счёт, письмо закину.
Или что-то тестовое надо сварганить, посмотреть на загрузку
-
- Сообщения: 185
- Зарегистрирован: 24 ноя 2016, 21:14
На форуме микротик написали что быстрее таки ip list, проверил на своей шкуре, сделал сегодня, заметно упала нагрузка от фаервола.
Для того чтобы это утверждать надо быть уверенным что лист " у ней внутре" не превращается в список из правил. Таки да, не превращается.
За ссылку спасибо - погляжу ( вообще учитывая что с микротика сейчас все больше, надо бы пойти учиться и начать просмотривать профильное) . а WAN/LAN оно ясно, ну и RAW - не там много можно на прероутинге сделать. В этом случае почти все записи живут в таблице NAT и соотв RAW не спасет.vbsev писал(а): ↑17 окт 2018, 10:59 Ещё, для оптимизации firewall можно использовать списки интерфейсов (типа LAN WAN) для однотипных правил.
На недавнем муме в Москве https://mum.mikrotik.com/2018/RUM/agenda/RU
рассматривали оптимизацию firewall, но что-то я там про списки не услышал ничего.
Смотрел вики по этому поводу, но там ни слова о загрузке/разгрузке проца списками.
Для разгрузки проца можно Raw использовать, даже лабораторку делали - проц разгружается хорошо.
Попробую спросить Тренера на этот счёт, письмо закину.
Или что-то тестовое надо сварганить, посмотреть на загрузку
-
- Сообщения: 84
- Зарегистрирован: 19 авг 2018, 09:35
Не, там жешь iptables, читал по нему руководство на предмет работы списков. Используется модуль дополнительный
ipset http://ipset.netfilter.org/ipset.man.html
Что оттуда выдрали микротиковцы сказать не могу, но там используются разные типы хэш, а никак не правила firewall.
В том выступлении Кирила на муме я подчерпнул для себя, что если используются тунели, то т.к. в тунеле меняется src ip, то натить пакет не обязательно - тем самым можно пускать мимо ната, снимая нагрузку на проц.anad писал(а): ↑17 окт 2018, 11:46 За ссылку спасибо - погляжу ( вообще учитывая что с микротика сейчас все больше, надо бы пойти учиться и начать просмотривать профильное) . а WAN/LAN оно ясно, ну и RAW - не там много можно на прероутинге сделать. В этом случае почти все записи живут в таблице NAT и соотв RAW не спасет.