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

QoS for Youtube

Dear Folks

Our BYOD users are growing and growing. We have a limited WAN bandwidth of ## Mbit/s. Sometimes we experiencing slow Internet access for everyone and I notice the Internet line port's network usage is 100%. 

According to the logs Youtube is being used most of the time. I guess it's what's causing the trouble.

I would like to limit the bandwith for Youtube as a result of this.

Under (UTM v9.103-5) Interfaces & Routing > QoS > Status I have all interfaces deactivated. We are using a 4x1Gbit Link Aggregation for different VLANs whereby I just want to limit Youtube access for a specific VLAN.

Under Traffic Selectors I created a new selector: Source VLAN->Application Youtube > Any
I also created a new Download Throttling rule: Limit: 10240 kbit/s, Limit: Shared, above Traffic Selector

Does it work that way and will the specific VLAN be limited to 10Mbit for its Youtube usage now? Or am I missing an important part?

Thank you in advance! I am excited to learn something new! :-)
--Uwe


This thread was automatically locked due to age.
  • FYI: 

    The general slowness for downloads has been solved: The UTM needed to be restarted. Meh...
  • Glad that the reboot solved your slowness issue.

    I got told by our Sophos UTM reseller that QoS ONLY works for outbound traffic.

    Yes and no.  You can prioritize or limit outbound traffic, but you only can limit some inbound traffic.  That means that you often can't prevent some inbound traffic from filling the pipe, thereby choking the traffic you prefer.  This is why I suggested selecting ECN in Post #8 above.

    Actually the Flow Monitor (Application Control) is the only hint I am able to use to identify the current bandwidth usage, isn't it?

    Yes, but Application Control and Bandwidth Usage reporting would help you to identify particular individuals and sites that seem to be problems.  Some problems are only solvable with rules that are enforced.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Actually the Flow Monitor (Application Control) is the only hint I am able to use to identify the current bandwidth usage, isn't it?


    Hi, 

    Other ways to see bandwidth usage:

    1. 'iftop' is available on the console / shell / ssh terminal

    2. 'iptraf' can be hacked in if you don't like iftop.

    Barry
  • Dear BAlfson

    I didn't hear about thge ECN yet but read through the help page. Hmm... Would that be the end point that the ISP should control the QoS from, too?

    Regarding the Flow Monitor:
    I turned off QoS again because I think it caused the problems over the past few days.

    Please have a look on the screenshots I just captured. The bandwidth use is on maximum and when I sum up the according column I don't come up to 20Mbit. Also when clicking on the iTunes Clients I just see the Internet interface. 
    I expect that streaming services are taking up all the bandwidth

    So I cannot say WHO is causing WHICH bottlenecks, means WHO causes WHAT amount of bandwidth use with WHICH service. Can you help with that?
  • Or does the Flow Monitor just show outbound traffic? And not all the packets that go from the Internet to the internal networks? Because most of it is INBOUND traffic from the WAN...
  • BarryG: AWESOME!

    Thanks to your great hint I am able to identify the root cause of the bottleneck. See the attached picture. it's the Akamai Update Servers!!

    For now I just want to block all update possibilities for all networks (quick fix as step one).
    Although I enabled an Akamai Application Control rule and set up a "drop" rule for any->any->[2x IP Addresses according to screenshot] it doesn't work. How can I kill the open update streams? Or what would you do to prevent this communication?
  • Update: After some while it is getting better now...

    I am waiting now if that was the entire problem/solution.
  • SOLVED.

    Yes, the root cause was the Akamai Server Farm IP Addresses. I will stay tuned and find out what impacts these restrictions have on our network. 
    However, blocking the Akamai IP addresses (not a range yet) that the SSH command tool "iftop" revealed in Application Control and Firewall helps for now!

    Back to studio! :-)
  • We had a similar issue in the past where the Adobe Update Servers sucked up all bandwith because of the http proxy scanning and delaying the transfer so that the client looped the updates over and over again. We put the Adobe Update URL's the 'always block' lists of the proxy profiles.

    Regards
    Manfred
  • Hi, LOTS of sites (and apps) use Akamai; perhaps you can find which computer was accessing it and figure if an application is trying to update too often.

    Barry