Document toolboxDocument toolbox

Frequently Asked Questions

This page contains the answers to the frequently asked questions about the NIOS Network Insight feature.


Q. How long does discovery take? Is there any indication of when the first pass is complete?

A. Discovery is an iterative process when new devices are found based on active polling or data collected from already discovered devices. Discovery is constantly running (unless disabled by the user) in order to keep the discovered data relevant, and it is not possible to predict or tell when all devices are discovered. 

To monitor the whole discovery process, go to Administration > Logs > Syslog. Many interesting logs from various discovery services can be found on discovery members. On the Grid Master, you can monitor messages about newly discovered (unmanaged) networks and newly found devices.


Q. How to avoid polling end-host devices? In other words, I want to discover the end hosts but I don't want them polled directly. Related to this, in Network Insight if I want to discover end hosts, do I need to enable discovery on a subnet of end hosts when I already have discovery enabled on the management subnet that manages the routers or switches the end hosts are attached to?

A. Discovery should be enabled for both the subnet of end hosts and the management subnet. To avoid polling the end host subnet, SNMP and CLI Collection must be disabled in network properties. End hosts are found and identified even without polling.

If end hosts and management devices exist in the same subnet, it is not possible to avoid polling the end hosts. In this case, split this network into subnetworks to override its discovery properties.


Q. How do I poll only specific network devices?

A. You can add the necessary devices as seed routers. To do that, open Member Discovery Properties for appropriate members of the type Probe and add a device IP address on the Seed tab. You can also specify such devices as /32 networks.

Note

If a device is added as a seed router, its type is considered a Router by default. After successful SNMP collection, fingerprinting, and other processes, Network Insight changes the device type to the correct one. However, if the device is not reachable or its type cannot be identified, its type may remain Router.


Q. How do I automate the discovery of new network devices? In other words, a new device is on the network and I want it discovered ASAP.

A. You can increase the discovery priority of a device by adding it as a Fixed Address or Host. You can optionally Enable Immediate Discovery. If you choose not to perform immediate discovery but do Enable Discovery, the new network or other object is discovered at a normal time determined by Network Insight. Devices matching IP addresses selected for immediate discovery are given one-time priority over other discovered devices, for data collection and counting toward any device found matching the license limits. You can also convert the corresponding IP address from the IPAM tab to a Fixed Address or Host.

There is another way to discover a device immediately. On the IPAM tab, you can create a network with prefix /32 with the IP address of your device and click Discover Now on it. This network is treated as a direct path to the device and it is discovered very soon.


Q. How do I stop the automatic creation of IPAM objects via Network Insight?

A. You can check an option in Grid Discovery Properties > Advanced Polling Settings > Disable discovery for networks not in IPAM. If newly discovered networks are not contained in any existing network, new unmanaged objects (networks that were collected from devices’ routing tables) will not be created in IPAM. Otherwise, yellow networks appear even if you have deleted them before.
If you want to disable the discovery of a network, you can add it in IPAM or click Edit for an existing one and clear the Enable Discovery check box. The network will never be discovered unless you change this setting again.
You can also explicitly exclude specific IPs or IP ranges from discovery in Network editor > Discovery Exclusions. Another way to exclude specific IP addresses is to select them in the IP map or IP list and then click Exclusion > Enable Exclusion. Discovery will never take place on these IPs unless you specifically change their exclusion setting.


Q. Are both SNMP and CLI required for interrogating devices? If so, what is the order of their operation?
A. SNMP is used at least to collect basic information about the device such as its name, model, and vendor. This information is required to enable CLI collection on the device. To find out if SNMP or CLI is used to collect specific data, see the table on the Data Collection page.


Q. How is the network discovery database cleaned up if I want to wipe all data and start again?

A. It is possible and necessary to do from Infoblox Admin CLI on both consolidator and probe members using the following command: reset database net-automation. It will take some time for the discovery service to restart again on these members and respond to the Grid Master. No additional actions like stopping services are required.


Q. How do I remove unwanted devices and device information?

A. We do not have a special button in the UI to remove specific devices. If you do not want to see a device on the Devices tab, clear discovered data from the IP addresses of its interfaces and add these IPs to the exclusion on the IPAM tab.

You do not need to exclude interfaces with a grey background, only managed and unmanaged (white and yellow) interfaces are discovered by Network Insight.

To remove an unwanted device, do one of the following:

  • Delete the network that contains this device in IPAM.
  • Disable discovery of the network that contains this device in IPAM.
  • Add the device IP address in Discovery Exclusions of the corresponding network in IPAM.
  • Add the IP range that contains the device IP address in Discovery Exclusions of the corresponding network in IPAM.


Q. What is the best way to deploy VRF mapping in our environment?

A. Map one VRF to one network view to ensure that IP addresses are not overlapping.


Q. How many devices are scanned simultaneously?

A. It is not possible to tell the exact number. The Network Insight engine does its best to make parallel polling of devices with a good balance between keeping the data up to date and polling nonaggressively. For information about frequencies of device polling, see Data Collection.


Q. Once devices are registered, how often does discovery hit the devices?

A. Devices can be hit by different means—by active polling, collection, etc., and it is not possible to tell the exact time. Their frequencies are listed on the Data Collection page.


Q. How often do new scans occur?

A. For details, see Data Collection.


Q. Which log files can I consult for the discovery process?

A. To view logs, go to Administration > Logs > Syslog. In the drop-down menu, you can select a member for which you want to see the logs.

The following types of discovery events can be logged to the syslog on the Grid Master:

  • Discovery sends notifications about the discovery status. Examples: “The grid member is connected to the grid master.” or “Discovery Collector Service is
    working.”
  • Discovery Conflict sends notifications about conflicts between the DHCP address and the existing IP address.
  • Discovery Unmanaged sends notifications related to the discovery of unmanaged devices and networks. Examples: “New unmanaged devices/networks were found during the network discovery process. New unmanaged devices in '10.40.16.0/20' network in 'default' network view.”

Some error messages appear in the syslog. For example, connection errors of vDiscovery (“Communication with vSphere server failed with error”), parsing errors of native discovery (“CSV import error … Please contact the support team”). Also, some start/stop events during member upgrade are logged: "Stopped the discovery operation. A member has not completed its upgrade". Network Insight, if enabled, can log discovery process details such as “Some object has been created/deleted” or “Cannot find the network in NIOS for IP … “. Also, there are some Conversion Policy messages such as “%name% created from the discovered IP address” or “conversion type have been changed since the last run”.

On discovery members, you can see mostly logs from discovery core utilities (such as PathCollector, netautoctl, and DiscoveryEngine) and kernel messages.


Q. Why doesn’t my container have a First Discovered or Last Discovered value when networks in the container have been discovered?

A. Network containers can be created manually or automatically. In the first case, the First Discovered/Last Discovered timestamps are not displayed, because by design the information about discovered networks inside is not propagated to the container level. If the container was automatically converted from a network, it preserves the value from this network.


Q. Why do some networks have a gray background?

A. Gray networks are also called non-NIOS networks. These networks are displayed with a blank value in the Managed column. This indicates that the network is discovered but available network information is not sufficient to identify and catalog the network in IPAM. This can be due to the following reasons:

  • The admin or operation status of the corresponding interface is down which means the interface is either disconnected physically or disabled by the administrator.
  • The prefix length for the network is /32 (ipv4) or /128 (ipv6). Network Insight treats this as a route to a specific device rather than a subnet. Therefore, it does not create this network in IPAM.
  • The route for this interface is configured incorrectly.
  • The route is learned from a remote source via BGP, OSPF, and so on (i.e., indirect next hop), or it comes from a static route using the netmgmt protocol. Network Insight creates networks in IPAM for only direct and local routes from routing tables.
  • The network is within a VRF and the VRF is not mapped to a network view. VRF mapping is required in this case for the network to appear in IPAM. Sometime after the VRF is mapped, the network turns from non-NIOS to unmanaged, or managed, if the network is already present in IPAM.

Yellow networks. These networks are unmanaged. It indicates that the network is not managed under IPAM, but enough network information is cataloged so that the network can be converted to managed status. You can provision these networks onto devices.

White networks. These networks are currently managed under IPAM, converted to an IPAM network. You can provision and de-provision managed networks. When you manually create or convert an existing unmanaged network on the IPAM tab, this network is considered as managed. Otherwise, it is considered unmanaged. Managed networks are always white, and unmanaged are yellow.

In the screenshot, you can see that we created network 2.5.40.0/24, and it is white and managed. Grey and yellow networks were later collected from discovered devices.


Q. How is the management interface on an end host determined?

A. End hosts normally have one interface, so it is considered to be the management interface. If they have several, they are treated as separate devices with their own addresses.


Q. What does the “This network is currently not available as a NIOS Network object.” message mean that appears when you hover over a network object in NIOS?

A. This message appears over the gray networks described above. These networks are not handled by NIOS and not discovered by Network Insight. When a network is in this state, you are limited to de-provisioning discovered networks of this type from their host device and viewing device details.