i have a SLB Application Processor Complex module on my Cisco 6504 which basically does some load balancing work. I am pretty new to this device but the configurations and setup looks somewhat similar to the Cisco ACE but i only have some experience with the Cisco CSS.
What i would like to know is what the equivalent command to the CSS "flow timeout" is on the CSM. Would that be the "idle timeout" command? I understand that the "pending timeout" is more to governing how long it takes to setup a 3 way handshake from client to server and the "idle timeout" is what i am looking for. Please correct me if i am wrong...
On the CSS, a flow timeout is on 16secs for most standard ports and 8 secs for HTTP. I would like to know what the default setting is for the CSM idle timeout?? Thanks alot!!
For Idle Timeout the the default is 1 hour/ 3600 sec.
As you know for Cicso CSM thare are 2 timers per vserver.
If a connection is timed out it's because of one of these timers.
Idle timeout per vserver - If there is no traffic neither from client nor server. Idle connection timer duration in seconds; the range is from 0 (connection remains open indefinitely) to 13500000. The default is 1 hour. If you do not specify a duration value, the default value is applied.
This example shows how to specify an idle timer duration of 4000:
Cat6k-2(config-slb-vserver)# idle 4000
Pending timeout per vserver - is the max time allowed to complete the 3-way handshake.The default is 30 sec.Range is from 1 to 65535. This is a SLB virtual server configuration submode command. The pending connection timeout sets the response time for terminating connections if a switch becomes flooded with traffic. If the 3-way handshake does not complete within this time, the connection is dropped.
The CSM expect to see 2-way traffic within the pending timeout. If no traffic is received from the server, the session is removed.
This example shows how to set the number to wait for a connection to be made to the server:
Cat6k-2(config-slb-vserver)# pending 300
These are not counted as failures.
A failure is when the server does not respond or respond with a reset.
The CSM can hold 1 million connections in memory at the max.
So, if you set the idle timeout to 10 hours, your max connection rate is 1 M / 10 * 3600 = ~250 conn/sec.
Assuming they would all be open and then idle.
When the number of pending connections exceeds a configurable threshold, the CSM begins using the SYN cookies feature, encrypting all of the connection state information in the sequence numbers that it generates. This action prevents the CSM from consuming any flow state for pending (not fully established) TCP connections. This behavior is fully implemented in hardware and provides a good protection against SYN attacks.
Generic TCP termination
Some connections may not require TCP termination for Layer 7 load balancing. You can configure any virtual server to terminate all incoming TCP connections before load balancing those connections to the real servers. This configuration allows you to take advantage of all the CSM DoS features located in Layer 4 load-balancing environments.
To select the traffic type and appropriate timeout value, use the unidirectional command in the SLB virtual server submode.
[no | default] unidirectional
some protocol automatically set the 'unidirectional' function.
For example : UDP.
You can see if a vserver is unidirectional or bidirectional by doing a 'sho mod csm X vser name
When a virtual server is configured as unidirectional, it no longer uses the pending timer. Instead, the idle timer will determine when to close idle or errant flows. Because the idle timer has a much longer default duration than the pending timer, be sure to set the idle timer to an appropriate value.
Use the command "show module csm slot# stats" to get the details of connection.
The statistics counters are 32-bit. Totals are accumulated since the last time the counters were cleared.
This example shows how to display SLB statistics:
Connections Created: 180
Connections Destroyed: 180
Connections Current: 0
Connections Timed-Out: 0
Connections Failed: 0
Server initiated Connections:
Created:0, Current:0, Failed:0
L4 Load-Balanced Decisions:180
L4 Rejected Connections: 0
L7 Load-Balanced Decisions:0
L7 Rejected Connections:
Reached max parse len:0, Cookie out of mem:0,
Cfg version mismatch:0, Bad SSL2 format:0
L4/L7 Rejected Connections:
No policy:0, No policy match 0,
No real:0, ACL denied 0,
Checksum Failures: IP:0, TCP:0
Redirect Connections:0, Redirect Dropped:0
FTP Connections: 0
Tx:Unicast:1506, Multicast:0, Broadcast:50898,
Rx:Unicast:2385, Multicast:6148349, Broadcast:53916,
Overflow Errors:0, CRC Errors:0
Table mentioned below describes the fields in the display.
Number of connections that have been created on the CSM.
Number of connections that have been destroyed on the CSM.
Number of current connections at the time the command was issued.
Number of connections that have timed out, which can occur for the following reasons:
•connection has been idle (in one or both directions) for longer than the configured idle timeout.
•TCP connection setup not completed successfully.
Number of connections failed because the server did not respond within the timeout period, or the server replied with a reset.
Server initiated Connections
Number of connections created by real servers, the number of current connections, and the number of connections that failed (because the destination is unreachable).
L4 Load-Balanced Decisions
Number of Layer 4 load-balancing decisions attempted.
L4 Rejected Connections
Number of Layer 4 connections rejected because no real server was available
L7 Load-Balanced Decisions
Number of Layer 7 load-balancing decisions attempted.
L7 Rejected Connections: Total
Number of Layer 7 connections rejected.
L7 Rejected Connections: Parser
Number of Layer 7 connections rejected because the Layer 7 processor in the CSM ran out of session buffers to save the parsing state for multi-packet HTTP headers. The show module csm
L7 Rejected Connections: Reached max parse len
Number of Layer 7 connections rejected because the HTTP header in the packet is longer than max-parse-len. When a virtual server is configured with HTTP persistent rebalancing or cookie matching/sticky, the CSM must parse to the end of HTTP header. The default max-parse-len value is 2000 bytes.
L7 Rejected Connections: Cookie out of mem:
Number of Layer 7 connections rejected because of no memory to store cookies. When a virtual server is configured with cookie matching, the CSM must save the cookie contents in memory.
L7 Rejected Connections: Cfg version mismatch
Number of Layer 7 connections rejected because part of the request was processed with an older version of the configuration. This counter should only increase after configuration changes.
L7 Rejected Connections: Bad SSL2 format:
Number of Layer 7 connections rejected because the request is using an unsupported SSL format or the format is not valid SSL.
L4/L7 Rejected Connections
Number of Layer 4 and Layer 7 connections rejected for policy related reasons:
No policy: connection rejected because the request matched a virtual server, but this virtual server did not have a policy configured.
No policy match: connection rejected because the request matched a virtual server, but the request did not match any policy configured on the virtual server.
No real: connection rejected because no real server was available to service the request
ACL denied: connection rejected because a request matched a policy with a client-access-list entry and the entry is configured to deny the request.
Server Initiated: connection initiated by a real server is rejected.
Number of checksum failures detected (there are separate counters for IP and TCP failures).
Number of connections redirected, and the number of redirect connections dropped.
Number of FTP connections opened.
Number of MAC frames received and transmitted on the CSM backplane connection.
For getting details on all of these commands kindy refer Catalyst 6500 Series Switch Content Switching Module Command Reference, 4.2 URL mentioned below:
Thanks Sachin for your help. That really helps!!
Between the CSM and the CSS, the default timeout values for "idle timeout" and "flow timeout" respectively seem to have a great difference with one being just 16secs and the other on 3600secs. Have you had any experience with the CSS? But it certainly looks like the CSM is able to handle greater load as compared to the CSS.
Merry Xmas btw
Hi Daniel ,
Merry Xmas to you and your family!!
I have worked in different large data centres across Europe/US and there I get the chance to work with all flavors of load balancers from CISCO.
I have worked on CSM/CSS/ACE/Content Engines/SSLM/WAAS/WAE and so many more devices.
It is great to hear back from you and I am waiting for more queries as I would love to answer queries. I like to help others using Data Cente Application networking as this is my passion.
since we are on the topic of flow timeouts, i am just curious which mechanisms or rather commands are used on the Cisco ACE ?? And what is the default value for it ??
Another question i have is in a typical proxy environment whereby:
client traffic ---> Proxy server ---> Load Balancer
So when for example, multiple requests are seen coming from 1 proxy server to a particular VIP, I am assuming that a Cisco CSM/CSS will open multiple similar flows even if the source and destination will be the same. Will this be differentiated through unique sessions that are opened up on the load balancers?? Or how do they keep track of this?
Thanks in advance!