User Tools

Site Tools


infoblox_nios:azure

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
infoblox_nios:azure [2024/09/10 16:51] – [DHCP in Azure] bstaffordinfoblox_nios:azure [2025/03/07 04:36] (current) – [Private Link] bstafford
Line 10: Line 10:
 ===== Private Link ===== ===== 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. 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.
 +
 +168.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 ===== ===== X6 in Azure =====
  
Line 38: Line 74:
   * The time taken for an HA failover can vary depending on the response time from the host.   * 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.   * 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 ===== ===== DHCP in Azure =====
 **NOTE**: 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.
Line 80: Line 163:
 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. 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.+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.
  
  
infoblox_nios/azure.1725987100.txt.gz · Last modified: by bstafford