Steven_Carmody@BROWN.EDU (10/18/90)
WeUre in the process of looking at SNMP based monitors, and expect to use one to monitor gateways and services in the campus network. ThereUs a discussion starting in this digest which seems headed toward developing a RscorecardS comparing many of the currently available products. I think everyone will benefit if the community creates a such a yardstick. However, in an interest in getting our site moving, and at the great risk of oversimplification, IUd like to get a sense of whatUs out there. So far, I can see three groups of products: 1) the PC-based monitors (wollongong, the recently announced novell one, etc), 2) the NyserNet/PSI monitor, and 3) a large number of commercially available, UNIX based monitors (often from router vendors). IUve separated 2 and 3 because the NyserNet package is available to universities for approximately 1/10 the cost of the packages in category 3. The question is -- are there any generalizations which can be made about each of the categories? can the PC-based packages handle a large campus sized network? are there major problems with the NyserNet monitor that the packages in category 3 have corrected? Any info and experiences would be appreciated.
kwe@buit13.bu.edu (Kent England) (10/19/90)
In article <9010181639.AA14322@po.cis.brown.edu> Steven_Carmody@BROWN.EDU writes: >... I'd like to get a sense of what's out there. So far, I >can see three groups of products: 1) the PC-based monitors (wollongong, the >recently announced novell one, etc), 2) the NyserNet/PSI monitor, and 3) a >large number of commercially available, UNIX based monitors (often from >router vendors)... > >The question is -- are there any generalizations which can be made about >each of the categories? I can generalize. :-) 1) I don't like PC based packages because I need workstation power and multitasking. You will need multitasking and virtual memory to do good fault management and data gathering. Of course, you could use a pile of PCs. And I do understand the need for a low end PC package for smallish PC networks. So I would say they are OK for small nets with unsophisticated tool requirements, but not suitable for largish nets. The Proteon Overview PC tool is pretty good, even in its earliest release, with which I am most familiar. 2) The NYSERnet stuff is still pretty good in comparison to other software, and that is disappointing. It indicates that the development of tools has stalled or gotten sidetracked. Some points of interest: 3) Fancy graphics. Migrating from an early X window environment to Motif doesn't buy the network manager a lot. This has distracted developers excessively. But Motif is very pretty; witness the Cabletron displays. Nice pastels, shadows, pictures, etc. Value? To be determined. The people running the InterOp show network used ping and traceroute a lot, but then they may be old fashioned. :-) Databases. A database is an important feature of an advanced network management fault monitor and data gatherer. Early implementations fall short in the ease of use category. We need some database interfaces that match the window environment more closely. Configuration. It is very difficult to adopt or change a tool in a large network if the tool does not help the network manager configure the tool. This is one area where the NYSERnet tool is just awful, requiring the same data to be entered multiple times consistently in the snmpxmon.cf file. Dynamic configuration of commercial products is on the drawing board in the tools I have examined closely, but is not available in a production release. Data gathering and interpretation. This area has been entirely neglected in the tools I have seen. Data gathering and analysis should be database driven. Report generators should be supplied and should be customizable. The database must be accessible outside the network management tool. The database must be custom extensible to deal with such local issues as inventory and cost accounting. There should be utilities for automagic aging and compression of performance data timelines, reducing the demand for disk space growth and easing back-up and archiving. No one is addressing these issues, in the tools I have examined. NYSERnet is still as good as any of the other tools, which is disappointing. One reason I think that progress is disappointing is that the network management market is limited. Developers are getting enamored of the "Distributed Computing Environment Management". I have heard more than one developer talk about stuffing every conceivable variable and extension into the MIB for managing PCs, workstations, and servers and this is a distraction away from the purely Network Management needs of largish networks. However, I understand that tools for DCE management are useful. Sun's tool is interesting. If it saves sysadmin time, it's a good thing. DCE management tools have a wider market than purely NM tools. But DCE management is more embryonic than NM, so I would rather see some vendors concentrate on solving NM problems before turning to DCEM. They could learn from us. One bright note: Cabletron's Network Virtual Machine and object oriented development environment are powerful architectural elements of next generation tools. The NVM can scale well, and holds out some hope of unified Internet management (if such could happen politically and organizationally and could be standardized for interoperability). The OOP model in the Cabletron Spectrum tool is an apparently powerful technique for allowing user customization and for MIB and device tracking. I think object oriented techniques will prove very useful in managing development of sophisticated NM tools, but that is just my embryonic gut feel; it has yet to be demonstrated. --Kent
fin@UNET.UNET.UMN.EDU ("Craig A. Finseth") (10/26/90)
I do realize that an overloaded router should be addressed, but if SNMP could gaurantee me a reply if a router was UP and doing its primary funtion, I would stop using ping to monitor our routers and pay *serious* attention to snmp based monitoring programs, as opposed to *saying* I use SNMP to prove that I am in sync with the new technologies that exist. That is to say, is there someone out there who relies *only* on SNMP to monitor the net ? Or will 'ping' be used as a monitoring tool for the rest of IP's life ? I see no reason why it is desirable to stop using ping (or, more precisely, the ICMP Echo mechanism). Most checking just wants to know "are you there" and the ICMP Echo mechanism does that with much less overhead than SNMP ever could. For example, the network monitoring here at the U uses ICMP Echo for most checking, reserving SNMP for those "higher level" tasks such as checking routing tables and interface configurations. The software also knows not to perform the higher level checks unless the device is known to be up. (It also knows not to check hosts behind a down router, but that is not related to SNMP). Craig A. Finseth fin@unet.umn.edu [CAF13] University Networking Services +1 612 624 3375 desk University of Minnesota +1 612 625 0006 problems 130 Lind Hall, 207 Church St SE +1 612 626 1002 FAX Minneapolis MN 55455-0134, U.S.A.
cpw%snow-white@LANL.GOV (C. Philip Wood) (10/26/90)
UP WITH ICMP! SNMP is not enough. What good is SNMP if the nodes on a network do not support it. And why should they. They were on the net before SNMP was a gleam in some relational database guru's eyes. ICMP offers a lot more than SNMP cause it's there and SNMP is not. I'm a raving supporter of TRACEROUTE and PING! Five years from now I'll switch to SNMP or something like it. Hmmm, is that five or ten years from now? I forget. Phil PS: I actually brought up some snmp stuff. And for the nodes on the network that support it, cisco router's, a couple of UNIX machines running PSI stuff, and Multinet on VMS, it's hunkydory!
pushp@CERF.NET (Pushpendra Mohta) (10/26/90)
>> >>as near as i can tell, and no one has come out and said this, but it seems >>to be an undercurrent in alot of people's minds, is that SNMP is enough, and >>ping is somehow dirty, and shouldnt be used. (*geesh*) >> >> >> And not to mention the fact that only traceroute and ping will work when debugging problems with boxes you dont know the SNMP community names of ... --pushpendra CERFnet
kasten@europa.interlan.COM (Frank Kastenholz) (10/26/90)
> From snmp-ok-forw@nisc.psi.net Thu Oct 25 20:44:29 1990 > From: aggarwal@nisc.jvnc.net (Vikas Aggarwal) > To: stev@ftp.COM, stewart@xyplex.COM > Subject: Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors] > Cc: snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil > > >> SNMP was not used as much as it could have been for one simple reason. no > >> matter what people tell you, the tools currently on the market are not easy > >> to use. > > Another fact is that systems supporting SNMP do not consider snmp as a > high priority task- as a result I have routers that do not respond to To all of those box builders (including Racal Interlan :-) To structure your in-box priorities in such a way as to make management (and, for bridges and routers, Spanning tree and your routing protocols) run at a lower priority than the "main" purpose of the box (e.g. forwarding packets for bridges/routers) is ABSOLUTELY BASS ACKWARDSLY WRONG. As Vikas described in his memo - when a network starts to depart for the Twinkie zone, the bridge/router may spend absolutely 100% of its time bridging/routing. Regardless of the efficiency of the network management protocol and it underlying transport, the NM packets will not be processed by the box. The manager will not be able to find out what's wrong, nor will s/he be able to take effective action (similarly for bridges - if the max out at 100% doing bridging, then spanning tree packets get ignored and the spanning tree algorithm breaks and you may wind up with loops in the net, meaning that offered load will increase - can you say melt down?) When everything else is going completely bonkers, NM, etc, MUST WORK. One of the reasons that NM protocols and agent load must be kept small is to reduce the amount of work that the box must do at this highest priority. Now, I hear the masses crying out - "I don't want NM to be highest priority - then anybody with a network management station can bring a box to its knees". Well, I hate to say this but, if someone has an NM station, they can do this anyway (set ifOperStatus.* to down). Besides which, this is not a problem of network management, this is a problem of security. If you have unauthorised people doing NM on your network, then you have a security problem, NOT a NM protocol problem. Btw, this is not just smoke, this is heat and light. Here at Interlan, we learned the hard way that what I've just said is true. During development of our bridges, under heavy load, our bridges would lock up from a NM/Spanning Tree point of view. NM said the bridges were down. For the "working" bridges, spanning tree indicated that those bridges failed. Yet there they were, forwarding packets..... In fact, sometimes they would lock up so hard that even the local console would stop working. The only way we had of solving the problems was to partition the network until things got better. Cheers Frank Kastenholz Racal Interlan
kwe@buit13.bu.edu (Kent England) (10/27/90)
In article <9010251553.AA02760@nisc.jvnc.net> aggarwal@NISC.JVNC.NET (Vikas Aggarwal) writes: > >Another fact is that systems supporting SNMP do not consider snmp as a >high priority task- as a result I have routers that do not respond to >SNMP is they are busy passing traffic. As a consequence, during the >better parts of most afternoons, I would have sites change status to >"unknown" or "down" all the time because the routers would not respond >to SNMP. > SNMP should be given higher priority as ICMP usually is, but that does not guarantee that CPU utilization will be requested by the network management station. Perhaps you are lucky that your routers are telling you something you need to know that you otherwise would not ask. Even though you are unable to get your routers to respond to SNMP queries, this situation is indirectly giving you network management information that you could use. Go forth and upgrade your router CPUs and add memory or go get skinnier pipes for your overwrought routers. --Kent
salzman@NMS.HLS.COM (Mike Salzman) (10/27/90)
Several messages have recently flamed SNMP, perhaps as a reaction to or byproduct of the Marshall and Karl debate society. The comments are incongruous since both ICMP and SNMP and other techniques have a role to play in the process of installing, monitoring, maintaining, testing and diagnosing a network. Although SNMP is a relatively recent development, and is a popular protocol targeted at network management applications, its developers never claimed that it should replace all other techniques and applications. It also does not address all network managment issues. The flavor of universal ompnipotence and the consequent exclusion of all other methods, techniques and applications is a byproduct of simplistic jounalistic reporting that afflicts our industry, and of marketing hype. SNMP is intended to manage operational networks. The fact that a router between manager X and device Y has failed does not preclude the manager station from using out-of-band (i.e. non ethernet) transmission channels to reach device Y. The lack of robustness is to a large extent an application design shortcoming, not an attribute of the protocol. The layering of the protocol in its most popular incarnation (over UDP) is also not an inherent aspect of the protocol, although it is highly recommended. Poor network design may have as much to do with preventing the operation of SNMP 'links' to managed devices, as does the depedence on IP. Clearly, however, it is necessary to use tools other than and in addition to SNMP to bring up the network. These include Ping. At a higher layer, it may be necessary to use PING-LIKE techniques to bounce data from EIA ports for example. Here again SNMP is not directly applicable. The conclusions are: 1. SNMP is a useful, interoperable protocol 2. It is not the sole and universal protocol 3. SNMP is not a replacement for well thought out, practical management applications -- it is an application tool 4. Poor design of network facilities and fallback routes is not an attribute of the protocol. -------------------- salzman@hls.com ---------------------- Michael M. Salzman Voice (415) 966-7479 Fax (415)960-3738 Hughes Lan Systems 1225 Charleston Road Mt View Ca 94043