Re: [opennms-discuss] OpenNMS Network Map 'Design RequirementsDocument'

[Ian C. B. <icb...@nk...>]

On Wed, 2002-07-10 at 21:04, John Blake wrote:
> I'm new to Opennms so if this is a stupid question, you'll know why.
> 
> My understanding is that you give it a range of Ip's and then you
>  discover what services are on those ip's.
>  But it currently tries all the services, for numerous ports for each
> service,
> on all the ips.
>  Wouldnt it be better if something was created like you did in the
>  SNMP poller section that you could have the option to select
>  what Groups and then what Systems the ip range belonged to?

Eventually, the hope is to tie in scans from other systems like Nessus
to feed this discovery process somewhat as well.

As for grouping ranges of IPs, I'm all for CIDR netblocks to segment off
network legs for dynamic map grouping.

>  Say, these Ip's are servers so I want them polled for the normal server
> services.
>  But these other IP's are routers and I know i dont have SMTP running on it
> so let me just select them to be
>  polled for routing services.

But why not just discover this fact? If port 25 is listening, it's a
good bet that SMTP is running on it. Enabling monitoring of that service
should be left up to the user (do they really *want* to know when it is
down? if so, add it to be monitored. if not, ignore it).

>  Seems like that would definately drop the discovery time if you're
> discovering routers/switches.

Is discovery time such a problem? There are other ways to "speed up"
discovery, most port scanners (like nmap) have techniques to improve
scanning speed.

>  Also, concerning the maps.
>  Could Opennms use the Openmap app from www.openmap.bbn.com?

It's a bit of overkill for just logistical (not 100% accurate
geospatial) maps. Few operations have a lat/long of every piece of
equipment they have, much less a need to accurately depict it this way.

But I will agree, it would be interesting to build at least some maps on
a precise mapping engine.

Looking over the project, there does not seem to be a way to generate
SVG yet. I'll wager that there is some form of vector export though.

>  It sounds like its perfect for the open mapping software you're looking
> for.

It sounds perfect for one of the mapping models. If we are drawing
Geospacial maps, it is nice to have that precision. If we are drawing
logical topology maps, it really doesn't make much sense at all.

>  It will place nodes on a map by layers, by Long/lat, and manually.

Requiring a earth-sphere Long/Lat for map placement, or even mapping to
one, is relatively ominous if all you have are IP addresses and some
vague notion of how they are related to each other (much less a physical
real-world location, if that is really at all important to the user).
 
>  Since it does it by layers, you could have it look in the dbase and be able
> to select which type of devices you want displayed.

The goal is to output a vector representation of node data. There will
be some notion of layers, of course, but requiring that all nodes have a
unique position and layer that they belong to leaves the map designer in
the same situation that NetSaint/Nagios do to their users today.

>  And it would be displayed according to whatever criteria is in the dbase.

The key is offering a simplistic human interface to the information
stored in the database. Make it too complex and you've ruined the
benefit of using the mapping tool to begin with.

>  Say, this layer is for all servers, and this other is for servers running
> http.

Why not make those "layers" basic search criteria on a database of
discovered nodes?

>  Or this layer if for the servers running solaris8, etc.
>  You'd be able to show all the solaris8 servers running http ( or whatever
> ya want).

That's why a search works well, with auto-mapping. Otherwise nodes on
the solaris8 "layer" (Map.A[]) might occlude the view of nodes on the
http "layer" (Map.B[]). It would be possible to have a union of (Map.A[]
U Map.B[]) redrawn in a resultant map of Map.C[], but why? Trust me,
it's more difficult to deal with, and there doesn't seem to be much of a
reason for this extra layer of complexity.

- Ian C. Blenke <icb...@nk...> <ia...@bl...>