[c-nsp] Stale tcp connection on FWSM

[Andrew Yourtchenko]

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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>