Follow up Questions for Network Discovery

 

  1. 1st question
    1. Yes, it would be Network node devices doing this, i.e. RMM managed device (i.e. with a running agent) that have been explicitly nominated as network node. The network node uses a number of techniques to do this (not all of the planned ones have been implemented, below are listed only those that have been implemented)
      1. ICMP , aka “Ping sweep” 
      2. Local (NN) ARP cache scan
      3. Known NID (Network infrastructure devices) ARP cache scan
      4. DHCP broadcast traffic interception
    2. No powershell/command prompt scripts are used. There are a few system commands used, as below
      1. Mac OS : arp system command is  used as there is no easy-to-implement API to be used
      2. Mac OS : ping system command is  used, as the .NET library is buggy up to version 5 and we use 3.1.
    3. Discovery does not consider devices that have at least 1 IP and 1 MAC address. This is why the ping method itself is not able to generate “valid” devices. It is the combination of the ping and ARP methods that do generate devices, ping is actually “filling in” the ARP cache (so that the OS knows how to deliver the ICMP message on OSI level 2 ). 
    4. Further to the above, It is well known that in the majority of cases MAC addresses get “lost” when traffic passes via routers (devices that connect networks). In normal circumstances the number of NID devices is much higher than the amount of network nodes. . This is exactly why we try and scan ARP caches of all NIDs, to get the most correct information. This is done leveraging SNMP protocol, so officially is part of the SNMP scanner, but technically is the same ARP cache scanning, just via a different technology.
    5. Understanding the need to “double check” what agent does, the following tools/technologies are useful
      1. Ping a device. The absence of the reply is not a problem in itself, as that device might have ICMP traffic filtered. The real usefulness of this is to see if the MAC address of the device has appeared in the ARM cache of the NN or the nearest router.
      2. Further to the above “arp -a -n” to check the local ARP cache content (NN). Beware the entries in this table tend to expire as they get older AND if the table becomes full, which may be if many hosts are pinged. This is why the agent will check the local cache once in 14 seconds.
      3. Furthermore, check the ARP caches of switches and routers. For this one can use good, old snmpwalk, or a very useful tool : iReasoning MIB Browser. The SNMP table to check are 1.3.6.1.2.1.4.24.4 and 1.3.6.1.2.1.4.21
      4. Although discovery of the devices does not 100% require that the device is accessible from the NN, that is however required to classify the device
  2. 2nd question
    1. Device classification is performed by matching the DHCP fingerprint against a know the DB
      1. The DB is rudimentary, it has been empirically filled in and lacks info
      2. There are known situations when the same fingerprint appears on MacOS and iOS devices which does not help
      3. Because it depends on DHCP, the device cannot be classified until it will have renewed its DHCP lease, which does not happen very often
      4. There is work in progress to improve this using a different technique (ICMP reply TTL value), mainly for Windows, in theory will be released in 10.6
      5. The DHCP fingerprint method is not bad, but to produce good results it need to be treated as a project rather than just a case.
  3. 3rd question
    1. The NN keeps a list of “known networks”. They are used by the ICMP scanner, so it pings every network regularly
    2. The “known networks” list is permanently updated when new networks are found
      1. New networks are found when we encounter a NID that is connected to multiple subnets. We will check that for every NID
    3. The additionally specified networks from the question are just being added at the very beginning. So if none are added, the list is initially empty and then the network node will add those networks that it can discover. 
      1. In a properly configured network the network node is well able to detect all the networks anyway.
      2. A potential improvement is to make the NN ignore any networks but those that have been manually added, if that is desired by the customer
  4. 4th question on static IPs
    1. We don’t “fallback” to anything, all scanners are permanently working. The same device will be discovered multiple times by each scanner, and the Network node will build an aggregated “view” of the device from all scanners. The devices with static IPs will be discovered just as any other devices, including their place in the topology. Currently what they won’t get is the OS, because that relies on DHCP
  5. 5th question
    1. SSH creds are for onboarding, aka “agent deployment” for Mac and Linux
      1. Linux agent deployment is not yet implemented
    2. They have been present in the old UI, but the old UI only supported Windows-to-Windows agent deployment form the CSM

 

Have more questions?

Contact us

Was this article helpful?
0 out of 0 found this helpful

Provide feedback for the Documentation team!

Browse this section