2009/5/27 irix <i...@ukr.net>:
> Hello Misc,
>
>> since queueing only happens at output, that's going to be totally
>> useless. it's not just a question of how altq distinguishes traffic,
>> you're asking to totally change how altq works.
>
> Okey, i see. But I can not understand why you are sure that traffic
> can only outlet Shape , You can say that's silly to try to Shape traffic
that came,
> but if it works it's worse than outgoing (if only for tcp) it is not
> stupid ?
>
> Assume that you are right and the traffic can Shape only outlet for what
purpose then in other projects (freebsd, linux, netbsd)
> including the original altqd opportunity for shaping incoming traffic
> via CDNR has been included?
>
> This is not the presentation of claims or something else, I want to
understand why you uperlis and
> do not want to see nothing else.
What is uperlis?
>>
>> if you have some requirement for features that altq+pf doesn't have
>> at the moment, you have a few choices:
>>
>> - use different software that already does what you want.
>>
>> - pay someone to code the features.
>>
>> - code the features yourself. (if you don't code, this will require
>> learning how to do that first, obviously).
>>
> I did.
You did what?
> But it pains me to see the obvious defects in my favorite system,
> and complete indifference on the part of developers to the obvious defects.
This is not a defect. Throttling inbound traffic is meaningless. The
point of throttling traffic is to reduce load on network elements
(links, routers, etc) and possibly enforce accounting policies. The
traffic has already arrived at your router so it has already traversed
the link and been processed by the network stack. You throttle what
you can control - like the rate at which traffic from the world
egresses the internal interface on your router on its way to the host
you want throttled.
>> but, unless you want to use altq on a server (rather than a router),
>> there isn't really a problem with the queuing happening only on output.
>> just give the queues on both interfaces the same name, then you can
>> assign in both directions with a single rule.
>>
>> stupid example ruleset. not actually tested, but I have others like
>> it, and it should be enough to give you the general idea.
>>
>> -- -- -- -- --
>> altq on bge0 cbq bandwidth 4000Kb queue { normal, slow, fast }
>> altq on vlan5 cbq bandwidth 20000Kb queue { normal, slow, fast }
>> altq on vlan9 cbq bandwidth 1000Kb queue { normal, slow, fast }
>>
>> queue normal bandwidth 40% priority 4 cbq(default borrow)
>> queue slow bandwidth 10% priority 1
>> queue fast bandwidth 50% priority 7
>>
>> pass
>> pass in proto icmp queue (slow)
>> pass in proto tcp to port 22 queue (fast)
>> -- -- -- -- --
>>
>> (I think some people just look at a couple of example configs which
>> use different queue names on interfaces and assume that it's necessary,
>> but it isn't).
>
> Thanks, for this example. I did not know this.
>
> But under dynamic queues, I understand, the creation of a large number of
dynamic patterns.
> For example creates template for the queue with an indication of the speed
such as 512Kbit / s,
> and then creates template for the filter of which you can
> specify a subnet like 192.168.1.0/24 and this pattern break this subnet to
the desired number of rules in this case,
> to 254, and under each This rule will create a dynamic part of the dynamic
pattern of 512Kbit / s for each rule.
What?
-HKS
>
> --
> Best regards,
> irix mailto:i...@ukr.net
