NetXMS Support Forum

Hi Lukas,

thank's a lot for this hit - it works as expeced and saved a lot of time :-)

best regards

Hi,

is there a way to bulk edit the expected interface state for a selected range of devices?

it's possible to change all interfaces of a singular device at once - we're running 100+ switches in the network with 10000+ ports and we would like to the expected interface state to IGNORE... it's quite time intensive to do this switch by switch... ;-)

thank's a lot &
best regards

Hi Victor,

many thanks for doublechecking the issue!!!!

Best regards,
Bernhard

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

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

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,

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