Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!europa.interlan.COM!kasten
From: kasten@europa.interlan.COM (Frank Kastenholz)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: [swrinde!zaphod.mps.ohio-state.edu!samsung!xylogics!bu.edu!buit13!kwe@ucsd.edu: Re: SNMP monitors]
Message-ID: <9010261220.AA01390@europa.InterLan.Com>
Date: 26 Oct 90 12:20:25 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 56


 > 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