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/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
