Wired Intelligent Edge

Hi there,

If I set NetEdit discover my devices and give it just a very small subnet, it still tries to scan / probe every single IP in my network.

The network range I input just seems to filter the results of the discovery process, but NetEdit still tries to access the devices (either by SNMP or SSH) on every IP.

A quick example:

- I enter my core switch IP as 10.1.1.1/32; so, just one IP on this range

- I enter 10.1.1.1 as seed device

- After some hours discovery is still active, and the logs show NetEdit is probing every single device on all my network, either directly or indirectly connected to 10.1.1.1

Regards

Aruba NetEdit 2.0.2 or what?

Yes. 2.0.2.

One example:

I added subnet 10.0.1.1/32 and 10.0.1.2/32 . Seed device 10.0.1.1 . 10.0.1.2 is connected to 10.0.1.1 and has some phones connected.

I see the following for every phone:

IP 10.0.4.99 not discovered since it does not support switch/router : [TELEPHONE].

10.0.4.99 is not set as discovery subnet. And for the NetEdit to figure out it is a TELEPHONE, I guess it is connecting somehow to it.

I also see an entry for every single device on my network. Some show [TELEPHONE], some show [OTHER], some do not show anything. The ones that show are the ones that have SNMP with community public. It looks to me that NetEdit tries to connect to every single device with SNMP community Public, even tho they are not set as managed subnets.

Is this normal?

Thanks

Vincent Giles don't say, when connect to a switch, it will scan all LLDP device found ?

Hi ricardoduarte,

NetEdit will start discovery from any known device(s) and will discover anything that is within at least one managed subnet which has credentials configured in NetEdit. You can view all of your managed subnets by looking at Configuration > Managed Subnets.

When you add a 'seed' really you're just directly adding an IP for NetEdit to start from. The discovery from that seed is not limited to the subnet where it occurs, but will iteratively discover neighbors as long as those neighbors are in any one of the managed subnets configured in NetEdit.

Regarding the log entries which look like:

IP 10.0.4.99 not discovered since it does not support switch/router: [TELEPHONE].

This information is obtained from the LLDP neighbor entry, not from accessing the device itself. The LLDP protocol allows neighbors to communicate "capabilities" to eachother, one of which is TELEPHONE (others are ROUTER or SWITCH). This log message appears because the check for the IP appearing within a managed subnet appears after the check for capabilities (we only discover neighbors with ROUTER/SWITCH capabilities). For any routers/switches outside the managed subnet(s), you should see a message like:

IP 10.0.4.99 not discovered since no matching credentials were found.

Shaun

Hi Shaun,

Thus, if I not misunderstood your explanation, NetEdit collects/receives LLDP capabilities information from any neighbor devices not necessarily contacting (discovering) directly a specific device first (provided the device we are referring to belongs to a managed subnet) and then it filters only those ones that are being reported with ROUTER or SWITCH capability, only against those devices NetEdit applies the discovery process contacting them directly according to credentials it should have already configured.

So, if I'm not in error, it's a sort of two steps process: filtering devices with matching advertised LLDP Capabilities and then contacting them (logging into) through what you call "discovery".

Given the logic you explained shouldn't the message logged for any ROUTER/SWITCH capable device outside managed subnet(s) be properly rephrased as:

IP 10.0.4.99 not be discovered since it is not within any managed subnet.

instead?

But with such type of logged message we're supposing that a discovery attempt happened when instead it shouldn't have happened at all given the conditions explained.

I mean, if - as you wrote - the discovery process acts iteratively only within managed subnet(s) defined into NetEdit (about which credentials to devices are also properly defined) then NetEdit should not log a message saying that a particular device is not discovered because preliminarily it doesn't own matching credentials (exactly because matching credentials are supposed to be bound to managed subnet(s) only).

And to drill down it a little bit more...since you wrote that "...the check for the IP appearing within a managed subnet appears after the check for capabilities (we only discover neighbors with ROUTER/SWITCH capabilities)" I ask if the logged message should not be instead be totally different in terms of completeness (being dependent on the fact that first collected advertised LLDP capabilities are assessed and then, if matched, only device within managed subnet(s) will be really contacted/discovered):

IP 10.0.4.99 Advertised as LLDP ROUTER/SWITCH but will not be discovered since it is not within any managed subnet.

Let me share few slides to help  for the discovery as Shaun explained.

I agree that it may be more self-explanatory to use the log message you proposed:

IP 10.0.4.99 not be discovered since it is not within any managed subnet.

We chose the released wording because the technical requirement for discovery is that NetEdit is aware of the device IP and that NetEdit has working credentials for the device. The managed subnets are the configuration mechanism we use to associate credentials to IPs.

Regarding having "LLDP" appear in the log message, we do not explicitly state LLDP since we also support CDP-based discovery (if LLDP is disabled). The layer of code which logs the discovery message is not aware of the underlying neighbor protocol which provided the data (LLDP/CDP). I do agree that including the source of the data/fields in the log message would be more helpful, however.