[c-nsp] Stale tcp connection on FWSM

[Matthew Melbourne]

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 <ayourtch at cisco.com>

> 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/
>>
>>


-- 
Matthew Melbourne