Differences

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

--- infoblox_nios:azure [2024/08/19 10:40] – [X6 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 24: / Line 60: @@
 | TE-v2225/CP-v2225 | 8 | 56Gb | [[https://cloudprice.net/vm/Standard_DS13_v2|Standard_DS13_v2]] | N/A |
-HA not supported on TE-926 because it only has two interfaces. Three needed for HA (MGMT, LAN1, HA)
+[[https://docs.infoblox.com/space/vniosazure/37650561/About+Infoblox+vNIOS+for+Microsoft+Azure|HA not supported]] on TE-926 because it only has two interfaces. Three needed for HA (MGMT, LAN1, HA)
 https://cloudprice.net/vm/Standard_E4s_v3
+Limitations and recommendations specific only to Azure Public Cloud:
+  * Azure Public Cloud does not support IPv6 network configuration.
+  * Adding or deleting a network interface when a vNIOS for Azure instance is powered on, can result in unexpected behavior. You must first power off the instance, add or delete the interface, and then start the instance.
+  * vNIOS for Azure Public Cloud instances do not support high availability (HA) configuration on the following virtual machine sizes:
+  *  Standard DS11 v2 that is used in IB-V825 and CP-V805 appliances
+  * Standard_E4s_v3 that is used in IB-V926 appliances
+  * vNIOS for Azure Public Cloud instances do not support an HA setup with nodes on different cloud platforms, regions, or hosts.
+  * 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.
+===== 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 =====
+**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 58: / 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.