Re: is 'set prio' in pf unidirectional or bidirectional?

[lists]

Sat, 18 Jun 2016 11:29:50 + (UTC) Bohdan Tashchuk

> On Fri, 6/17/16, Marko Cupać  wrote:
>      
> > Perhaps it would be useful to add that 'set prio' does nothing
> > unless "hardware is slower at transmitting packets than the
> > thing that generates these packets to send", as stated here:
> >
> >  [http://marc.info/?l=openbsd-misc=145257356119612=2]
> >
> > ... thus making it inappropriate for solution of OP's problem.
>
> Hi,
>
> I'm the OP. I agree that a single VoIP session doesn't need
> 'set prio' in normal circumstances.
>
> The reason I want to implement it in my home network is
> because, occasionally, one of the kids will upload
> something big, e.g. a few hundred megabytes of pictures,
> to some social network.
>
> When that happens, my Internet "goes to shit" for the
> duration. The upload attempts to push 100 Mbit/sec
> or more to my firewall. Which then tries to push
> to the Internet over the 5 Mbit/sec uplink speed of my
> cable modem. Which immediately saturates. Which results
> in the usual problems, such as 2000 msec or longer ping
> times. Etc. Of course, TCP eventually backs off, but things
> remain quite unpleasant for the duration of the upload.

Actually, it's not exactly this what causes, but this is exactly what
happens as you describe it.  It is very disappointing to have to deal
with this while trying to get work done.  Please see Daniel Hartmeier
has a page with details what you can actually do to sort it out.  It
is frustrating that the CPE (cable, aDSL and various other typically
asymmetric broadband Client Premises Equipment) don't try an inch to
help you out with their default configurations.  Pretty useless, huh?

Prioritizing empty TCP ACKs with pf and ALTQ
[http://www.benzedrine.ch/ackpri.html]

I can't tell if this still applies and if the configuration snippets
will be exactly as is, the page is dated and pf got several reworks.

But you'll get the idea pretty well, and understand how to solve it.
I can attest this worked for me several times in the past very fine.

> I don't want VoIP to suffer under those circumstances. So
> if I can work around this with 'set prio' (and not need to
> get queues involved), then it's certainly worth trying to do it.
>
> I will, of course, do some tcpdump monitoring in the near
> future, and report back to the list as to how successful I
> was in solving my problem by simply using 'set prio'.

Re: is 'set prio' in pf unidirectional or bidirectional?

[lists]

Sat, 18 Jun 2016 17:54:04 +0200 Marko Cupać 
> I am not a developer, just a guy who tries to achieve similar goal as
> you.

You're doing a good job with the mailing list posts on progress reports.

You can still help by testing the program via configuration changes, and
real usage reports.  The mailing list feedback is therefore very welcome.
If somebody not part of the developers snaps at you, ignore them and ask
again rephrasing your report.  You could submit your findings as patches
to the docs to begin with the FAQ, and match that against the real world
usage edge cases, especially if not directly applicable to a manual page.

> I am writing you in private because I've been asking basically the same
> questions here on misc@ a few months ago, eg:
>
> [http://marc.info/?l=openbsd-misc=145219178028408=2]
>
> To cut the long story short, after almost 10 years of successfully using
> OpenBSD's PF for traffic shaping, I can't make it work anymore since
> ALTQ was thrown out and new queuing mechanism was introduced in 5.5.

This is a reminder that the queuing section of the packet filter FAQ is
now in the attic as it's not been updated, it is just not so useful now.

[http://cvsweb.openbsd.org/cgi-bin/cvsweb/www/faq/pf/queueing.html]

If someone wants to really help, I suggest this document is brought back
from the out-of-date state and polished to match reality.  Until the day,
just consult the manual page queuing section (or ultimately the sources):

[http://man.openbsd.org/pf.conf.5#QUEUEING]

To gain more insight into this, keep working on it just like Marko tries.

> All the resources about current state of queuing in PF, including FAQ,
> manpages, and latest edition of "Book of PF" claim that what you
> (and I) need to achieve is done with a few simple lines, as it was in
> ALTQ days. It is not true. I came to conclusion that queuing in PF is
> broken, but there is no one who will fix it.

Source plunge may be required to be able to tame the FAQ queuing section.

> If you manage to achieve your goal (throttling one kind of traffic to
> prioritize other kind of traffic), please let me know.

Here is a free verse from the UNIX main book of revelations: if one
program does not possess a special dynamic quality you seek from it,
you shall write a program to change dynamically that program config
file and properly signal that program to continue performing duties.

> Regards,
> --
> Before enlightenment - chop wood, draw water.
> After  enlightenment - chop wood, draw water.
>
> Marko Cupać
> https://www.mimar.rs/

Re: is 'set prio' in pf unidirectional or bidirectional?

[Marko Cupać]

On Sat, 18 Jun 2016 11:29:50 + (UTC)
Bohdan Tashchuk  wrote:

> On Fri, 6/17/16, Marko Cupać  wrote:
>      
> > Perhaps it would be useful to add that 'set prio' does nothing
> > unless "hardware is slower at transmitting packets than the
> > thing that generates these packets to send", as stated here:
> >
> >  [http://marc.info/?l=openbsd-misc=145257356119612=2]
> >
> > ... thus making it inappropriate for solution of OP's problem.
>
> Hi,
>
> I'm the OP. I agree that a single VoIP session doesn't need
> 'set prio' in normal circumstances.
>
> The reason I want to implement it in my home network is
> because, occasionally, one of the kids will upload
> something big, e.g. a few hundred megabytes of pictures,
> to some social network.
>
> When that happens, my Internet "goes to shit" for the
> duration. The upload attempts to push 100 Mbit/sec
> or more to my firewall. Which then tries to push
> to the Internet over the 5 Mbit/sec uplink speed of my
> cable modem. Which immediately saturates. Which results
> in the usual problems, such as 2000 msec or longer ping
> times. Etc. Of course, TCP eventually backs off, but things
> remain quite unpleasant for the duration of the upload.
>
> I don't want VoIP to suffer under those circumstances. So
> if I can work around this with 'set prio' (and not need to
> get queues involved), then it's certainly worth trying to do it.
>
> I will, of course, do some tcpdump monitoring in the near
> future, and report back to the list as to how successful I
> was in solving my problem by simply using 'set prio'.

I was trying to achieve the same goal the same way as you, as it came
to me as a common sense that packets with higher prio would be processed
first. However, I found out this is not how things work. Prio does not
respect bandwidth set on queue. It starts to discard packets with lower
prio value when interface's physical bandwidth is saturated, which - in
your and my case - means never.

Maybe you will have better luck with queues. Make sure you set max
bandwidth on parent queue. I prefer to set also min:

# QUEUES
queue ul on $if_extbandwidth 800K min 800K max 800K
   queue hi  parent ul bandwidth 100K
   queue std parent ul bandwidth 600K default
   queue low parent ul bandwidth 100K

This work on traffic leaving external interface - traffic in low queue
will get 800K, but once traffic in std queue kicks in, low will get
throttled to 100K.

I haven't managed to make it work as expected for traffic leaving
internal interface (eg. replies from the Internet to requests from
local network).

Regards,
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: is 'set prio' in pf unidirectional or bidirectional?

[Marko Cupać]

Bohdan,

I am not a developer, just a guy who tries to achieve similar goal as
you.

I am writing you in private because I've been asking basically the same
questions here on misc@ a few months ago, eg:

[http://marc.info/?l=openbsd-misc=145219178028408=2]

To cut the long story short, after almost 10 years of successfully using
OpenBSD's PF for traffic shaping, I can't make it work anymore since
ALTQ was thrown out and new queuing mechanism was introduced in 5.5.

All the resources about current state of queuing in PF, including FAQ,
manpages, and latest edition of "Book of PF" claim that what you
(and I) need to achieve is done with a few simple lines, as it was in
ALTQ days. It is not true. I came to conclusion that queuing in PF is
broken, but there is no one who will fix it.

As I said, prio does not respect queue bandwidth set by admin, it
starts to discard packets with lowest prio only when physical interface
gets saturated. In world of 1Gb NICs this is almost never.

I managed to make queuing work with as expected with fixed bandwidth
queues only (meaning set target, min and max values) for all queues
(parents and children).

If you manage to achieve your goal (throttling one kind of traffic to
prioritize other kind of traffic), please let me know.

Regards,
--
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: is 'set prio' in pf unidirectional or bidirectional?

[Bohdan Tashchuk]

On Fri, 6/17/16, Marko Cupać  wrote:
     
> Perhaps it would be useful to add that 'set prio' does nothing
> unless "hardware is slower at transmitting packets than the
> thing that generates these packets to send", as stated here:
>
>  [http://marc.info/?l=openbsd-misc=145257356119612=2]
>
> ... thus making it inappropriate for solution of OP's problem.

Hi,

I'm the OP. I agree that a single VoIP session doesn't need
'set prio' in normal circumstances.

The reason I want to implement it in my home network is
because, occasionally, one of the kids will upload
something big, e.g. a few hundred megabytes of pictures,
to some social network.

When that happens, my Internet "goes to shit" for the
duration. The upload attempts to push 100 Mbit/sec
or more to my firewall. Which then tries to push
to the Internet over the 5 Mbit/sec uplink speed of my
cable modem. Which immediately saturates. Which results
in the usual problems, such as 2000 msec or longer ping
times. Etc. Of course, TCP eventually backs off, but things
remain quite unpleasant for the duration of the upload.

I don't want VoIP to suffer under those circumstances. So
if I can work around this with 'set prio' (and not need to
get queues involved), then it's certainly worth trying to do it.

I will, of course, do some tcpdump monitoring in the near
future, and report back to the list as to how successful I
was in solving my problem by simply using 'set prio'.

Re: is 'set prio' in pf unidirectional or bidirectional?

[Marko Cupać]

On Wed, 15 Jun 2016 20:18:25 +0100
Andy Lemin  wrote:

> Peter is quite right, to add some examples to his suggestion;
>
> tcpdump -nettti pflog0 <- Shows only dropped packets
> tcpdump -nettti em0 <- Shows all packets on the interface, including
> ToS values and VLAN ID etc.
> tcpdump -nettti vlanX <- Shows only packets on the VLAN without the
> extra info.
>
> Sure you can figure out the rest..
>
> There are also a few caveats to writing good PF QoS rules that some
> are not aware off. For example the PRIO value is copied into the VLAN
> header as the CoS value, but if it is an untagged VLAN the frame wont
> have a value as their is no VLAN header to store it in. I.e. PRIO is
> only transitive for connected VLAN subnets, beyond the nexthop you
> cannot control layer 2 CoS, only layer 3 QoS is transitive.
>
> Also PRIO is strictly speaking internal to the firewall, and it works
> for both ingress and egress, whereas queuing/shaping is egress only.
> Best to think of it as a priority picker or scheduler. I.e. packets
> get selected from the buffers for processing based on their priority
> whether they are input or output buffers (I am only 90% sure of this,
> so please correct me if I am wrong).
>
> Also common good practice assumes that you would normally want to use
> two prio values; E.g.
>
> pass quick on { $if_ext, $if_DMZ } proto { tcp, udp } from any to {
> $int_ip_dns0 } port { 53 } queue (wan_web,wan_pri) set prio (2,4)
> The first prio (2) is used for the payload packets in the session
> (ToS not set), and the second prio (4) is used for the control
> packets (ACKs etc because they have the ToS set). This again also
> sets the VLAN CoS correctly for each packet type in the same session.
>
> Another thing to be careful of is setting ToS yourself and using PRIO
> (and if using queues too). For example;
>
> match in proto tcp all scrub (no-df max-mss 1460)
>
> match in proto { udp, icmp } all scrub (no-df max-mss 1472)
>
> match out on { $if_ext } proto { tcp, udp } from any to
> {  } scrub (no-df max-mss 1420) set (tos ef, prio 7)
>
> The first two lines are just housekeeping. But the third line will
> set the ToS value EF on every single packet in the session (payload
> and ACKs) for the VoIP traffic. This means that the later pass rules
> will place all voip traffic into 'second' "queue" and second
> "priority".
>
> And if you didn't spot the clue in the first example, yes, I believe
> state does match returning traffic and does apply the prio to return
> traffic also. But you wont see it with tcpdump unless you are using
> VLANs to inspect the CoS field.
>
>
> In my first example you will also notice I have only one rule that
> matches traffic on both the inside and outside interfaces, so you
> need to make sure you are using the same queue names on both the
> inside and outside interfaces. This is done by adding the "on
> $if_ext" directive to your queues. E.g.
>
> queue ext_root on $if_ext bandwidth 800M
>
> queue qlocal on $if_ext parent ext_root bandwidth 600M
>
> queue local_kern on $if_ext parent qlocal bandwidth 6M min 6M
> burst 10M for 1000ms
>
> queue local_pri on $if_ext parent qlocal bandwidth 60M min 60M
>
> queue local_data on $if_ext parent qlocal bandwidth 510M min
> 100M
>
> queue qwan on $if_ext  parent ext_root bandwidth 190M
>
> queue wan_rt on $if_ext  parent qwan bandwidth 38M min 19M
> burst 38M for 5000ms
>
> queue wan_int on $if_ext parent qwan bandwidth 19M min 9M
>
> queue wan_pri on $if_ext parent qwan bandwidth 19M min 10M
> burst 25M for 2000ms
>
> queue wan_vpn on $if_ext parent qwan bandwidth 50M min 25M
>
> queue wan_web on $if_ext parent qwan bandwidth 19M min 10M
> burst 19M for 3000ms
>
> queue wan_dflt on $if_ext parent qwan bandwidth 19M min 10M
> burst 19M for 5000ms
>
> queue wan_bulk on $if_ext parent qwan bandwidth 20M max 50M
> default
>
>
> queue trunk_root on $if_trunk bandwidth 4294M
>
> queue qlocal on $if_trunk parent trunk_root bandwidth 4.1G
>
> queue local_kern on $if_trunk parent qlocal bandwidth 8M min
> 8M burst 8M for 1000ms
>
> queue local_pri on $if_trunk parent qlocal bandwidth 150M min
> 150M burst 200M for 2500ms
>
> queue local_data on $if_trunk parent qlocal bandwidth 4G min
> 1G
>
> queue qwan on $if_trunk parent trunk_root bandwidth 190M
>
> queue wan_rt on $if_trunk  parent qwan bandwidth 38M min 19M
> burst 38M for 5000ms
>
> queue wan_int on $if_trunk parent qwan bandwidth 19M min 9M
>
> queue wan_pri on $if_trunk parent qwan bandwidth 19M min 10M
> burst 25M for 2000ms
>
> queue wan_vpn on $if_trunk parent qwan bandwidth 50M min 25M
>
> queue wan_web on $if_trunk parent qwan bandwidth 19M min 10M
> burst 19M for 3000ms
>
> queue wan_dflt on $if_trunk parent qwan bandwidth 19M min 10M
> burst 19M for 5000ms
>
> queue wan_bulk on 

Re: is 'set prio' in pf unidirectional or bidirectional?

[Andy Lemin]

Ohh, Forgot to mention.. PF by default sets good ToS values on its CARP
heartbeats, but we use HP Procurve switches with DiffServ enabled.

By default with HP, HP maps the ToS value that PF uses for CARP by default,
into a low priority CoS queue! Yes really ;) Don't you just love HP. And on
many HP switches, you cannot modify this DiffServ <-> CoS mapping.

So the suggestion at the bottom is just to set a ToS that HP switches will
prioritise..

Have fun, all the best.

Andy Lemin


On Wed, Jun 15, 2016 at 8:18 PM, Andy Lemin  wrote:

> Peter is quite right, to add some examples to his suggestion;
>
> tcpdump -nettti pflog0 <- Shows only dropped packets
> tcpdump -nettti em0 <- Shows all packets on the interface, including ToS
> values and VLAN ID etc.
> tcpdump -nettti vlanX <- Shows only packets on the VLAN without the extra
> info.
>
> Sure you can figure out the rest..
>
> There are also a few caveats to writing good PF QoS rules that some are
> not aware off. For example the PRIO value is copied into the VLAN header as
> the CoS value, but if it is an untagged VLAN the frame wont have a value as
> their is no VLAN header to store it in. I.e. PRIO is only transitive for
> connected VLAN subnets, beyond the nexthop you cannot control layer 2 CoS,
> only layer 3 QoS is transitive.
>
> Also PRIO is strictly speaking internal to the firewall, and it works for
> both ingress and egress, whereas queuing/shaping is egress only. Best to
> think of it as a priority picker or scheduler. I.e. packets get selected
> from the buffers for processing based on their priority whether they are
> input or output buffers (I am only 90% sure of this, so please correct me
> if I am wrong).
>
> Also common good practice assumes that you would normally want to use two
> prio values; E.g.
>
> pass quick on { $if_ext, $if_DMZ } proto { tcp, udp } from any to {
> $int_ip_dns0 } port { 53 } queue (wan_web,wan_pri) set prio (2,4)
> The first prio (2) is used for the payload packets in the session (ToS not
> set), and the second prio (4) is used for the control packets (ACKs etc
> because they have the ToS set). This again also sets the VLAN CoS correctly
> for each packet type in the same session.
>
> Another thing to be careful of is setting ToS yourself and using PRIO (and
> if using queues too). For example;
>
> match in proto tcp all scrub (no-df max-mss 1460)
>
> match in proto { udp, icmp } all scrub (no-df max-mss 1472)
>
> match out on { $if_ext } proto { tcp, udp } from any to {
>  } scrub (no-df max-mss 1420) set (tos ef, prio 7)
>
> The first two lines are just housekeeping. But the third line will set the
> ToS value EF on every single packet in the session (payload and ACKs) for
> the VoIP traffic. This means that the later pass rules will place all
> voip traffic into 'second' "queue" and second "priority".
>
> And if you didn't spot the clue in the first example, yes, I believe state
> does match returning traffic and does apply the prio to return traffic
> also. But you wont see it with tcpdump unless you are using VLANs to
> inspect the CoS field.
>
>
> In my first example you will also notice I have only one rule that matches
> traffic on both the inside and outside interfaces, so you need to make sure
> you are using the same queue names on both the inside and outside
> interfaces. This is done by adding the "on $if_ext" directive to your
> queues. E.g.
>
> queue ext_root on $if_ext bandwidth 800M
>
> queue qlocal on $if_ext parent ext_root bandwidth 600M
>
> queue local_kern on $if_ext parent qlocal bandwidth 6M min 6M
> burst 10M for 1000ms
>
> queue local_pri on $if_ext parent qlocal bandwidth 60M min 60M
>
> queue local_data on $if_ext parent qlocal bandwidth 510M min 100M
>
> queue qwan on $if_ext  parent ext_root bandwidth 190M
>
> queue wan_rt on $if_ext  parent qwan bandwidth 38M min 19M burst
> 38M for 5000ms
>
> queue wan_int on $if_ext parent qwan bandwidth 19M min 9M
>
> queue wan_pri on $if_ext parent qwan bandwidth 19M min 10M burst
> 25M for 2000ms
>
> queue wan_vpn on $if_ext parent qwan bandwidth 50M min 25M
>
> queue wan_web on $if_ext parent qwan bandwidth 19M min 10M burst
> 19M for 3000ms
>
> queue wan_dflt on $if_ext parent qwan bandwidth 19M min 10M burst
> 19M for 5000ms
>
> queue wan_bulk on $if_ext parent qwan bandwidth 20M max 50M
> default
>
>
> queue trunk_root on $if_trunk bandwidth 4294M
>
> queue qlocal on $if_trunk parent trunk_root bandwidth 4.1G
>
> queue local_kern on $if_trunk parent qlocal bandwidth 8M min 8M
> burst 8M for 1000ms
>
> queue local_pri on $if_trunk parent qlocal bandwidth 150M min
> 150M burst 200M for 2500ms
>
> queue local_data on $if_trunk parent qlocal bandwidth 4G min 1G
>
> queue qwan on $if_trunk parent trunk_root bandwidth 190M
>
> queue wan_rt on $if_trunk  parent qwan bandwidth 38M min 19M
> burst 38M 

Re: is 'set prio' in pf unidirectional or bidirectional?

[Andy Lemin]

Peter is quite right, to add some examples to his suggestion;

tcpdump -nettti pflog0 <- Shows only dropped packets
tcpdump -nettti em0 <- Shows all packets on the interface, including ToS
values and VLAN ID etc.
tcpdump -nettti vlanX <- Shows only packets on the VLAN without the extra
info.

Sure you can figure out the rest..

There are also a few caveats to writing good PF QoS rules that some are not
aware off. For example the PRIO value is copied into the VLAN header as the
CoS value, but if it is an untagged VLAN the frame wont have a value as
their is no VLAN header to store it in. I.e. PRIO is only transitive for
connected VLAN subnets, beyond the nexthop you cannot control layer 2 CoS,
only layer 3 QoS is transitive.

Also PRIO is strictly speaking internal to the firewall, and it works for
both ingress and egress, whereas queuing/shaping is egress only. Best to
think of it as a priority picker or scheduler. I.e. packets get selected
from the buffers for processing based on their priority whether they are
input or output buffers (I am only 90% sure of this, so please correct me
if I am wrong).

Also common good practice assumes that you would normally want to use two
prio values; E.g.

pass quick on { $if_ext, $if_DMZ } proto { tcp, udp } from any to {
$int_ip_dns0 } port { 53 } queue (wan_web,wan_pri) set prio (2,4)
The first prio (2) is used for the payload packets in the session (ToS not
set), and the second prio (4) is used for the control packets (ACKs etc
because they have the ToS set). This again also sets the VLAN CoS correctly
for each packet type in the same session.

Another thing to be careful of is setting ToS yourself and using PRIO (and
if using queues too). For example;

match in proto tcp all scrub (no-df max-mss 1460)

match in proto { udp, icmp } all scrub (no-df max-mss 1472)

match out on { $if_ext } proto { tcp, udp } from any to { 
} scrub (no-df max-mss 1420) set (tos ef, prio 7)

The first two lines are just housekeeping. But the third line will set the
ToS value EF on every single packet in the session (payload and ACKs) for
the VoIP traffic. This means that the later pass rules will place all voip
traffic into 'second' "queue" and second "priority".

And if you didn't spot the clue in the first example, yes, I believe state
does match returning traffic and does apply the prio to return traffic
also. But you wont see it with tcpdump unless you are using VLANs to
inspect the CoS field.


In my first example you will also notice I have only one rule that matches
traffic on both the inside and outside interfaces, so you need to make sure
you are using the same queue names on both the inside and outside
interfaces. This is done by adding the "on $if_ext" directive to your
queues. E.g.

queue ext_root on $if_ext bandwidth 800M

queue qlocal on $if_ext parent ext_root bandwidth 600M

queue local_kern on $if_ext parent qlocal bandwidth 6M min 6M burst
10M for 1000ms

queue local_pri on $if_ext parent qlocal bandwidth 60M min 60M

queue local_data on $if_ext parent qlocal bandwidth 510M min 100M

queue qwan on $if_ext  parent ext_root bandwidth 190M

queue wan_rt on $if_ext  parent qwan bandwidth 38M min 19M burst
38M for 5000ms

queue wan_int on $if_ext parent qwan bandwidth 19M min 9M

queue wan_pri on $if_ext parent qwan bandwidth 19M min 10M burst
25M for 2000ms

queue wan_vpn on $if_ext parent qwan bandwidth 50M min 25M

queue wan_web on $if_ext parent qwan bandwidth 19M min 10M burst
19M for 3000ms

queue wan_dflt on $if_ext parent qwan bandwidth 19M min 10M burst
19M for 5000ms

queue wan_bulk on $if_ext parent qwan bandwidth 20M max 50M default


queue trunk_root on $if_trunk bandwidth 4294M

queue qlocal on $if_trunk parent trunk_root bandwidth 4.1G

queue local_kern on $if_trunk parent qlocal bandwidth 8M min 8M
burst 8M for 1000ms

queue local_pri on $if_trunk parent qlocal bandwidth 150M min 150M
burst 200M for 2500ms

queue local_data on $if_trunk parent qlocal bandwidth 4G min 1G

queue qwan on $if_trunk parent trunk_root bandwidth 190M

queue wan_rt on $if_trunk  parent qwan bandwidth 38M min 19M burst
38M for 5000ms

queue wan_int on $if_trunk parent qwan bandwidth 19M min 9M

queue wan_pri on $if_trunk parent qwan bandwidth 19M min 10M burst
25M for 2000ms

queue wan_vpn on $if_trunk parent qwan bandwidth 50M min 25M

queue wan_web on $if_trunk parent qwan bandwidth 19M min 10M burst
19M for 3000ms

queue wan_dflt on $if_trunk parent qwan bandwidth 19M min 10M burst
19M for 5000ms

queue wan_bulk on $if_trunk parent qwan bandwidth 20M max 50M
default


Another hint, if you are using VLANs to gain the benefit of using the
priority field in the VLAN header, to maintain your CoS on your layer 2 all
the way to the client, you should apply your queues to the trunk interface,
and not each VLAN.

Re: is 'set prio' in pf unidirectional or bidirectional?

[Peter N. M. Hansteen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

This is one of the cases where the best possible answer is, "tcpdump
is your friend".

You have outlined a number of test cases. It would be really useful if
you try each one of them, and use tcpdump to record and identify the
effects of each one. It's worth noting that tcpdump with the right
options is able to display information such as the packets's ToS and
which rule in the loaded PF rule set the packet matched.

If you run those tests properly and report your findings, I'm sure it
will be appreciated.

- -- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
iQIcBAEBCAAGBQJXYSecAAoJELJiGF9h4DyeghcP/RZQeJ/4P8cj6DUoBhSw7HuZ
q0t8fgnnyfw7ItkWGP6WayW9aT7oMfR9XdgX3jn/jFBLj8aW55K1i/v4PbXFJTkB
yjnJ1WJN7fohVSYOYyfnjxCxw2RdGbcVUZpYkFCfIzsKPTxsuJynJyR7i6Ke8dYE
5FiF68oqhKq0yAiHcE91UlMVFH/v8NAy3crzkeK1yjgYK3sU5dVs0H7D/qR8Zlfe
fmOO9SqDDcvMMn/7c6bQ9sHKBXSsHizZcf//yuQseSXv9ttsl/3XZyUEhS3fyqNt
WKw80vNwQ7MJShOFqjn12G+j72s0kaSkiDEi93rXUZJxsoD28Vn6dyBJhcrWFtfr
eEOwuyp82FiNabAvn3StzkKE+cAQ01Kag0hFhgwx/u1sD/9K31B9J8IiMpSIplFV
tx4jfWBh1MjadAu3DIvHINYzEPoaju4zUY1mh840l5Wz7SpaBUyeJce0eNtA3n6Z
pbpZQsi9mHCP7MOR2b+RvzcjFc4m5XoiLz29aMQDzeLj4GzroY9H0ramWchqbj1y
BXKtFNgOglKIkjickdlSnzahFAf53r5T6vv1KY7Ea4Z5PP88e8OiXdcJqiuJlo0T
c9VXE5cCy37i21ZPV4YK3LsuiCxMVuGtQ63B/OnP1kX34NVoatpZz6gcx5Y62MWA
rsxLSEMFHSJuoJzgGF7j
=mgmr
-END PGP SIGNATURE-