> управлять можно
>только _своим_ трафиком. То есть, исходом. На вход повлиять нельзя _никак_.
>Под входящим тут имеется в виду не тот трафик, который идет в интерфейс, а тот, который >пришел, но еще не передан на обработку. Почему его "_нельзя_" зашейпить? Можно. Только >криво это и с трудом можно придумать этому оправдание. О чем и речь.Речь идёт о проходящем трафике, который пришел на интерфейс, и в скором времени уйдет через какой-то другой интерфейс.
В 99% случаев говоря "хочу зашейпить вход" кому-то, имеют ввиду "проходящий трафик" мимо роутера.
т.е. зашейпить вход клиенту - это означает зашейпить на выходе из роутера или на входе в роутер.
ipfw может шейпить этот трафик без проблем, а ALTQ только на выходе.
ситуация есть LAN 192.168.1.0/24, 192.168.2.0/24 которые доступны через rl1 и rl2 роутера.
На роутере запущен OSPF и трафик к этим сетям динамически уходит через rl1 или через rl2 в зависимости он загрузки каналов или друхих прочих факторов, которые нам не известны.
ipfw легко можно зашейпить трафик к этим сетям собирая пакеты на входе в роутер (rl0):
ipfw pipe 1 config bw 512Kbit/s mask dst-ip 0xffffff00
ipfw add 1 pipe 1 all from any to 192.168.1.0/24 in recv rl0
ipfw add 1 pipe 1 all from any to 192.168.2.0/24 in recv rl0
И нас не заботит через какой интерфейс/интерфейсы пойдет пакет дальше.
Реализовать в ALTQ такое невозможно, т.к. на rl2 и rl1 это две разные очереди. И они никак!!! с друг другом "общаться" не смогут. Поэтому если трафик к LAN's будет уходить через rl1 со скорость 128Кбит, то мы не как не сможем зашейпить его на rl2 на скорость 384Кбит/с. А так как трафик будет распределятся между двумя каналами каким-то случайным образом, то я вообще не представляю как можно сделать такое с помощью ALTQ.
В догонку:
http://www.nabble.com/altq-td18171872.html#a23453905
