Unfortunately I havent played around with bandwidth limiting in PAN, just prioritize traffic up/down. Would a workaround for you be to put facebook traffic in the lowest priority group instead? This way the facebook users gets all bandwidth if noone else is using your uplink but as soon someone else is using it the others will have their traffic before the facebook users. The below example is how to get backup-traffic (traffic to/from backupservers placed on a dedicated interface of the PAN) to be put in lowest prio, but should be easily modified to suit your needs to do the same for traffic matching application facebook or similar. In QoS Profile create one with just the classes you need (I think this is not needed if you are happy with the default setup of 8 classes in 4 different priogroups): <entry name="BACKUP"> <class> <entry name="class8"> <priority>low</priority> </entry> </class> </entry> Then on the physical interface you define it to use the particular profile, like so (I think this is in the QoS part of the GUI): <entry name="ethernet1/1"> <regular-traffic> <groups> <entry name="regular-traffic-group"> <members> <entry name="BACKUP_1_1"> <match> <local-address> <address> <member>any</member> </address> <interface>ethernet1/2</interface> </local-address> </match> <qos-profile>BACKUP</qos-profile> </entry> </members> </entry> </groups> <default-group> <qos-profile>default</qos-profile> </default-group> </regular-traffic> <tunnel-traffic> <groups> <entry name="tunnel-traffic-group"/> </groups> </tunnel-traffic> <enabled>yes</enabled> </entry> <entry name="ethernet1/2"> <regular-traffic> <groups> <entry name="regular-traffic-group"> <members> <entry name="BACKUP_1_2"> <match> <local-address> <address> <member>any</member> </address> </local-address> </match> <qos-profile>BACKUP</qos-profile> </entry> </members> </entry> </groups> <default-group> <qos-profile>default</qos-profile> </default-group> </regular-traffic> <tunnel-traffic> <groups> <entry name="tunnel-traffic-group"/> </groups> </tunnel-traffic> <enabled>yes</enabled> </entry> A note here is that QoS is applied for egress traffic. In order to make the traffic get lowest prio in both directions you need to setup the above rule for both external and internal interface. The above gives that traffic arriving at eth1/1 (uplink) and is designated for eth1/2 (backup) will have the custom QoS-profile (BACKUP instead of default). Traffic arriving at eth1/2 (backup) will use the BACKUP QoS-profile for all traffic. In your case (with mixed traffic) it would probably be best to just use the default QoS-profile. And finally setup a QoS rule for which traffic should be marked to be processed by the QoS: <entry name="BACKUP_BACKUP"> <from> <member>any</member> </from> <to> <member>BACKUP</member> </to> <source> <member>any</member> </source> <destination> <member>any</member> </destination> <source-user> <member>any</member> </source-user> <category> <member>any</member> </category> <application> <member>any</member> </application> <service> <member>any</member> </service> <action> <class>8</class> </action> <description>Traffic to backupservers</description> <negate-source>no</negate-source> <negate-destination>no</negate-destination> </entry> <entry name="BACKUP_RESTORE"> <from> <member>BACKUP</member> </from> <to> <member>any</member> </to> <source> <member>any</member> </source> <destination> <member>any</member> </destination> <source-user> <member>any</member> </source-user> <category> <member>any</member> </category> <application> <member>any</member> </application> <service> <member>any</member> </service> <action> <class>8</class> </action> <description>Traffic from backupservers</description> <negate-source>no</negate-source> <negate-destination>no</negate-destination> </entry>
... View more