Based on what you posted so far, IMO, you are far from overrunning the box.
I would focus on what are correct settings for your box(es). Then, I would
make sure it's valid traffic. You could either work from bottom up or from
top down (go unlimited for the static and work your way back).
If you still are having valid issues, then look at the FWSM limits.
HTH!
tv
----- Original Message -----
From: "Matthew Melbourne" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, December 29, 2009 10:34 AM
Subject: Re: [c-nsp] Stale tcp connection on FWSM
Thanks for your reply. It looks like it could be oversubscription of the
session path, though I am not completely familiar with the internal
architecture of the FWSM.
system/xxx# show np all stats | inc Close
PKT_CNT: Close indication sent : 1929469548
PKT_CNT: Close indication sent : 946451842
Close Indications : 4197817416
Close Notify Errors : 16
How could I determine if this is genuine oversubscription? Are there any
recommendations for mitigating the issue with the current code base?
Best regards,
Matt
2009/12/29 Andrew Yourtchenko <[email protected]>
Reducing the timeut most probably would not help in this case - the
counters for the connections are maintained in the session path, while
the
connections themselves are in the fast path.
Give "show np all stats | inc Close" - if the sum of the first two
numbers
is running ahead of the third number, then it's a result of the
oversubscription of the session path.
We've an enhancement request CSCsv60119 around a similar area (embryonic
connections counting) to get more resilient behaviour under stress
conditions - with the current code it's considered a limitation.
Maybe worth taking a closer look at what the overall CPS through the FWSM
is and whether it is a genuine oversubscription or there is something
other
factor that influenced the traffic pattern. Depending on what your
historic
monitoring data shows, it could be either.
thanks,
andrew
On Tue, 29 Dec 2009, Matthew Melbourne wrote:
We have a transparent firewall context on a FWSM (code revision:
3.1(16)).
Recently the number of tcp connections has been increasing to a point
where
it hits the limit defined in the static and new connections are denied.
However a "show conn | inc x.x.x.148" doesn't show nearly the number of
active connections the "show local-host" command might suggest.
A "clear local-host x.x.x.x" fixes the problem temporarily, but the
problem
resurfaces later (and on different hosts). Is there any way to see any
more
detail on these 11000+ connections?
xxx# sh local-host x.x.x.148 all
IPv4 local hosts:
Local host: <x.x.x.148>, tcp conn(s)/limit = 11806/20000,
embryonic(s)/limit = 4470/50 udp conn(s)/limit = 0/0
Xlate(s):
Global x.x.x.148 Local x.x.x.148
I am considering whether we should perhaps reduce the default TCP
connection
timeout to less than the default one hour. I am beginning to agree with
other contributors here, that firewalls placed in front of servers is of
limited benefit and just creates masses of state which needs to be
maintained, as well as opening up other potential DoS vectors. :-)
Cheers,
Matt
--
Matthew Melbourne
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
--
Matthew Melbourne
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
