Discussion:
**self-help/DIY NMS fans** What is your next wish in the NMS areana?
(too old to reply)
t***@yahoo.com
2008-07-15 19:37:04 UTC
Permalink
This is a broad question addressed to consumers of NMS (Network
Management Systems) in small to Medium network scenarios. This is a
sweeping term that covers IT Network Managers, IT Admins, Network Ops,
Cable Operators, Hardware Integrators, Vendors..etc...anyone dealing
with Network Management (host side network monitoring or management)
on a day to day basis in their work life in small / Medium businesses
(SMB). If you are one, you can respond to this posting.

I help people who want to write their own NMS, who have some
application programmers but otherwise lack resources. I want to give
them components so they are empowered and not spend tens of thousands
and stay dependenat on a massive feature ladden shrink-wrapped
software they can buy off the shelf. It can be summarized that
currently the pet of such a **self-help** framework is resourced by
components in 2 major categories:

1. SNMP v1, v2, v3
2. RMON (1,2)

With several vendors in this area, the choices are many.

If you are the kind of DIY NMS consumer I describe above, what would
do you have the highest on your wish-list, the kind of support you are
looking for to write ** your own ** NMS? If you want to respond to
this posting stay on this thread of conversation and also let me know
what is that you do in your work life (vedor, IT admin, Net Ops, Net
Manager etc. etc.)

I look forward to your responses.

Regards
Your NMS component developer
unknown
2008-07-18 14:12:58 UTC
Permalink
Post by t***@yahoo.com
1. SNMP v1, v2, v3
2. RMON (1,2)
Drop RMON - old, aged, not that useful anymore - I never quite liked
the idea of network equipment expending CPU to measure the traffic it's
passing.

Five minute averages of anything are not useful - averages aren't a
reality you can plan on. 20% "average" utilization polled from SNMP
statistics or similar miss several-second 99% utilization issues that
crush application performance and perhaps even force them to disconnect.

Really helpful? Do detailed testing / analysis, even automated, of
vendor SNMP MIB's, find out what works, what's broken, what's good,
what's bad, before I plop it into a compiler and find out that some bug
updates (n) incorrectly. This could even be a good service / business
model.

/dmfh

--
_ __ _
__| |_ __ / _| |_ 01100100 01101101
/ _` | ' \| _| ' \ 01100110 01101000
\__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx
Madhav
2008-07-19 03:27:57 UTC
Permalink
On Jul 18, 7:12 pm, Digital Mercenary For Honor
Post by unknown
Post by t***@yahoo.com
1. SNMP v1, v2, v3
2. RMON (1,2)
Drop RMON - old, aged, not that useful anymore - I never quite liked
the idea of network equipment expending CPU to measure the traffic it's
passing.
Five minute averages of anything are not useful - averages aren't a
reality you can plan on. 20% "average" utilization polled from SNMP
statistics or similar miss several-second 99% utilization issues that
crush application performance and perhaps even force them to disconnect.
Really helpful? Do detailed testing / analysis, even automated, of
vendor SNMP MIB's, find out what works, what's broken, what's good,
what's bad, before I plop it into a compiler and find out that some bug
updates (n) incorrectly. This could even be a good service / business
model.
/dmfh
--
    _        __ _
 __| |_ __  / _| |_             01100100 01101101
/ _` | '  \|  _| ' \            01100110 01101000
\__,_|_|_|_|_| |_||_|            dmfh(-2)dmfh.cx
Hi,

In the User's perspective the GUI should be faster and efficient.More
or less the NMS app should cover all the options he expects.Supports
all platforms,based on standard standard MIBS.....

Thanks
Madhav
unknown
2008-07-24 20:41:03 UTC
Permalink
Post by Madhav
In the User's perspective the GUI should be faster and efficient.More
or less the NMS app should cover all the options he expects.Supports
all platforms,based on standard standard MIBS.....
Inter-operability and multiple platform support are not that useful
when the underlying data polled is not useful or broken, and after a
decade of working with vendor equipment from the "Big Four" : Nortel,
Cisco, Juniper, Extreme, I've found their SNMP support to be lacking
and spotty, even for standard MIB-II stuff. Bugs abound.

Any tool you have is not that useful if the data used to assemble
analysis or results is flawed. What I'm saying is that one could offer
extreme value by independently validating the SNMP functionality,
fully, MIB-item, by MIB-item and produce test results. It would also
potentially prompt vendors to fix broken things.

It's about the fundamentals first, not the presentation and analysis
first, etc.

/dmfh

--
_ __ _
__| |_ __ / _| |_ 01100100 01101101
/ _` | ' \| _| ' \ 01100110 01101000
\__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx

Loading...