Jens Elkner wrote:
Hi,
as previously written, we 've seen a lot of problems / unavalibility /
strange behavior wrt. our Internet aka more or less public related
services running on Solaris machine after upgrading to S10u4 or higher.
Firstly, this mailing list is for OpenSolaris, NOT Solaris 10.
The correct forum for you to express your grievences is via
the support channel as you appear to have done but it seems
like you didn't like the answers you received...
Finally (in July 2009, i.e. almost 2 years later!!!) it turned out,
that the state table size is by far too small - see fr_statemax in
ipf -T list | awk '/fr_state/ { print $1, $7 }'
So the sun case engineer explained, if ipf can not insert an entry into
the state table, it just _continues_ evaluating the rules that follow.
I couldn't believe my eyes!!! What a crap!!!
Well, what would you have it do?
It is not appropriate to have ipfilter automatically
grow the tables as you suggest through "automatic
tuning" because then your system becomes vulnerable
to a denial of service attack from remote attackers.
If you're not aware of how much network traffic is
going through your firewall and you're not paying
attention to what your firewall is doing then you've
got more work to do in order to manage the system
effectively.
...
Wrt. a required syslog message he respond, that a counter increment
(ipfstat: packet state*lost) costs 2 cycles on sparc, only, but a syslog
message 2000 cycles and would cause ipf to "hang"/be unusable, and closed
the case.
syslog message from where?
Generating messages from within kernel modules
is generally frowned upon.
3) Actually I would expect, that there is some kind of global SW
register (perhaps called log indicator table), where one could
also add a "state table full counter", which gets incremeted by
ipf and I assume,
Something like that exists.
that there is also a kernel log daemon or even user
space logger, which can read this table in certain intervalls and
log the problem. So the 2 vs. 2000 cycle reason for making Solaris
users live harder than necessary is IMHO a very poor one / implies
a not very well thought SW design (at least in the eyes of a normal
human beeing ;-) having not much ipf insights because of shallow
documentation).
Usually, an admin always looks in /var/adm/messages first, if the
cause of a problem can not be determined/is not really reproducable.
/var/adm/messages isn't generally considered an "interface".
Whilst we can send messages to/via it, we are not allowed to
rely on them as being the only communication channel with the
systems administrator.
So is this, because at some time the state table was full, or is
this, because ipf tried to insert a state, which is already present
in the table?
It is because it tried to insert a state entry to a table that is full.
Sure, ipf's behavior to processs the rules list like
'the rule is ignored' is for my taste more than a minor security
issue, but anyway, should one rise fr_statemax the value to make
it bigger and bigger 'til one finds out, that actually ipf is having
a problem? And what is also not clear: are the 'lost' counters also
snapshots (for what intervall/time), or is this an accumulation
from when ipf got started/refreshed?
It's part of something much more than that.
What it allows is for you to create "keep state" rules
that define a maximum number of states allowed for them
and when that maximum is reached for other rules to be
then applied to packets. The problem of when the global
maximum is reached is a degenerative case of that.
...
BTW: Why shows 'ipfstat -t' so many entries with negative ttls. It
appears, that if the min? value of -59:-59 is reached, ttl gets
reset to 0:00 and restarts decrementing it ... - strange
That's a known bug... fixed in the current opensolaris
source code tree and will be fixed in the next release.
A fix is also being considered for Solaris 10.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
