infoblox_nios:discovery_vdiscovery
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| infoblox_nios:discovery_vdiscovery [2023/09/28 14:35] – [Network Discovery] bstafford | infoblox_nios:discovery_vdiscovery [2024/04/04 09:33] (current) – bstafford | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== | + | ====== |
| For NIOS vDiscovery to work with ESXi and to add DNS names to discovered objects, we need the Cloud Network Automation licence and the NIOS Grid must have the DNS zones added (even if the zones are not assigned to any appliance and even if Infoblox is not actually used for DNS). Otherwise, we just detect if the IP addresses are in use or not. We also need to create the networks in advanced. If we don't, the data doesn' | For NIOS vDiscovery to work with ESXi and to add DNS names to discovered objects, we need the Cloud Network Automation licence and the NIOS Grid must have the DNS zones added (even if the zones are not assigned to any appliance and even if Infoblox is not actually used for DNS). Otherwise, we just detect if the IP addresses are in use or not. We also need to create the networks in advanced. If we don't, the data doesn' | ||
| The current vDiscovery feature supports tenants, networks, and compute VMs only. It does not support data that is retrieved from load balancer networks, load balancer VMs, Kubernetes platform VMs, application gateways, service VMs, SQL VMs, or any other VMs that are created using cloud services such as Kubernetes service or analytics service, where the IPAM is handled by the respective orchestration engines of the cloud provider. Note that if the vDiscovery job retrieves unsupported data from AWS, Azure, or GCP, then it impacts the performance of the vDiscovery process. | The current vDiscovery feature supports tenants, networks, and compute VMs only. It does not support data that is retrieved from load balancer networks, load balancer VMs, Kubernetes platform VMs, application gateways, service VMs, SQL VMs, or any other VMs that are created using cloud services such as Kubernetes service or analytics service, where the IPAM is handled by the respective orchestration engines of the cloud provider. Note that if the vDiscovery job retrieves unsupported data from AWS, Azure, or GCP, then it impacts the performance of the vDiscovery process. | ||
| - | [[https:// | + | [[https:// |
| + | |||
| + | ===== Performance ===== | ||
| + | TE-2215 with NIOS 8.6.3 (where new AWS sync engine was released) can syn thousands of zones across hundreds of different VPCs. | ||
| ===== Best Practice ===== | ===== Best Practice ===== | ||
| Infoblox also recommends that you select “The tenant’s network view” as the network views for both public and private IP addresses. [[https:// | Infoblox also recommends that you select “The tenant’s network view” as the network views for both public and private IP addresses. [[https:// | ||
| + | |||
| + | Azure [[https:// | ||
| + | * Your subnets shouldn' | ||
| + | |||
| ===== VMware ===== | ===== VMware ===== | ||
| - | We can run vdiscovery | + | * You can run vDiscovery |
| + | * If you run vDiscovery against VMware where a VM is powered off, the powered off VM will be ignored. | ||
| + | * If you run vDiscovery against VMware where a VM does NOT have VMware Tools installed, VMware won't be aware of the VM's IP address and vDiscovery will ignore the VM with error message '' | ||
| + | ===== DNS Variables ===== | ||
| + | There is a [[https:// | ||
| + | * vm_id | ||
| + | * vm_name | ||
| + | * discovered_name | ||
| + | * tenant_id | ||
| + | * tenant_name | ||
| + | * subnet_id | ||
| + | * subnet_name | ||
| + | * network_id | ||
| + | * network_name | ||
| + | * vport_name | ||
| + | * ip_address | ||
| + | * ip_address_octet1 or 1 | ||
| + | * ip_address_octet2 or 2 | ||
| + | * ip_address_octet3 or 3 | ||
| + | * ip_address_octet4 or 4 | ||
| ===== Troubleshooting ===== | ===== Troubleshooting ===== | ||
| + | ==== SSL Issues ==== | ||
| + | < | ||
| + | Either the root CA and intermediate CA certificates have not been imported into NIOS (e.g in internal, VMware environments using internal PKI) or the root CA and intermediate CA certificates do not follow RFC 5280 which demands keyUsage extension MUST be present. | ||
| ==== NTP Issues ==== | ==== NTP Issues ==== | ||
| The following error messages were seen when the NIOS system was 15+ minutes out of date. | The following error messages were seen when the NIOS system was 15+ minutes out of date. | ||
| Line 80: | Line 109: | ||
| ===== Troubleshooting ===== | ===== Troubleshooting ===== | ||
| + | |||
| + | [[https:// | ||
| When you see an error message, the GUI may not say what has gone wrong. Get the support bundle | When you see an error message, the GUI may not say what has gone wrong. Get the support bundle | ||
infoblox_nios/discovery_vdiscovery.1695911706.txt.gz · Last modified: by bstafford
