Solved: ACE timeout settings

Bruce Summers · ‎12-14-2009

Hey folks,

I'm digging through the admin guide and I cant seem to locate anything about timeouts, other than sticky timeouts...

basically, what i'm looking for is something that will tell me what the "session" timeout setting is...Is it a global setting, is it configured per server farm, etc...???

any help would be appreciated...

thanks.

Bruce

Sean Merrow · ‎12-14-2009

Bruce,

Most of the ACE timers can be found at the following link:

Configuring TCP/IP Normalization and IP Reassembly Parameters

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/security/guide/tcpipnrm.html

Without seeing an actual failure in a network capture, it is hard to speculate on what the cause is. The ACE doesn't care about the size of a file traversing it. If your VIP is only layer 4 (VIP and port), then the ACE sees it as nothing more than a TCP session and doesn't look any higher up the stack. If the class is layer 7 (HTTP header parsing), then it still only looks at the header.

The best place to get a capture is from the ACE tengig port, especially if the client PCs are locked down. The tengig capture will give both sides of the connection. The before and after showtechs will allow you/TAC to see if any error counters are incrementing at the time of a failure.

You can also use the ACE's built-in packet capture utility if all else fails. I like to use a SPAN first. After all, the ACE could be the culprit here, and using the built-in utility is kinda like asking one of the suspects of a crime for the facts of the case. ;- )

Another tool to use is the 'show conn ?' and 'show conn detail' commands immediately after you launch a test connection. This will give you some insight as to the state of the connection and how far along it got.

Sean

View solution in original post

Bruce Summers · ‎12-14-2009

I should have caveat'd this with my overarching problem.

A user, using MS SharePoint, attempts to upload a file larger than just a couple of MB, it clocks for about 2 minutes, and then dies...

I'm attempting to get amplifying information about "dies", but suffice it to say, they cant upload the files...

bruce

Sean Merrow · ‎12-14-2009

Hi Bruce,

By default, the ACE will use the following inactivity timers before removing an inactive connection:

ICMP—2 seconds

TCP—3600 seconds (1 hour)

UDP—120 seconds (2 minutes)

These timers can be adjusted using a connection parameter-map and applying it to the class. However, if your customer is uploading a file, the connection is hardly inactive. So, this will require further investigation.

Can the client ping the VIP using the IP address? How about using the FQDN of the VIP? If the answer to either of these is no, then perhaps you have a layer 1 - 3 problem, or a DNS issue.

Next, you might want to run a network capture utility (ie. tcpdump, Wireshark, etc.) on the client PC to see how far the connection to the VIP gets. Given that the connection seems to chug away for a couple minutes, might mean that the connection hits the VIP, is load balanced to a server, but the server is bypassing the ACE with its response back to the client. Be sure the server's response will make it back to the ACE first so the ACE can change the source address of the response from the server's IP back to the VIP.

If this capture doesn't help, you might want to move to the tengig port of the ACE. For this, you would set up a standard monitor session and set the source interface to TengigX/1 where X is the slot number the ACE resides in. This will give you both client and server side captures in one capture.

If none of this gets you enough information to figure out the issue, then I would recommend following this action plan:

- get a showtech from the context in which the VIP resides

- start a capture of the tengig ACE port

- replicate a connection failure 3 times

- stop the capture and save to a binary file

- get a second showtech from the same context

- send the two showtechs and capture into Cisco TAC for assistance.

Be sure to indicate the IP address of the client used in the test, the VIP the client tried to connect to, etc.

Hope this helps!

Sean

Bruce Summers · ‎12-14-2009

thanks Sean,

it does help...appreciate the pointers..

so, those timers only apply to "inactive" connections...

dns/vip address access isnt a problem...they can get to the VIP, by the IP and by FQDN, as well as all 4 servers in the farm (directly).

I'm pretty sure they wont be able to install wireshark on their workstations...they are locked down pretty hard...but, i'll see what i can do from mine...

I was poking around today and found some information using "sho terminal internal info" which shows file size of unlimited...i'm assuming this is the size of files that is allowed to traverse the ACE?

Bruce

Bruce Summers · ‎12-14-2009

also,

are there any other timeouts that could cause such a symptom?

bruce

Sean Merrow · ‎12-14-2009

Bruce,

Most of the ACE timers can be found at the following link:

Configuring TCP/IP Normalization and IP Reassembly Parameters

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/configuration/security/guide/tcpipnrm.html

Without seeing an actual failure in a network capture, it is hard to speculate on what the cause is. The ACE doesn't care about the size of a file traversing it. If your VIP is only layer 4 (VIP and port), then the ACE sees it as nothing more than a TCP session and doesn't look any higher up the stack. If the class is layer 7 (HTTP header parsing), then it still only looks at the header.

The best place to get a capture is from the ACE tengig port, especially if the client PCs are locked down. The tengig capture will give both sides of the connection. The before and after showtechs will allow you/TAC to see if any error counters are incrementing at the time of a failure.

You can also use the ACE's built-in packet capture utility if all else fails. I like to use a SPAN first. After all, the ACE could be the culprit here, and using the built-in utility is kinda like asking one of the suspects of a crime for the facts of the case. ;- )

Another tool to use is the 'show conn ?' and 'show conn detail' commands immediately after you launch a test connection. This will give you some insight as to the state of the connection and how far along it got.

Sean

Bruce Summers · ‎12-14-2009

again, thanks...

Yea, i tried doing some captures, but disocered the host is being natted at the outbound firewall...the user isnt local to me... ;-)

I'll work on some of your suggestions...

thanks...

Bruce

Bruce Summers · ‎12-17-2009

Hey Sean,

Went through some testing...

I bypassed the ACE (by going directly to the server) and i get the same error...

unable to upload the file...its gotta be a config on the sharepoint server then...

thanks

Bruce