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@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@devolution.com> To: nanog@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)