Versions Compared

Old Version 7

changes.mady.by.user Shwetha S

Saved on

compared with

New Version Current

changes.mady.by.user Jyothi KP

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 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 high availability ( 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.

...