Multi-LAN does not really play well with the shaper, currently. The only way (as far as I know) to handle multi-LAN properly would be to create a bridge with all the interfaces and apply the shaper to it. If you do that, although all LANs will be on the same subnet, you can still somewhat filter traffic between them (by activating the proper system tunables).

Anyway, bridging sounds exactly like you want. And "guaranteeing bandwith" makes me think of HFSC  ;)

Thank you.

Thank you all supermega, shinzo and kejianshi for your kind suggestions, but I haven't solved the problem.

I looked at the tuning cards link but it didn't have the cards I'm using (re and msk cards).

I also tried shinzo's suggestions but it wasn't able to limit. It went wide open to 20Mbps/6Mbps. (I tried both net.link.bridge.pfil_bridge=1 and 0). I've tried different permutations of putting limiters on LAN/WAN/OPT1 or pairs of child queues on both LAN/WAN to no avail.

I also changed cables and added another brand new NIC card and tried different permutations of interface assignments to no avail.

If I disable all the rules (pfctl -d), the upload speed becomes normal (6Mbps), so I think it might a problem with my rules/settings/pfSense (probably not hardware).

I'm open to more suggestions, thank you all again, much appreciated!!

You should be able to do it with a HFSC scheduler

Great, that's what I hoped it meant from looking at the raw rules

Without shaping the entire traffic from everyone, you cannot shape a subset of the LAN. Shaping works by dropping / queueing packets. This can't work unless all traffic is classified. Once you have basic rules in place, you can create further rules for specific IP addresses.

Either way you need to completely understand HFSC and how the queues work or you'll fail to get it working.

@shawniverson:

Most definitely!  I am using both and it is working great.  No special/unusual configuration needed (in some cases)

Here's a sticky post that may help:

http://forum.pfsense.org/index.php/topic,14436.msg76415.html#msg76415

Do you know if that sticky is still relevant with pfSense 2.1 ?

–---------
The easy way Traffic Shaping with Squid Transparent Proxy
Add under Firewall Rules

Action = Pass
Interface= LAN
Source= LAN subnet
Protocol = TCP
Source = LAN
Destination = any
Destination port range = (Squid Proxy port) eg. 3128

Just an update, go this working by moving the rule to the LAN tab

used the ack queue for SSH interactive and used the main queue for SCP

$ cat /tmp/rules.debug <snip>pass  in  quick  on $LAN  proto { tcp udp }  from any to any port 22  keep state  queue (qP2P,qOthersHigh)  dnpipe ( 4, 3)  label "USER_RULE: Prioritise SSH not SCP traffic"</snip>

Burst speed after being idle perhaps?

In 2.1 theres an option to state normal speed and a burst speed when its been idle which might be what you are seeing, hence the above.

Yeah, ever since I have upgraded to 2.1-Rel my PRIQ queues just don't make sense.
They show crazy numbers, sometimes in the Gb range, they take a minute or two to stabilize to real numbers.

Like a VOIP queue should show roughly 50pps/64Kbits + 10% overhead or so per call.
It used to show that pretty much instantly when a call was started in 2.0.X.
Now it takes a minute for it to even crawl up to 64kbits.

Hi CSBS
Please post a bug report. I have tried but could not back my findings up with fact so it was rejected. Sounds like you have good evidence.

Else 2.1 final is out… you can try to upgrade if you dare upgrade your production router. Interesting to head if bug exist in 2.1 or if it is solved.

No, unfortunately. I have given up using limiters on this particular production router.

I just bought some new routers and want to set one up with 2.1 and test that to see if issue with limiters has been solved in 2.1.

I am confused of how to define this rule or where to add it. Can you give me a push in the right direction? Im looking around but not sure i get it.

BTW: I've had your problems with wrapping my head around certain phenomena. Like, I also had cases where everything looked alright but still: no packets would show up in certain queues. My approach solved all those issues for me.

Anyway, no matter how you do it, just remember: each queue works on exactly one interface in exactly one direction (outbound).

"My" approach just implements this behaviour by putting the queueing rules directly "on top of" the corresponding interface. One rule for each queue.

I would use pftop via ssh or serial console. Launch pftop, order by connection age or something, launch game, check destination ports.