Differences

This shows you the differences between two versions of the page.

--- infoblox_nios:azure [2024/09/04 13:38] – [DHCP in Azure] bstafford
+++ infoblox_nios:azure [2025/03/07 04:36] (current) – [Private Link] bstafford
@@ Line 10: / Line 10: @@
 ===== Private Link =====
 When configuring forward zone to web.core.windows.net, you will have to untick "Forward only" because the Private Link resolver will respond with authority date for windows.net which is not a subdomain of web-core.windows.net.
+.63.129.16 is the magic DNS IP in Azure.
+Resolver = $180 montly per endpoint.
+===== HA =====
+Documentation on [[https://docs.infoblox.com/space/vniosazure/636026896/Deploying+the+vNIOS+Instance+with+High+Availability|Azure HA]] and some extra data [[https://docs.infoblox.com/space/vniosazure/37650561/About+Infoblox+vNIOS+for+Microsoft+Azure#Limitations-and-Recommendations|here]].
+Permission details for HA are [[https://docs.infoblox.com/space/vniosazure/37814511/Prerequisites+for+the+Azure+Public+Cloud+Deployment#Creating-an-User-Assigned-Managed-Identity|here]].
+  * You must create a Managed Identity and set the scope as a subscription.
+  * The custom role must be assigned to the Managed Identity.
+  * The Managed Identity must be assigned to both vNIOS of the HA configuration.
+NIOS HA in Azure/AWS/GCP supported from NIOS 9.0.4 onwards.
+Three interfaces required (MGMT, LAN1 and HA)
+HA interface shoudl have a secondary IP assigned if in AWS/Azure. In GCP, this is called an alias IP being associated. This IP will be designated as the VIP.
+Certain permissions through EC2 Instance profile (AWS), Managed Identities (Azure) and Service account (GCP) are required.
+A DNS resolver must be available.
+For GCP, if the configured DNS resolver fails to resolve the Google API metadata.google.internal, Infoblox recommends to use 169.254.169.254 as the resolver.
+In NIOS 9.0.4 and higher, under Grid > Grid Manager > Members > Properties > Network there is now a tick box in the HA section called "Public Cloud". Tick this and a drop down box will appear under the tick box and allow you to specify which public cloud the HA pair is being deployed in.
+In the "Ports and Addresses" section of the window will now have an "Interface ID "column which you can fill in with data from the cloud.
+Due to a certain restriction from Azure, the Address Resolution Protocol (ARP) functionality on the passive node of an HA pair always remains enabled. It cannot be disabled. Therefore, the passive node always responds to ping requests.
+The time taken for an HA failover can vary depending on the response time from the host.
+vNIOS for Azure does not support automatic upgrade of software (NIOS) on an HA node If the node is running on a version of NIOS that is prior to 9.0.4
 ===== X6 in Azure =====
@@ Line 38: / Line 74: @@
   * The time taken for an HA failover can vary depending on the response time from the host.
   * vNIOS for Azure does not support automatic upgrade of software (NIOS) on an HA node If the node is running on a version of NIOS that is prior to 9.0.4.
+===== Deploying in Azure =====
+Azure PowerShell
+<code>$locName="UK South"
+$pubName="infoblox"
+$offername = "infoblox-vm-appliances-903"
+$skuName="vgsot"
+$versionName="903.50212.0"
+Get-AzVMImage -Location $locName -PublisherName $pubName -Offer $offerName -Skus $skuName -Version $versionName</code>
+Find Publisher
+<code>$locName="UK South"
+Get-AzVMImagePublisher -Location $locName</code>
+Find Offer
+<code>$pubName="infoblox"
+Get-AzVMImageOffer -Location $locName -PublisherName $pubName | Select Offer</code>
+<code>infoblox-bloxone-33
+infoblox-bloxone-34
+infoblox-cp-v1405
+infoblox-nios-for-9_0_x-for-ddi
+infoblox-vm-appliances-853
+infoblox-vm-appliances-860
+infoblox-vm-appliances-861
+infoblox-vm-appliances-862
+infoblox-vm-appliances-863
+infoblox-vm-appliances-900
+infoblox-vm-appliances-901
+infoblox-vm-appliances-902
+infoblox-vm-appliances-903
+infoblox-vm-appliances-904
+infoblox-vm-appliances-904-test
+infoblox-vm-appliances-905
+infoblox-vnios-te-v1420
+infoblox_nios_payg</code>
+Get Skus
+<code>$offername = "infoblox-vm-appliances-903"
+Get-AzVMImageSku -Location $locName -PublisherName $pubName -Offer $offerName | Select Skus</code>
+<code>Skus
+----
+niosprivateoffer
+vgsot
+vgsot-ni
+vsot
+vsot-ni</code>
+Get Version
+<code>$skuName="vgsot-ni"
+Get-AzVMImage -Location $locName -PublisherName $pubName -Offer $offerName -Skus $skuName</code>
 ===== DHCP in Azure =====
-See end of this section for why DHCP doesn't work properly in Azure still.
+**NOTE**: See end of this section for why DHCP doesn't work properly in Azure still.
 Unlike AWS and GCP, Azure uses standard DHCP code for issuing DHCP to VM's in Azure itself. This means they are more sensitive to T1 timers (somehow).
@@ Line 72: / Line 155: @@
 Some unofficial lab testing in Feb 2023 seemed to show that DHCP rate limiting in Azure has been lifted and that it works. However, Microsoft still do not support it as of May 2023.
+** Why DHCP in Azure is still a bad idea **
+When two DHCP members are configured in a Failover Association (any system using Failover Association) then the first lease given to a client is the MCLT (normally 1 hour). Half way through this (e.g. 30 minutes) it will try and renew. The DHCP server will then issue a full lease. Since Azure blocks T1, this cannot happen. At T2, the client issues a rebind. The DHCP failover association sees the T2 rebind and assumes there is a problem with the peer and so issues MCLT again.
+This means that clients can never have full lease time and thus may easily overwhelm a DHCP server. e.g. if you size the DHCP server based on 50,000 devices having 14 day lease times, it probably won't cope with 50,000 devices trying to renew every 30 minutes.
+Because DHCP FO uses "lazy" updates, there is a higher chance in this scenario that when one peer goes down it does so after having provided a lease without its peer being informed.  That is what MCLT is for, time to get the two peers' DHCP database synced up.  In the Azure scenario, it is kind of perpetually in a state where you can't be 100% sure that both peers are aware of all the leases.
+Remember, T2 is rebind and not a renewal. A lot of "normal" devices may work with this but many IoT devices do not cope well without T1 timers.
+This does not affect Infoblox Universal DDI because it uses a different methodology for DHCP HA.
-Because T1 is blocked in Azure, Failover Association won't work in Azure. This does not impact Universal DDI which runs on Kia and doesn't use Failover Associations. The issue is around DHCPFO specifically. At T2 (rebind) DHCPD issues MCLT (typically 1h) for lease time again vs the “real” lease time. So, with T1 blocked, you’ll never get anything *but* MCLT for lease time.