useful description of QoS anywhere?

See Gert's comment in https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/39232.

Cheers - Bob

I've found this message already and the last reply does give some hints, but it is not explaining all the topics I've mentioned nor is it even approved by Astaro (no further reply does not mean it is correct, maybe just nobody from Astaros side reacted). Because of that I have recognized it, but did not considered it to be reliable (no offense agains hagman!). 

Therefor I repeat my question where Astaro is providing sufficient information on how to use the bandwith management features effectively?

Gert is the "inventor" of the Astaro: Astaro Management.  I think you can assume his words are gospel. [;)]

You might benefit from: Configuring QoS

Cheers - Bob

Gert is the "inventor" of the Astaro: Astaro Management.  I think you can assume his words are gospel. [;)]

ok, I will. [:)] But am I missing something? In thread "http://www.astaro.org/astaro-gateway...-limiting.html" I can not find any comment by somebody called "gert", only hagman, AlanT and yourself.

You might benefit from: Configuring QoS

Thank you for pointing me to that presentation. But it is explaining v6 not v7 and therefor gives me no new information on how to work with the v7 bandwith management correctly.

Yes, you're right, that wasn't Gert, but AlanT, Alan Toews, Astaro Director of Engineering and leader of Astaro Support Americas team.  Another person whose words on Astaro bear close attention.

Powderhound posted his experiences in: https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/39142.

Here's the thread that I remembered with Gert's participation: https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/39102.

I share your frustration with the Astaro documentation which is short on the kinds of "philosophy" discussions that let you understand how to think about various things.  That said, there have been some big improvements in the quality of the articles  on the KnowledgeBase.

Thank you for pointing me to that presentation. But it is explaining v6 not v7 and therefor gives me no new information on how to work with the v7 bandwith management correctly. 

Oops!  Time to get rid of that link - Thanks!

Cheers - Bob

Powderhound posted his experiences in: http://www.astaro.org/astaro-gateway-products/network-security-firewall-nat-qos-ips-more/25047-traffic-prioritization-observations.html.

Thanks, that makes things much clearer. But I am a little bit shocked that the limitation is taking place on a session-basis, not on a packet-basis. This is making it quite impossible to really guarantee minimum bandwiths to certain services, large downloads will block the whole mechanism.

I have now created a bandwith pool on our internal interface, limiting services HTTP, HTTPS and HTTP Proxy to 500kBit (our external connection is 1984/1984 kBit), by using a group and checking the "specifiy upper bandwith limit" checkbox. 

Problem is, that this pool is only effective for direct downloads, not for downloads using the HTTP Proxy of the ASG. But the latter is the important part for me. Which kind of traffic selector is needed for this? Currently I use "Any -> HTTP Proxy -> Any".

I share your frustration with the Astaro documentation which is short on the kinds of "philosophy" discussions that let you understand how to think about various things.  That said, there have been some big improvements in the quality of the articles  on the KnowledgeBase.

I'm glad you share my opinion. [:)] I have searched the KB for articles, but did not find some regarding v7 version of bandwith management. Maybe I overlooked one, at least I did not find one.

I hope that documentation will be improved in the future. It would be a shame if Astaro is implementing nice features, but describe them so badly that nobody can use them or people give up frustratedly. For us users the ASG is a black box and without knowing how it is ticking, we don't know how to set it up correctly.

Bye, Frank

I think the limitation to a session basis is because of the way the world's webservers work.  If you also enable QoS on the External interface, the inbound traffic on it is then managed by "various techniques such as Stochastic Fairness Queuing (SFQ) or Random Early Detection (RED)."

In any case, the Astaro QoS focuses on guaranteeing bandwidth to specific traffic, and is not organized around limiting other traffic.  That, in general, allows maximal usage of bandwidth instead of artificially limiting some traffic when it's unnecessary.  There's another thread that was active yesterday with a number for a KB article about guaranteeing bandwidth to an IPsec VPN.

Currently I use "Any -> HTTP Proxy -> Any".

I don't think there should be any port 8080 traffic back to internal IPs from the Internal interface, and I would have expected the rule to apply to traffic coming from the internal interface.  If you were to keep that, then, instead of the first "Any," I think you would want "Internet" which is included in V7.5, but needs to be defined in earlier versions: 0.0.0.0/0 bound to External interface.

Even those of us who charge for helping people with Astaro need better documentation.  That's one of the reasons I've been so active here over the last year - pushing and proding others to document and then attempting to repeat and summarize to be sure I've understood correctly.

Little by little, the stuff on here gets into the KnowledgeBase.  I keep pushing Astaro to adopt the Amazon.com model* for handling support requests, but the light hasn't gone on yet.

Cheers - Bob
* Treat each request as a request to improve the programs and/or documentation.

I don't think there should be any port 8080 traffic back to internal IPs from the Internal interface, and I would have expected the rule to apply to traffic coming from the internal interface.  If you were to keep that, then, instead of the first "Any," I think you would want "Internet" which is included in V7.5, but needs to be defined in earlier versions: 0.0.0.0/0 bound to External interface.

After upgrading to v7.500, I have changed the traffic selector from "Any -> HTTP Proxy -> Any" to "Internet -> HTTP Proxy -> Any", but with no success. Downloads are still consuming the complete bandwidth. 

And taking a look into the traffic with Ethereal shows that the packets are coming from :8080 to :.

How is the service specification of a traffic selector meant? The port of the selected service is considered to be the target port, no matter on which interface the selector is bound later on? In this case it would be clear that my selector can not work, because the traffic is *coming* from that port (8080), not *going* to that port.


Another question: I've created traffic selectors and bandwidth rules to guarantee bandwidth for one VPN tunnel. Hopefully it works, but so far I can not easily check this (one of my problems with Astaro's BW management). Would it make sense to use the TOS-Bits "minimize delay" in these traffic selectors?

Bye, Frank

At which time of data transfer the traffic selectors are checked

at the time a packet ENTERS an interface and also when it LEAVES the ASG on an interface

what are the source and destination from QoS's perspective? 

source = the sender of the packet, destination = the recipient of the packet

On which interface(s) do I have to create the bandwith pools? 

always on the interface where the traffic LEAVES the ASG

How can I check that a traffic selector/pool is hit by the current traffic? 

not really at all, there is no tools or so, besides the bandwitdth monitor.

How can I configure QoS for VPNs? 

see kb article 293190

Can I maybe prioritize only outgoing traffic at all, no incoming traffic (the beginning of the QoS chapter in the manual sounds like that)??

Yes, you have read the documentation ;-) The QoS shaping works mainly for outgoing traffic - outgoing means "traffic that leaves the ASG on an interface"

And taking a look into the traffic with Ethereal shows that the packets are coming from :8080 to :.

How is the service specification of a traffic selector meant? The port of the selected service is considered to be the target port, no matter on which interface the selector is bound later on? In this case it would be clear that my selector can not work, because the traffic is *coming* from that port (8080), not *going* to that port.

ok, you are talking about the traffic which is created by clients which have the ASG http proxy  to surf the web. So it is on your internal (LAN) interface. The proxy downloads the web traffic on the EXTERNAL interface, so the QoS rule on the INTERNAL interface won´t help you anything there. YOu have to define guarantees for the non-httpttraffic (like VPN or VoIp) on the EXTERN IF then you will achive that the web proxy will try to limit it´s download speed. However, as the downloaded data is coming INTO the ASG, and the packet shaping is mainly for OUTGOING traffic, the efficiency of your efforts will be small.

[QUOTE=starfish4711;124722]Another question: I've created traffic selectors and bandwidth rules to guarantee bandwidth for one VPN tunnel. Hopefully it works, but so far I can not easily check this (one of my problems with Astaro's BW management). Would it make sense to use the TOS-Bits "minimize delay" in these traffic selectors?[QUOTE]

No, the TOS and DSCP Bits are only usefull if the traffic enters the ASG with these bits ALREADY set. The ASG doesn´t set these bits on traffic that didn´t have it set already.

Try using "iftop" on the command line to detect whether your QoS rules have en effect or not.

see kb article 293190

yes, that is basically what I have done.

ok, you are talking about the traffic which is created by clients which have the ASG http proxy  to surf the web. So it is on your internal (LAN) interface. The proxy downloads the web traffic on the EXTERNAL interface, so the QoS rule on the INTERNAL interface won´t help you anything there. YOu have to define guarantees for the non-httpttraffic (like VPN or VoIp) on the EXTERN IF then you will achive that the web proxy will try to limit it´s download speed. However, as the downloaded data is coming INTO the ASG, and the packet shaping is mainly for OUTGOING traffic, the efficiency of your efforts will be small.

Ok, but interesting point is, that a traffic selector for HTTP does work on the internal interface, as long as the http proxy is not involved. That means if I download a file directly through the firewall (by creating a temp. fw rule and disabling the proxy settings in my browser) the download speed is reduced by my bandwith pool at the internal interface (of course in this case the traffic selector is using protocol http and https instead of http proxy).

It's interesting because of the fact that in this case the traffic selector should not be able catch the traffic, giving the assumption that its protocol selection is looking at the *destination* port.

I've tested this with firmware 7.403, before I upgraded to 7.500 to follow BAlfson's suggestion (see my comment inside this thread). 

I admit that limiting the http traffic on the internal interface is not really what I wanted to do, but I guess that it would solve my problem: the traffic limit will delay the incoming download packets to the clients, causing the clients to demand the next download piece later as without the traffic limit.

No, the TOS and DSCP Bits are only usefull if the traffic enters the ASG with these bits ALREADY set. The ASG doesn´t set these bits on traffic that didn´t have it set already.

ok, besides the TOS/DSCP settings in a QoS rule, can I configure ASG to set this bits anywhere else (would it make sense to use these flags on the internet, I'm afraid  they are not used there anyway?)?

Try using "iftop" on the command line to detect whether your QoS rules have en effect or not.

nice tool, thanks! :-)

But how can I use it to check whether my QoS rules are working? Basically it shows the same info as the bandwidth monitor (just much faster, that's nice) and only because my "QoS enhanced" connection is listed here it does not prove that my rule is working. Or am I mistaken?