Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 16 replies
  • Subscribers 2 subscribers
  • Views 8020 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

useful description of QoS anywhere?

starfish4711
Hi,

using ASG220 v7.405 I want to use the bandwidth management features/QoS to guarantee a minimum bandwith to a certain VPN tunnel and reduce latency of this connection (because of VoIP traffic going through this tunnel). In addition I like to limit the incoming traffic caused by file downloads using the HTTP proxy.

I've checked the current manual, the knowledge base and this forum and came to the result, that in these places no sufficient description can be found (manual/kb) and other people are also confused how to use the feature (forum).

The manual only describes how to enter data into the forms, but does not describe how the QoS systems works at all. Nor does it provide any useful examples. Therefor I have no idea in which way I have to define the traffic selectors or pools. I've tried several times, but with no luck. 

questions over questions:
At which time of data transfer the traffic selectors are checked, what are the source and destination from QoS's perspective? On which interface(s) do I have to create the bandwith pools? How can I check that a traffic selector/pool is hit by the current traffic? How can I configure QoS for VPNs? Can I maybe prioritize only outgoing traffic at all, no incoming traffic (the beginning of the QoS chapter in the manual sounds like that)??

Therefor: is there any detailed description of the QoS feature? Examples?

Thanks in advance!


This thread was automatically locked due to age.
  • 0 in reply to starfish4711
    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).

    Yes, it´s exactly like this. I think you even could make it WITH the proxy enabled, however the proxya will EXTERNALLY (on the WAN interface) always download with max speed.

     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.

    Hmm..think...think......it´s been a long time since I experimented with this so I am not 100% sure what trhe correct traffic selector would be. It can be that you have to define a "vice versa" selector (i.e. src-port 80, dest-poret 1:65535) so it matches. 

    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.


    Yes, it is not "elegant" (and may cause other problems on the WAN line because it can happen the client  will send out many retransmit packets) but in general, it works.


     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?)?

    No, you can´t (and - as you suspected on your own - it would help you much as no Internet provider really cares about those bits. It is normally used inside MPLS networks).

    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?


    The only way I know to check whether a QoS rule matches is limiting the traffic in the rule so much, that you can "measure" it. I.E. if you wantr whether your http rule matches, simply define the rule, then confdigure it to use not more than 5 kBit/second. Then make a download. If it is slooooow, your rule matches, if not, it doesn´t :-)
  • 0
    starfsih, it occurs to me that we haven't heard the complaint to which you're reacting.  You've explained the problems you've had in attempting the solution you've conceived, but we haven't challenged that original choice of that solution yet.  What is the motivation for wanting to limit bandwidth if that's not necessary to guarantee bandwidth to the VPN tunnel?  I ask because I don't think QoS is well-enough understood to have "standard" solutions for given scenarios.

    Cheers - Bob
  • 0 in reply to BAlfson
    starfsih, it occurs to me that we haven't heard the complaint to which you're reacting.


    Basically I want to guarantee a certain bandwidth for IP telephones, which are connected to our main PBX system via a VPN link.

    To reduce complexity of the problem, I falled back to guarantee the bandwidth to the complete VPN link, not only the traffic of the phones.


    What is the motivation for wanting to limit bandwidth if that's not necessary to guarantee bandwidth to the VPN tunnel?


    Just the experience that problems with the phones are always connected with huge downloads at the same time (ok, no surprise). Therefor I want to take them out of the picture. I agree that limiting a service without need is not the best solution, but at the moment it seems to me that boosting the VPN link is not sufficient enough. 

    Cheers, Frank
  • 0
    Thanks, that's really helpful.  One of the threads I listed on the first page of this thread is about VPNs and confirms that you can't put a traffic slector on traffic inside the VPN, only on the IPsec packets themselves.

    Now, I'm not certain about this, but I think you might only need to limit HTTP traffic to 80-to-90% of your download speed instead of restricting it dramatically.  That would be a traffic selector like 'Internet -> HTTP -> Internal (Network)' and a bandwidth pool on the Internal interface.  I'd be curious to know if you see any difference in VoIP sound quality between limiting HTTP to 20% instead of 80%.

    Cheers - Bob
  • 0 in reply to BAlfson
    Now, I'm not certain about this, but I think you might only need to limit HTTP traffic to 80-to-90% of your download speed instead of restricting it dramatically.  That would be a traffic selector like 'Internet -> HTTP -> Internal (Network)' and a bandwidth pool on the Internal interface.


    no, that does not work. But I solved it now: I created a new service definition for the traffic back from the HTTP Proxy to the clients (source port 8080, destination port 1:65535) and used that for my traffic selector ("internal (Address) →  → Internal (Network)"). Now the downstream data is limited. We will check whether it will enhance VoIP quality.

    Thanks so far!
  • 0 in reply to starfish4711
    Excellent!  Thanks for posting that.  Now that I see your traffic selector, it makes perfect sense.

    Did you also try setting a bandwidth guarantee for IPsec on the External interface?

    I'll be curious to know if you see a difference between limiting 'internal (Address) →  → Internal (Network)' to 80% or some other number much smaller.

    Very cool.

    Cheers - Bob