y question is, which interface is
> appropriate to choose for queueing? pppoe0, em0, or wg0? I'd think wg0,
> as I'm unsure how pf(4) would classify traffic otherwise. However, I'm
> not confident in that conclusion, so I decided to ask.
>
> If additional details are needed, I'm happy to provide them.
>
> --
> https://amissing.link
>
default
I want to employ this rule. My question is, which interface is
appropriate to choose for queueing? pppoe0, em0, or wg0? I'd think wg0,
as I'm unsure how pf(4) would classify traffic otherwise. However, I'm
not confident in that conclusion, so I decided to ask.
If additional deta
-> 150 and 70 to 40 Mbit.
the is no queue setting at the pf rules , just the defined queues.
both traffic jumps by pf from one rdomain , root XBL DMZ , to the internet
rdomains.
i try also to use my "gateway" interfaces vetherX , but this works not
with the queueing.
without queuing , d
On 2018-02-16, Predrag Punosevac wrote:
> Stuart Henderson wrote:
>
>> It can already be monitored to some extent, base snmpd does already
>> support a number of things in OPENBSD-PF-MIB, but not queues yet.
>
> Any chance that you share with us how you plot the data you recover with
> snmpwalk fr
Stuart Henderson wrote:
> It can already be monitored to some extent, base snmpd does already
> support a number of things in OPENBSD-PF-MIB, but not queues yet.
Any chance that you share with us how you plot the data you recover with
snmpwalk from those MIBs. I would be most interested in
LibreN
On 2018-02-15, Kaya Saman wrote:
>
>
> On 02/15/2018 01:34 PM, Stuart Henderson wrote:
>> On 2018/02/15 13:27, Kaya Saman wrote:
>>>
>>> On 02/15/2018 12:13 PM, Stuart Henderson wrote:
>>>> On 2018-02-15, Kaya Saman wrote:
>>>>> does
On 02/15/2018 01:34 PM, Stuart Henderson wrote:
On 2018/02/15 13:27, Kaya Saman wrote:
On 02/15/2018 12:13 PM, Stuart Henderson wrote:
On 2018-02-15, Kaya Saman wrote:
does queueing still function with pfstat? As far as I'm aware it still
uses the old altq method which has long
On 2018/02/15 13:27, Kaya Saman wrote:
>
>
> On 02/15/2018 12:13 PM, Stuart Henderson wrote:
> > On 2018-02-15, Kaya Saman wrote:
> > > does queueing still function with pfstat? As far as I'm aware it still
> > > uses the old altq method which has long been
On 02/15/2018 12:13 PM, Stuart Henderson wrote:
On 2018-02-15, Kaya Saman wrote:
does queueing still function with pfstat? As far as I'm aware it still
uses the old altq method which has long been abandoned.
you're correct, pfstat hasn't been updated to follow changes in PF
On 2018-02-15, Kaya Saman wrote:
>
> does queueing still function with pfstat? As far as I'm aware it still
> uses the old altq method which has long been abandoned.
you're correct, pfstat hasn't been updated to follow changes in PF for
a long time. the only change in pf
Hi,
does queueing still function with pfstat? As far as I'm aware it still
uses the old altq method which has long been abandoned.
It would be great if pfstat would graph queues again but the config
example in: /usr/local/share/examples/pfstat/pfstat.conf still has the
old altq
Hi,
I'm (re)trying out queuing possibilities in 6.2.
I am trying out different possibilities, mixing queue with prio.
I have accidentally put two different lines in my pf.conf:
match proto tcp to any port domain set prio 6 set queue dns
match proto udp to any port domain set queue dns pri
On 07/27/2017 05:30 PM, Stuart Henderson wrote:
On 2017-07-26, Kaya Saman wrote:
[snip]
I'm finding that I don't really need much in the way of "downstream"
queueing though. It might be needed in special cases but using mikeb's
shiny new fq-codel code in -
On 2017-07-26, Kaya Saman wrote:
>
> [snip]
>> I'm finding that I don't really need much in the way of "downstream"
>> queueing though. It might be needed in special cases but using mikeb's
>> shiny new fq-codel code in -current, one single queue d
[snip]
I'm finding that I don't really need much in the way of "downstream"
queueing though. It might be needed in special cases but using mikeb's
shiny new fq-codel code in -current, one single queue definition on the
upstream interface is keeping traffic flowing nicel
traffic in
both directions. So you just want "somequeue", not "somequeue_in"
and "somequeue_out", and get rid of the received-on.
I have revised my queueing statements as you suggested and will
definitely look further into adjusting them via your input.
I created a
terfaces
Generally I prefer simple failover for trunk, then this would be easy
(a separate queue on each physical interface - the interfaces don't need
to interact with each other, only one is used at a time).
If you must have load-balancing you could play with queueing on the trunk
interfa
Hi,
I'm trying to setup packet queueing on a WAN interface with 80Mb/s
downstream bandwidth and 20Mb/s upstream bandwidth.
The first point of call of course is the PF manual:
https://man.openbsd.org/pf.conf.5
Then had a look to see what others had issues with and solutions sugg
Il 11/05/2017 01:42, Erling Westenvik ha scritto:
> Check out pfctl(8) and the -F option. The issue might be resolvable
> simply by flushing one or more of the filter parameters you'll find
> there.
I had always assumed that loading a new ruleset with pfctl -f also
implied "-F all".
This explain
On Thu, May 11, 2017 at 12:09:26AM +0200, Gabriele Tozzi wrote:
>
> Looks like I've solved by only renaming the queues.
>
> Instead of naming them "high", "normal" and "low", I have now named them
> "exthi", "extstd" and "extlo" and then everything seems to work as expended.
>
> Maybe "high" is a (
Looks like I've solved by only renaming the queues.
Instead of naming them "high", "normal" and "low", I have now named them
"exthi", "extstd" and "extlo" and then everything seems to work as expended.
Maybe "high" is a (maybe undocumented) reserved queue name?
I will look for it.
I have also checked "pfctl -s rules | grep high" and it returns no data.
To the best of my knowledge, this confirms that there is no pf rule
explicitly sending packets to the "high" queue... but lots of packets
are queued there anyway, so I am supposing ther
but perhaps someone else would be able to see something that you didn't,
hence the requirement to share the file.
-luis
On Wed, May 10, 2017 at 12:50 PM, Gabriele Tozzi wrote:
>
> Il 10/05/2017 14:45, Daniel Melameth ha scritto:
> >> queue ext on $Ext bandwidth 900K
> >> queue normal parent e
Il 10/05/2017 14:45, Daniel Melameth ha scritto:
>> queue ext on $Ext bandwidth 900K
>> queue normal parent ext bandwidth 386K, max 850K qlimit 10 default
>> queue high parent ext bandwidth 193K qlimit 10
>> queue low parent ext bandwidth 193K, max 540Kb qlimit 10
>
> You'll have to post your p
On Wed, May 10, 2017 at 4:47 AM, Gabriele Tozzi wrote:
> I have a quite simple pf setup: I have defined 3 queues for my external
> interface in my pf.conf:
>
> queue ext on $Ext bandwidth 900K
> queue normal parent ext bandwidth 386K, max 850K qlimit 10 default
> queue high parent ext bandwidth
Hello there,
I have noticed some weirdness when using "pfctl -s queue -v" so I have
decided to investigate.
I have a quite simple pf setup: I have defined 3 queues for my external
interface in my pf.conf:
queue ext on $Ext bandwidth 900K
queue normal parent ext bandwidth 386K, max 850K qlimit 1
pf.conf(5) states:
"All bandwidth values must be specified as an absolute value. The
suffixes K, M, and G are used to represent bits, kilobits, megabits, and
gigabits per second, respectively."
I guess that either should b be prepended to the list of suffixes even though
it isn't mandatory, or th
On Fri, 2 Dec 2016 12:14:56 + (UTC)
Stuart Henderson wrote:
> On 2016-11-25, Marko Cupać wrote:
> > Hi,
> >
> > I'd like to do limit bandwidth on gre tunnel protected with ipsec in
> > transport mode.
> I haven't tried this exact scenario. But I understand the general way
> things work and
On 2016-11-25, Marko Cupać wrote:
> Hi,
>
> I'd like to do limit bandwidth on gre tunnel protected with ipsec in
> transport mode.
>
> I've set single default queue on gre interface, matched everything
> that goes out to that queue, and finally passed everything out that
> interface:
>
> # SNIP
>
Hi,
I'd like to do limit bandwidth on gre tunnel protected with ipsec in
transport mode.
I've set single default queue on gre interface, matched everything
that goes out to that queue, and finally passed everything out that
interface:
# SNIP
queue mother on gre204 bandwidth 25M min 25M max 25M
On 2016-03-09, Mihai Popescu wrote:
>> -
>> queue download on $if_int bandwidth 10M max 10M
>> queue ssh parent download bandwidth 1M
>> queue web parent download bandwidth 8M
>> queue bulk parent download bandwidth 1M default
>>
>> match to port sshset queue ssh
>> match from port
On Wed, 9 Mar 2016 12:58:39 -0500
Christopher Sean Hilton wrote:
> I've also been trying to get help with queuing. Perhaps we can help
> each other out.
>
> I'm using queuing to alleviate bufferbloat and make my son's gaming
> performance better. I'm on an asymetric cablemodem connection here in
On Wed, 9 Mar 2016 21:28:10 +0200
Mihai Popescu wrote:
> > -
> > queue download on $if_int bandwidth 10M max 10M
> > queue ssh parent download bandwidth 1M
> > queue web parent download bandwidth 8M
> > queue bulk parent download bandwidth 1M default
> >
> > match to port sshset q
On Thu, 10 Mar 2016 13:28:11 +1100
Darren Tucker wrote:
> On Thu, Mar 10, 2016 at 1:38 AM, Marko Cupać
> wrote: [...]
> > queue download on $if_int bandwidth 10M max 10M
>
> What's $if_int set to?
>
> I played with queueing recently and initially used inter
On Thu, Mar 10, 2016 at 1:38 AM, Marko Cupać wrote:
[...]
> queue download on $if_int bandwidth 10M max 10M
What's $if_int set to?
I played with queueing recently and initially used interface group
names instead of interface names ("queue foo on egress ...") since
that&#x
On Wed, Mar 09, 2016 at 02:45:36PM -0700, Daniel Melameth wrote:
> On Wed, Mar 9, 2016 at 10:58 AM, Christopher Sean Hilton
> wrote:
> > I'm using queuing to alleviate bufferbloat and make my son's gaming
> > performance better. I'm on an asymetric cablemodem connection here in
> > the U.S. My dow
On Wed, Mar 9, 2016 at 10:58 AM, Christopher Sean Hilton
wrote:
> I'm using queuing to alleviate bufferbloat and make my son's gaming
> performance better. I'm on an asymetric cablemodem connection here in
> the U.S. My download is 100M and my upload is 40M. I use a queue
> definition similar to t
> -
> queue download on $if_int bandwidth 10M max 10M
> queue ssh parent download bandwidth 1M
> queue web parent download bandwidth 8M
> queue bulk parent download bandwidth 1M default
>
> match to port sshset queue ssh
> match from port sshset queue ssh
> match to port {
On Wed, Mar 09, 2016 at 03:38:30PM +0100, Marko CupaÄ wrote:
> Hi,
>
[... snip ...]
I've also been trying to get help with queuing. Perhaps we can help
each other out.
I'm using queuing to alleviate bufferbloat and make my son's gaming
performance better. I'm on an asymetric cablemodem connecti
On Wed, Mar 09, 2016 at 03:38:30PM +0100, Marko Cupać wrote:
> Hi,
>
[ ...snip... ]
> So, what exactly do I need to do to submit bug report? Any outputs of
> any commands? Logs? I understand developers won't take my word for it,
> but I simply don't know how to prove it, except watching output of
Hi,
Over last few months, in a few separate threads here on misc@, I have
been trying to call attention to the fact that pf queueing mechanism
does not shape traffic as it should, at least on my APU box.
It took me some time to test hundreds of possible configurations on 5.8,
both amd64 and i386
On Wed, Mar 02, 2016 at 10:46:08PM +1000, David Gwynne wrote:
> > On 2 Mar 2016, at 1:51 AM, Christopher Sean Hilton
> > wrote:
> >
> > I would like to apply queueing to packets traversing a gif tunnel. I'd
> > like to know what works better, Tagging outbou
> On 2 Mar 2016, at 1:51 AM, Christopher Sean Hilton
wrote:
>
> I would like to apply queueing to packets traversing a gif tunnel. I'd
> like to know what works better, Tagging outbound packets on the gif
> interface and applying them to queues by tag when they leave on the
I would like to apply queueing to packets traversing a gif tunnel. I'd
like to know what works better, Tagging outbound packets on the gif
interface and applying them to queues by tag when they leave on the
external interface? Or assigning packets to the queues directly when
they are on th
Prior threads explain how to set up bidirectional queueing, e.g.:
http://marc.info/?t=12947296581&r=1&w=2
http://marc.info/?t=13534516473&r=1&w=2
However, recommendations would be appreciated on the best approach to
shape/control download traffic on an OpenBSD 5.8
bin/cvsweb/~checkout~/www/faq/pf/index.html?&content-type=text/html]
Line 63
[http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/www/faq/pf/queueing.html?&content-type=text/html]
WARNING: This document is currently out-of-date and refers to a
queueing method that will be removed in OpenBS
On Fri, 15 Jan 2016 21:57:15 +1000
David Gwynne wrote:
> the other thing to note is that loading a ruleset resets the
> assignment of existing states to queues.
>
> states are assigned to queues via rules, but if the rules go away
> (which is what happens when you load a new ruleset) the intermed
> On 15 Jan 2016, at 9:07 PM, Craig Skinner wrote:
>
> On 2016-01-15 Fri 12:53 PM |, David Gwynne wrote:
>>> On 13 Jan 2016, at 19:19, Marko Cupa?? wrote:
>>>
>>> Have we come to conclusion that currently prio makes no sense at all?
>>
>> it wont have the effect you want. that doesn't mean it doe
On 2016-01-15 Fri 12:53 PM |, David Gwynne wrote:
> > On 13 Jan 2016, at 19:19, Marko Cupa?? wrote:
> >
> > Have we come to conclusion that currently prio makes no sense at all?
>
> it wont have the effect you want. that doesn't mean it doesn't make sense
> somewhere else.
>
Such as an ADSL PPP
gt; your hardware is slower at transmitting packets than the thing that
>>> generates these packets to send.
>>>>
>>>> in your case you're probably getting packets from a relatively
>>>> slow internet
>>> connection and transmitting them on a
> Ok, let's start insult each other.
No insult intended from my side and no one commited.
> I've setup my first PF on OpenBSD in 2006.
As Master Fu said once, if you can't setup it by yourself, maybe you
should not use it.
> Stuck your advice up your ass and fuck off.
I'm curious who will dear
> I'm writing this so I don't get another set of mails which warn me I
> can't shape inbound, but need to shape outbound traffic.
Hello Marko,
Don't you think you are out of subject with this thread already?
Now, seriously, do you expect someone to teach you queues online?
Maybe the PF implement
On Wed, 13 Jan 2016 16:36:23 +0200
Mihai Popescu wrote:
> > I'm writing this so I don't get another set of mails which warn me I
> > can't shape inbound, but need to shape outbound traffic.
>
> Hello Marko,
>
> Don't you think you are out of subject with this thread already?
> Now, seriously, do
On Wed, 13 Jan 2016 10:19:22 +0100
Marko Cupać wrote:
> Can I hope that saying 'currently' means this is not the intended
> design? Or should I come to peace with the fact that with OpenBSD and
> PF I can forget about shaping inbound TCP traffic in a way that
> child queues can expand to max lin
cklog of packets that priq can
> > > come into
> > effect. the only way you can build up a backlog of packets is if
> > your hardware is slower at transmitting packets than the thing that
> > generates these packets to send.
> > >
> > > in your case you&#x
re probably getting packets from a relatively slow internet
> connection and transmitting them on a high speed local network. the transmit
> hardware is almost certainly going to be faster than your source of packets,
> so you'll never build up a queue of backlogged packets, so prio is effec
erates these packets
to send.
>
> in your case you're probably getting packets from a relatively slow internet
connection and transmitting them on a high speed local network. the transmit
hardware is almost certainly going to be faster than your source of packets,
so you'll never buil
Besides what you explained now, I don't have the knowledge of
underlying queueing mechanisms of PF. But from what you said, it seems
logical that it should be possible to build up a queue of backlogged
packets not only by hitting physical limit of the hardware, but also
by setting logical limit. Ot
> On 11 Jan 2016, at 22:43, Daniel Melameth wrote:
>
> On Sun, Jan 10, 2016 at 7:58 AM, Marko Cupać wrote:
>> On Sat, 9 Jan 2016 11:11:27 -0700
>> Daniel Melameth wrote:
>>> You NEED to set a max on your ROOT queues.
>> I came to this conclusion as well. But not only on root queues. For
>> examp
aps I'm misunderstanding how prio
> works.
I would expect this as well, and I've been able to get it to work on
old ALTQ queueing system but not on current queueing system. Either I'm
misunderstanding how prio works as well, or we are coming to the point
where multiple users
On Sun, Jan 10, 2016 at 7:58 AM, Marko Cupać wrote:
> On Sat, 9 Jan 2016 11:11:27 -0700
> Daniel Melameth wrote:
>> You NEED to set a max on your ROOT queues.
> I came to this conclusion as well. But not only on root queues. For
> example, when max is set on root queue but only bandwidth on child
On Sat, 9 Jan 2016 11:11:27 -0700
Daniel Melameth wrote:
> You NEED to set a max on your ROOT queues.
I came to this conclusion as well. But not only on root queues. For
example, when max is set on root queue but only bandwidth on child
queues, no shaping takes place:
queue upload on $if_ext
On Fri, Jan 8, 2016 at 6:35 PM, Marko CupaÄ wrote:
> On Fri, 8 Jan 2016 11:13:08 -0500
> sven falempin wrote:
>
> > You will need to forward the all rule set i think, maybe the set prio
> > 0 is erased by a further rules, try to pass in quick those p2p
> > traffic before maybe ?
>
> I had the l
led down and http(s) should be given all the available
> bandwidth.
>
> The problem is that p2p does not get throttled down when http(s) is on
> wire. I spent days re-reading QUEUEING section of pf.conf and
> chapter #7 of 3rd edition of "Book of PF" but I still couldn
--
Before queue - p2p high priority, http(s) low priority, no bad self
image on the misc@.
After queue - p2p high priority, http(s) low priority, bad self image
on the misc@.
Where is the enlightment gone?
> Situation is still the same: torrents being downloaded at full speed
> (~8Mbit/s), simultaneous download of install59.fs from ftp.openbsd.org
> averages at ~6Kbit/s.
I'm not a PF consultant, but be aware that p2p can be a real beast to
setup. I was asked by someone to handle a double NAT situati
tware capabilities.
New queueing mechanism might be cool from developer's point of view,
but if people who actually configure production firewalls need 50 hours
not to accomplish the same goal which they used to accomplish in 20
minutes, I'm sure they would go for uncool queueing mechan
On Fri, 8 Jan 2016 11:13:08 -0500
sven falempin wrote:
> You will need to forward the all rule set i think, maybe the set prio
> 0 is erased by a further rules, try to pass in quick those p2p
> traffic before maybe ?
I had the luxury of ditching the complete ruleset for very simple one:
---pf.c
On 8 януари 2016 г. 17:51:21 Marko Cupać wrote:
I am completely confused. It seems that everything I've known about
queueing in PF does not apply any more, while at the same time there are
no reliable sources to learn new stuff.
Let's follow this paragraph from 'Book of
I am completely confused. It seems that everything I've known about
queueing in PF does not apply any more, while at the same time there are
no reliable sources to learn new stuff.
Let's follow this paragraph from 'Book of PF':
---quote---
Shaping by Setting Traffic Priorit
On Fri, Jan 8, 2016 at 12:44 PM, Marko Cupać wrote:
> Should I conclude my goal of throttling smaller priority traffic to
> minimum when higher priority traffic arrives can't be achieved with
> current PF? If I haven't gone senile, I did this successfully on dozens
> of firewalls back in altq/HFS
On Thu, 7 Jan 2016 22:41:47 + (UTC)
Stuart Henderson wrote:
> On 2016-01-07, Marko Cupać wrote:
> > # QUEUES
> > queue upload on $if_ext bandwidth 860K
> >queue ack parent upload qlimit 50 bandwidth 10K
> >queue fast parent upload qlimit 50 bandwidth 20K
On 2016-01-07, Marko Cupać wrote:
> # QUEUES
> queue upload on $if_ext bandwidth 860K
>queue ack parent upload qlimit 50 bandwidth 10K
>queue fast parent upload qlimit 50 bandwidth 20K
>queue bulk parent upload qlimit 50 bandwidth 800K default
>queu
hould be throttled down and http(s) should be given all the available
> bandwidth.
>
> The problem is that p2p does not get throttled down when http(s) is on
> wire. I spent days re-reading QUEUEING section of pf.conf and
> chapter #7 of 3rd edition of "Book of PF" but I
Am Mittwoch, den 04.11.2015, 10:09 +0800 schrieb Glenn Faustino:
> I notice that under queueing section of the pf.conf man page the total
> child queues bandwidth exceed what's defined in the parent.
Oops, now I found the /other/ example #|
> Can the bandwidth on the child queues
Am Mittwoch, den 04.11.2015, 13:37 +1100 schrieb Jason Tubnor:
> While pf(4) will let you define and load queues that exceed the parent
> (top
> level) queue, when you start to load up your queues, you'll get
> congestion
> defeating the purpose of queuing. To what point, depends on your
> enviro
On 4 November 2015 at 13:09, Glenn Faustino
wrote:
> I notice that under queueing section of the pf.conf man page the total
> child queues bandwidth exceed what's defined in the parent. rootq was
> defined with 100M bandwidth and the child queues defined http 60M, mail
> 10M
Hi,
I notice that under queueing section of the pf.conf man page the total
child queues bandwidth exceed what's defined in the parent. rootq was
defined with 100M bandwidth and the child queues defined http 60M, mail
10M, ssh 20M and std 20M.
Can the bandwidth on the child queues exceed w
On Mon, Sep 22, 2014 at 03:27:50PM +0200, Henning Brauer wrote:
> * Zé Loff [2014-09-22 14:57]:
> > Apologies in advance for reposting this, but I was afraid my original
> > message would get overlooked left inside its original (and slightly
> > unrelated) thread ("pf queue max bug").
> >
> > pf.
* Zé Loff [2014-09-22 14:57]:
> Apologies in advance for reposting this, but I was afraid my original
> message would get overlooked left inside its original (and slightly
> unrelated) thread ("pf queue max bug").
>
> pf.conf's man page shows some minor inconsistencies on the definition of
> queu
Apologies in advance for reposting this, but I was afraid my original
message would get overlooked left inside its original (and slightly
unrelated) thread ("pf queue max bug").
pf.conf's man page shows some minor inconsistencies on the definition of
queues. In some cases the queue parameters appe
Henning Brauer [hb-open...@ml.bsws.de] wrote:
> > Any idea why this was so much less of a problem with altq?
>
> it wasn't... the hfsc core was the same, and cbq worked exactly the same
> way too.
>
> People might not have paid as much attention? I dunno.
>
Raising HZ was frowned upon when I po
On 2014-08-22, Henning Brauer wrote:
> * Stuart Henderson [2014-08-22 13:51]:
>> On 2014-08-22, Henning Brauer wrote:
>> > * Federico Giannici [2014-08-22 09:51]:
>> >> On 08/22/14 08:22, Henning Brauer wrote:
>> >> >* Adam Thompson [2014-08-21 19:13]:
>> >> >>Unless I've mis-understood all th
On 22-08-2014 08:58, Henning Brauer wrote:
> it wasn't... the hfsc core was the same, and cbq worked exactly the same
> way too.
>
> People might not have paid as much attention? I dunno.
I believe it also has something to do with the network cards getting
better and also the internet links speeds
* Stuart Henderson [2014-08-22 13:51]:
> On 2014-08-22, Henning Brauer wrote:
> > * Federico Giannici [2014-08-22 09:51]:
> >> On 08/22/14 08:22, Henning Brauer wrote:
> >> >* Adam Thompson [2014-08-21 19:13]:
> >> >>Unless I've mis-understood all the emails and reports about this, it
> >> >>a
On 2014-08-22, Henning Brauer wrote:
> * Federico Giannici [2014-08-22 09:51]:
>> On 08/22/14 08:22, Henning Brauer wrote:
>> >* Adam Thompson [2014-08-21 19:13]:
>> >>Unless I've mis-understood all the emails and reports about this, it
>> >>affects low-bandwidth queues, not low-bandwidth inter
On Fri, Aug 22, 2014 at 10:05 AM, Henning Brauer wrote:
> * Federico Giannici [2014-08-22 09:51]:
>> On 08/22/14 08:22, Henning Brauer wrote:
>> >* Adam Thompson [2014-08-21 19:13]:
>> >>Unless I've mis-understood all the emails and reports about this, it
>> >>affects low-bandwidth queues, not
* Federico Giannici [2014-08-22 09:51]:
> On 08/22/14 08:22, Henning Brauer wrote:
> >* Adam Thompson [2014-08-21 19:13]:
> >>Unless I've mis-understood all the emails and reports about this, it
> >>affects low-bandwidth queues, not low-bandwidth interfaces.
> >>In other words, limiting traffic
On 08/22/14 08:22, Henning Brauer wrote:
* Adam Thompson [2014-08-21 19:13]:
Unless I've mis-understood all the emails and reports about this, it affects
low-bandwidth queues, not low-bandwidth interfaces.
In other words, limiting traffic to 50Mbps on a 1Gb link will work fine,
limiting it to
* Adam Thompson [2014-08-21 19:13]:
> Unless I've mis-understood all the emails and reports about this, it affects
> low-bandwidth queues, not low-bandwidth interfaces.
> In other words, limiting traffic to 50Mbps on a 1Gb link will work fine,
> limiting it to 50kbps on the same link will not.
>
On 2014-08-21, Federico Giannici wrote:
> On 08/21/14 19:03, Stuart Henderson wrote:
>> On 2014-08-21, Federico Giannici wrote:
>>> We are using a firewall/qos server with a lot of HFSC queues.
>>> We have just switched to the new queueing system of 5.5.
>>
On 08/21/14 19:03, Stuart Henderson wrote:
On 2014-08-21, Federico Giannici wrote:
We are using a firewall/qos server with a lot of HFSC queues.
We have just switched to the new queueing system of 5.5.
We'd like to get rid of custom kernels because now there is no longer
the limit of 64
03:12 PM CDT, Stuart Henderson
wrote:
>On 2014-08-21, Federico Giannici wrote:
>> We are using a firewall/qos server with a lot of HFSC queues.
>> We have just switched to the new queueing system of 5.5.
>> We'd like to get rid of custom kernels because now there is no l
On 2014-08-21, Federico Giannici wrote:
> We are using a firewall/qos server with a lot of HFSC queues.
> We have just switched to the new queueing system of 5.5.
> We'd like to get rid of custom kernels because now there is no longer
> the limit of 64 HFSC classes, but I have r
We are using a firewall/qos server with a lot of HFSC queues.
We have just switched to the new queueing system of 5.5.
We'd like to get rid of custom kernels because now there is no longer
the limit of 64 HFSC classes, but I have recently read that there are
still limits to the efficacy o
P/S and B/S values. pftop does not show queues at all.
>>
>> Was nice to see those values in real time. Are they gone for good, or
>> developers need some time to adjust them for new queueing mechanism?
>
> I believe this has been resolved in
> http://www.openbsd.org/cgi-
On Tue, 6 May 2014 13:09:25 -0600
Daniel Melameth wrote:
> I believe this has been resolved in
> http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/systat/pftop.c.diff?r1=1.24;r2=1.25,
> but I have not yet confirmed.
I have also noticed that output of 'systat queues' shows much larger
number of P
ce to see those values in real time. Are they gone for good, or
> developers need some time to adjust them for new queueing mechanism?
I believe this has been resolved in
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/systat/pftop.c.diff?r1=1.24;r2=1.25,
but I have not yet confirmed.
* Marko Cupać [2014-05-06 17:55]:
> Was nice to see those values in real time. Are they gone for good, or
> developers need some time to adjust them for new queueing mechanism?
that's what it comes down to.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services
Hi, One thing worth mentioning..
Queuing only works on 'Egress', not ingress. So if you want to queue
downstream traffic from the Internet, you need to queue it as it
egresses the internal interfaces.
If you have a LAN and a DMZ however and you queue on each interface you
will have to slice
1 - 100 of 210 matches
Mail list logo
