<p><span> <a href="../compose?to=%22Andrew%20Kornilov%22%20%3Cakornilov%40ipxp.net%3E">Andrew Kornilov <akornilov@ipxp.net></a></span></p><p>writes:</p><p>>Alexander SUre Podkopaev <span><<a href="../compose?to=podkopaev-a-n@yandex.ru">podkopaev-a-n@yandex.ru</a>> writes:</span><br>>> Что-то я не пойму, что вы паритесь? Сбивает с толку -j[ump] - типа, переход?<br>>> Нету его там, там скорее procedure call :-)<br>>> -j MARK --set-mark только ставит метку и "идет дальше", до конца цепочки или -j RETURN<br>>> А если у вас пакет попадает под ДВА правила сразу, значит, правила нужно уточнять.<br>>> А иначе классическая "дилемма мартышки - толи к умным, толи к красивым".<br>>Уточнять правила больше некуда. <br></p><p><br></p><p>ИМХО, если пакет попадает под два правила с разным mark - правила
НУЖНО уточнять (уточнять в данном случае может означать дробить на
более мелкие группы портов\адресов). Если же mark один - то и -j RETURN может быть один в конце.<br></p><p><br></p><p>>Придется городить ненужный return на каждое правило и грузить CPU избыточными операциями.</p><p>1. Если понять, что -J MARK это не jump, а subroutine call,и их может быть несколько - то становиться понятным, что -j RETURN в вашем случае НУЖЕН. У меня на одном сервере есть специальная цепочка для -m state --state NEW, там для хоста динамически создается\убивается 4 разных правила set-mark + restore-mark + RETURN. Но там скорости ADSLные.<br> </p><p>2. Сколько предполагается правил, что Вы боитесь перегрузить ЦПУ? Или у вас скорости 100Мб\с и выше? <br></p><p><br></p><br>