https://opennet.me/openforum/vsluhforumID1/80023.html Убил выходные, но так и не получилось.<br>Решил разобраться с pf, т.к. появилась необходимость в использовании altq.<br>Сразу, знание ipfw, сыграло злую шутку из-за включенного по умолчанию keep state во всех правилах pf. В слествии этого не работают все примеры нарытые в инете. Быстрое курение манов по pf не спасло. Более тщательное курение манов дало заветный ключ no state (который не описывается отдельно в опциях управления состоянием и только один раз упоминается в тексте и при беглом просмотре просто не заметен) и то, что при входящем пакете, если для него есть запись в таблице состоаний, то он сразу пропускается минуя все правила. Т.е. по-умолчанию если клиент инициализирует соединение, то пакет попадает под правило:<br>pass in on $int_if from $net to any<br>Делается запись в таблице состояний и теперь даже исходящий в локалку трафик будет идти через это правило, т.е. на правиле:<br>pass out on $int_if from any to $net<br>будет 0.<br>Такой вариант не дает возможность резать исходящий к клиенту трафик с помощью altq. https://opennet.me/openforum/vsluhforumID1/80023.html#2 Sun, 27 Apr 2008 21:27:54 GMT &gt;Т.е. вы хотите сказать что altq не пашет с keep state? <br><br>Ну, глобально, работает, но не так как надо.<br>Как я говорил, при наличии keep state на внутреннем интерфейсе, получается так, что входящий и исходящий трафик от/к клиенту проходит через одно правило. И при включении altq на внутреннем интерфейсе получается так, что весь трафик проходит через queue, а нам надо только исходящий к клиенту трафик направить в эту очередь.<br>Конечно, в большинстве случаев, это не так страшно, но если есть 2 канала наружу и исходящая скорость одного больше входящей другого, то тут будет засада.<br><br> https://opennet.me/openforum/vsluhforumID1/80023.html#1 Sun, 27 Apr 2008 21:00:29 GMT Т.е. вы хотите сказать что altq не пашет с keep state?<br><br><br>