ACE4710 probe failure after reload

Answered Question
Jun 8th, 2010
User Badges:

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

Correct Answer by Sean Merrow about 6 years 10 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Sean Merrow Tue, 06/08/2010 - 08:43
User Badges:
  • Silver, 250 points or more

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 Vale... Tue, 06/08/2010 - 16:41
User Badges:

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 Wed, 06/09/2010 - 06:49
User Badges:
  • Silver, 250 points or more

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 Vale... Wed, 06/09/2010 - 07:33
User Badges:

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 Wed, 06/09/2010 - 07:44
User Badges:
  • Silver, 250 points or more

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

steve_mils Wed, 06/09/2010 - 07:03
User Badges:

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 Wed, 06/09/2010 - 07:20
User Badges:
  • Silver, 250 points or more

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 Wed, 06/09/2010 - 07:27
User Badges:

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

Actions

This Discussion