condition: ip range

[glut0r]

Just thinking it would be nice to have ip range as a possible condition in configuration->actions->discovery actions.

The point is, I may use ranges in discovery, but not in actions.

I may use 'ranges' inside /24 e.g. 1.2.3.1-254, but when I want to perform autodiscovery on /19 which is 32x /24, the pain in ass arises since I cannot use more general conditions.
Would be nice to have something like 1.2.224-255.1-254 as ip condition in actions.

Another one, would be autodiscovery module performing rev dns lookup. Maybe it's me doing something wrong, but I cannot get discovered hosts beeing added in a different way than IP addresses, which makes autodiscovery useless for me. Correct me if I'm wrong, but I think it's impossible to automatically add autodiscovered host with hostname set to something useful and not host's ip address?

Or perhaps autodiscovery is not the right thing to put above functionality in. Actions seems the right place to do this. Item beeing discovered, hiting actions, automatic 'add host' performing rev dns lookup and automatically filling hostname is available. Would be great. If that would be possible, together with larger ip ranges, zabbix would become automatic network monitoring solution. The only thing network/system admin would have to do to add host to zabbix, would be to add it to dns/rev dns. Removing not-responding host is already possible.

[Alexei]

Thanks for the ideas. Added to my TODO list for evaluation.

[georgew]

I like the greater than class-c range idea, as I need to autodiscover hosts in a couple of /21's, and one /22, as well as a /18. 84 autodiscovery rules, or three...

As for how to express the range, it can be one of two ways... We can put in the first and last IP, 10.0.0.1-10.0.63.255, or we can express a range in each octet as above... 10.0.0-63.0-255... there are advantages to both methods, so supporting them both would be cool if you could do it. That way we can do some strange things like 10.0.0-63.129-255 to autodetect only the second half of each class c... So I can segregate my desktops from servers, while keeping them in the same logical network, and repeat that pattern on every floor of a building... or only autodetect dhcp ranges (or skip dhcp ranges). The first and last IP method allows arbitrary starting and end points... it is also easier for you to parse.

But as for the reverse lookup, that is a great feature, but it needs to be optional, as we would prefer to see the IP address. But even though I would rather see the IP address, I think doing an RDNS and having that as a tagging option is a good thing for people other than myself. The problem with my rdns is some of it is wrong, because people forget to set it... IP's are never wrong.


George

[Calypso]

Any idea if this problem will be taken care of in a future version?

I have 'bout the same problem: have a /16 to discover, and I don't want to end up splitting the IP range in several discovery rules ...

[trooper]

I may use 'ranges' inside /24 e.g. 1.2.3.1-254, but when I want to perform autodiscovery on /19 which is 32x /24, the pain in ass arises since I cannot use more general conditions.
Would be nice to have something like 1.2.224-255.1-254 as ip condition in actions.

The more flexible method is to use wildcard masks like Cisco does.
So you will be able to discover not only whole networks like /19, but, for example, every host in all networks /24 with the last octet = 100:

192.168.0.100 0.0.255.0
will match
192.168.0.100
192.168.1.100
...
192.168.255.100

[svg]

workaround by generating the range in a shell script

workaround by generating the range in a shell script, quick and dirty:

#!/bin/sh
for n in $(seq 0 127); do echo -n "10.10.$n.0-255,"; done | sed s/,$//

Although beware, the field is limited to 255 chars, so this example won't fit totally in it!

[vlturner]

condition: ip range (autodiscovery thoughts)

The inclusion of a netmask solves the problem.

Why not use the method provided to coding already.
This defines the range and the broadcast.

A proper ping against the broadcast gets all the hots to respond.