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

Does UTM do Equalizing?

UweT
Hi Folks!

We are facing the problem of some LAN connections jamming our WAN bandwidth.

So I am looking for Equalizing options that i.e. Netequalizer provides.

Please have a 6min look onto that video. Although the device would be in front of the UTM and behind our WAN router: Can you tell if the Sophos UTM does the same in the first row? We should be able to use what we have already. As written in a thread before we have QoS set up now but it is still not running properly.


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

    There's not much you can do if your ISP doesn't support ECN.  When the inbound pipe is filled from the outside, it's hard to control. I didn't look at the video, but there's no way I know of for NetEqualizer to solve the download problem any better than the UTM.  If there is, I'd be glad to learn about it...

    Cheers - Bob
  • 0
    Hopefully SOPHOS will add support for CoDel any time soon...
  • 0
    According to 67ef1d, CoDel is in 9.1: https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/21914.  Mario, does this mean that Download Throttling can now tell the ISP's router what traffic flow to prioritize?

    Cheers - Bob
  • 0 in reply to BAlfson
    Codel is indeed implemented in this version. However as 67ef1d pointed out, the implementation doesn't effect the root queues. At this point, I don't see any difference between the user experience when using old HFSC qdisks (like in older versions of astaro) or using codel qdisks like in the current version[:$]
    gatekeeper:/home/login # tc -s qdisc ls dev eth0
    qdisc hfsc 1: root refcnt 2 default 5 
     Sent 3087851 bytes 18956 pkt (dropped 0, overlimits 3615 requeues 0) 
     backlog 0b 0p requeues 0 
    qdisc fq_codel 8052: parent 1:2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms 
     Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
     backlog 0b 0p requeues 0 
      maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
      new_flows_len 0 old_flows_len 0
    qdisc fq_codel 8053: parent 1:3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms 
     Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
     backlog 0b 0p requeues 0 
      maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
      new_flows_len 0 old_flows_len 0
    qdisc fq_codel 8054: parent 1:4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms 
     Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
     backlog 0b 0p requeues 0 
      maxpacket 256 drop_overlimit 0 new_flow_count 0 ecn_mark 0
      new_flows_len 0 old_flows_len 0
    qdisc fq_codel 2: parent 1:5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms 
     Sent 3087796 bytes 18955 pkt (dropped 0, overlimits 0 requeues 0) 
     backlog 0b 0p requeues 0 
      maxpacket 6459 drop_overlimit 0 new_flow_count 5042 ecn_mark 0
      new_flows_len 0 old_flows_len 1
  • 0
    Bill, does putting a Download Throttle in place for specific traffic cause fq_codel to instruct the upstream router to reduce the amount of such traffic it sends down the pipe to the UTM?  For example, at one site, I made two Download Throttling rules on a 20Mbps line:
    [LIST=1]
    • Limit VoIP to 19 Mbps
    • Limit All to 19 Mbps
    [/LIST]
    My goal was to guarantee 1Mbps to incoming VoIP.

    Cheers - Bob
  • 0
    BAlfson, that is still not possible. Download-limiting still requires dropping packets and cause the TCP sender to send fewer packets.
  • 0 in reply to BAlfson
    Bill, does putting a Download Throttle in place for specific traffic cause fq_codel to instruct the upstream router to reduce the amount of such traffic it sends down the pipe to the UTM?  ...
    My goal was to guarantee 1Mbps to incoming VoIP.
    Remember all CoDel tries to do is minimize delay by trying to limit buffering. It is still fairly new so in reality will have minimal support from ISP side. 
    For what you are trying to achieve, I would do it the old fashioned way on internal LAN. Download throttling is not optimum for voip etc.

    Since the newer versions of UTM are proxy aware, I would put three rules on internal 



    1. allow voip with guaranteed 1mbps and max 19 mbps (or whatever number)


     


    2. Allow ANY Webadmin ANY line Speed 
    3. Allow ALL ANY ANY guranteed 1Kbps 19 mbps max     





    This is the throttle all traffic selector 




    This gives you guaranteed bandwidth in each pool instead of a dumb throttled pipe. But you already knew that didn't you ;-) You can probably modify the third rule to destination internet and can probably skip the second rule. 

    Regards
    Bill
  • 0 in reply to BAlfson
    Hi BAlfson

    as I got to hear NetEqualizer works like a charm in another facility. Didn't contact them yet. But the video should show you how the concept works.

    Anyway, we have identified and mixed a major problem on our site that instantly fixed a tail of other problems. Probably also the application control/bandwith throttleling. I still do monitor this thingie. Currently all inbound traffic seems to be kept "in line".

    Anyway the problem was that the LAN port interface on the ISP's switch on our site was configured with 100Mbit/s HALF duplex. It is connected to the WAN UTM interface that works with 100Mbit/s FULL Duplex as it seemed/seems. I couldn't find the section on how to configure the UTM's port but we set the ISP's switch port to FULL duplex. It instantly solved a bunch of problems! And yes, also speed!

    The thing is when having a manually set port to 100Mbit/s FULL duplex you HAVE to configure the other end as well . All automatically recognized and configured ports work with HALF duplex by default (industrial standard).

    That's the story...
  • 0 in reply to UweT
     I couldn't find the section on how to configure the UTM's port but we set the ISP's switch port to FULL duplex. It instantly solved a bunch of problems! And yes, also speed!

    The thing is when having a manually set port to 100Mbit/s FULL duplex you HAVE to configure the other end as well . All automatically recognized and configured ports work with HALF duplex by default (industrial standard).


    You can hard-set an interfaces speed / duplex under Interfaces&Routing/Interfaces/Hardware Tab... just hit the edit button.

    Speed/Duplex mismatch is a common issue with all sorts of equipment -- there's certain equipment I've used that, even with both sides hard-set to the same speed / duplex, and both support auto MDI/X, that I've had to craft a crossover cable to get them to work together.  On the UTM, an easy way to discover a speed/duplex or other interface issue is to log into the shell, su up to root, then run ifconfig ethx (where ethx is the Ethernet interface you want to check)... look for errors, overruns, frame errors, collisions, etc. constantly incrementing.
  • 0 in reply to BrucekConvergent
    there's certain equipment I've used that, even with both sides hard-set to the same speed / duplex, and both support auto MDI/X, that I've had to craft a crossover cable to get them to work together. 


    Someone else this week had the same problem with a Cisco device and UTM on a server, and I've had it in the past with a Cisco switch.

    'ethtool' is another useful command-line tool to check speeds, etc., e.g. 
    ethtool eth0

    Barry