ACE4710 probe failure after reload

[steve_mils]

Hi all,

I'm just going through some failover testing with a pair of ACE 4710 appliances configured as a fault tolerant pair and have noticed that it takes a while for my probes to start working correctly. To explain better:

1. Reload the primary appliance
2. Secondary appliance becomes active as expected
   
3. Primary appliance comes back up and immediately becomes active again (preempt is enabled by default)
   
4. HTTP probes on the primary fail for around 30 seconds before becoming successful (on first failover at point 2 above probes are fine)

We're running the latest code: Version A3(2.5).

Has anybody seen this behaviour before? I was thinking that a preempt delay would help here - but in the meantime I've disabled preempt on the ft groups so that I can manually switchover.

Thanks, Steve

[Sean Merrow · Accepted solution]

Hi Steve,

Since you are using the ACE 4710, you may need to use the carrier delay feature.  This gives spanning-tree some time to converge.  Have a look at the feature in the docs and see if that helps.

Regards,

Sean

[Jaime Soto Valenzuela]

Hi,

I was seeing the same issue in a client. I´m going to apply the carrier-delay command in interface of ACE. This command should be applied only in ACTIVE ACE?

Regards,

Jaime

[Sean Merrow]

Hi Jaime,

Both your standby and active ACE should have the same config.  By default, any config changes you make to the active ACE will automatically be sync'd to the standby.

Sean

[Jaime Soto Valenzuela]

Hi Sean,

I don´t have synchronized the context Admin, only the data contexts are sync.

If I configured the carrier-delay command in both interfaces Gi1/1 (Active and Standby), when the Active down, the Standby going to take the time configured in carrier-dalay in to be In-Service...or not??. In this moment the client won´t have services.

For that I think only applied in the Active ACE.

If I am confused please clarify.

Regards,

Jaime.

[Sean Merrow]

Hi Jaime,

Carrier-delay is for when link has gone down.  Just because the active ACE goes down, doesn't mean the standby ACE is losing link. When you have redundant ACE, you should sync'd configs.  If you only apply it to the active ACE, what happens in a failover?  Would you remove the config from the now standby and add it to the new active? ;- )

Hope this helps clear it up.

Sean

[Jaime Soto Valenzuela]

Ok Sean, thank for your clarification.

Jaime.

[steve_mils]

Hi Sean,

Thanks for that - it worked. The probes still fail for a bit but the VIP only drops 2 pings instead of around 12. I've tried setting the carrier-delay to various numbers and have settled on 50 seconds as acceptable.

BTW - I think you need to change this setting on both ACEs because you're working in the Admin context - and the configuration for this is not synced across boxes.

[Sean Merrow]

Thanks for the follow-up Steve, and I'm glad it helped.

If your Admin context is not automatically sync'ing, then it sounds like you don't have an FT group configured for it, like you do for the user contexts.  Is this the case?  If so, I would recommend configuring one so you don't have to duplicate changes to the Admin context on both ACE.

Sean

[steve_mils]

Ah ha!

You're right - this is the case. I only have FT set up on the other contexts. I just assumed that you wouldn't want to sync the Admin context just in case interface configuration gets overwritten or something. I guess I should RTFM ;-)

Thanks for your help on this. Cheers, Steve