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
I don't see what's wrong with community string security. My set all of my passwords to "public" just to make things easy.
Life in Orange County
me... i will concider it when there is an OS version available.
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.
Microsoft has had a "implementation" (term used loosely) of WBEM in windows since as far back as at least Windows 2000 -- except it defined its own little corner of the MIB tree and didnt store anything in the actualy useful standard MIBs.
Of course, WBEM didnt have any marketing to go with it, so it died.
then again, at least its another shot to put SNMP in the grave where it belongs. especially before version 3, SNMP is a brutal and unreliable hack. im sure somebody will disagree quickly, but i can promise you that person never used SNMP for any major network management. *shiver*
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.
Then why are you using the "MS Word" spell-checker?
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
"wiss-management". To rhyme with "mismanagement".
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
If you're curious to see what they're missing;
Just wait and see what IBM has in their alternative.
It'll be out in another hand full of months, no doubt
SNMP is a nightmare in my opinion, good riddance!
Web services on the other hand, are very nice to work with.
I work with SNMP quite often and I hate it, web services are much easier to deal with. Let me tell you, if you've never worked with them have no fear for web services are easy as pie.
Yes, I am a smart ass; it's better than the alternative.
this page but without going blind
Actually that's just a myth that your mother told you to keep you from spending all that time in the bathroom with the sears catalog.
Can we try to determine right now what kinds of patents these companies have on this "standard", since we already know what their "strategy" is?
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...
It's probably patented by M$.
Does everything include nothing?
Goodbye SMTP? I remember people havingtrouble keeping those straight in my highschool Net+ prep course. We've really got too many accronyms in this industry.
Your CPU is not doing anything else, at least do something.
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)
So first came SNMP, then came CIMP (or whatever the acronym was), then came CIM (common information model), and WBEM (web based enterprise mgment -- xml over http) for transport. Can someone explain whether this is an extension of WBEM?
What is being specified here? It looks like a couple of existing WS features that might be useful in a management protocol, plus a few eventing extensions. Sure one might be able to build a management protocol on it, but how would you (or they) know until you tried it?
As an example, look at the few meagre paragraphs on addressing. They seem convinced that a 4-level scheme is fine, but not a word on why they think that or a suggestion about how more deeply indented addressing schemes might be mapped into theirs.
This paper is more idle speculation than specification.
Most devices don't even implement SNMPv3. There are a few out there that don't even implement SNMPv2, for crying out loud.
I really don't see SNMP dying any time soon. RMON was out for some time, but has quitely gone over the hill.
On the other hand, we have seen many devices with a web management interface. Standarizing that kind of interface is a good things, but has nothing to do with SNMP.
morcego
How is it possible in this era of security issues that new standards are still being drawn up without security being a requirement?
The Russian Mafia has stepped forward with tools to fight organised crime.
no big sig
So I'd be wary of betting your ass on MOM. Folks in India will only do enought testing to get by.
I don't see how they expect this to replace SNMP. I see more SNMP used on network devices then servers in order to collect traffic stats and error counts and stuff like that. There is no replacement for SNMP unless the infrastructure companies join. Maybe this can replace SNMP *FOR SERVERS*, but not overall and even then with the amount of monitoring systems that user SNMP that people also monitor some servers with.... I just don't see it unless you get everybody on board especially Cisco and Nortel.
"Microsoft will build support for WS-Management into an update to Windows Server"
Once this support is built, I have a feeling that if you so much as ping a Windows server, regardless of whether it's enabled, it'll instantly give you full-administrator in some fun only-by-Microsoft way. Combining IIS and the management level that they're talking about seems to just beg for disaster.
--sean
"[T]he single essential element on which all discoveries will be dependent is human freedom." -- Barry Goldwater
I am just literate enough in the subject matter to know what SNMP is basically. I have not implemented anything, nor dealt with it in any meaningfull way.
My question is: what is broken about it particularly? I am a programmer, so dont make the answer too "dumbed down".
Genuinely curious.
Thanks,
David
emt 377 emt 4
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'm sure we'll see more UDP bound SOAP standards being implemented. UPnP started it a long time ago, in a propriertary sort of way, meant for small devices. WS-* doesnt descriminate over transport: thats good.
You got one thing dead right though: RAM is the fundamental limit to tcp/ip. It is really the only excuse for not being able to do tcp/ip. Interesting that microcontrollers havent advanced ram more quickly. I'm still hacking on a 136 byte controller, for example.
Still seems like if you're going to bother to make a managed device, making the jump to some WS-* shouldnt be oh so difficult.
Myren
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.
Here's one SOAP over UDP spec -
= /library/en-us/dnglobspec/html/soap-over-udp.asp
http://msdn.microsoft.com/library/default.asp?url
Everything these guys touch turns into a bloated mess. We run thousands of web service transactions a day at work and not a single one of them uses anything WS and or SOAP related. We choose to stick with xml-rpc since it is simple yet powerful. There is not a single reason so far that we could come up with that would justify us moving to WS and SOAP.
Got Code?
Judged solely on Nortel's recent business history SNMP will soon replace it.
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.
it is remarkably difficult to use SNMP through NAT.
encryption support for SNMP is also very poor. that is, few vendors implement it and it's very cumbersome to use even if it is implemented.
the huge proprietary convoluted MIBs vendors use also doesnt help much, especially when the documentation on them is poor to nonexistent. it's also very annoying when they use a proprietary MIB when an existing standard one would have fit just as well (or better).
vendors using retarded convoluted proprietary MIBs when an existing standard one would work just as well (or better).
vendors using proprietary datatypes (or strings) when existing standard datatypes work just fine. laziness? stupidity? beats me.
SNMP also works very poorly through NAT. or lossy/high latency WANs.
vendors seem to think the 'simple' in SNMP means they can cut corners and do a minimal implementation, so you get devices which crash when you request large sets of data. a simple snmpwalk can crash many vendors devices.
You can call a method on a webservice with one line of perl. Nuff said.
No, I did not read the f***ing article!
Just about anything to replace the overly complex, badly designed and horribly insecure piece of hammered rhinocerous poop that is SNMP (which is not simple, nor really a management protocol) sounds great to me.
Even if I have to pay money for it. Have you priced commercial SNMP tools? Good God.
SNMP deserves to die.
Any sufficiently advanced technology is insufficiently documented.
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.
Microsoft capitalizes "Web Services" and seems to use it as if it refers to some set of protocols or something. To someone who doesn't bother to keep up on the latest Microsoft buzzwords (the FLOSS world lets you avoid much of that), the idea of "Web Services" being equivalent to "web services" seems unlikely.
Is "Web Services" just the latest way to say "implemented using SOAP"?
May we never see th
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.
Okay, I'm curious. SNMP allows for polling and for requesting feedback on events (traps). It provides exposed data structures that can present scalar values, trees, and multidimensional arrays. I can't really think of any network monitoring/management system that can't be built using this. What specific problems does SNMP have?
I'll buy a lack of encryption as an issue, but I don't think that it's really feasible issue to fix -- many embedded devices don't have the CPU time to handle it.
May we never see th
Clearly you've never had the pleasure of programming for SNMP. It's archaic and unreliable crap. It's so frigging complicated that there is only single source code reference implementation that ALL VENDORS use! Remember that SNMP crash exploit 2 years ago? Every vendor from Cisco to Microsoft was using the same code base. Time to bury SNMP for good.
> If I don't see Cisco and/or Nortel on the list,
_ papers/200017.pdf
n t/junoscope/junoscope64/index.html
> it's not going to replace SNMP anytime soon.
> Correction: _ever_.
I am afraid this is not really true.
Most vendors (including Cisco and Juniper) are moving away from SNMP, towards an XML-based framework.
See this link:
http://www.juniper.net/solutions/literature/white
You can download the JunoScript perl API from their site, it is fully supported in FreeBSD but runs well even on Linux.
http://www.juniper.net/techpubs/software/manageme
http://shit.slashdot.org/article.pl?sid=04/10/08/1 944219
Assuming that all vendors use the same code because they are all affected by the same vulnerability is erroneous. The recent flaws you are thinking about(authentication and ASN.1) were protocol flaws meaning anybody who implemented the standard were affected.
SNMP is as simple as any other extensible protocol. ASN.1 can be a bit obtuse if you're not familiar with self-referential languages but no programmer should count themselves in that category. You might complain that admins are not programmers but:
1) net-snmp is dead simple to configure from source
2) more expensive implementations are even easier
3) a junior admin with snmpwalk should be able to figure out which OID's he would want to monitor
Surprisingly enough, that is the real Alan Cox, and you're a troll.
Correct me if I'm wrong but wasn't UPnP supposed to be the new device config protocol that was going to kill SNMP and eliminate the need for admins?
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.
The license of the document is stating that is an Royalty-Free *and* RAND. Another tentative to lookup free software license... Please ask them to release the specification under a royalty free, irrevocable license.
Ah... so the network equipment folks have chance to sell upgrades or new equipment :)
If folks like Datapower will have it, XML / SOAP based communications would be part of the network layer rather than sitting on a higher layer...
Don't forget you can use XMPP as a transport for basically anything, and this WS-thing is certainly no exception. There is even an experimental JEP on transporting SOAP over Jabber.
My exception safety is -fno-exceptions.
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.
1. Release WS-Pants.
2. ???
3. Profit!!!1!
Which is very suspiciously similar to WS-Management, 'cept for the shorter name and the completely different set of signatories. Both try and provide a distributed "resources" view of SOAP endpoints, because if they were called "Distributed Objects" we'd all realise that the "Distributed Objects bad, Service Oriented Architecture" was so much bollocks.
Now, the fact that they are fairly similar means there is scope for convergence. I'd guess MS were the main author here (like DELL and AMD care about software), so if MS and IBM can be friend, and MS join the oasis working group, then we can see progress.
But I wouldn't hold my breath.
Everyone I know who has worked with CIM hates it. Maybe you have had a better experience. too many objects, too dictatorial a model. They even have a model for help desks and support calls. That is way over the top.
net-snmp - free
What's up Gold, about $200.00