ACE Redirect not working

Unanswered Question
Jan 28th, 2010

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
  rserver Test

class-map match-any Test
  2 match virtual-address tcp eq www

policy-map type loadbalance first-match Test
  class class-default
    serverfarm Test

class Test
    loadbalance vip inservice
    loadbalance policy Test
    loadbalance vip icmp-reply active

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
bshellrude Thu, 01/28/2010 - 09:32

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?

paul.rehill Thu, 01/28/2010 - 10:51

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.

bshellrude Thu, 01/28/2010 - 11:26

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??

paul.rehill Thu, 01/28/2010 - 11:29

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

bshellrude Thu, 01/28/2010 - 11:35

Oh... So 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?

paul.rehill Thu, 01/28/2010 - 11:38

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.

bshellrude Thu, 01/28/2010 - 11:54

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


paul.rehill Thu, 01/28/2010 - 11:57

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       

bshellrude Thu, 01/28/2010 - 12:13

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

paul.rehill Thu, 01/28/2010 - 12:22

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.

paul.rehill Fri, 01/29/2010 - 06:06

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.

bshellrude Fri, 01/29/2010 - 07:30

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

Glad you got it figured out!


This Discussion