Infoblox Network Insight

Basic NIOS can do basic Network Discover:

Data Management > IPAM > Select network and click “Discovery”. IPv4 only and uses NMAP.

The NetworkInsight license (a.k.a Discovery license) allows the Infoblox to use SNMP and other protocols to discover and catalogue a diverse assortment of device types including routers, enterprise switches, firewalls and security appliance, load balancer, enterprise printer, wireless access points, end hosts, application servers, etc.

So, NetworkInsight provides better data. However, as with the built in discovery functionality, you need to be careful. Depending on how and where it is being used in the network, it may be advisable to deploy more appliances (e.g. one in America, one in EMEA, one in APAC, etc) to reduce the amount of probing traffic flowing around the globe.

WHen deploying multiple devices, you use NIOS devices for probing the networks (we call them probes) and they report to the “consolidator” devices which then report to the Grid Master. Technically it can happen on the Grid Master (or preferably the Grid Master Candidate) but that can cause messness with the firewall rules.

A NetworkInsight appliance can be standalone. It can't do DNS or DHCP but it can gather IPAM data just like a “normal” NIOS Grid.

Best Practice documentation for Discovery.

“complete ping sweep” being enabled Grid wide is bad. It should only be used on /24. Don't enable at Grid level.

Locate member close to the networks being discovered (<500ms RTT)

In very tiny lab network, added a subnet to Palo VM and Network Insight added it to IPAM 99 minutes later.

For extra device support (“drivers”), get support to raise a NEWDEVICE ticket with engineering.

• If an UNMANGED network is resized on a switch (larger or smaller), it is resized and any defined objects inside the original UNMANGED network are deleted (tested with “IP Reservations”).
• If an UNMANAGED network is made larger on a switch, and if there is something already there (e.g. another network), NIOS will create an UNMANAGED network container. The original UNMANAGED network will be deleted (including any IP Reservations) but the MANAGED network (necessary to create the IP object) will remain as a MANAGED network (along with any IP Reservations) inside the UNMANAGED container.
  • » The problem here is that IPAM no longer reflects the fact that an existing network has been resized and a manually created network that didn't exist on the network is still represented in IPAM.

• If an empty MANAGED network is made smaller on a switch, a MANAGED container is created and an UNMANAGED network is created inside the container.
• If an empty MANAGED network is made larger on a switch, an UNMANAGED network container is created and the MANAGED network is inside the container.
• If a MANAGED network is made smaller on a switch and if there is an IP Reservation in the original network, the MANAGED network does not change. (regardless of whether the IP Reservation fits into the new network)
  • » The problem here is that IPAM no longer reflects the fact that an existing network has been resized (made smaller).

• If a MANAGED network is made larger on a switch and if there is an IP Reservation in the network that is still in the network, the MANAGED network remains but will be put inside an UNMANAGED container that reflects the new network size.
  • » The problem here is that IPAM no longer reflects the fact that an existing network has been resized (made larger).
• If a MANAGED network is made larger on a switch, and if there is an IP Reservation that was in an adjacent network (MANAGED), NIOS will create an UNMANAGED container to represent the newly resized, larger network and also keep the original (since it is manged, it can't be resized). Any IP Reservations inside either network (original MANAGED network or adjacent MANAGED network that fall inside the new, larger network) will remain in NIOS.

If you find a huge number of networks have been discovered, they will be unmanaged. To make them managed “en-masse”, create a filter for unmanaged and then perform a IBCSV export. Use that file in CSV import DELETE mode to remove them. Then use the same file in ADD mode to add them back. Then they will be managed.

Network Discovery will try and use the lowest IP address as the management first, so 10.x.x.x but the management is 172.x.x.x. You must force via the GUI the new default management interface to be 172.x.x.x. In some cases this has to be done by support.

Vendor Support

From the Docs

When the Grid Master database reaches its maximum capacity (the maximum capacity varies based on the appliance model), the Grid Master stops updating the database and requests that the Grid member stop the discovery. When the discovering Grid member database reaches its capacity, the Grid member pauses the discovery.

• P = Probe
• C = Consolidator

To convert multiple networks from unmanaged to managed, under IPAM, add filter for managed=no and then export to IB CSV format. Use CSV Import to delete them. Then use same file to add them back, and they will be managed.

A discovered entity is considered “unmanaged” if it is discovered in a network for which no information is being stored in the NIOS database. You are not able to configure unmanaged objects in NIOS. Depending on the nature of the discovered entity, you may convert certain unmanaged entities into managed objects so you can manage them through Grid Manager. When an entity is in the managed state, you can configure settings such as applying permissions to it, limiting who can modify the configurations and deployments, and when those changes can be applied. You cannot do so with unmanaged objects.

If discovered subnet (specifically subnet; not IP) is not converted to manged, then if the subnet is removed from network, it can just vanish from NIOS. I've seen it vanish in a lab and not vanish in a production network.

If you convert a subnet to managed, if the subnet is removed, then it remains in NIOS and the “last discovered will just get older and older”.