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?

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
  • Tried that Bruce.  Does not work I think because the proxy is acting as a client buffering full speed from the Tinterweb then trying to serve to the LAN throttled.  

    My next throw of the dice is to disable IDS, Web and App proxies so it is basically just a router, and try what you suggested to see if that works.   

    I don't know enough about this stuff, but presumably we cannot control a TCP stream by the window/ack mechanism can we?  That would mean having the QOS mechanism embedded in the TCP driver, wouldn't it?  Be awesome if we could because then we could throttle any TCP stream in the download direction on the external interface without losing a single packet or forcing a re-transmit.  

    I was going to use the 1k subnet that Netflix's content servers are on in Europe to do my "application recognition".   Think that may work but trying to find a 1 hour slot to do the watching of another couple of episodes of Breaking Bad (while working this issue of course).
Reply
  • Tried that Bruce.  Does not work I think because the proxy is acting as a client buffering full speed from the Tinterweb then trying to serve to the LAN throttled.  

    My next throw of the dice is to disable IDS, Web and App proxies so it is basically just a router, and try what you suggested to see if that works.   

    I don't know enough about this stuff, but presumably we cannot control a TCP stream by the window/ack mechanism can we?  That would mean having the QOS mechanism embedded in the TCP driver, wouldn't it?  Be awesome if we could because then we could throttle any TCP stream in the download direction on the external interface without losing a single packet or forcing a re-transmit.  

    I was going to use the 1k subnet that Netflix's content servers are on in Europe to do my "application recognition".   Think that may work but trying to find a 1 hour slot to do the watching of another couple of episodes of Breaking Bad (while working this issue of course).
Children
  • Tried that Bruce.  Does not work I think because the proxy is acting as a client buffering full speed from the Tinterweb then trying to serve to the LAN throttled.  

    My next throw of the dice is to disable IDS, Web and App proxies so it is basically just a router, and try what you suggested to see if that works.   

    I don't know enough about this stuff, but presumably we cannot control a TCP stream by the window/ack mechanism can we?  That would mean having the QOS mechanism embedded in the TCP driver, wouldn't it?  Be awesome if we could because then we could throttle any TCP stream in the download direction on the external interface without losing a single packet or forcing a re-transmit.  

    I was going to use the 1k subnet that Netflix's content servers are on in Europe to do my "application recognition".   Think that may work but trying to find a 1 hour slot to do the watching of another couple of episodes of Breaking Bad (while working this issue of course).


    Then I suggest starting an official support case with Sophos.  You may be having the issue William speaks of.