[c-nsp] Stale tcp connection on FWSM

[Tony Varriale]

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" <matt at melbourne.org.uk>
To: <ayourtch at cisco.com>
Cc: <cisco-nsp at puck.nether.net>
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 <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
> _______________________________________________
> 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/