> Your next assignment is to take a Kinetics FastPath 4 and get the
> protocol you detail below to fit in its memory. The KFPS4 was chosen
> because it represents good minimum platform for back when snmp was
> being developed and is still a reasonable minimum-sized platform to
> design for given the proliferation of tiny microcontrollers that you
> may want to snmp-control. I'll even be gracious and allow you to rip
> out all the appletalk functionality (the whole reason the box existed
> in the first place) in an effort to gain more memory to do its thing.
> Remember that it has to be as extensible as snmp, and since it is
> ascii-based you will of course have to fit the entire text
> representation of the MIB in there as well. The FastPath 4 had either
> 64k or 256k of memory depending on which rev you got.
And it have not internal tables already? Organised by the vendor-defined
structures (port.statistic.traffic_statistic.{input_butes,input_packets,
output_bytes,output_packets})?
I claim _SNMP realisations tends to be slow and pure because MIB
structure have nothing with the real data organisation_. To make protocol
implementation simpler, you need to make data structure looks like it is
stored already in the memory.
And then, this FastPath have TCP/UDP stack and 'sprintf' function? You
don't
need to convert host data to the network data, you don't need to store
data structures and alogn fields in the memory in case of the text
protocol. And then, if this device have any CLI (and 99% of devices have
it already) you just have everything to add one more text language.
>
> I suppose you also argue that bootp and tftp are terrible protocols
Not at all. Note - this protocols do not need to be FLEXIBLE ->
binary format work best this case.
But if you need FLEXIBLE and COMPATIBLE protocol - text format sometimes
is much better. And if your protocol can be used by human been for debug
purposes - in extra one arg to make it binary. Modern network tends to use
text protocols more (and compare H.323 and SIP protocols - first can't be
read withouth the tears from the eyes)...
I don't try to prove 'binary is better_ or _text is better_; I am trying
to understand why SNMP protocol appear to be so unpleasant and
/relatively - you can't avoid it but 99% of network configurations and
even 20 - 30% of network monitoring don't use it - imagine engeneer who
use SNMP instead of CLI to debug serial link/ useless.
Alex.
> because they are not text-based.
>
> Cheers,
>
> ---Rob
>
>
> "Alex P. Rudnev" <alex(a)Relcom.EU.net> writes:
>
> > And the worst thing, If someone think _SNMP IS SUITABLE PROTOCOL_ he is
> > wrong. In case of CISCO (as an example) we was caused to use boths 'SNMP'
> > and 'rsh show ....' methods to get appropriate information. I think
> > those who developed SNMP was the childs of the hell (it's terrible
> > example of _how you should not develop protocols_; for example, compare
> >
> > 'rsh -t 120 -l monitor "show ip route"'
> >
> > request and requesting ip route table by SNMP; compare 'sh interface
> > Serial0' and SNMP (10 - 20 different MIB tables with the very euristic
> > INDEXES), try to ask _how much BGP router does router have_ or _how mach
> > packets was received by ISL sublink_ etc etc. If someone answer _that's
> > because of CISCO don't like SNMP_ I can't agree - no, thet's because SNMP
> > is wrong protocol at all.
> >
> > Such protocol should be:
> >
> > - ascii text based;
> > - with domain-like names, with the asterisk;
> > - based on reliable UDP and/or TCP;
> > - use something like MD5 checksumming for the simple protection.
> >
> > For example, I'd like to ask
> >
> > 'BASE 'router'
> > GET interface Serial*
> > '
> >
> > and get
> > ORIGIN router.interface.Serial1
> > in-packets: 223334 u32
> > in-errors: 1122 u23
> > in-bytes: 124563874 u64
> > ....
> > ORIGIN router.interface.Serial2
> > ....
> >
> > (1) TEXT mode, no terrible binary octets, etc etc;
> > (2) SIMPLE variables, withouth terrible MIB descriptions (they are not
> > usefull here);
> > (3) Another hierarchy (interface.variable, not variable.index)
> > (4) simple addition private variables
> >
> > CISCO.in-bad-frames: 223344
> > instead of (as now)
> >
> > vendor.cisco.mgrt....interface.lapsha-na-palochke.INDEX
> >
> > etc etc...
> >
> > And then, if the protocol (SNMP) is BAD, don't think the tools for this
> > protocol should be GOOD.
> >
> > // And compare this with the WEB interface implemented into some new
> > routers and switches - simple, robust, can be used easily, and 100 times
> > more flexible. Through it's only simple interfaces with the operator, not
> > for the tools, for now.
> >
> > Alex.
> >
> >
> >
> >
> >
> > On Wed, 9 Jun 1999, Scott Call wrote:
> >
> > > Date: Wed, 09 Jun 1999 12:51:33 -0700
> > > From: Scott Call <scall(a)devolution.com>
> > > To: nanog(a)merit.edu
> > > Subject: Re: HP Openview Slowness.
> > >
> > >
> > > "Alex P. Rudnev" wrote:
> > >
> > > > If you begin to use commercial soft after free one, then:
> > > > - don't drop free soft, ypu'll use it anyway;
> > >
> > > I know :) I'm doing HPOV because the 'suits' want a pretty network map on a projector
> > > somewhere. MRTG/etc will still be very present in the system :)
> > >
> > > > - increase memory, CPU and disk up to 2 - 4 times (if you had 64RAM,
> > > > install 512);
> > >
> > > Noted, thanks.
> > >
> > > > - be ready to be disappointed;
> > >
> > > :)
> > >
> > > > Through HP OV is not bad piece of software.
> > >
> > > It's not, but I am disappointed it's not more router-centric. I appreciate the need to
> > > monitor workstations, but I've got multitudes more network devices that workstations/servers.
> > >
> > > Thanks for all the responses everyone.
> > > -scott
> > >
> > > --
> > > -------------------------------------------------------------------------
> > > |Scott Call |"How could this be a problem in a country where |
> > > |Router Geek | we have Intel and Microsoft"-AlGore on y2 k |
> > > -------------------------------------------------------------------------
> > >
> > >
> > >
> > >
> > >
> >
> > Aleksei Roudnev, Network Operations Center, Relcom, Moscow
> > (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
> > (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
>
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
