Azure Cluster Issue

[HeikoAnkenbrand]

I am use a R80.30 Azure Cluster!

The cluster does not move to the second gateway in case of error.

When I start the following script, I get an error (see picture).

# $FWDIR/scripts/azure_ha_test.py

And a few minutes later everything is shown as successful.

Even if everything is displayed correctly, the cluster will not work properly. As soon as the active gateway changes status, the routes in azure are not modified. Therefore no packets are forwarded.

What can I do here?
Or should I open a TAC case!

[Chris_Atkinson]

Heiko,

Does the failover occur if you wait (takes a long time) or not at all and how are you triggering the failover test?

Consulting TAC may well be the path to resolution.

Regards,

Chris

[Roman_Kats]

Hi Heiko,

Could you open a TAC case for this issue?

Thanks

[HeikoAnkenbrand]

Yes, I'll do it on Monday.

Thanks

[Martin_Valenta]

Why still cluster, why not to use scale sets?

[mdjmcnally]

Quick Question but why with R80.30 would the routes need to update.

Whenever deployed even since R80.20 then has used the Front End Load Balancer with a HealthCheck to fail over the inbound and you point the UDR for the Subnets at the Back End Load Balancer, so that they don't need to update.

As such the Health Check on the Load Balancers is what controls the failover in the current images.

The Load Balancers perform a HealthCheck against the two Firewalls Interface IP but only the Active Cluster Member responds so the Load Balancer sends the traffic to the IP that responds, it doesn't need to reconfigure.

UDR routes point at the Back End Load Balancer that does the same Health Check but the IP of the Back End Load Balancer doesn't change so the Routes in the UDR don't need to update.

Apologies if misunderstood your post.

[Matthias_Haas]

I agree with mdjmcnally.

you may check which template version you are running:

cat /etc/in-azure

If its below "20180301" then no internal/backend loadbalancer was used, I believe, see sk122793