|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: [SNMP] Re: HP Openview Slowness.
I am not sure if CISCO support 'bgp_prefixes_per_peer' now, may be, yes already. But we had some comparasion: (1) To get ip accounting by SNMP, it takes 10 minutes. By 'telnet' - 4 srconds; (2) To get ip routing table by 'rsh' or 'telnet' (we use 'ciscotalk' tool with the 'send/expect pairs) you need 10 - 20 lines written by PERL and 1 sec or real time; to do it by SNMP - try yourself; (3) To get 'sh ip bgp sum' table by 'telnet' you need 1 second, by SNMP - try yourself (trough we poll BGP connections by SNMP); (4) TO get EVERYTHING about the interface, you can write 1 (ONE) request: 'rsh .... show interface Serial0'. How much requests and variables you should poll to do it by SNMP. How mach different MIB files you should drag through to do it by SNMP (and determine if this interface have Sync or Async mode in case of universal serial interface, for example). Etc etc... SNMP can work (just as LANE can work, H.323 can work); but it's an example of the wrong designes (except LANE) because there is ways to do it 100 - 200 times simpler (GET router.interface.Serial0.* , for example). Result: I need core BGP table from the router. Guess how I get it. By 'ciscotalk + show ip bgp routes', no doubt (I am not suicider to do it by SNMP). Through the HPOV is so huge not due to SNMP, I think, but due to attempt to join a lot of _useless usially_ features in the same software-box. Alex. > Date: Thu, 10 Jun 1999 08:57:07 -0400 (EDT) > From: Mike Heller <[email protected]> > To: "Alex P. Rudnev" <[email protected]> > Cc: Scott Call <[email protected]>, [email protected] > Subject: Re: [SNMP] Re: HP Openview Slowness. > > Even though I *hate* the products, I did have fantastic success pulling > snmp data from BayNetworks routers. I'm just as surprised as you that > cisco doesn't support bgp_prefixes_per_peer. I don't think you can blame > the protocol as vendors can implement extensions beyond the spec as they > please. > > REgards, > Mike > > On Thu, 10 Jun 1999, Alex P. Rudnev wrote: > > > > > 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 <[email protected]> > > > To: [email protected] > > > 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)
|