Slashdot Mirror
Goodbye SNMP? Hello, WS-Management
Laoping writes "News.com has a story about a new Web services management specification designed to simplify network administration across a wide range of devices. A bunch of a big tech companies developed it together (Microsoft, Intel, AMD, Dell and Sun). Microsoft will build support for WS-Management into an update to Windows Server, which is due late next year, and in the version of its Microsoft Operations Manager management software due in 2006. The .PDF release, that makes it clear that it is meant to be a Simple Network Management Protocol killer. Now I am all for a replacement for SNMP, but is this the way go?"
hmmm, I wonder if this will catch on as quickly as IPv6 has.....
CS: It is all sink or swim...oh and did I mention there are sharks in that water?
The moron submitting the summary says "goodbye [long established and well entrenched technology]". SNMP has been around for a very, very long time. No matter how much better this is, it will not replace SNMP any time soon.
Read the article about the 32-bit MCUs a few stories down for yet another example.
click
Maybe it will be OK, if it uses persistent HTTP connections, which allow several requests and replies before terminating the transaction. Otherwise the ancient HTTP/1.0 message model is too limited to map all the messaging topology to the spectrum of object management requirements.
--
make install -not war
SNMP is not going anywhere anytime soon, until the major network players adopt WS-Management (that's if they adopt it at all). Looking at the PDF there are some major players missing, Cisco, Juniper, 3Com, HP, to name a few.
"Microsoft will build support for WS-Management into an update to Windows Server"
Clearly this is war! SNMP and M$-Management will battle it out for the top market share...oh wait...
will it be encumbered by patents? looking at the contributors, my guess is yes
... i mean, you'll probably need (by the time it comes out) at least a 3.8Ghz P4 and 2G of RAM
snmp v3 works perfectly fine as it is. let's leave well enough alone
but, this will probably work out well for intel
vodka, straight up, thank you!
If I don't see Cisco and/or Nortel on the list, it's not going to replace SNMP anytime soon. Correction: _ever_.
.
-- I care not for your foolish signatures.
I thought that the open replacement for SNMP was WBEM. Microsoft, in fact, has already implimented this, basically, as WMI, or Windows Management Instrumentation.
Anyone know why this is suddenly being pushed, and not WBEM?
It's interesting to see such diverse companies developing a standard such as this: I can see Microsoft, Intel, and AMD working on something like this, possibly Dell, but why Sun Microsystems?
Also on the folks churning out billions of tiny little devices. If you've only got 16K of RAM TCP is hard work let along management services while UDP is doable properly on a microcontroller.
The real power of snmp is what you can achieve through scripting it - queries and updates etc.
That becomes nigh-on impossible with this WS-Management craziness.
Typical Microsoft - always thinking there is some pleb click-clicking away.
Imagine you have to change some rmon threshold on 400+ devices, or integrate this with the corporate asset database.
Now you get the picture.
CIM is a fine, object-oriented replacement for SNMP, is mature and has XML-based communications over HTTP.
.PDF doesn't even reference CIM.
http://www.dmtf.org/standards/cim/
Microsoft already has a CIMOM implementation in its WMI service, although it uses DCOM to implement RPCs. Sun also has a CIMOM implementation for Solaris.
I find it very strange that the WS-Management
Using webservices for something like this seems like an enormous bandwidth waste to me. Whatever happened to optimization?
To ensure interoperability of devices and to enable any one console to manage any device, there will now be the standard default login "BILL" and password of "MOMONEY" for all devices. Users are not advised to change any passwords otherwise universal control will not be achieved.
-- If god wanted me to have a sig, he'd have given me a sense of humor.
I don't mean to pooh pooh this idea just because it's somewhat Windows specific but the only real advantage I see to this over snmp is that the delivery modes are more sophisticated and the data can be organized hierarchally. So why not just add builtin event notification to snmp? Otherwise using XML for something that should be a low-cost service seems wrong to me. System monitoring should be as small and SIMPLE as possible to reduce the possibility for exploits as it will likely be running with a high level of anonymous access on almost every workstation, server, and router in the organization. The whole thing smells of XML pixie dust designed to drive up requirements and thus sell servers and new software to go with. If you have a problem with snmp then fix it. Don't reinvent it with techniques that are expensive in clock cyles and exploits.
I can totally see this standard easily integrating with the 1000+ network element monitoring and statistics gathering software package that I use right now. /sarcasm
It was a PITA enough just to get all of the devices reporting to the same polling engines. I can't even imagine going through and changing it all to some halfassed XML implementation. If they really want it to be an "SNMP replacement", they should just improve on what's already available. Make it compatible with SNMP but more powerful.
-Randy
This new protocol simply cannot be adopted until it's fully acronymic... I mean come on, SNMP and WBEM and even CIM have been fully acronymous for some time now, and this WS-Management thing still has an entire word spelled out in the name? That won't fly in my shop, no sir.
-Lod
People are more likely to adopt standards that they can implement without getting sued or shelling out large quantities of money to be allowed to adhere to. Despite the comments about the protocol being heavier than SNMP (TCP based, SOAP envelopes, etc.) I think there are cases where a richer, more extensible XML-based syntax would be nice for this kind of application. Or maybe SNMP is "good enough" that adoption will be limited (hard to say without reading the whole spec and comparing), but I don't think crapping on it just because it's Microsoft is fair, at least during those rare moments when they are playing well with others.
This has probably been covered elsewhere, but I found that Tim Bray's short essay on WS-Overload summed it up better than I could have:
Worth a look: http://tbray.org/ongoing/When/200x/2004/09/18/WS-rm -rf WS-*
I wonder if you could use XMPP (Jabber) to monitor devices. Each device connects to the server like a person IMing. It can easily send a message when something bad/good happens. You can have a roster (buddy list) of the devices you want to monitor.
Doesn't this sound like the kind of solution that would be primarily software-based?
Despite that, the only largely software-based companies involved are two VERY proprietary-obsessed companies??
Meanwhile, what can AMD and Intel offer to such a solution? Since when are they involved in building new networking-related systems?
Also, someone else on here brought up the issue of patent-encumbered technology. This will *definitely* be an issue with these vendors/manufacturers, seeing as they'll all be interested merely in their capital gain as opposed to simply contributing to the general technological advancement of the internet/networks in general...
"WS-Management can also be used to manage things like set-top boxes and TiVo-like digital video recorders"
Yup, all containing AMD or Intel CPUs, running an embedded MS/Sun OS... now we see why the CPU manufacturers are involved...
Am I the only one getting sick of hearing about these new "great" proposals made by huge companies when their true intent is blatantly obvious? SNMP *works*, yet for some reason, as usual, some big company has to come along and try and run it over with their new crippleware, claiming it's the New & Improved (tm) version of whatever it was that worked just fine before...
Nobody else seemed to mention this yet so I thought I'd point out that Sun seems to be contradicting their latest monitoring framework:
JMX
By going along with this new specification. Network Management, monitoring, and other SNMP-like operations in Java are moving to the JMX or java media extension framework. In Java 5, the VM has JMX hooks built in for monitoring and control. Alas, I have to agree that SNMP is tired and old, but it still is in place in a lot of environments (and in routers, firewalls, and other hardware appliances) and is really easy to interface and use. I doubt this will catch on very quickly...
.: 2+2 = PI SQRT(1+N)
How is it possible in this era of security issues that new standards are still being drawn up without security being a requirement?
Ok, lets try to summarize why we like SNMP:
-Implementations can fit in a few kb memory footprint. I don't see web services beating that any time soon. (Oh, and not all the devices on the planet are 4Ghz P4's with a gigabyte of ram so it is still important not to be a memory hog on many areas).
-For relatively simple purposes, S(imple)NMP is almost as simple as it gets. Like say, for the monitoring of the temperature of a router, using something like web services would surely be overkill.
-There are many implementations for your favorite unix flavor. Probably best is the excelent net-snmp package. The 5.x version has many new methods of extending the main agent instrumentation through compiled in modules, dynamicaly loadable modules, external (pass) scripts, even embedded perl. Solaris 10 will be using the net-snmp package as part of the standard installation.
-The protocol is extremely efficient so there is little presure on the underlying medium. The PDU's are encoded in BER, so the implementations are abundant and quite standard. And yes, this is very very important because practicaly all versions of agents and toolkits are 100% compatible between them.
-Because the SMI is defined in ASN.1, there is no ambiguity in the structure of the management information. See previous bullet why this is important.
-There are excellent tools like HP OpenView NNM which can really simplify monitoring of even extremely large networks.
Now let's see some of its disadvantages:
-Poor security, corrected in version 3 (somewhat complex) but still most people use version 1 or 2c.
-Setable objects are IMHO a nightmare to use. For those of you who are reloading their router by setting sysUpTime to 0, I may seem dead wrong, but it appears that most people's safe bet would be just to log in to the machine and do the job they want. To generalize that idea, SNMP is unbeatable when it comes to monitoring things, but when it comes to actualy controlling things from away, it loses. Perhaps that is exactly the niche that those web services will complement (not replace!) SNMP.
-Extremely difficult to describe complex data structures using SMI. But then again I may be too impatient.
Lastly, though it will sound bitter, there is no clear evidence that web services or WBEM or whatever will be able to actualy help network administrators do their job better than they do it today.
And remember everyone, there is no big company that can necessarily know your job and your needs better than you, as much as they profess to. So on this matter we must not take the word of those who are trying to sell us the New Management Ubertool but on the contrary try to evaluate it in the real world and figure out if it actualy is usefull or not.
And that's my five cents for tonight.
I agree completely - however, I do wish to point out that ASN.1 and BER are a pain to code & maintain. XML is definitely an improvement, but I would argue its flexibility is what is going to fracture it. This is not putting down XML or its use, but on the so-called 'partners' who are involved in this 'deal' have an established pattern of adding their own 'extensions' which defeat interoperability and serve to enforce market share and not true integration.
If I were doing this, I would take the strenghts of SNMP (e.g., nice simple interface of get/set/walk etc). and make a HTTP style language for it. Extend the language for specific needs but don't make them optional. Keep the data and its overheads small and clean. And lest I forget, add a proper layer of security that may not have been important when SNMP came along but today is indispensible.
when a piece of metal needs to be monitored from something that further than a piece or two of cat5 away, being forced into UDP can make SNMP borderline useless. did the packet drop, or is the network down? hmm.. ill use SNMP to see if its the network. hmmm, negative. did the packet drop, or is ... rinse, repeat.
add the lack of error protection, and SNMP can be very very frustrating. and sure, UDP will make it *most* of the time, but there are a lot of applications for SNMP where most just isnt good enough.
SNMPv3 does largely mitigate the problems by allowing TCP instead of just UDP. but, the reason for not replacing SNMP also holds SNMP back: a lot of the massive instaled base is in big iron, that does not support SNMPv3 over TCP.
basically, the more ive worked with SNMP, the more ive realized that the "S" is the key letter. it is fantastic for some quick chores ona local reliable network, but just plain doesn't scale. there is a vast array of management and monitoring problems that just arent simple enough for SNMP to handle well.
snmp v3 works perfectly fine as it is. let's leave well enough alone
:)
considering most vendors are still using v1 or v2, that should be 'lets leave snmp v3 alone'
to be perfectly honest, SNMP is anything but simple. the only thing simple about it is the protocol itself. it then got buried under avalanches of proprietary MIBs, all partially overlapping yet all mutually incompatible. some only partially documented (or not documented at all). not only that, the insistence of vendors using funky proprietary data types (or worse, strings) when existing datatypes would work perfectly fine.
what was needed imo was a MIB guideline and 'retarded implementation' verification. to ensure vendors didn't create obfuscated and spaghettified MIBs.
If it guarantees delivery it would be much better. SNMP is udp and there is no way to know if the trap was recieved.
I've seen systems that are snmp based, where a cluster is used, and if the system has a fail-over many old traps are read again and alerted on. I think if the sending application can get an acknowledgement from the central app (netiq, netcool, compaq insight manager, tivoli, hp openview, etc) these type of false alerts would go away. When the sender can see the alert as a transaction it eliminates a lot of problems.
-Joe4
Silly Rabbit: tricks are for kids.
SNMP? what is SNMP ? Well SNMP is a "big thing" in the networking environment where all the big players develop their applications based on it for example Network Management Systems.
.
SNMP has evolved from time to improving from one version to another from data retrival to security.
Well its a well establised phenomenom and no one can change it in a day as most of the big fish in this business rely on it to satisfy their appetite.
Lots and lots of work is undergoin specially in SNMPs 3rd version as most of the companies have not established their products with version 3 support.It has proved to be an invaluable entity in my NMS and other NMSs in the market.
Take for exampe those net-snmp guys they have done some tremendous using snmp support(visit:www.net-snmp.org) for more details
I really think SNMP has still got immense potential to be on the top provided some more research is undertaken.
If I was to build a cheap DSL modem, switch, IP camera or wireless gateway, I would probably be working with an 8/16 bit processor and limited memory to save money. In such a case, I would want to minimize my code and memory footprint and my CPU requirements.
Now lets look at XML. It is a bloated, complex, textual way of representing information. It requires some sort of a parser to read requests and storage of strings rather than individual bytes for response codes.
This sort of 'advancement' might be good for hardware developers peddling their latest wares with more RAM, flash and CPU grunt than their last release but from a technical and consumer point, I don't see there being huge advantages.
I think the idea is a good one, however it is prone to a security risk. A website has a domain name, these can easily be remembered and found by using a search engine. Now lets say you have this WS Management software, what good is it if it is run on a domain to control systems, because it could be searched and found out easily, this would mean that blackhat hackers would have an easy time finding out where to access the management software, and then they could proceed to gain access to it through exploitative penetration.