Hi Jeff,
How to try and trouble shoot the problem...
You'll need to actually analyse in depth a single connection that fails to
work. Do you see extra output in the ipmon log files for it?
Do you see the normal add/remove state messages?
If you can pick a specific address to trace it from (that isn't otherwise
used), using dtrace might help...the probes you want are something
like this:
fbt:ipf:fr_check:entry/((struct ip *)arg0)->ip_src.s_addr == 0xipaddr ||
(struct ip *)arg0)->ip_dst.s_addr == 0xipaddr/ { self->follow = 1; }
fbt:ipf:fr-check:return/self->follow/{self->follow = 0;}
fbt:ipf::entry/self->follow/{}
fbt:ipf::return/self->follow/{}
Darren
Jeff A. Earickson wrote:
> Darren,
>
> I have been using Sun's shipped version of ipfilter in the
> past few months with my Solaris 10 systems. Things have worked well
> with this setup (ipfilter 4.0.3, pfil 2.1.4).
>
> In my last patch cycle on Feb 28, Sun patch 125014-02 got
> applied to my systems (ipfilter 4.1.9, pfil 2.1.6) and now
> I'm starting to see vague indications of network issues.
> My biggest headache is with my mail server (a V490 using
> multipathing, running sendmail). Email is piling up in the
> outbound queues. If I put in an empty ipfilter ruleset and
> restart ipfilter, then I can get most of this email to go when
> I run the queues by hand. If I restart ipfilter with the
> ruleset that I always had, things start piling up again.
>
> I'm also having complaints from students in Australia not
> being able to connect to our webmail servers, coincident with
> this patch application to these systems.
>
> I haven't opened a Sun case yet, because I don't have much to
> go on. Got any insight here?
>
> Jeff Earickson
> Colby College
