Yes, it was. There was a point where Cabletron was such a big supplier
of equipment (all layers) they had to take all sorts of steps to prove
their technologies were interoperable with others.
Spectrum, back in the day, had some really awesome options for ISV's,
say if you were had a product that was a systems/network controller,
they had some pretty tight integration packages. No one but a very
select few will ever have seen some of the things they deployed and
how truly awesome it was (minus the overhead and whatnot you
mentioned, we had to turn ours off)
This is actually one of the reasons I'm an OpenNMS zealot. While auto-
discovery through specifying IP ranges or through SNMP trap receipt is
great and all, those features aren't really something that scales with
day to day operations. With that said, the provisioning groups feature
is something that provides so much functionality that may go
overlooked -- it allows for things like provisioning and change
management systems to drive your network as they should, rather than
relying on hindsight when things move around. It's super enterprisey!
Gonna get wordy since we're talking best practices...
A MAC/IP pair will never be consistent enough to use it for something
like a primary key on the node table given the scenario of an IP
change. A MAC or IP would also turn up fail in the event of a hardware
swap coupled with a re-ip'ing (happens ALL the time at the same time).
The Asset Management system baked into ONMS could sort of do this, but
it can get sort of confusing after changing out hardware later.
I'd reckon to say the only human understandable CONSISTENT identifier
for any sort of equipment is knowing that it's the X Numbered Y Device
at Site Z, in which X, Y, and Z will wildly vary by business type. You
could, OpenNMS does, and many vendors ask for things like building
number, floor number, rack number, and rack position, but I always
feel completely ridiculous explaining that there's only one room, one
floor, a few racks and fewer rack positions at my remote sites. When
you're talking monitoring, things like port numbers, interfaces, etc.,
come into play, but when something completely fails, it's the X
Numbered, Y Device at Site Z.
If you want OpenNMS to track XYZ, it can, and do a fine job at that.
But it can't, and never could come close to, make assumptions about
whats in your head.
So, to:
1.) Reduce Human Error via input or field device change out/
misconfiguration
2.) Document Changes
3.) Properly arrange for ONMS to know your changes and when they're to
happen
4.) Always have your eyeballs on the right device with little or no
delay (see #3)
5.) Make sure your end users and/or customers are happy people
It's critical to have an awesome grasp on your inventory and change
management procedures. The XML node import and Asset Management
systems built into ONMS aren't as quick, impressive, or flashy as auto-
discovery or adding IP's manually, but it's the real deal as far as
enterprise management.
I'm not currently using the Asset system, but I do currently use the
XML importer. Our network people could probably get some use out of
the AM component, but everything I'm monitoring is either one or two
different units. The XML schema can be a little hard to follow for
people who don't use it, but if you create one via the WebUI, it will
drop it in opennms/etc for you. You define set physical locations,
then the nodes within, the services monitored, etc., etc.
The magic, and if you only read two lines of this long rant, is this:
If you have a consistent value (external key) for your device set in
the XML, and you make changes to any other data, OpenNMS will still
equate that external key to your Node ID in the DB, and after clicking
"import' after making changes, you have NOTHING to worry about. Keep
your change management, ticketing, etc., properly maintained, and
OpenNMS will handle it all for you.
I keep meaning to do something to make this easier for people, but it
always falls through the cracks.
- Mike
On Nov 3, 2009, at 8:12 PM, David Hustace wrote:
>
> On Nov 3, 2009, at 4:24 PM,
[hidden email] wrote:
>
>> Spectrum does use an IP Address/ MAC Address combination as a
>> unique key.
>
> That's why spectrum rocks ;) Actually, outside of some of the
> performance and maintenance related issues of Spectrum, it was a
> pretty cool tool. Wasn't it Cabletron that owned the patent to
> every network management related concept in the universe!
>
> -D
>
> David Hustace
> The OpenNMS Group, Inc.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.
http://p.sf.net/sfu/bobj-july_______________________________________________> Please read the OpenNMS Mailing List FAQ:
>
http://www.opennms.org/index.php/Mailing_List_FAQ>
> opennms-discuss mailing list
>
> To *unsubscribe* or change your subscription options, see the bottom
> of this page:
>
https://lists.sourceforge.net/lists/listinfo/opennms-discuss------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.
http://p.sf.net/sfu/bobj-july_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQopennms-discuss mailing list
To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss
