Traffic Shaping Rules



  • I'm using the traffic shaper to create 7 queues for 7 host on a lan Along with corresponding rules to queue traffic into specific queue. After configuration the rules generated is causing the traffic shaping for uploads not to work or be shaped properly.
    The problem is that all uploads fall into the qHighUpL queue particular because of the rule thats highlighted in bold red.
    Im not sure I fully understand this but why is this rule genearted? I think its causing all my uploads to fall into that queue.

    Im using 1.0-BETA1-TESTING-SNAPSHOT-2-8-06 .

    dc1 = Wan
    dc0 = Lan

    block all tag unshaped label "SHAPER: first match rule"
    pass in on  dc0 from $LeonIP to any  keep state tagged unshaped tag qHighDownL
    pass out on  dc1 from any to any  keep state tagged unshaped tag qHighUpL
    pass in on  dc1 from any to $LeonIP  keep state tagged unshaped tag qHighUpL
    pass out on  dc0 from any to $LeonIP  keep state tagged unshaped tag qHighDownL
    pass in on  dc0 from 192.168.1.10 to any  keep state tagged unshaped tag q1DownL
    pass out on  dc1 from any to any  keep state tagged unshaped tag q1UpL
    pass in on  dc1 from any to 192.168.1.10  keep state tagged unshaped tag q1UpL
    pass out on  dc0 from any to 192.168.1.10  keep state tagged unshaped tag q1DownL
    pass in on  dc0 from 192.168.1.11 to any  keep state tagged unshaped tag q2DownL
    pass out on  dc1 from any to any  keep state tagged unshaped tag q2UpL
    pass in on  dc1 from any to 192.168.1.11  keep state tagged unshaped tag q2UpL
    pass out on  dc0 from any to 192.168.1.11  keep state tagged unshaped tag q2DownL
    pass in on  dc0 from 192.168.1.12 to any  keep state tagged unshaped tag q3DownL
    pass out on  dc1 from any to any  keep state tagged unshaped tag q3UpL
    pass in on  dc1 from any to 192.168.1.12  keep state tagged unshaped tag q3UpL
    pass out on  dc0 from any to 192.168.1.12  keep state tagged unshaped tag q3DownL
    pass in on  dc0 from 192.168.1.13 to any  keep state tagged unshaped tag q4DownL
    pass out on  dc1 from any to any  keep state tagged unshaped tag q4UpL
    pass in on  dc1 from any to 192.168.1.13  keep state tagged unshaped tag q4UpL
    pass out on  dc0 from any to 192.168.1.13  keep state tagged unshaped tag q4DownL
    pass in on  dc0 from 192.168.1.14 to any  keep state tagged unshaped tag q5DownL
    pass out on  dc1 from any to any  keep state tagged unshaped tag q5UpL
    pass in on  dc1 from any to 192.168.1.14  keep state tagged unshaped tag q5UpL
    pass out on  dc0 from any to 192.168.1.14  keep state tagged unshaped tag q5DownL
    pass in on  dc0 from 192.168.1.15 to any  keep state tagged unshaped tag q5DownL
    pass out on  dc1 from any to any  keep state tagged unshaped tag q6UpL
    pass in on  dc1 from any to 192.168.1.15  keep state tagged unshaped tag q5UpL
    pass out on  dc0 from any to 192.168.1.15  keep state tagged unshaped tag q5DownL



  • Yup, that'll do it.  Shaper gets hit after NAT occurs so we don't know what the source IP really is, there's not a heck of a lot I can do about this issue right now I'm afraid.  I'm open to suggestions on how to make our pf config better (and still keep shaping seperate from rules).  In the meantime, I'm trying to figure out what I need to modify in kernel to make queue assignments sticky per packet which will allow us to fix this properly on the inside interface (note: this won't happen for 1.0, guaranteed).

    –Bill



  • Here is another thing I observed today.. This rule:

    pass out on  dc0 from any to 192.168.1.7  keep state tagged unshaped tag qHighDownL            (subset of rules posted earlier)

    dc0 - LAN interface

    Does not work for traffic originating from the firewall itself. Squid and ssh traffic to 192.168.1.7 for example would fall into the default queue instead of qHighDownL, so does all traffic to any ip whos traffic originated at the firewall. It only works for traffic comming through WAN.

    Squid is boud to lo 127.0.0.1 while ssh is bound to the any address *. Is there any reason why this rule don't work for such traffic? I though about it and still can figure out why.

    EDIT:

    tried iperf from firewall to lan pc with ip address 192.168.1.7 -> the traffic found its way into the correct queue. however the others stated above still don't get queued properly. Could it have have something to do with the direction in which the connections were establish?


Locked