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.

For example.

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
Connection: close
Location: http://www.test.com

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.

What does a "show service detail" for that class say for dropped

connections?

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       

Stupid question.

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.

Huh... Well got to admit I was pretty skeptical that was going to fix it... But go figure!!

Glad you got it figured out!