[c-nsp] CISCO-BULK-FILE-MIB/CISCO-FTP-CLIENT-MIB

[Chris Roberts]

> Sent: 10 August 2005 12:31
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] CISCO-BULK-FILE-MIB/CISCO-FTP-CLIENT-MIB
> 
> I'm using these two MIBs to collect bulk statistics from some routers.
> 

Apologies for replying to self - I'm revisiting this SNMP problem and have
opened a TAC case but thought I'd post my findings investigating this here
and also ask again if anyone had any more experience with this? 

I've done a lot more testing and it seems that CISCO-BULK-FILE-MIB when used
with the default options in the Cisco example script does NOT actually write
the file until you start the FTP copy, and will generate the file on the fly
during the FTP. If you request the BULK-FILE MIB to write the file somewhere
else (e.g. flash: or ftp:) it WILL write the file when requested to, and it
appears to be this writing the MIB to some location that seems to be the
slow part. 

Actually copying the file once written to e.g. flash is very quick. Does
anyone know why committing this data (which can be perused quickly [sub 3-4
secs] using sh vpdn sess all, in my case) is so slow to be written to a
file? Could this be a bug in the BULK-FILE MIB, or is it writing to flash by
default (I couldn't find the /tmp referred to in the documentation) and
therefore is slow because of the flash speed?

Any help is appreciated. I think using Net::Telnet::Cisco sucks, but at the
moment it seems to be leagues faster than the BULK MIB. One thought I have
had is whether I can create a RAM disk or write to memory somehow with a
location: prefix to eliminate the flash from the equation? NVRam is pretty
full so that won't work :(

Cheers,
Chris.

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.14/129 - Release Date: 11/10/2005