10-May-2022 12:34
Hi!
I'm building a F5 cluster. 2 VMs, 3 interfaces:
I Azure I have 3 VNets - according to needs
When I wanted to start forming a cluster, I noticed VMs does not ping each other on external nor internal interfaces.
Only MGMT (which currently are opened to connect from Internet - temporarily).
While this is internal subnet traffic, NSGs shouldn't be a problem. Yet - if it doesn't work, we added permit internal to internal on any port/proto. Nothing changed...
I have simple setup as it can be:
BigIP1
BigIP2
bigip1 doesn't ping bigip2. Doesn't resolve ARP. I tried to add static ARP on both sides - didn't help...
[admin@bigip1:Active:Standalone] ~ # ping 10.0.3.10
PING 10.0.3.10 (10.0.3.10) 56(84) bytes of data.
64 bytes from 10.0.3.10: icmp_seq=1 ttl=255 time=0.733 ms
^C
--- 10.0.3.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.733/0.733/0.733/0.000 ms
[admin@bigip1:Active:Standalone] ~ # ping 10.0.3.11
PING 10.0.3.11 (10.0.3.11) 56(84) bytes of data.
64 bytes from 10.0.3.11: icmp_seq=1 ttl=64 time=0.042 ms
^C
--- 10.0.3.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.042/0.042/0.042/0.000 ms
[admin@bigip1:Active:Standalone] ~ # ping 10.0.3.12
PING 10.0.3.12 (10.0.3.12) 56(84) bytes of data.
^C
--- 10.0.3.12 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms
[admin@bigip1:Active:Standalone] ~ # arp -a | grep 10.0.3
? (10.0.3.10) at 00:0d:3a:2d:74:82 [ether] on internal
[admin@bigip1:Active:Standalone] ~ #
I even created similar setup in GNS3, which works perfectly, so I assume something is wrong on Azure side.
But after clearing out NSGs I'm confused what can it be...
Using Version 16.1.2.1
11-May-2022 01:57
Hi,
This is definitely an issue on the Azure side, You have to allow communication between internal networks from your Big-IP, in the Restricted Src Address you have to specify the IP addresses of the network – the ones that are allowed to connect to the BIG-IP.
Review the next link to try to find the step that you miss in your azure configuration:
https://community.f5.com/t5/technical-articles/create-a-big-ip-ha-pair-in-azure/ta-p/282837
Additional in this link you have all the information:
Hope it´s work.
11-May-2022 02:13 - edited 11-May-2022 02:13
Hi @shadow_82,
I strongly advise against building a failover cluster in the cloud. Resources in the cloud are far to expensive to use them in standby mode. Failover might take longer than expected (=bad customer experience).
I do recommend to have an active/active setup and utilize GSLB as a service (F5 DNS Load Balancer Cloud Service) to distribute traffic between the two instances. Use Terraform / AS3 (any form of automation) to keep the config on both BIG-IP nodes consistent.
If you insist on using failover - this is how it's done the F5 way: https://clouddocs.f5.com/products/extensions/f5-cloud-failover/latest/
KR
Daniel
13-May-2022 00:47
Thanks for answer!
This is something we are thinking about, maybe not active active due to heavier troubleshooting once something bad occurs (you have to divide traffic going though 2 F5s, not 1).
Yet maybe having only 1 F5 running and second being shut down in cluster - until some upgrade procedure will be needed.
This might be the sweet spot.
You pay for 1 VM running 24/7/365 and spin up the 2nd one for upgrade purposes (to switchover)
11-May-2022 09:04
@Jeff_Giroux_F5 did a series of lightboards on Azure deployments that might be helpful. Check them out here.