--- title: "Limitations and Recommendations" canonical: "https://docs.infoblox.com/space/vniosazure/1324975255/Limitations%20and%20Recommendations" format: markdown --- Consider the limitations and recommendations listed in this topic when deploying vNIOS for Azure: > Macro (toc) # Common Limitations and Recommendations - DHCP failover does not work in environments with NAT configuration. When configuring a DHCP failover, ensure that the primary and secondary DHCP servers are not in NAT-configured environments. - The GMC (Grid Master Candidate) promotion test does not work in NAT-configured environments. Although the promotion fails the test, the GMC promotion operation completes successfully. For the promotion to pass the test, the GMC member and the other members in the Grid must not include the NAT configuration. - If you need to set a static IP address on the MGMT interface when configuring a vNIOS instance with multiple interfaces (LAN1 and MGMT), set it from the Grid Manager UI; for steps, refer to the *[Infoblox Documentation Portal](https://docs.infoblox.com/space/NIOS/35400616/NIOS)*.* *If you try to set the IP address from the NIOS CLI, the `set interface mgmt` command will fail to enable the MGMT interface, because NIOS assumes that the LAN1 IP address of a vNIOS instance deployed on any cloud platform is always dynamic. - Use the vNIOS for Azure appliances to provide DHCP services for networks on platforms other than Azure (Azure Public Cloud and Azure Stack Hub) because networks on Azure obtain their IP leases from the native DHCP servers even though NIOS is configured to provide DHCP services. - vNIOS for Azure instances do not support LAN2 interfaces. If you have configured the LAN2 interface on an instance, it might still function as expected. However, this is not supported because Infoblox has not qualified LAN2 on public cloud instances. Additionally, as NIOS supports high availability configurations from version 9.0.4, it treats the third interface as HA by default. Therefore, if you have configured a LAN2 interface, NIOS will treat it as an HA interface, causing errors and unexpected behavior. - Avoid interchanging network interfaces on a vNIOS instance as it can result in unexpected behavior. - vNIOS for Azure does not support the use of Weighted Random Early Detection (WRED) mechanism in network schedulers because the Elastic Network Adapter (ENA) poll-mode driver does not provide the API required for 100 Gbps ENA interfaces and also because the ixgbevf driver for the Intel NIC 82599 SR-IOV on Azure does not provide the API required for the 10 Gbps SR-IOV interfaces. - Performances of features such as DNS Infrastructure Protection (formerly called as Advanced DNS Protection/Threat Protection in versions of NIOS previous to 9.0.8), virtual DNS Caching Acceleration, and dnstap may be impacted on appliances running on a version of NIOS prior to 9.0.7 as it uses failSafe PMD to run these services instead of NetVSC PMD that is recommended by Azure specifically for DPDK-22.11 LTS or later. NIOS 9.0.7 and later support NetVSC PMD. - vNIOS instances running NIOS 9.0.5 or later support DNS Infrastructure Protection, virtual DNS Caching Acceleration (vDCA), and dnstap. - Accelerated networking should be configured on the Azure instance interfaces to support features such as DNS Infrastructure Protection, virtual DNS Caching Acceleration (vDCA), and dnstap. - vNIOS for Azure instances do not support Microsoft Azure Network Adapter (MANA) interfaces. - vNIOS for Azure VMs intermittently fail and the "The last operation performed on this VM failed" error message is displayed during automated (Terraform-based) deployments, while manual deployments succeed. This is because NIOS is not a standard cloud Linux distribution; it has its own kernel/init. Microsoft Azure expects every VM to run the Azure Linux Guest Agent but NIOS uses a custom OS that does not include the agent. Therefore, "Not Ready"/"Unknown" agent state is displayed in Microsoft Azure. You can ignore the error and proceed with the deployment. # Limitations Specific to Azure Public Cloud - vNIOS for Azure does not support IPv6 network configurations in NIOS versions prior to 9.0.8. From NIOS 9.0.8, it supports IPv6-only and dual stack network configurations. - Azure public cloud does not support IPv6-only network interface. You can create an IPv4-only or IPv4 and IPv6 network interface. - Adding or deleting a network interface when a vNIOS for Azure instance is powered on may result in unexpected behavior. You must first power off the instance, add or delete the interface, and then start the instance. ## Limitations Specific to HA - 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 and Standard_E4s_v5 that is used in IB-V926 appliances - vNIOS for Azure Public Cloud instances do not support an HA setup with its nodes deployed on different cloud platforms, regions, resource groups, availability zones, or on different instance types such as node 1 on a physical appliance and node 2 on a virtual appliance. When deploying instances through marketplace, to use the same resource group for deploying instances of an HA pair, you must follow specific sequence of steps as defined in the *[Configuring Basic Settings](https://infoblox-docs.atlassian.net/wiki/spaces/vniosazure/pages/37454016)* step of the *[marketplace deployment](https://infoblox-docs.atlassian.net/wiki/spaces/vniosazure/pages/37486729)*. - 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 Azure API. - Azure network interface cards (NICs) function as routers. When processes such as failover occur, the IP address is removed from a NIC, which subsequently triggers updates to Azure’s routing system. This can result in a delay in response time. - vNIOS for Azure does not support automatic upgrade of NIOS software on an HA node if the node is running on a version of NIOS that is prior to 9.0.4. - vNIOS for Azure HA deployments are not supported on IPv6 addresses. - If the active node experiences any of the following errors, an HA failover is initiated as the active node is deemed unhealthy: - Insufficient role permissions - DNS resolver unreachable - VIP missing from the active node’s HA interface - API failures # Limitations and Recommendations specific to Azure Stack Hub - Azure Stack Hub is supported only from NIOS 8.6.1 onwards. Ensure that you do not downgrade or auto-sync to a NIOS version that is earlier than 8.6.1. - Azure Stack Hub does not support IPv6 network configuration. - vNIOS for Azure Stack Hub appliances are not available for deployment from the Microsoft Azure Stack Hub Marketplace. - vNIOS for Azure Stack Hub instances do not support HA configuration. - vNIOS for Azure Stack Hub instances do not support vDiscovery. - vNIOS for Azure Stack Hub instances do not support DNS Infrastructure Protection (formerly called as Advanced DNS Protection/Threat Protection in versions of NIOS previous to 9.0.8), virtual DNS Caching Acceleration, and dnstap. - In the current release, in Grid Manager, the **Platform** column on the **Members** tab displays the platform of a vNIOS for Azure Stack Hub member as Azure instead of Azure Stack Hub. - If you are using an Azure Stack Hub version earlier than 1.2102.28.87, sometimes, a vNIOS for Azure Stack Hub instance deployed from the Azure CLI might go to a Failed state. To fix this, redeploy the instance from the Azure Stack Hub portal. For more information, see *[Deploying a VM instance from the Microsoft Azure Stack Hub portal](https://infoblox-docs.atlassian.net/wiki/spaces/vniosazure/pages/37650661)*. - When deploying vNIOS for Azure Stack Hub, you might notice that some characters are missing in the messages displayed in the serial console log. This occurs because the default baud rate in Azure Stack Hub is 115200 and the default baud rate in NIOS is 9600.