Welcome, Guest. Please login or register.
Did you miss your activation email?
Wednesday 30 October 2024, 04:35:12 pm

Login with username, password and session length

Visit the Official Endian Bug tracker  HERE
14248 Posts in 4376 Topics by 6515 Members
Latest Member: hulteends
Search:     Advanced search
+  EFW Support
|-+  Support
| |-+  General Support
| | |-+  QoS not working on 3.2.0 alpha 1
0 Members and 2 Guests are viewing this topic. « previous next »
Pages: [1] Go Down Print
Author Topic: QoS not working on 3.2.0 alpha 1  (Read 26305 times)
escotland
Full Member
***
Offline Offline

Posts: 23


« on: Tuesday 08 March 2016, 09:45:17 pm »

I was trying to add the range from 192.168.20.100 to 192.168.20.200 line by line (yes, 100 lines that is) in a rule, after I had created a QoS device and two classes, but, after I pasted the ips in, I got this attached error displayed.

I am trying to set two rules so that any IPs between .100 and .200 would get 40 percent of available traffic, and the rest, the staff network static ones, would get the other half at all times.

However, because I can't just define an IP range from the UI and have to manually type in the IPs one by one, I had to try and add all of them individually, by using magic-cookie co uk plist html to create them.

I then just have to delete the QoS as it does not work.

We updated to 3.2.0 alpha 1 because QoS didn't work on 2.5.1, but, I see that there are issues here as well.

Does anyone have a workaround for this at the moment?

I filed a bug report at jira endian com browse UTM-1438 but I'm sure I had put it under the wrong project, as I couldn't find a QoS service under Endian Firewall Community and didn't know what to put it under.


Thanks.

(I can't upload an attachment as the moment as this forum is showing me an error message saying that the attachment directory is not writable...)
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #1 on: Wednesday 09 March 2016, 05:27:54 am »

You shouldn't manually add 100 IPs, what you need is to convert your IP range to CIDR notation:
http://ip2cidr.com/
Your range is converted to:
192.168.20.100/30
192.168.20.104/29
192.168.20.112/28
192.168.20.128/26
192.168.20.192/29
192.168.20.200/32

Ip ranges are a no-no in many firewall systems, they usually use the CIDR notation.
It can be worse on some cases, but it's cleaner.
Logged
escotland
Full Member
***
Offline Offline

Posts: 23


« Reply #2 on: Wednesday 09 March 2016, 05:53:03 am »

You shouldn't manually add 100 IPs, what you need is to convert your IP range to CIDR notation:
http://ip2cidr.com/
Your range is converted to:
192.168.20.100/30
192.168.20.104/29
192.168.20.112/28
192.168.20.128/26
192.168.20.192/29
192.168.20.200/32

Ip ranges are a no-no in many firewall systems, they usually use the CIDR notation.
It can be worse on some cases, but it's cleaner.

Right, thank you so much, I had no idea I was supposed to use that, if only the error I was getting actually specified that.

The only problem I have now is that I can't really do anything with the above as clamav is crazily eating up all of my CPU resources and for the life of me I just can't turn it off.

It's disabled from the web filter default policy and everything else, but the thing just won't turn off.


I'll try what you suggested when I finally get that sorted and let you know if it worked.


THanks.
Logged
escotland
Full Member
***
Offline Offline

Posts: 23


« Reply #3 on: Wednesday 09 March 2016, 06:00:08 am »

You shouldn't manually add 100 IPs, what you need is to convert your IP range to CIDR notation:
http://ip2cidr.com/
Your range is converted to:
192.168.20.100/30
192.168.20.104/29
192.168.20.112/28
192.168.20.128/26
192.168.20.192/29
192.168.20.200/32

Ip ranges are a no-no in many firewall systems, they usually use the CIDR notation.
It can be worse on some cases, but it's cleaner.

Naah, it doesn't work, same error, what am I doing wrong?

What I'm trying to do is to create a rule that forces IPs inside the above range to go into a certain class regardless of the protocol that they use.

I'm basically trying to force our guest DHCP clients to only have half of our "entire" 8 mbps internet bandwidth, so that our staff computers can have the other half at all times.

In all honesty, I don't even know if I'm going about this the right way, as I'm usually used to point and shoot bandwidth management in Draytek routers.

Is there some other way of achieving the above perhaps?
Logged
escotland
Full Member
***
Offline Offline

Posts: 23


« Reply #4 on: Wednesday 09 March 2016, 06:43:41 am »

You shouldn't manually add 100 IPs, what you need is to convert your IP range to CIDR notation:
http://ip2cidr.com/
Your range is converted to:
192.168.20.100/30
192.168.20.104/29
192.168.20.112/28
192.168.20.128/26
192.168.20.192/29
192.168.20.200/32

Ip ranges are a no-no in many firewall systems, they usually use the CIDR notation.
It can be worse on some cases, but it's cleaner.

Could it be that it's not working for me because I'm not entering anything in the destination field? I'd want the rule to apply to any outgoing destination as per the source above.

I'm leaving the destination field empty. Am I supposed to put something else in?


Thanks.
Logged
escotland
Full Member
***
Offline Offline

Posts: 23


« Reply #5 on: Wednesday 09 March 2016, 07:58:43 pm »

Yup, QoS definitely doesn't work, I've just tried adding one single IP into the source list, and I still get the same error message that says that "The management interface encountered an error. Please contact an administrator. "

QoS is really broken in 3.2.0 alpha 1...
Logged
escotland
Full Member
***
Offline Offline

Posts: 23


« Reply #6 on: Thursday 10 March 2016, 12:33:51 am »

I've created a bug report at https://jira.endian.com/browse/UTM-1443 and happily someone has responded and the issue is being worked on. Yey.
Logged
mrkroket
Hero Member
*****
Offline Offline

Posts: 495


« Reply #7 on: Friday 11 March 2016, 02:39:03 am »

I still haven't used 3.2.0, but on prior versions QoS works more or less.

1-On Services->QoS->Devices create a device for uplink, with the 90% of your real bandwidth.
2-On classes, create all the classes you need. IMPORTANT! Reserved values must total 100% for each device, otherwise it won't work. Better use always % instead of kbps.
3-On rules, you can add any rule you need, only take into account that rules are evaluated in order, and the first one that matches your traffic will be used.

Once you configure all, you can see the traffic on console, with the command tc -s qdisc or watch -n 1 'tc -s qdisc' for continous monitoring.
If you see that all bytes goes for a single sfq, your rules are wrong and all traffic goes always via a single rule.

If you want to separate your total bandwidth in half, I would do:
1-Create the device with the 90% of the real bandwidth (use speedtest or similar to get the real speed, while nothing is using the internet). I.E. you have 8000/8000 I'd use 7200/7200.
2-Create two blocks of classes, half for one group and half for the rest, like that:
   class1: Users_HighPriority   - 2% reserve - 100% limit
   class2: Users_UDPRealtime - 10% reserve - 100% limit
   class3: Users_WebSurf - 15% reserve - 95% limit
   class4: Users_General - 23% reserve - 100% limit

   class5: Guest_HighPriority   - 2% reserve - 100% limit
   class6: Guest_UDPRealtime - 10% reserve - 100% limit
   class7: Guest_WebSurf - 15% reserve - 95% limit
   class8: Guest_General - 23% reserve - 100% limit

The important thing is that all classes must add up 100% reserve (limit could be anything)

3-Create rules for that

Rule1: Source: <IP DHCP range> Dest: <ANY> Protocol: icmp  Traffic Class: Guest_HighPriority
Rule2: Source: <ANY> Dest: <IP DHCP range> Protocol: icmp  Traffic Class: Guest_HighPriority
Rule3: Source: <ANY> Dest: <ANY> Protocol: icmp  Traffic Class: Users_HighPriority

Rule4: Source: <IP DHCP range> Dest: <ANY> Protocol: udp  Traffic Class: Guest_UDPRealtime
Rule5: Source: <ANY> Dest: <IP DHCP range> Protocol: udp  Traffic Class: Guest_UDPRealtime
Rule6: Source: <ANY> Dest: <ANY> Protocol: udp  Traffic Class: Users_UDPRealtime

Rule4: Source: <IP DHCP range> Dest: <ANY> Protocol: tcp Port: 80,443  Traffic Class: Guest_WebSurf
Rule5: Source: <ANY> Dest: <IP DHCP range> Protocol:  tcp Port: 80,443  Traffic Class: Guest_WebSurf
Rule6: Source: <ANY> Dest: <ANY> Protocol: tcp Port: 80,443  Traffic Class: Users_WebSurf

Rule7: Source: <IP DHCP range> Dest: <ANY> Protocol: <ANY>  Traffic Class: Guest_General
Rule8: Source: <ANY> Dest: <IP DHCP range> Protocol:  <ANY>  Traffic Class: Guest_General
Rule9: Source: <ANY> Dest: <ANY> Protocol: <ANY>  Traffic Class: Users_General

It should work splitting the bandwidth in half, and also priorizing traffic inside these two main groups (so someone dl things won't block voice traffic).
Logged
escotland
Full Member
***
Offline Offline

Posts: 23


« Reply #8 on: Friday 11 March 2016, 03:37:40 am »

Thanks for that, but, nothing works, even if I create a new QoS device with 7000 download and 300 upload and leave the default classes on and then try to create one simple rule it breaks.

It simply does not work at the moment, do please try it on 3.2.0 alpha.


Thanks

I still haven't used 3.2.0, but on prior versions QoS works more or less.

1-On Services->QoS->Devices create a device for uplink, with the 90% of your real bandwidth.
2-On classes, create all the classes you need. IMPORTANT! Reserved values must total 100% for each device, otherwise it won't work. Better use always % instead of kbps.
3-On rules, you can add any rule you need, only take into account that rules are evaluated in order, and the first one that matches your traffic will be used.

Once you configure all, you can see the traffic on console, with the command tc -s qdisc or watch -n 1 'tc -s qdisc' for continous monitoring.
If you see that all bytes goes for a single sfq, your rules are wrong and all traffic goes always via a single rule.

If you want to separate your total bandwidth in half, I would do:
1-Create the device with the 90% of the real bandwidth (use speedtest or similar to get the real speed, while nothing is using the internet). I.E. you have 8000/8000 I'd use 7200/7200.
2-Create two blocks of classes, half for one group and half for the rest, like that:
   class1: Users_HighPriority   - 2% reserve - 100% limit
   class2: Users_UDPRealtime - 10% reserve - 100% limit
   class3: Users_WebSurf - 15% reserve - 95% limit
   class4: Users_General - 23% reserve - 100% limit

   class5: Guest_HighPriority   - 2% reserve - 100% limit
   class6: Guest_UDPRealtime - 10% reserve - 100% limit
   class7: Guest_WebSurf - 15% reserve - 95% limit
   class8: Guest_General - 23% reserve - 100% limit

The important thing is that all classes must add up 100% reserve (limit could be anything)

3-Create rules for that

Rule1: Source: <IP DHCP range> Dest: <ANY> Protocol: icmp  Traffic Class: Guest_HighPriority
Rule2: Source: <ANY> Dest: <IP DHCP range> Protocol: icmp  Traffic Class: Guest_HighPriority
Rule3: Source: <ANY> Dest: <ANY> Protocol: icmp  Traffic Class: Users_HighPriority

Rule4: Source: <IP DHCP range> Dest: <ANY> Protocol: udp  Traffic Class: Guest_UDPRealtime
Rule5: Source: <ANY> Dest: <IP DHCP range> Protocol: udp  Traffic Class: Guest_UDPRealtime
Rule6: Source: <ANY> Dest: <ANY> Protocol: udp  Traffic Class: Users_UDPRealtime

Rule4: Source: <IP DHCP range> Dest: <ANY> Protocol: tcp Port: 80,443  Traffic Class: Guest_WebSurf
Rule5: Source: <ANY> Dest: <IP DHCP range> Protocol:  tcp Port: 80,443  Traffic Class: Guest_WebSurf
Rule6: Source: <ANY> Dest: <ANY> Protocol: tcp Port: 80,443  Traffic Class: Users_WebSurf

Rule7: Source: <IP DHCP range> Dest: <ANY> Protocol: <ANY>  Traffic Class: Guest_General
Rule8: Source: <ANY> Dest: <IP DHCP range> Protocol:  <ANY>  Traffic Class: Guest_General
Rule9: Source: <ANY> Dest: <ANY> Protocol: <ANY>  Traffic Class: Users_General

It should work splitting the bandwidth in half, and also priorizing traffic inside these two main groups (so someone dl things won't block voice traffic).
Logged
Pages: [1] Go Up Print 
« previous next »
Jump to:  

Page created in 0.078 seconds with 19 queries.
Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Design by 7dana.com