F5 BigIp cluster active/stanby in Azure, failover very slow

Hi Alexandre_Demasi​ 

I know it's 2 years late but I just came across your question. You have an excellent diagram and thank you for providing it. I also like this approach and I have written about in on DevCentral in the past in this article: https://community.f5.com/kb/technicalarticles/transparent-load-balancing-in-azure-part-2/332419

I have helped customers set this up. You have explained it well. But your question is: why does it take up to 3 mins for the ALB to realize failover?

If your iRule is working properly, the health probes from ALB will start failing immediately when a device becomes Standby for traffic-group-1. So I think we can say one of the following things could be your problem:

1. Your ALB/iRule is not 100% correct. Are you doing TCP health checks at ALB but expecting an HTTP request in your iRule? I've seen customers set that up accidentally.
2. Your ALB health probe frequency is too long.
3. Your second iRule is a simple HTTP::respond 200. In my example, I actually respond with content like "I am healthy!". That may not matter, but that's what I do. 
4. Could there be a port mis-match between your 2 VIPs? I have seen a customer set up the first VIP listening on 8001 but then the "probing-vip" is listening on a different port, so the forwarding iRule is not getting traffic on the right port.

Those are my best guesses. Because this setup requires some advanced knowledge, I only recommend it to F5 customers that I know have the confidence in their entire F5/Azure team to support it. Sometimes, as long as they are using SNAT AutoMap and not requiring true src IP at their application, I tell them to use architecture number 4 from this article and run Active/Active: https://community.f5.com/kb/technicalarticles/four-activeactive-load-balancing-examples-with-f5-big-ip-and-azure-load-balancer/327959

Message me over DevCentral or reach out some other way if you ever want to catch up about this. That goes for any customer reading this :)

Mike.