Document toolboxDocument toolbox

About Infoblox vNIOS for GCP

Owned by Jyothi KP
Last updated: Sept 05, 2024
4 min read

Infoblox vNIOS for GCP is an Infoblox virtual appliance that enables you to deploy robust, manageable, and cost-effective Infoblox appliances in Google Cloud. Infoblox vNIOS provides core network services and a framework for integrating all the components of the modular Infoblox solution. It provides integrated, secure, and easy-to-manage DNS, DHCP, and IPAM (IP address management) services. For more information about the Infoblox Grid, DNS, DHCP, and IPAM, refer to the Infoblox NIOS documentation.

You can use Infoblox vNIOS for GCP virtual appliances to provide enterprise-grade DNS, DHCP, and IPAM services across your VPC and shared VPC networks on GCP. You can deploy either a two network interface instance or a single network interface instance of the vNIOS appliance on the GCP. Instead of manually provisioning IP addresses and DNS name spaces for network devices and interfaces, you can deploy an Infoblox vNIOS for GCP instance as one of the following:

  • A standalone NIOS appliance to provide DNS services in your Google VPC.

  • A virtual cloud member tied to an on-premises (non-Cloud) NIOS Grid.

  • A Grid Master synchronizing with other GCP-hosted vNIOS Grid members in your Google VPC, and across VPCs or Zones in different regions.

  • A Grid Master or a member in a high availability (HA) setup.

Infoblox vNIOS for GCP fully supports automated allocations of IP addresses and DNS record creation for business workloads. You can reduce provisioning errors and quickly provision and de-commission resources in your public cloud. NIOS handles all IP address management of GCP instances as well as provisioning and managing all private IP addresses through IPAM.

Infoblox vNIOS for GCP deployments may be part of a hybrid cloud strategy that supports managing organizational assets on public clouds (for example, Amazon) and on private clouds (for example, OpenStack and VMware). You can use Grid Manager as a unified console to support all cloud platforms, to ensure uniform DNS policies and to provision network and IP addresses.

You can use the vDiscovery feature to configure and run the vDiscovery jobs to discover and periodically re-discover all resources in networks across multiple projects inside your GCP cloud and synchronize data with NIOS.

Starting from NIOS 9.0.5, vNIOS for GCP deployments support multi-project synchronization of Google Cloud DNS data by integrating NIOS with Google Cloud DNS. This integration enables NIOS to discover and synchronize DNS data from multiple GCP projects within a GCP organization, providing a unified visualization experience.

Limitations of vNIOS for GCP

  • vNIOS for GCP instances do not support Advanced DNS Protection.

  • vNIOS for GCP instances do not the support LAN2 interface.

  • vNIOS for GCP instances do not support DHCP on IPv6 networks as GCP does not support IPv6.

  • vNIOS instance deployed on GCP provides DHCP services for on-premises networks only. It does not serve DHCP for networks deployed on any platform.

  • If you change the name of a VM in GCP, the hardware ID also changes. Therefore, if your vNIOS for GCP license is associated with the earlier hardware ID, changing the VM name may result in a license error.

  • Adding or deleting a network interface when a vNIOS for GCP 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.

  • Limitations related to high availability (HA) configuration, a capability introduced in NIOS 9.0.4:

    • vNIOS for GCP instances do not support HA configuration on the instance type n1-highmem-2 that is used in IB-V825 and CP-V805 appliances.

    • vNIOS for GCP instances do not support an HA setup with nodes on different cloud platforms, regions, or hosts.

    • Due to a certain restriction from GCP, 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.

    • vNIOS for GCP instances do not support the use of external IP address for accessing an HA Grid Master.

    • The time taken for an HA failover can vary depending on the response time from the host.

    • vNIOS for GCP 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.

    • If both nodes of an HA pair are powered off simultaneously, the alias IP address (VIP) assigned to the HA interface may get released to the free pool. If that happens, you must recover the IP address and reconfigure it as the alias IP address.

  • Limitations related to vDiscovery:

    • Infoblox vDiscovery for GCP does not support the discovery of load balancers.

    • When a VM in GCP uses the custom hostname option, the VM name and the VM hostname fields are different. vDiscovery for GCP uses only the VM name for the managed VM and ignores the VM hostname.

    • In NIOS versions prior to 9.0.4, when running vDiscovery across multiple projects, you must create one vDiscovery job per GCP project. vDiscovery across multiple GCP projects through a single vDiscovery job is not supported.

    • When you create an instance using a snapshot on GCP and then run vDiscovery, the OS field in the IPAM tab will be blank.

    • In NIOS versions prior to 9.0.4, running vDiscovery to discover virtual entities in a service project does not discover the VM if the network interface of the VM is using the shared VPC subnet of its host project.

    • From NIOS 9.0.4 onwards, if you want to discover shared resources (resources deployed in a shared VPC) using vDiscovery, ensure that the host project(s) and its service project(s) run on the same member or virtual node.

    • From NIOS 9.0.4 onwards, if you want to discover shared resources using vDiscovery to discover virtual entities in a service project, ensure that you discover the host project(s) first followed by the service project(s).

    • A vDiscovery job fails to discover a shared VPC if an HA failover occurs in between the discovery of the host and service projects. To discover the shared VPC, rerun the vDiscovery job on host and service projects after the HA failover.

    • From NIOS 9.0.4, it is necessary for the same member to discover both the host project and its service projects.

    • The discovery of shared VPC resources for a service project may lag by one or more intervals depending on the host project(s) discovery of the shared VPC.

Â