Infoblox
The Infoblox integration reads the networks and used IPs from your Infoblox Grid Manager and brings them into Connect's Inventory. A first discovery is queued as soon as you provision the account, and it re-runs automatically every day after that.
This integration only reads. Nothing is created, changed, or deleted on your grid.
Before you start
| Prerequisite | Why it's needed | Where to check in Grid Manager |
|---|---|---|
| The Grid Master's address, or a Grid Master Candidate with read-only API access | Discovery reads through WAPI's request handler, which a Grid Master Candidate with read-only API access refuses; on such a candidate discovery reads networks one at a time instead, as long as the API user can read Grid Member objects. That works but takes hours on a large grid; without that read permission the run stops with an error. Any other member doesn't answer the WAPI at all: it serves its web UI or redirects to the master, and the test says so | Grid > Grid Manager > Members, where the Grid Master is marked |
| A Grid Manager user with read permission on the network views you want discovered | Discovery reads every network view that user can read, so a view it cannot read is silently left out | Administration > Administrators, and the user's permissions |
| A Grid Manager user with WAPI (API) access, read permission on networks and IP addresses, and permission to use the request handler | Discovery reads network and address objects, in batches | Administration > Administrators, and the user's permissions |
| Read permission on DNS records, DNS views, fixed addresses, DHCP ranges, DHCP leases and bulk hosts for that user | Optional. With it, discovery reads those objects once for the whole grid and works out each network's used addresses from them, instead of asking the grid for every network. On a large grid that turns days into hours. Without it, discovery still works the slower way | Administration > Administrators, and the user's permissions |
| Outbound HTTPS from the Connector to the Grid Manager | The Connector opens every connection to the grid | Network Requirements |
Read-only access is enough. WAPI 2.5 or later lets discovery read many networks in one request, which speeds it up on a large grid; older versions still work, just more slowly. A user who can also read the grid's DNS records, fixed addresses, DHCP ranges, leases and bulk hosts gets the fastest path: discovery reads those once for the whole grid rather than asking for each network's addresses. Each run checks what the user can read and picks the path.
Set up an Infoblox account
- In Connect, go to Integrations and click New Integration Account.
- Provider: Infoblox. Give it a name and a project. The name is the label shown throughout Connect, so use something you and your team will recognize, such as the Grid Manager hostname.
- Click Continue to Provisioning, then on the Provision page fill in:
- Connector: the Connector to route discovery through. Setting this is what makes discovery use your on-prem Connector instead of a direct cloud connection.
- Host Address: your Grid Master's IP or hostname. A grid member refuses the reads discovery depends on, and the first job says so.
- Username / Password: a Grid Manager user with WAPI access. Once saved, the password opens blank; leave it blank to keep it. See Passwords and tokens are write-only.
- Under Advanced, Allow Self-Signed Certificate is on by default, because most grids present a self-signed certificate. Turn it off if your grid uses a certificate from a publicly trusted CA. Leave WAPI Version blank to auto-negotiate, or pin a version; a version the grid rejects falls back to auto-negotiate.
- Click Provision Account, then press Test to confirm the Connector can reach the grid and sign in with these credentials. A passing test names the WAPI version it negotiated and ends with what the grid said to a bulk read:
The grid accepts bulk requests.means the host is the Grid Master. Any other ending says whether the first run will stop early or read networks one at a time, and why; see What the Infoblox test says about bulk reads. The first discovery normally starts within about a minute. Watch it under Settings > Connectors > Jobs.
What gets discovered
Discovery covers every network view your API user can read: each run reads those views' networks and used IPs and uploads them as inventory items. A view the user has no read permission on is left out silently, with nothing in the job to say so, which is the first thing to check if a network you expect is missing. Re-running discovery updates existing items (matched by their Infoblox reference), adds new ones, and removes items for networks the grid has dropped. That last step is held back when a run's results look untrustworthy; see Details and edge cases.
The same CIDR can exist in more than one network view. Each one is discovered as its own item, since its Infoblox reference carries the view it belongs to.
Verify it landed
Compare against your grid's Data Management > IPAM view: the networks there, their used addresses, and their extensible attributes are what discovery collects. Check each network view your API user can read, not just default, since discovery covers them all.
| What appears | Where to look |
|---|---|
| The discovered networks | Connect: Inventory. One item per network, of type Network, sourced from Infoblox and named by its CIDR |
| Their extensible attributes | The item's tags. An attribute with several values is combined into one |
| Their use in a Group | Connect: Groups. A discovered network's CIDR is matched by a Group's CIDR criteria |
Once your on-prem networks are in inventory, you can build a Group from them and export it to Panorama or NSX like any other Group.
Dense networks are summarized by CIDR
Most networks are brought in with their individual used IP addresses attached. A network with more than about 12,000 used IPv4 addresses, or about 5,000 IPv6 addresses, is brought in differently: instead of an address list, the inventory item has the network's CIDR plus its utilization counts (Infoblox's utilization percentage and its dynamic and static host counts). A /18 that is three quarters used, or a dense IPv6 /64, will cross this threshold. A partial address list would look complete while missing addresses, so a dense network gets its CIDR instead.
The figures are approximate. A network with unusually large extensible attributes can be summarized with somewhat fewer addresses in use. A network can also be kept as its CIDR for one run when the grid doesn't return its addresses in time, which happens on a busy grid. So the same network can come back summarized on a busy day and enumerated on a quiet one. The job's summary says how many were kept that way.
What this means in practice:
- The network is still discovered, and still matches Groups. A Group filtering on a CIDR that contains it still picks it up.
- A Group picks up the whole CIDR. For a Group exported to Panorama or NSX, the entire summarized network goes into the exported group, including addresses that sit unused in Infoblox today. If you're writing enforcement policy against that Group, plan for the full prefix.
- That network carries utilization counts in place of per-address detail in Inventory.
A grid can mix both forms: dense networks summarized, everything else with full per-address detail. To tell which form a network took, open its item in Inventory: a summarized network shows utilization counts instead of an address list.
Separately, a Group's membership caps at 10,000 items overall, and a large grid can reach that even with summarization. See Group size limits.
Details and edge cases
A network the grid fails to answer for is kept as its CIDR. When the grid won't return one network's addresses during a run that otherwise finished, that network is written to Inventory as its CIDR alone, so it stays in Inventory while the grid is having trouble. The job's Summary counts them: Discovered 4,812 Infoblox networks with 60,412 used addresses (4,812 items uploaded, 6 with errors). A later clean run replaces them with their full address lists.
Wrong credentials stop the run at the first rejection. NIOS counts every failed login toward an account lockout, so a 401 ends the run there instead of retrying. The next daily run tries the same credentials once, so fix them before then. The job reports an authentication failure naming the host. Fix the credentials on the Provision page, and the next run signs in normally. A 403 on the sign-in itself, which is how a locked-out NIOS user is answered, ends the run the same way. A 403 on a later network or address read is the grid refusing that object rather than the login: discovery carries on and keeps each refused network as its CIDR, stopping only once the grid refuses everything it asks for.
Cleanup only removes networks that are really gone. At the end of a run, Connect removes inventory for networks the grid has dropped. That sweep is held back in three cases:
| Case | What happens |
|---|---|
| The run ended early, so its results are partial | Inventory is left as it is. The job is retried and carries on from where it stopped, unless the grid refused the API user or the bulk request handler, or 12 hours passed without one more network, which end it with an error. The next scheduled run still carries on from where the cycle stopped |
| The run completed with zero networks discovered | The job completes with cleanup skipped since nothing was discovered in its Summary |
| The run completed with fewer than half the networks of the last complete run, and that run found at least 100 | The job completes with cleanup skipped: 812 networks last run, 4 this run in its Summary |
The last two are what a wrong host, or an API user without access to the networks, look like, and sweeping on either would empty the account. If the drop is genuine, the next run compares against the smaller number and its cleanup goes ahead.
A large grid takes hours, by design. The Connector paces its requests to what the Grid Master is keeping up with, so discovery leaves the grid responsive to everything else using it. When the API user can read the grid's records (see Before you start), the Connector reads them once for the whole grid instead of asking for each network, which is what keeps a grid of tens of thousands of networks to hours. One pass is capped at 12 hours; past that the job keeps everything it uploaded and starts the next pass from where it stopped, under the same job, so a grid that needs longer is still read in full and cleanup waits until it is. Watch the counts climb under Settings > Connectors > Jobs.
One discovery runs at a time. A daily run that lands while a discovery for the same account is still running is skipped, since the running one covers it, and a Connector reads each Grid Master for one account at a time, so several accounts pointed at one grid queue rather than compete. Saving the Provision page queues a fresh discovery, unless one is already waiting to start, and it starts as soon as the running one finishes.
For common issues, see Troubleshooting.
Infoblox documentation
- Viewing Networks: the Data Management > IPAM screen, including choosing which columns and extensible attributes to display
- About Viewing Network Details: drilling into a network to see its addresses
- WAPI Detailed: the API discovery uses, if you're scoping the permissions of the account you create for it