I have a strange issue but I'm not sure it is content switch related in any way.
A group of hosts talk to two servers connected behind a content switch via a VIP.
Some dev are complaining about a high level of discarded / reset connections.
From the trace we ran you can see some RST,ACK packets in Wireshark but no RST packet prior to that last RST,ACK packet sent by the ACE module to the clients.
Did anybody come across the same kind of situation?
What is the source address on these RST packets?
Is it ACE vlan address / Client Address?
If its ACE then could you post the probe config of the probes used to check availability of these servers.
Syed Iftekhar Ahmed
Is there a chance that you are running code A2 (3.2)? You may be hitting a bug that I have found within my environment as well. CSCti88248.
CSCti88248—When the ACE is waiting to reassemble client packets, it may reset TCP-based client connections if all the following conditions exist:
–ACE is configured with a Layer 7 load-balancing policy where the ACE proxies the client-side TCP connection before making a load-balancing decision
–Client-side connection experiences packet loss
–The TCP TX racing messages (data) counter in the output of the show np n me-stats -stcp is incrementing
This problem can also occur with secure (SSL) terminated connections. Workaround: Configure an empty connection parameter map and add it to a multi-match policy map under the class map that is configured for the VIP experiencing the problem. For example:
parameter-map type connection TCPReassembly
policy-map multi-match MultiMatch_PolicyMap
loadbalance vip inservice
loadbalance policy L7_HTTP_PolicyMap
loadbalance vip icmp-reply active
connection advanced-options TCPReassembly Regards
Any chance this problem is related to http-traffic? I've experienced a similar problem with http-headers exceeding the maximum length (4k as I recall) and consequently, ACE issued a RST towards the client, whenever this criteria was met.
If so, this can be solved by configuring an http-parameter map (or modifying an existing one) with the length-exceed continue option. This instructs the ACE to disregard any excessive http-header-lengths.