Practical considerations for using Azure internal load balancer and BIG-IP
Background
I recently had a scenario that required me to do some testing and I thought it would be a good opportunity to share. A user told me that he wants to put BIG-IP in Azure, but he has a few...
Updated Feb 12, 2024
Version 4.0
MichaelOLeary
Employee
Employee
raviraj
Altostratus
AltostratusHello MichaelOLeary
Thank you very much for this scenario and explaination. Option-C with Azure Internal LB with two rules seems to be more relevant.
Do you have illustrative config exmaple for option-C
I have following queries.
1. In case of Option-C: F5 VE active-standby with Azure ILB and two rules. What are the destination address ranges we need to add in UDR with next hop as Azure ILB 2nd front-end IP (for example 10.0.3.50) , whether those are 'end user client subnets or Onprem IP address ranges' (from where traffic is initiated) and can still we have default-route pointing towards firewall for other Internet bound traffic such as patch updates.
One more doubt I have is, if those routes in 'UDR' are end user client subnets or Onprem IP address ranges and if not all traffic from end users are going through F5 (for example some traffic directly going to App Servers which is not behind any LBs) then will it cause any issues
2. If backend Servers (actual application VMs) are resides in AVS(Azure VMware Solution) then we can still leverage Option-C with either active-active or active-standby configuration. As per my understanding, need to do 'source NAT' for 'active-standby config' as well since in AVS not sure how to put that static route pointing towards Azure ILB. However please correct my understanding if it is wrong.