Re: OpenBSD 5.5 set prio 3 and interface shaping
On Aug 22, 2014, at 7:15 PM, Kevin Gerrard ke...@txwre.com wrote: I realize that this May seem like a dumb question for one of the developers. There's not much traffic on this pf list. You might have better luck asking on the openbsd misc list, there are a lot more people subscribed to that one. Did you look at the section labeled queuing in the pf man page? Assuming your outbound interface is em0, then: queue std on em0 bandwidth 25M should limit your outbound traffic to no more than 25M, as long as all outbound traffic is assigned to the std queue or one of its children.
SysKonnect sk driver high CPU interrupt rate after 3.8 upgrade
We have been running a pair of firewalls under 3.3 for quite some time, and just upgraded them to 3.8. Before the upgrade, they would typically run at about 35-40% interrupts. After the upgrade, they are running at 90-95% interrupt utilization. It looks like a lot of changes have been made to the sk driver over the past couple of years, apparently for the worse for our particular cards :(. The cards in particular are: skc0 at pci6 dev 1 function 0 Schneider Koch 984x GE rev 0x12: irq 11 skc0: SysKonnect GEnesis (0x0) sk0 at skc0 port A: address 00:00:5a:9a:7f:d4 xmphy0 at sk0 phy 0: XaQti Corp. XMAC II Gigabit PHY, rev. 2 Any suggestions on reducing the interrupt load to the previous levels? Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768
Re: Keeping a lot of states
On Tue, 16 Mar 2004, Jedi/Sector One wrote: On Tue, Mar 16, 2004 at 12:24:36PM -0800, Paul B. Henson wrote: We're running an X86 box with 512MB ram, nmbclusters = 8192, nkmempages = 81920 Didn't Cedric say that nkmempages 16384 on x86 was instable? Did you test it that way for a long time? It's been running in production since July 2003 without a blip. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768
Re: Keeping a lot of states
On Tue, 16 Mar 2004, Jedi/Sector One wrote: What is the highest safe value I should raise NMBCLUSTERS to on x86? How many states max will it keep? We're running an X86 box with 512MB ram, nmbclusters = 8192, nkmempages = 81920, and a state limit of 100. In testing I got up to about 1.3mil states before it died. I don't think you'll get any higher than this, as I recall at 1.3mil the kernel was using something like 480MB. Adding more physical memory actually decreases the amount of usable kernel memory... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768
upgrade to 3.3
I've finally gotten around to setting up 3.3 on a test system and hopefully
soon will deploy it in production.
At an operating system level, version 3.3 seems to have improved kernel
memory management. My system has 512 MB of RAM. Under 3.1, I was unable to
increase NMBCLUSTERS past 4096 without panicking the system at boot, nor
was I able to increase NKMEMPAGES over the default maximum, allowing only
100,000 active states. We did occasionally get mclpool limit errors, so it
was annoying not to be able to increase the allocation. Our active states
are usually between 40-50 thousand, so the state limit was not too big of a
deal, although occasionally we would hit the maximum during high load or
denial of service attacks.
With 3.3, I was able to set NMBCLUSTERS to 16384 with no problems, as well
as increase NKMEMPAGES to twice the default. During testing, I hit 400,000
states with no issues. I could have probably gone higher but I became bored
of waiting for the states to be generated ;)...
As for pf, the first thing I did was incorporate a local change into the
parser allowing for embedded comments within strings. I believe the
accepted way to accomplish this is via string concatenation, but I find
that aesthetically displeasing and involving far too many characters.
The main new feature I found myself availing of was tables. They allowed me
to dramatically decrease the size of my rule set, as well as make it far
less complex and easier to maintain. It is probably considerably more
efficient as well.
My one quibble with tables again involves the parser. I am fond of embedded
comments for documentation purposes, and found it annoying that tables
declared in place had to be on the same logical line and allowed no
comments within the table definition. I really would have liked to do
something like:
table foo { 1.3.4.5 # blah
5.5.7.8 # bluh
3.5.8.9 # bleh
}
Fortunately, tables defined via an external file allow this type of in line
comments, and most of my tables were fairly large so I went ahead and
defined them in separate files. However, for smaller tables defined in
place, this type of commenting would be useful.
Kudos to all of the pf developers. I really appreciate your work...
I'm hoping the next time I upgrade I'll find production ready stateful load
balancing/failover :).
--
Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | [EMAIL PROTECTED]
California State Polytechnic University | Pomona CA 91768
portable pf
Is there any widespread interest in developing a portable version of pf, similar to portable ssh? I know some efforts have been made to port it to other BSD variants, but I would be very interested in a Solaris port. I've used ipf under Solaris for a long time, however pf has long since overtaken it in feature set and reliability. I have ongoing issues with system crashes under Solaris when a lot of state is maintained. I would be interested in undertaking it myself but unfortunately I have ongoing repetitive stress issues and have a hard enough time keeping up with actual job duties :(... I could however host a development environment. -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | [EMAIL PROTECTED] California State Polytechnic University | Pomona CA 91768
Re: Commenting rule sets
On Tue, 13 Aug 2002, Philipp Buehler wrote:
On 13/08/2002, francisco [EMAIL PROTECTED] wrote To Paul B. Henson:
foonets = { 10.0.0.0/24, # subnet blah
10.0.1.0/24, # important stuff
10.0.2.0/24 # don't forget
}
it does in -current, since July 19, 2002.
And it does not since some hours later.
Out of curiosity, what style of comment was temporarily supported, and why
was it removed from the parser?
I do think some way of documenting sets defined in a variable would be
useful.
--
Paul B. Henson | (909) 869-3781 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | [EMAIL PROTECTED]
California State Polytechnic University | Pomona CA 91768
Commenting rule sets
in putting together a rule set, I'm going to have a number of instances of
variable definitions such as the following:
foonets = { 10.0.0.0/24,
10.0.1.0/24,
10.0.2.0/24 }
I'd really like to be able to comment these in line, e.g.
foonets = { 10.0.0.0/24, # subnet blah
10.0.1.0/24, # important stuff
10.0.2.0/24 # don't forget
}
however, the parser does not currently support this. Is there any way to
accomplish this type of commenting or achieve a similar documentation
without using inline comments?
If not, any thoughts on implementing some type of inline comment?
allowing the above syntax? Or perhaps C style?
foonets = { 10.0.0.0/24 /* subnet blah */,
10.0.1.0/24 /* important stuff */,
10.0.2.0/24 /* don't forget */
}
I don't really want to have a comment before the variable definition, as
there will be anywhere from dozens to hundreds of subnets.
Thanks...
--
Paul B. Henson | (909) 869-3781 | http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst | [EMAIL PROTECTED]
California State Polytechnic University | Pomona CA 91768
