Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 2 subscribers
  • Views 11775 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

How Can I: Classify Netflix Traffic from Unclassified Traffic?

PhunkFX
On my college campus, where I administer a software based UTM setup, we see astronomical loads of Netflix traffic clogging up our pipe.  I have noticed in the flow monitor that it comes up as UNCLASSIFIED and there is no way to throttle that kind of traffic. 

Is there a way that I can classify Netflix so that it can be throttled?  Or do any of the gurus out here have any other ideas?  I'm all ears.  On Tuesdays and Thursdays, my WAN link is pegged at 100% 100mb/s from 8:30am to 2:30pm, and the majority of the traffic is Netflix.  Funny really.  

Thanks.


This thread was automatically locked due to age.
Parents
  • 0
    Scott, 

    I can get FTP to control nicely in download using Download throttling.   

    Is the difference with Netflix that the web proxy is acting as a buffering client for Netflix before QOS (download or upload) can kick in?  

    Thanks in advance,
  • 0 in reply to AdrienBelcourt
    If all else fails, create an regular (upload) qos rule for Netflix, throttling it, BUT use the internal interface(s) of the UTM, as the source parameter, and the client network(s) you wish to throttle it for as the destination -- and place the rule on the internal interface(s) of the utm.  It's sort of an upload QoS rule in reverse... it will work, I've done it before (assuming application control is detecting Netflix traffic correctly -- I'm not aware that it isn't, but one poster here has said it isn't working right).  This is what I used to do all the time before we had download throttling.  Squeeze the pipe on the other side, the flow will slow on the internet side [:)]
  • 0 in reply to BrucekConvergent
    If all else fails, create an regular (upload) qos rule for Netflix, throttling it, BUT use the internal interface(s) of the UTM, as the source parameter, and the client network(s) you wish to throttle it for as the destination -- and place the rule on the internal interface(s) of the utm.  It's sort of an upload QoS rule in reverse... it will work, I've done it before (assuming application control is detecting Netflix traffic correctly -- I'm not aware that it isn't, but one poster here has said it isn't working right).  This is what I used to do all the time before we had download throttling.  Squeeze the pipe on the other side, the flow will slow on the internet side [:)]


    if you depend on the classification(which this apparently does) as long as the proxy has this rdns/classification problem it isn't going to be reliably controllable.
Reply
  • 0 in reply to BrucekConvergent
    If all else fails, create an regular (upload) qos rule for Netflix, throttling it, BUT use the internal interface(s) of the UTM, as the source parameter, and the client network(s) you wish to throttle it for as the destination -- and place the rule on the internal interface(s) of the utm.  It's sort of an upload QoS rule in reverse... it will work, I've done it before (assuming application control is detecting Netflix traffic correctly -- I'm not aware that it isn't, but one poster here has said it isn't working right).  This is what I used to do all the time before we had download throttling.  Squeeze the pipe on the other side, the flow will slow on the internet side [:)]


    if you depend on the classification(which this apparently does) as long as the proxy has this rdns/classification problem it isn't going to be reliably controllable.
Children
No Data