We have a ACE redirect configured on 3 physically seperate ACE modules with the following config. It works on one ACE Module and not on the other 2.
Capture on the ACE and sniffer gives this error.R [bad tcp cksum 2d41!] ACE sends resets to the client. Anyone run into this issue?
The software version is system: Version A2(1.0a) [build 3.0(0)A2(1.0a)
rserver redirect Test
serverfarm redirect Test
class-map match-any Test
2 match virtual-address 192.168.10.10 tcp eq www
policy-map type loadbalance first-match Test
loadbalance vip inservice
loadbalance policy Test
loadbalance vip icmp-reply active
Is there a difference in topology between the sites that are working and the one's that aren't?
Any chance that the one that isn't working, has the server people are being redirected to, implemented in a network such that it might be replying directly to the client?
Topology is exactly the same. All 3 contexts are in routed mode.
I actually try to hit the VIP directly using IP via telnet. No DNS is involved so my going to a wrong server is not an issue.
Sorry maybe I didn't explain what I was getting at good enough...
I guess I'm basically asking if there's potential for asymmetry at the site that's not working.
Say I have a load balanced server. It has two interfaces a "front end" and a "back end". I manage the server on the backend from my laptop, for which the server has a route. Now if I try to hit the public VIP of the LB, traffic is routed to the VIP, then to the server, but because the server already has a route to my laptop via the backend, it bypasses the load balancer on the return and replies directly to me, thus putting the flow out of sync and never completing the connection...
Not saying that's it, but I've had so many asymmetry issues that are tough to figure out that It's usually one of the first things I rule out...
It's possible if the site that's not working is local to you and the others aren't, this may be a potential issue??
That is not an issue in this case as there really is no real server in this case. Just redirect. This is the output from the one that works. As you can see all it does is give me the new URL.
HTTP/1.1 302 Found
Oh... So www.test.com doesn't live behind the ACE's?
Also from what I've read, depending on where you capture... If you capture on the ACE itself the bad tcp cksum is normal...
So the configurations between the 3 sites are exactly the same?
Sniffer in front of the ACE just shows resets from the ACE. We will be rebooting the module tonight in one of the environments and see if it fixes it.
All packets show as dropped.
VIP State: INSERVICE
curr conns : 0 , hit count : 40
dropped conns : 6
After another telnet attempt
VIP State: INSERVICE
curr conns : 0 , hit count : 43
dropped conns : 9
The ACE's do know how to get back to the client right? The return traffic isn't being routed a different way than it came in?
Another thing you could try, not sure it will make a difference, is changing the returned code to a 301 instead of the default 302
I have ruled out routing and firewall issues. If I place a real server in that server farm the VIP responds fine. I can try the 302 that but the default works in another setting. I will try that anyway.
Reboot of the ACE fixed the problem.Apparently ACE starts behaving weird after being up for more than 485 days. However, I am not sure if this was our problem.
CSCtb23312—The ACE becomes unresponsive when its uptime reaches approximately 485 days. Workaround: Gracefully reboot the ACE before its uptime reaches 480 days.
Will be looking to upgrade soon guess.
Thanks for the replies.