QoS not working on 3.2.0 alpha 1

[Guest]

[escotland]

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...)

[mrkroket]

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.

[escotland]

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.

[escotland]

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?

[escotland]

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.

[escotland]

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...

[escotland]

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.

[mrkroket]

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).

[escotland]

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).