PfSense RC3 - Traffic Shaper Issues in resent builds
-
hi …..
traffic shaper could run normally.
updater pfSense-Full-Update-2.0-RC3-i386-20110728-2121.tgz
thks.
-
hi …..
traffic shaper could run normally.
updater pfSense-Full-Update-2.0-RC3-i386-20110728-2121.tgz
thks.
Tried that build, and the one from today. Remove shaper and re-ran wizard, no workie.
–--------------------------------------------------
Current Version : 2.0-RC3 Latest Version : Fri Jul 29 06:00:10 EDT 2011Jul 29 15:34:30 php: : The command '/sbin/pfctl -o basic -f /tmp/rules.debug' returned exit code '1', the output was 'bandwidth for qInternet higher than interface /tmp/rules.debug:43: errors in queue definition parent qInternet not found for qACK /tmp/rules.debug:44: errors in queue definition parent qInternet not found for qVoIP /tmp/rules.debug:45: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded'
Jul 29 15:34:30 php: : New alert found: There were error(s) loading the rules: bandwidth for qInternet higher than interface /tmp/rules.debug:43: errors in queue definition parent qInternet not found for qACK /tmp/rules.debug:44: errors in queue definition parent qInternet not found for qVoIP /tmp/rules.debug:45: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded The line in question reads [43]: queue qInternet on le1 bandwidth 16Mb hfsc ( ecn , linkshare 16Mb , upperlimit 16Mb ) { qACK, qVoIP }
Jul 29 15:34:30 php: : There were error(s) loading the rules: bandwidth for qInternet higher than interface /tmp/rules.debug:43: errors in queue definition parent qInternet not found for qACK /tmp/rules.debug:44: errors in queue definition parent qInternet not found for qVoIP /tmp/rules.debug:45: errors in queue definition pfctl: Syntax error in config file: pf rules not loaded - The line in question reads [43]: queue qInternet on le1 bandwidth 16Mb hfsc ( ecn , linkshare 16Mb , upperlimit 16Mb ) { qACK, qVoIP } -
I've also never seen the shaper actually work in 2.x…
Also there is still no real documentation on how to configure that beast. Even on Cisco Routers QoS is easier to configure and it will work as expected afterwards... -
grazman what is the link speed of you rinterface?
-
@ermal:
grazman what is the link speed of you rinterface?
16down/2up. At least thats what I am telling it for this configuration.
-
@ermal:
grazman what is the link speed of you rinterface?
16down/2up. At least thats what I am telling it for this configuration.
Why does the wizard create the queue's like this?
WAN
qInternet
qACK
qDefault
qVoIPLAN
qLink
qInternet
qACK
qVoIPThis looks lopsided.
-
Hi all,
Many time before I never success for traffic sharp, today with built on Fri Jul 29 14:40:48 EDT 2011, I can finish make a traffic sharp wizard without any error notice,
Thank you to team dev.
-
@ermal:
Please wait for a new snapshot to come and do not hijack people's threads.
If you are not happy with shaping put some resources on it.ermal,
I apologize, but I was not able to test until today. I updated to 2.0-RC3 (amd64)
built on Fri Jul 29 22:14:50 EDT 2011. I did not have the issues where two queues have the same priority or the "direction must be explicit with rules that specify routing " error. However, I am still having issues with performance. Previously all vlan to vlan traffic was being limited to 5Mbps. Now the limit is 10Mbps (a little more than 1MB/s). I set the WAN download to 50Mbps and WAN upload to 5Mbps, but changing these values do not seem to have an effect.Without Traffic Shaper settings, I have been able to pass 1.6Gbps from vlan to valn through this firewall. Computers with GigE connections can transfer data at up to 940Mbps (112MB/s).
Again I am not seeing the same on my personal pfSense firewall, but I am running 2.0-RC3 (amd64) built on Fri Jul 8 02:49:42 EDT 2011 which still uses the qDefault as the default queue which is set to a priority of 3 for all interfaces. The only other obvious difference is that I am not using Outbound NAT or CARP Virtual IPs.
On another note, I am unclear on the benefit of the change from qDefault to qLink on all interfaces except the WAN interface in that the qLink queue is given a lower priority than qOthersLow. I would think that the purpose of qOthersLow is to set something lower than the default.
I hope this update helps.
-
Please do not cross post, http://redmine.pfsense.org/issues/1734.
It makes it difficult to follow-up.
For me its a configuration tuning and not a bug.
As far as i can see you are using PRIQ discipline.Please follow the instrunctions on the ticket
Can you please check that putting the bandwidth of the physical interface on the root queues(with interface names) on all the LAN interfaces helps you with this issue?
-
ermal,
You are correct, I am using the PRIQ discipline.
Initial testing indicates that adding a value to the Bandwidth field for an interface does allow increased performance. Again this is initial testing, so I am not 100% sure that there are no performance issues. I will do more through testing ASAP.
As far as the bug or config argument, I understand your point of view. However, from my perspective, something has changed as I do not have to set the bandwidth field on my install of 2.0-RC3 (amd64) built on Fri Jul 8 02:49:42 EDT 2011 to have good performance with Traffic Shaper enabled. So the questions are as follows.
-
What has changes that requires the bandwidth field be set in resent builds, but not in 2.0-RC3 (amd64) built on Fri Jul 8 02:49:42 EDT 2011.
-
Is this change intended?
-
If filling in this field is going to be required to allow more than 10Mbps of traffic going forward, shouldn't that be added to the traffic shaper wizards?
Perhaps not everyone is experiencing this issue, so maybe this issue is limited to users with my type of setup. All the interfaces that I have tested are VLANs provided by a trunk that is provided by an LACP team made up of 2x GigE connetions between the pfSense hardware and a Cisco switch.
I have a connection that is direct, not a trunk, and it seems like traffic to that link was not limited, but I will need to verify that.
-
-
If you want to have the same behaviour as previous snapshots just go to the traffic shaper and select the lan interfaces and remove the shaper for it.
Leave only the WAN ones.Your issue is that PRIQ can specify bandwidth in only the root queue. So that is the reaon i tell you to remove put the interface bandwidth there.
Possibly at your speeds even increse the queue limit.