NetXMS Support Forum

hi,

i've configured netxms to automaticaly discover a specific subnet of my network with snmp. I've enabled 'Active and Passive' Discovery, specified the subnet i want to actively discover in 'Active Discovery Targets' and additionaly add the same Subnet to 'Address Filters'. Discovery filter attribute is set to 'auto'.


as the core switch/router get also discovered, netxms has knowledge of not just this specified network - it sees, as expected, all other subnets where the core switch has an interface in too.


my expectation was that when i configure 'Active Discovery Targets' that just these range get actively scanned. Unfortunately, the server doesn't scan just the specified subnet - it scans every ip within all known subnets with snmp and port 4700.


is this an expected behavour? or is there something wrong in my configuration.


all input is welcome, thanks a lot in advance

Hi bjet,

I do believe that what you experienced is expected behavior with Active Discovery - I experienced the same.


-Kevin

hi kevin,

many thanks for your reply.

so, but if it's really designed according to our both experience, what sense would it make to configure these 'Active Discovery Targets'? regardless of what i configure in the network discovery configuration, allways the whole network is scanned (except when disabling network discovery). There's no difference if i configure just the specific wanted subnet, a superset of this network or 0.0.0.0/0.

in my case we're running a /16 Network. there's a management subnet (/23) where all network infrastructure (switches) is located. we would need to just monitor the networking equipment with netxms. as every known ip range is scanned, all clients appear in netxms. that was definitely not our intention.

on the one hand there are now thousands of unwanted objects created in netxms (although they are naturally not talking snmp). on the other hand there are several sensitve systems which create alerts when getting unauthorized scanned - the security admin gets about 900 mail alerts/hour due 'unauthorized SNMP access'. as you can imagine, he don't like that ;-)

i've now configured a workaround with iptables controlling outgoing snmp traffic. that's an really ugly but i've no other idea yet (and it works)

as i'm quite new to netxms i hope that there's a solution within netxms i just do not know... :-)


best regards

Hi bjet,

Actually, I am quite new myself to NetXMS, and still in the learning curve.  I still do not have it deployed to all of our subnets.

When I started out, I had the same issue that you have, and I was getting alerts like crazy (NetXMS discovered our entire network).  So, I ended up dropping the database completely, and starting over. Now what I do is I define address filters first (in the Network Discovery Configuration) by checking "Accept node if it is within given range or subnet". I happen to use IP address ranges, because we have a lot of DHCP devices in the upper end of each range, and I don't need to monitor them. After that, I proceed and add subnets to the Active Discovery Targets. The other thing I did was modified some of the "fine tuning" parameters in Server Configuration because of the size of our network.

I'm not sure if this is the best way, but it worked for me.  I hope this helps!


-Kevin

Hi!

For better understanding, this is how discovery works:

If active discovery is on, server uses ICMP ping to find new nodes. Each responded address goes to polling queue.
If passive discovery is on, server polls routing and ARP tables on already known devices. Each new IP address found goes to polling queue.

In parallel, server gets IP addresses from polling queue and checks them for SNMP and NetXMS agent. Then, if it passes discovery filter, new node is created in NetXMS.

So, if NetXMS already knows you routers (and has SNMP access to them), most likely it will soon discovers all computers in your network - just because they are very likely to be found in router's ARP cache. To prevent discovery of unwanted devices, you should set discovery filter. You can limit IP addresses to discover, and you can only add nodes with certain capabilities (like only add SNMP-enabled nodes).

Best regards,
Victor

Quote from: Victor Kirhenshtein on October 24, 2012, 10:53:54 PM
To prevent discovery of unwanted devices, you should set discovery filter. You can limit IP addresses to discover, and you can only add nodes with certain capabilities (like only add SNMP-enabled nodes).

Hi Victor,

thank's a lot for your explanation. I totally agree with you that it should work that way. But unfortunately, it seems that my NetXMS installation ignores the "discovery filter".

my configuration looks exactly like this:

-> Network Discovery Configuration:
   "General": Active and passive
   "Active Discovery Targets": 172.17.44.0/255.255.254.0
   "Filer": Automatically generate script with following rules: "Accept node if it has SNMP agent" AND "Accept node if it is within given range or subnet" checked
   "Address Filters": 172.17.44.0/255.255.254.0


So, with that configuration, NetXMS should never send any SNMP Packet to IP Addresses other than 172.17.44.1 - 172.17.45.254, right? Checking the iptables log (i log every snmp activity an deny the ones which ran out of the discovery filter) i can see that NetXMS still tries to reach every IP Address within all the knowen Subnets..


for my understanding, the discovery filter fails, because NetXMS tries to poll nodes which are out of the configured discovery filter....

can you confim that, or is there something that i don't understand (?)

thanks a lot in advance,

Bernhard

just an examle:
ov  9 17:40:23 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.179 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=36898 DPT=161 LEN=60
Nov  9 17:40:23 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.179 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=36898 DPT=161 LEN=60
Nov  9 17:40:23 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.179 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=36898 DPT=161 LEN=63
Nov  9 17:40:23 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.180 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34137 DPT=161 LEN=60
Nov  9 17:40:23 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.180 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34137 DPT=161 LEN=60
Nov  9 17:40:23 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.180 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34137 DPT=161 LEN=60
Nov  9 17:40:23 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.180 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34137 DPT=161 LEN=60
Nov  9 17:40:23 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.180 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34137 DPT=161 LEN=63
Nov  9 17:40:25 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.187 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34437 DPT=161 LEN=60
Nov  9 17:40:25 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.187 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34437 DPT=161 LEN=60
Nov  9 17:40:25 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.187 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34437 DPT=161 LEN=60
Nov  9 17:40:25 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.187 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34437 DPT=161 LEN=60
Nov  9 17:40:25 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.187 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=34437 DPT=161 LEN=63
Nov  9 17:40:25 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.190 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51105 DPT=161 LEN=60
Nov  9 17:40:25 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.190 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51105 DPT=161 LEN=60
Nov  9 17:40:25 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.190 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51105 DPT=161 LEN=60
Nov  9 17:40:25 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.190 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51105 DPT=161 LEN=60
Nov  9 17:40:25 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.190 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=51105 DPT=161 LEN=63
Nov  9 17:40:26 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.191 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=39467 DPT=161 LEN=60
Nov  9 17:40:26 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.191 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=39467 DPT=161 LEN=60
Nov  9 17:40:26 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.191 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=39467 DPT=161 LEN=60
Nov  9 17:40:26 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.191 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=39467 DPT=161 LEN=60
Nov  9 17:40:26 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.191 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=39467 DPT=161 LEN=63
Nov  9 17:40:27 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.193 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=44207 DPT=161 LEN=60
Nov  9 17:40:27 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.193 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=44207 DPT=161 LEN=60
Nov  9 17:40:27 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.193 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=44207 DPT=161 LEN=60
Nov  9 17:40:27 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.193 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=44207 DPT=161 LEN=60
Nov  9 17:40:27 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.193 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=44207 DPT=161 LEN=63
Nov  9 17:40:29 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.195 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=58867 DPT=161 LEN=60
Nov  9 17:40:29 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.195 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=58867 DPT=161 LEN=60
Nov  9 17:40:29 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.195 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=58867 DPT=161 LEN=60
Nov  9 17:40:29 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.195 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=58867 DPT=161 LEN=60
Nov  9 17:40:29 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.195 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=58867 DPT=161 LEN=63
Nov  9 17:40:29 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.199 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=40301 DPT=161 LEN=60
Nov  9 17:40:29 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.199 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=40301 DPT=161 LEN=60
Nov  9 17:40:29 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.199 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=40301 DPT=161 LEN=60
Nov  9 17:40:29 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.199 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=40301 DPT=161 LEN=60
Nov  9 17:40:29 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.199 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=40301 DPT=161 LEN=63
Nov  9 17:40:30 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.200 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=56336 DPT=161 LEN=60
Nov  9 17:40:30 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.200 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=56336 DPT=161 LEN=60
Nov  9 17:40:30 stpx0785 kernel: IN= OUT=eth0 SRC=172.17.45.8 DST=172.17.32.200 LEN=80 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=56336 DPT=161 LEN=60

Quote from: millerpaint on October 24, 2012, 06:20:33 PM
..... So, I ended up dropping the database completely, and starting over. Now what I do is I define address filters first (in the Network Discovery Configuration) by checking "Accept node if it is within given range or subnet". I happen to use IP address ranges, because we have a lot of DHCP devices in the upper end of each range, and I don't need to monitor them. After that, I proceed and add subnets to the Active Discovery Targets.....

..doublechecking previous replys again, i've decided to do it like millerpaint - droping the database and starting from scratch. additionally i've upgraded to 1.2.4. this time only "Accept node if it is within given range or subnet" has been checked

unfortunately that doesn't work in my case. same behavour as before - netxms tries to discover nodes with ip addresse "outside" of the discovery filter.

21:25:41.646346 IP 172.17.45.8.57636 > 172.17.10.25.snmp:  C=test GetRequest(27)  .1.3.6.1.2.1.1.2.0
21:25:43.648504 IP 172.17.45.8.57636 > 172.17.10.25.snmp:  C=test GetRequest(27)  .1.3.6.1.2.1.1.2.0
21:25:45.650701 IP 172.17.45.8.57636 > 172.17.10.25.snmp:  C=test GetRequest(27)  .1.3.6.1.2.1.1.2.0
21:25:47.652917 IP 172.17.45.8.57636 > 172.17.10.25.snmp:  C=test GetRequest(27)  .1.3.6.1.2.1.1.2.0
21:25:49.657948 IP 172.17.45.8.41707 > 172.17.10.37.snmp:  C=test GetRequest(27)  .1.3.6.1.2.1.1.2.0
21:25:51.660058 IP 172.17.45.8.41707 > 172.17.10.37.snmp:  C=test GetRequest(27)  .1.3.6.1.2.1.1.2.0
21:25:53.662227 IP 172.17.45.8.41707 > 172.17.10.37.snmp:  C=test GetRequest(27)  .1.3.6.1.2.1.1.2.0
21:25:55.664462 IP 172.17.45.8.41707 > 172.17.10.37.snmp:  C=test GetRequest(27)  .1.3.6.1.2.1.1.2.0

it seems to me that just addresses get discovered which are prior to that discovered by passive discovery (discovering routers arp table) - that would match victors explanation of how discovery works

Quote from: Victor Kirhenshtein on October 24, 2012, 10:53:54 PM
In parallel, server gets IP addresses from polling queue and checks them for SNMP and NetXMS agent.

ARP Table from Router:
...
Internet  172.17.10.37            0   241a.4bc5.4873  ARPA   Vlan35
Internet  172.17.10.25            0   552c.13ca.744d  ARPA   Vlan35
....

and yes, these devices are not getting added to netxms... but the server again tries to discover them...

it looks like the discovery filter doesn't apply on discovering nodes, it seems to apply on creating new nodes...

can someone out there confirm my observations?

best regards & many thanks

Hi!

Just checked it. Yes, there are flaw in the logic - for each new IP address found server first collect all possible information (thus SNMP packets being sent), and only after that checks the filter. So nodes outside given IP range is not added to database, but still scanned. This behavior comes from the days when there was only custom script filters - for such filters it was not possible for server to know what information will be required by filter to made a decision. For automatic filters it is possible to made a decision early. I have added this as feature request for 1.2.5: https://www.radensolutions.com/chiliproject/issues/178.

Best regards,
Victor

Hi Victor,

many thanks for doublechecking the issue!!!!

Best regards,
Bernhard