toasters

toasters@lists.teaparty.net

13515 discussions

Re: what data is being used?
by Mark D Simmons 29 Jun '98

29 Jun '98

I recall asking for this in an RFE sense a year ago as it would be incredibly useful. Sun just put the capability to track the load on disks at the partition level in Solaris 2.6 - this sort of stat on a filer would be just as useful IMHO Per quota tree seemed most natural to me as that is already a distinctive structure in filer housekeeping meta-data. Directory level gathering might be too much load to put on a filer which is meant to perform under high demand... ...how about an admin command that flips a bit on a directory and makes it a watchpoint in the filesystem - accesses against anything beneath it count on that directory's stats. Even if the total number of such points were limited to put a boundary on overhead in the filer, it would still be a useful analytical tool.

1 0

Zowie! He's using 4 TB!
by Brian Rice 26 Jun '98

26 Jun '98

Has anyone else seen this little sparkle in the output of quota report? user sairam 4294947972 5120000 4294967282 512000 This shows up intermittently after I move a user to the filer with a restore rfD - . As you might imagine, it prevents the user from writing. Workaround is quota off; quota on. This is on an F630 running 4.3.3. I haven't filed a bug report yet, though I will as soon as I have confidence that I can state the sequence of events that triggers this phenomenon. Just curious to see if anyone else had seen it. Brian Rice brice(a)gnac.com

2 1

what data is being used?
by Daniel Quinlan 26 Jun '98

26 Jun '98

Are there any tools to gauge NFS load (reads, writes, NFS ops, whatever), perhaps on a quota tree or directory level. Why would I want to know such a thing? Say I have an 200GB F540 filer with two large trees. And I just purchased a 200GB F630 filer. I want to move one of the trees, but not both. I want to move the busier one, not the other one. There are some basic things I've been looking at in the above situation, but maybe someone here knows about a better method/technique/tool. I hoping someone will mention such an obvious solution that I'll be glad I didn't mention what sort of thing I've been doing. :-) - Dan

1 0

Re: Making CIFS hidden files from unix
by Daniel Quinlan 26 Jun '98

26 Jun '98

Steve Losen <scl(a)sasha.acc.virginia.edu> writes: > When we add new user accounts to our NetApp, we don't know if the owner > will use CIFS, unix, or both. (We use unix file protection semantics.) So > we are going to put unix dot files in the new home directory. But it > would be nice to prevent or discourage CIFS users from deleting them -- in > particular the .forward file. We were thinking that if we could make the > dot files "hidden" and "system", that that would help, even though CIFS > users can override and see hidden files if they want. > > [...] > > Is this overly complex? Is there a simpler way? Yes. I think so. A simpler solution is to configure sendmail to look for .forward files somewhere other than home directories. We put all .forward files (as well as procmail stuff) in a centralized location (physically on the mail server). For example, /local/mail/<username>/.forward /local/mail can be (auto)mounted to allow editing on clients. You can put symbolic links in user home directories, and it won't matter if people delete the links. This also allows for faster and more reliable mail delivery since the .forward files are now located on the mail server. You don't need to worry about someone's home directory being unavailable. - Dan

1 0

Making CIFS hidden files from unix
by Steve Losen 25 Jun '98

25 Jun '98

When we add new user accounts to our NetApp, we don't know if the owner will use CIFS, unix, or both. (We use unix file protection semantics.) So we are going to put unix dot files in the new home directory. But it would be nice to prevent or discourage CIFS users from deleting them -- in particular the .forward file. We were thinking that if we could make the dot files "hidden" and "system", that that would help, even though CIFS users can override and see hidden files if they want. Our account adding software is on unix, and I think I have a way to do what I want. I'll make a "new user" prototype directory and set the unix permissions on the dot files, then get on a PC and set "hidden" and "system" on them. I'll use the netapp dump utility to dump the prototype dir to a file. When I create a user, I'll use the netapp restore to bring back the prototype directory, chown the files to the new user, overwrite the .forward, and mv the prototype into place as the user's home dir. This preserves any CIFS hidden attributes, I presume. It looks like restore always restores back to the original location of the dumped directory. Is it possible to get restore to restore elsewhere? We're running NetApp Release 4.3.1. Is this overly complex? Is there a simpler way? Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

2 1

Re: always safe to delete dump snapshots?
by Paul Albers 25 Jun '98

25 Jun '98

Dan and Bruce, This was bug #650 and has been fixed in all the OnTap OS releases since 4.3x. The request to delete this snapshot_for_dump.<num> will fail. -paul At 08:42 AM 6/25/98 -0500, you wrote: >On 06/25/98 01:38:27 you wrote: >> >>Is it always safe to attempt to delete a snapshot_for_dump.<num>? >> >>Another way to phrase my question -- it will *never* succeed when a >>dump is in progress, right? >> >>Yes, I know it's supposed to not succeed, but since I'm writing a >>program to automatically delete snapshots, I'm exercising more >>paranoia than usual. > >Well, there USED to be an old bug that's been around since the >beginning that trying to delete one while a dump was in progress >would crash the filer. This bug was even mentioned in bold >letters in the admin guide (either in the snapshot or the dump >sections). Assuming they've fixed it to do what you say, then >you're correct. > >If they haven't, then you don't want to automatically delete those >files, unless you have some way of knowing ahead of time that they >are no longer associated with a dump process (say, one that failed >in some ungraceful way). Since this usually happened because of a >crash, one thing I used to do was include an automatic snap delete >at the end of the rc file to delete the snapshot_for_dump after the >filer had started up. The appearance of the snapshot_for_dump.n >mechanism broke that... I made the suggestion that having the OS >automatically delete those might be a good idea, but on the other >hand it might not... the user may really want to restart the >backup off that old image, rather than taking a new one right at >that moment. > >Bruce > > >

1 0

Re: always safe to delete dump snapshots?
by varun＠netapp.com 25 Jun '98

25 Jun '98

> From sirbruce(a)ix.netcom.com Thu Jun 25 06:45:51 1998 ... > Well, there USED to be an old bug that's been around since the > beginning that trying to delete one while a dump was in progress > would crash the filer. This bug was even mentioned in bold > letters in the admin guide (either in the snapshot or the dump > sections). Assuming they've fixed it to do what you say, then > you're correct. > This is bug 650. Fixed since release 4.2. You should get a "Snapshot in use by dump." message if you attempt to delete a snapshot that's being dumped.

1 0

Re: always safe to delete dump snapshots?
by sirbruce＠ix.netcom.com 25 Jun '98

25 Jun '98

On 06/25/98 01:38:27 you wrote: > >Is it always safe to attempt to delete a snapshot_for_dump.<num>? > >Another way to phrase my question -- it will *never* succeed when a >dump is in progress, right? > >Yes, I know it's supposed to not succeed, but since I'm writing a >program to automatically delete snapshots, I'm exercising more >paranoia than usual. Well, there USED to be an old bug that's been around since the beginning that trying to delete one while a dump was in progress would crash the filer. This bug was even mentioned in bold letters in the admin guide (either in the snapshot or the dump sections). Assuming they've fixed it to do what you say, then you're correct. If they haven't, then you don't want to automatically delete those files, unless you have some way of knowing ahead of time that they are no longer associated with a dump process (say, one that failed in some ungraceful way). Since this usually happened because of a crash, one thing I used to do was include an automatic snap delete at the end of the rc file to delete the snapshot_for_dump after the filer had started up. The appearance of the snapshot_for_dump.n mechanism broke that... I made the suggestion that having the OS automatically delete those might be a good idea, but on the other hand it might not... the user may really want to restart the backup off that old image, rather than taking a new one right at that moment. Bruce

1 0

always safe to delete dump snapshots?
by Daniel Quinlan 25 Jun '98

25 Jun '98

Is it always safe to attempt to delete a snapshot_for_dump.<num>? Another way to phrase my question -- it will *never* succeed when a dump is in progress, right? Yes, I know it's supposed to not succeed, but since I'm writing a program to automatically delete snapshots, I'm exercising more paranoia than usual. Thanks. - Dan

1 0

NFS performance question
by Alexei Rodriguez 24 Jun '98

24 Jun '98

Hey folks. I have a PII-400 machine running Solaris x86 2.6 which is using the dnet0 interface (built in interface on the motherboard) for the mounts. The mount that is giving us some problems is off of a f630 running 4.3.4D5 over gigabit. The PII has a 10/100 interface (adaptec I believe). The behavior I am seeing is as follows: - large file ops (like cat /dev/zero > foo) are bursty - iostat shows the filer 100% busy but the filer is not breaking a sweat. The stats: root@sealion:~/ # iostat -xn 2 extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 fd0 1.9 0.6 18.5 4.0 0.0 0.0 17.8 10.5 0 2 c0t0d0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 4.5 0 0 maytag:/home 0.0 0.0 0.0 0.0 0.0 0.0 0.0 27.9 0 0 maytag:/export/cim 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/httpd 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/logarchive 0.0 41.8 0.0 331.8 660.8 3.1 15796.9 74.4 20 62 whirlpool:/export/c0 0.0 0.0 0.4 0.0 0.0 0.0 0.1 94.9 0 0 maytag:/export/depot/col.x86-solaris26 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sealion:vold(pid261) extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 fd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t0d0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/home 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/cim 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/httpd 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/logarchive 0.0 0.0 0.0 0.0 0.0 4.0 0.0 0.0 0 100 whirlpool:/export/c0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/depot/col.x86-solaris26 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sealion:vold(pid261) extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 fd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t0d0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/home 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/cim 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/httpd 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/logarchive 0.0 0.0 0.0 0.0 0.0 4.0 0.0 0.0 0 100 whirlpool:/export/c0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/depot/col.x86-solaris26 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sealion:vold(pid261) ^C root@sealion:~/ # root@sealion:~/ # nfsstat -m /content from whirlpool:/export/c0 Flags: vers=3,proto=udp,sec=sys,hard,intr,link,symlink,rsize=8192,wsize=8192,retrans=5 Lookups: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms) Reads: srtt=2 (5ms), dev=2 (10ms), cur=1 (20ms) Writes: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms) All: srtt=7 (17ms), dev=3 (15ms), cur=2000 (40000ms) I was just wondering if anybody else had seen this sort of behavior on their end. I suspect this is hardware on my end (cable, card, etc) but swapping has not helped. Thanks. Alexei

1 0

Re: 'quota resize' - any way around it ?
by sirbruce＠ix.netcom.com 22 Jun '98

22 Jun '98

On 06/22/98 13:44:18 you wrote: >- just accept the fact that NetApp doesn't consider this wish to very >important and turn the quotas on/off as often as is feasible. So long as once/day was acceptable, this is what I would do. But if not, then... >- preload the /etc/quotas file with entries for all possible UIDs, then >just change the quota as they request it. This way the /etc/quotas will >always be the same length and contain the same number of users. ... this is probably what I would do. Assuming that's not too many UIDs that it's computationally expensive. Depending on how many users I expect to reasonably have, I might start with a smaller number and then add new ones in blocks ahead of their actual use (and then do a quota off/on that night). Bruce

1 0

Re: ATM and Fore SPANS failover
by Barbara Naden 18 Jun '98

18 Jun '98

At 10:35 PM 6/17/98 -0400, David B. Ritch wrote: >Actually, etherchannel is supported by Sun, Auspex, and Cisco. There >may be others, but those are the one that I know of. > >David Ritch > EtherChannel support is in the DATAOntap 5.1 release and is currently in external test. Barbara Naden >Alexei Rodriguez wrote: >[...] >> Sounds like etherchannel... I think Alteon was trying this with their Gigabit >> stuff; unfortunately, no other vendor supports this feature. > >

1 0

Re: CIFS file locking
by Paul Albers 18 Jun '98

18 Jun '98

Michael, You can also use "cifs sessions *" to see all the files that are open/locked by all the users. One limitation of this command is that it is not available to 'rsh'. So, you would have to run this from a telnet session and weed through the output, or capture the console output to a file that you could then parse for the file. Regards, Paul Albers At 12:31 PM 6/18/98 +0100, you wrote: >I think the command "cifs cessions username" does what you want: > >toaster> cifs sessions >Server Registers as 'TOASTER' in group 'NETAPP' >UNIX compatible Access Control is being used >Using the UNIX password database for authentication >======================================== >PC (user) #shares #files >ANDREW (abond) 1 1 >toaster> cifs sessions andrew > >users > shares/files opened > >ANDREW (abond) > HOME > Read-denyN - \ajb.1 > >Also, from release 5.1 (due later this month) you can see this information >from the NT Server Manager (In Use button). > >Regards, >Andrew Bond, UK Systems Engineer > >At 11:29 am 17-06-98 -0700, you wrote: >>I know that spreedsheet applications opened from the PC create >>a lock on that file that prevents all other access. But is there some >>way to find out who has that particular file open? >> >>On the toaster, I can find who has files opened - but that doesn't >>help much. >> >>This spreedsheet data was migrated from Novel. On Novel, you >>have the ability to see who has what file opened. >> >>Any ideas? >> >> >>-- >> ------------------------------------------------------------------------ >> >> Michael McBride CommQuest Technologies,Inc. >> >> Senior Unix Administrator 527 Encinitas Boulevard >> >> mcbride(a)CommQuest.com Encinitas, CA. 92024-3740 >> >> Voice: (760) 634-6239 Fax: (760) 634-6138 >> >> >> >> >> > >

1 0

CIFS file locking
by Mike McBride 18 Jun '98

18 Jun '98

I know that spreedsheet applications opened from the PC create a lock on that file that prevents all other access. But is there some way to find out who has that particular file open? On the toaster, I can find who has files opened - but that doesn't help much. This spreedsheet data was migrated from Novel. On Novel, you have the ability to see who has what file opened. Any ideas? -- ------------------------------------------------------------------------ Michael McBride CommQuest Technologies,Inc. Senior Unix Administrator 527 Encinitas Boulevard mcbride(a)CommQuest.com Encinitas, CA. 92024-3740 Voice: (760) 634-6239 Fax: (760) 634-6138

2 1

Re: posting history - who's wordy and who's quiet?
by sirbruce＠ix.netcom.com 18 Jun '98

18 Jun '98

On 06/17/98 14:07:10 you wrote: > >i was looking for a reason to have fun with perl modules for chopping up >email addresses, so here's the prolixity summary for the lifetime of the >list. i've cut-off at ten posts. > > 99 Brian Tao > 86 sirbruce(a)ix.netcom.com > 16 Bruce Sterling Woodcock Actually, if you combine mine, I managed to narrow out Brian for a minor (pyrrhic?) victory. Bruce

1 0

ATM and Fore SPANS failover
by Scott Miller 18 Jun '98

18 Jun '98

This is actually a request/question for netapp, but I'm hoping to generate a few "me too"'s from the list. We're a large (1200 systems) ATM shop. For various reasons, we're using Fore SPANS signalling, and will be for awhile. The move to standards-based ATM is going to be ugly, and we (and the standards) aren't quite ready yet. NetApp supports SPANS ATM, using Fore's PCI card and a port of the SPANS protocol engine in their ATM drivers. This is good. But, there are two features of Fore SPANS that NetApp doesn't support, that we rely on. This message is a request to NetApp to consider adding support for these two features: 1. load balancing. Fore SPANS on other platforms (IRIX, Solaris) provides interface aggregation such that multiple ATM interfaces on the same host are used equally. This is connection-based load balancing, in that new connections are assigned round-robin to all the interfaces in a given load balance group, on a given machine. On some platforms, all interfaces in a given system can have the same IP address, which simplifies management, and means there is one "view" of a multi-interface machine from the outside. Routing gets simpler, too. We can get some balancing using static routing configuations that spreads the load over all the interfaces in a system, but it's not quite the same. Plus, support for load balancing may help provide support for: 2. fail over. If an interface, or switch fabric, or other component fails, Fore SPANS will fail an interface, and all the connections will be re-established on the other available interfaces. Our core switch architecture is such that each server has multiple ATM "feet", in different switches and backplanes, so we've got fault tolerance with automatic failover when somthing in the network path croaks. It's the failover that we're most interested in, for the fault tolerance and redundancy reasons. load balancing makes administration easier, and helps us better utilize the switch architecture we have in place. So, NetApp, what are the chances of getting SPANS fail over and load balancing in your ATM implementation? -Skottie -- ----- Scott Miller | Walt Disney Feature Animation skottie(a)fa.disney.com | Digital Studio Technology

3 2

NetApp Gigabit Ethernet
by Daniel Quinlan 18 Jun '98

18 Jun '98

I have some questions about the NetApp Gigabit implementation, perhaps someone from NetApp could answer. 1. Throughput numbers for various filers and releases? 2. Total bandwidth using one gigabit vs. multiple fast ethernet (subnets) (we have filers with up to 8 fast ethernet interfaces) 3. Bonding channels - fast ethernet, gigabit ethernet 4. Jumbo frames? 5. Tested with which switches? 6. Anything else I should ask? This is off the top of my head, so I probably will have some more questions later. :-) Thanks. - Dan

1 0

Re: ATM and Fore SPANS failover
by Scott Miller 18 Jun '98

18 Jun '98

On Jun 17, 4:14pm, Alexei Rodriguez wrote: > Subject: Re: ATM and Fore SPANS failover > +--- In a previous state of mind, Scott Miller <skottie(a)fa.disney.com> wrote: > | > | On some platforms, all interfaces in a given system can have the same IP > | address, which simplifies management, and means there is one "view" > | of a multi-interface machine from the outside. Routing gets simpler, too. > > Sounds like etherchannel... I think Alteon was trying this with their Gigabit > stuff; unfortunately, no other vendor supports this feature. SGI is working on interface aggregation for 100baseT, but nothing is released yet. SGI's SPANS implementation does this, but it is connection-based load balancing, not traffic based. We've also talked with SGI about doing this for TCP/IP over HIPPI, but we haven't heard anything back. For Solaris systems, the ATM interfaces have seperate IP addresses, and the device driver re-directs VC's across both interfaces, independent of the IP layer routing. it's kind of funky, but it does provide load balancing and failover. > I had always wondered if anybody was using (packet-slicing) ATM for their > filers. What sort of performance are you getting? We're not using packet slicing, just two interfaces, each on a different subnet. I can get 11 MB/sec per interface sustained read, using two interfaces in a fibrechannel F630. For sustained writes, the F630 pegs the CPU at 100% at 12 MB/sec across both interfaces. -Skottie -- ----- Scott Miller | Walt Disney Feature Animation skottie(a)fa.disney.com | Digital Studio Technology

1 0

Re: Solaris ACLs
by sirbruce＠ix.netcom.com 17 Jun '98

17 Jun '98

On 06/16/98 15:24:59 you wrote: > >i asked netapp if Solaris ACLs were either implemented or planned in >ONTAP, and got a fast, polite, unqualified no. > >does anyone else out there have any interest in ACLs of any flavour other >than NT? (i'd like Solaris ACLs, in case that's unclear). I'd like to see them support all the different ACL types, Solaris, NT, Digital Unix, Irix, etc. (at least, I think the latter two have them) and have them all interoperate reasonably well. But that's no doubt a big undertaking for Netapp with very little return. It might make more sense is to wait on a standard ACL protocol (maybe as part of NFS v4) and then implement that and everyone will talk the same language. Bruce

2 1

Solaris ACLs
by Tom Yates 16 Jun '98

16 Jun '98

i asked netapp if Solaris ACLs were either implemented or planned in ONTAP, and got a fast, polite, unqualified no. does anyone else out there have any interest in ACLs of any flavour other than NT? (i'd like Solaris ACLs, in case that's unclear). Tom Yates - Unix Chap - The Mathworks, Inc. - +1 (508) 647 7561 MAG#65061 DoD#0135 AMA#461546 1024/CFDFDE39 0C E7 46 60 BB 96 87 05 04 BD FB F8 BB 20 C1 8C

1 0

Subscription
by Wm Kevin Shaw 12 Jun '98

12 Jun '98

How can I subscribe to this group? -- ======================================================================= _/_/_/_/ _/_/_/_/ _/ _/ Wm Kevin Shaw - MS: ESAE-222 _/ _/ _/ _/ _/ The Document Company, XEROX _/ _/_/_/_/_/ _/_/ 701 South Aviation Boulevard _/ _/ _/ _/ _/ El Segundo, California 90245 _/_/_/_/ _/ _/ _/ _/ Phone: 310.333.5991 FAX : 310.333.6350 CAX Systems Support EMail: wkshaw(a)cax.es.xerox.com ========================================================================

1 0

Re: filer-mrtg question
by Darrell Root 12 Jun '98

12 Jun '98

Mark Simmons wrote: > What it practically means to me is that the MIB is large and I'm not very > good at reading it. SNMP's umpteen different representations and translations > are also causing me grief. Perhaps this will help. I did a snmpwalk on my ONTAP4 filer, and went through the MIB definitions and wrote notes on what a bunch of stuff meant. I've put the snmpwalk output and my notes below. Share and enjoy! ONTAP5 will probably be different due to the multi-volume support. Your tables will also be slightly different due to the number of network interfaces. I'm currently using the following information: 1) Network interface traffic (1:public@fs12) 2) Disk space total and disk space used (1.3.6.1.4.1.789.1.5.4.1.4.1&1.3.6.1.4.1.789.1.5.4.1.3.1:public@fs11) 3) Current CPU percentage (via a script {see TIMETICKS discussion below}: 1.3.6.1.4.1.789.1.2.1.2.0 and 1.3.6.1.4.1.789.1.2.1.4.0 {cpu busy and cpu idle respectively}) 4) NFS ops (1.3.6.1.4.1.789.1.2.2.1.0&1.3.6.1.4.1.789.1.2.2.1.0:public@fs11) All in all a pretty good set of metrics that tells me when I need more CPU, when I need more networks, and when I need more disk space. All I'm missing is inodes (due to my lazyness) and response time (because I can't get that info this way). The only other note is that MRTG has trouble monitoring stuff of datatype TIMETICKS because the snmp module included with mrtg interprets that as an uptime statistic, and converts the timeticks into a "up 3 days 4 hours 21 minutes" string. Needless to say, when mrtg puts that into the logfile and then tries to read the logfile it says "logfile corrupt". Rather than get the CPU uptime information in TIMETICKS directly via snmp, I just put a perl script in my mrtg.conf file (inside backticks). The perl script does that one query for me. Later! Darrell Root rootd(a)nas.nasa.gov 1.3.6.1.2.1.1.1.0: OCTET STRING: NetApp Release 4.2a: Fri Sep 5 09:36:36 PDT 199 (textual entity description) 1.3.6.1.2.1.1.2.0: OBJECT IDENTIFIER: 1.3.6.1.4.1.789.1.1.1 (MIB number) 1.3.6.1.2.1.1.3.0: TIMETICKS: 1016120955 (uptime for snmp subsystem) 1.3.6.1.2.1.1.4.0: OCTET STRING: rootd(a)nas.nasa.gov (contact person) 1.3.6.1.2.1.1.5.0: OCTET STRING: fs12.nas.nasa.gov (hostname) 1.3.6.1.2.1.1.6.0: OCTET STRING: INA 258, Rm. 230 (physical location) 1.3.6.1.2.1.1.7.0: INTEGER: 72 (services provided hashcode {64+8->???) 1.3.6.1.2.1.2.1.0: INTEGER: 5 (number of net interfaces) 1.3.6.1.2.1.2.2.1.1.1: INTEGER: 1 (unique number for each interface) 1.3.6.1.2.1.2.2.1.1.2: INTEGER: 2 1.3.6.1.2.1.2.2.1.1.3: INTEGER: 3 1.3.6.1.2.1.2.2.1.1.4: INTEGER: 4 1.3.6.1.2.1.2.2.1.1.5: INTEGER: 5 1.3.6.1.2.1.2.2.1.2.1: OCTET STRING: fi0 (text string for each interface) 1.3.6.1.2.1.2.2.1.2.2: OCTET STRING: ns0 1.3.6.1.2.1.2.2.1.2.3: OCTET STRING: ns1 1.3.6.1.2.1.2.2.1.2.4: OCTET STRING: lo 1.3.6.1.2.1.2.2.1.2.5: OCTET STRING: vh 1.3.6.1.2.1.2.2.1.3.1: INTEGER: 15 (interface type 15=fddi) 1.3.6.1.2.1.2.2.1.3.2: INTEGER: 6 1.3.6.1.2.1.2.2.1.3.3: INTEGER: 6 (interface type 6=10bt ethernet) 1.3.6.1.2.1.2.2.1.3.4: INTEGER: 24 (interface type 24=loopback) 1.3.6.1.2.1.2.2.1.3.5: INTEGER: 24 1.3.6.1.2.1.2.2.1.4.1: INTEGER: 4352 (interface MTU) 1.3.6.1.2.1.2.2.1.4.2: INTEGER: 1500 1.3.6.1.2.1.2.2.1.4.3: INTEGER: 1500 1.3.6.1.2.1.2.2.1.4.4: INTEGER: 1536 1.3.6.1.2.1.2.2.1.4.5: INTEGER: 1536 1.3.6.1.2.1.2.2.1.5.1: GAUGE: 100000000 (interface speed in bits/sec) 1.3.6.1.2.1.2.2.1.5.2: GAUGE: 10000000 1.3.6.1.2.1.2.2.1.5.3: GAUGE: 10000000 1.3.6.1.2.1.2.2.1.5.4: GAUGE: 0 1.3.6.1.2.1.2.2.1.5.5: GAUGE: 0 1.3.6.1.2.1.2.2.1.6.1: OCTET STRING: 00 40 0B 40 2E 96 (MAC address) 1.3.6.1.2.1.2.2.1.6.2: OCTET STRING: 00 C0 F0 01 0A 75 1.3.6.1.2.1.2.2.1.6.3: OCTET STRING: 00 C0 F0 01 0B 27 1.3.6.1.2.1.2.2.1.6.4: OCTET STRING: 00 00 00 00 1.3.6.1.2.1.2.2.1.6.5: OCTET STRING: 00 00 00 00 1.3.6.1.2.1.2.2.1.7.1: INTEGER: 1 (desired if state 1=up,2=down,3=testing) 1.3.6.1.2.1.2.2.1.7.2: INTEGER: 1 1.3.6.1.2.1.2.2.1.7.3: INTEGER: 1 1.3.6.1.2.1.2.2.1.7.4: INTEGER: 2 1.3.6.1.2.1.2.2.1.7.5: INTEGER: 2 1.3.6.1.2.1.2.2.1.8.1: INTEGER: 1 (actual if state 1=up,2=down,3=testing) 1.3.6.1.2.1.2.2.1.8.2: INTEGER: 2 1.3.6.1.2.1.2.2.1.8.3: INTEGER: 2 1.3.6.1.2.1.2.2.1.8.4: INTEGER: 1 1.3.6.1.2.1.2.2.1.8.5: INTEGER: 1 1.3.6.1.2.1.2.2.1.9.1: TIMETICKS: 0 (sysuptime value when if went up) 1.3.6.1.2.1.2.2.1.9.2: TIMETICKS: 0 1.3.6.1.2.1.2.2.1.9.3: TIMETICKS: 0 1.3.6.1.2.1.2.2.1.9.4: TIMETICKS: 0 1.3.6.1.2.1.2.2.1.9.5: TIMETICKS: 0 1.3.6.1.2.1.2.2.1.10.1: COUNTER: 4133664568 (total octets received since uptime) 1.3.6.1.2.1.2.2.1.10.2: COUNTER: 477912285 1.3.6.1.2.1.2.2.1.10.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.10.4: COUNTER: 40 1.3.6.1.2.1.2.2.1.10.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.11.1: COUNTER: 320479142 (total unicast packets delivered upwards) 1.3.6.1.2.1.2.2.1.11.2: COUNTER: 24123 1.3.6.1.2.1.2.2.1.11.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.11.4: COUNTER: 1 1.3.6.1.2.1.2.2.1.11.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.12.1: COUNTER: 10896971 (total non-uni packets delivered upward) 1.3.6.1.2.1.2.2.1.12.2: COUNTER: 17635146 1.3.6.1.2.1.2.2.1.12.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.12.4: COUNTER: 0 1.3.6.1.2.1.2.2.1.12.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.13.1: COUNTER: 0 (total inbound packets discarded) 1.3.6.1.2.1.2.2.1.13.2: COUNTER: 0 1.3.6.1.2.1.2.2.1.13.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.13.4: COUNTER: 0 1.3.6.1.2.1.2.2.1.13.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.14.1: COUNTER: 0 (total inbound packets with errors) 1.3.6.1.2.1.2.2.1.14.2: COUNTER: 796 1.3.6.1.2.1.2.2.1.14.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.14.4: COUNTER: 0 1.3.6.1.2.1.2.2.1.14.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.15.1: COUNTER: 0 (total unknown packet types received) 1.3.6.1.2.1.2.2.1.15.2: COUNTER: 0 1.3.6.1.2.1.2.2.1.15.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.15.4: COUNTER: 0 1.3.6.1.2.1.2.2.1.15.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.16.1: COUNTER: 1248824778 (total octets transmitted) 1.3.6.1.2.1.2.2.1.16.2: COUNTER: 5156203 1.3.6.1.2.1.2.2.1.16.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.16.4: COUNTER: 40 1.3.6.1.2.1.2.2.1.16.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.17.1: COUNTER: 334377489 (total unicast packets transmitted) 1.3.6.1.2.1.2.2.1.17.2: COUNTER: 37566 1.3.6.1.2.1.2.2.1.17.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.17.4: COUNTER: 1 1.3.6.1.2.1.2.2.1.17.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.18.1: COUNTER: 0 (total broadcast packets trans) 1.3.6.1.2.1.2.2.1.18.2: COUNTER: 0 (note caused by higher level protocols only) 1.3.6.1.2.1.2.2.1.18.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.18.4: COUNTER: 0 1.3.6.1.2.1.2.2.1.18.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.19.1: COUNTER: 0 (total outbound packets discarded) 1.3.6.1.2.1.2.2.1.19.2: COUNTER: 0 1.3.6.1.2.1.2.2.1.19.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.19.4: COUNTER: 0 1.3.6.1.2.1.2.2.1.19.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.20.1: COUNTER: 0 (total outbound packets dropped due to errors) 1.3.6.1.2.1.2.2.1.20.2: COUNTER: 4 1.3.6.1.2.1.2.2.1.20.3: COUNTER: 0 1.3.6.1.2.1.2.2.1.20.4: COUNTER: 0 1.3.6.1.2.1.2.2.1.20.5: COUNTER: 0 1.3.6.1.2.1.2.2.1.21.1: GAUGE: 0 (length of output packet queue) 1.3.6.1.2.1.2.2.1.21.2: GAUGE: 0 1.3.6.1.2.1.2.2.1.21.3: GAUGE: 0 1.3.6.1.2.1.2.2.1.21.4: GAUGE: 0 1.3.6.1.2.1.2.2.1.21.5: GAUGE: 0 1.3.6.1.2.1.3.1.1.1.1.1.129.99.142.1: INTEGER: 1 (ARP table starts) 1.3.6.1.2.1.3.1.1.1.1.1.129.99.142.254: INTEGER: 1 1.3.6.1.2.1.3.1.1.2.1.1.129.99.142.1: OCTET STRING: 08 00 20 7A 76 F5 1.3.6.1.2.1.3.1.1.2.1.1.129.99.142.254: OCTET STRING: 00 00 A2 00 F8 06 1.3.6.1.2.1.3.1.1.3.1.1.129.99.142.1: IP ADDRESS: 129.99.142.1 1.3.6.1.2.1.3.1.1.3.1.1.129.99.142.254: IP ADDRESS: 129.99.142.254 (end ARP table) 1.3.6.1.2.1.4.1.0: INTEGER: 2 (ip gateway? 1=yes, 2=no) 1.3.6.1.2.1.4.2.0: INTEGER: 64 (default IP time-to-live number) 1.3.6.1.2.1.4.3.0: COUNTER: 346450714 (total input datagrams) 1.3.6.1.2.1.4.4.0: COUNTER: 2 (input datagrams with ip header errors) 1.3.6.1.2.1.4.5.0: COUNTER: 6 (input datagrams with wrong destination) 1.3.6.1.2.1.4.6.0: COUNTER: 0 (datagrams source routed through thi s host) 1.3.6.1.2.1.4.7.0: COUNTER: 13305421 (input datagrams of unknown protocol) 1.3.6.1.2.1.4.8.0: COUNTER: 0 (IP datagrams discarded due to resources) 1.3.6.1.2.1.4.9.0: COUNTER: 346450719 (total successfully delivered datagrams) 1.3.6.1.2.1.4.10.0: COUNTER: 321960220 (total outbound datagrams) 1.3.6.1.2.1.4.11.0: COUNTER: 0 (output datagrams discarded due to no route) 1.3.6.1.2.1.4.12.0: COUNTER: 6 (unroutable outbound packets discarded) 1.3.6.1.2.1.4.13.0: INTEGER: 60 (max seconds fragments held for reassembly) 1.3.6.1.2.1.4.14.0: COUNTER: 6080305 (number of ip fragments needing reassembly) 1.3.6.1.2.1.4.15.0: COUNTER: 6080305 (number of ip fragments successfully reassembled) 1.3.6.1.2.1.4.16.0: COUNTER: 213 (number of ip reassembly algorightm failures) 1.3.6.1.2.1.4.17.0: COUNTER: 12382739 (number of ip datagrams successfully fragmented) 1.3.6.1.2.1.4.18.0: COUNTER: 0 (number of ip datagrams discarded because theycouldn't be fragmented) 1.3.6.1.2.1.4.19.0: COUNTER: 12382739 (number ip datagram fragments generated)j 1.3.6.1.2.1.4.20.1.1.129.99.23.12: IP ADDRESS: 129.99.23.12 (ip address) 1.3.6.1.2.1.4.20.1.1.129.99.142.12: IP ADDRESS: 129.99.142.12 1.3.6.1.2.1.4.20.1.2.129.99.23.12: INTEGER: 2 (interface index) 1.3.6.1.2.1.4.20.1.2.129.99.142.12: INTEGER: 1 1.3.6.1.2.1.4.20.1.3.129.99.23.12: IP ADDRESS: 255.255.255.0 (netmask) 1.3.6.1.2.1.4.20.1.3.129.99.142.12: IP ADDRESS: 255.255.255.0 1.3.6.1.2.1.4.20.1.4.129.99.23.12: INTEGER: 0 (broadcast least significant biig) 1.3.6.1.2.1.4.20.1.4.129.99.142.12: INTEGER: 0 (WRONG, it's 1 not 0!!!) 1.3.6.1.2.1.4.20.1.5.129.99.23.12: INTEGER: 0 (largest ip datagram that can be reassembled) 1.3.6.1.2.1.4.20.1.5.129.99.142.12: INTEGER: 0 Here is the current routing table on this box for reference when reading the routing table below... Internet: Destination Gateway Flags Refs Use Interface default 129.99.142.254 UG 11 2218147 fi0 127.0.0.1 127.0.0.1 UH 0 1 lo 129.99.142/24 link#1 UC 0 0 fi0 129.99.142.1 8:0:20:7a:76:f5 UHL 2 159 fi0 129.99.142.254 0:0:a2:0:f8:6 UHL 1 0 fi0 1.3.6.1.2.1.4.21.1.1.0.0.0.0: IP ADDRESS: 0.0.0.0 (IP ROUTING TABLE STARTS) 1.3.6.1.2.1.4.21.1.1.127.0.0.1: IP ADDRESS: 127.0.0.1 (IP Addresses) 1.3.6.1.2.1.4.21.1.1.129.99.142.0: IP ADDRESS: 129.99.142.0 1.3.6.1.2.1.4.21.1.1.129.99.142.1: IP ADDRESS: 129.99.142.1 1.3.6.1.2.1.4.21.1.1.129.99.142.254: IP ADDRESS: 129.99.142.254 1.3.6.1.2.1.4.21.1.2.0.0.0.0: INTEGER: 1 (Route interface index) 1.3.6.1.2.1.4.21.1.2.127.0.0.1: INTEGER: 4 1.3.6.1.2.1.4.21.1.2.129.99.142.0: INTEGER: 1 1.3.6.1.2.1.4.21.1.2.129.99.142.1: INTEGER: 1 1.3.6.1.2.1.4.21.1.2.129.99.142.254: INTEGER: 1 1.3.6.1.2.1.4.21.1.3.0.0.0.0: INTEGER: 1 (route metric 1) 1.3.6.1.2.1.4.21.1.3.127.0.0.1: INTEGER: 0 1.3.6.1.2.1.4.21.1.3.129.99.142.0: INTEGER: 0 1.3.6.1.2.1.4.21.1.3.129.99.142.1: INTEGER: 0 1.3.6.1.2.1.4.21.1.3.129.99.142.254: INTEGER: 0 1.3.6.1.2.1.4.21.1.4.0.0.0.0: INTEGER: -1 (route metric 2) 1.3.6.1.2.1.4.21.1.4.127.0.0.1: INTEGER: -1 1.3.6.1.2.1.4.21.1.4.129.99.142.0: INTEGER: -1 1.3.6.1.2.1.4.21.1.4.129.99.142.1: INTEGER: -1 1.3.6.1.2.1.4.21.1.4.129.99.142.254: INTEGER: -1 1.3.6.1.2.1.4.21.1.5.0.0.0.0: INTEGER: -1 (route metric 3) 1.3.6.1.2.1.4.21.1.5.127.0.0.1: INTEGER: -1 1.3.6.1.2.1.4.21.1.5.129.99.142.0: INTEGER: -1 1.3.6.1.2.1.4.21.1.5.129.99.142.1: INTEGER: -1 1.3.6.1.2.1.4.21.1.5.129.99.142.254: INTEGER: -1 1.3.6.1.2.1.4.21.1.6.0.0.0.0: INTEGER: -1 (route metric 4) 1.3.6.1.2.1.4.21.1.6.127.0.0.1: INTEGER: -1 1.3.6.1.2.1.4.21.1.6.129.99.142.0: INTEGER: -1 1.3.6.1.2.1.4.21.1.6.129.99.142.1: INTEGER: -1 1.3.6.1.2.1.4.21.1.6.129.99.142.254: INTEGER: -1 1.3.6.1.2.1.4.21.1.7.0.0.0.0: IP ADDRESS: 129.99.142.254 (route next hop) 1.3.6.1.2.1.4.21.1.7.127.0.0.1: IP ADDRESS: 127.0.0.1 1.3.6.1.2.1.4.21.1.7.129.99.142.0: IP ADDRESS: 15.0.0.0 1.3.6.1.2.1.4.21.1.7.129.99.142.1: IP ADDRESS: 15.0.6.0 1.3.6.1.2.1.4.21.1.7.129.99.142.254: IP ADDRESS: 15.0.6.0 1.3.6.1.2.1.4.21.1.8.0.0.0.0: INTEGER: 4 (route type) 1.3.6.1.2.1.4.21.1.8.127.0.0.1: INTEGER: 3 (3=direct; 4=indirect) 1.3.6.1.2.1.4.21.1.8.129.99.142.0: INTEGER: 3 1.3.6.1.2.1.4.21.1.8.129.99.142.1: INTEGER: 3 1.3.6.1.2.1.4.21.1.8.129.99.142.254: INTEGER: 3 1.3.6.1.2.1.4.21.1.9.0.0.0.0: INTEGER: 2 (route protocol) 1.3.6.1.2.1.4.21.1.9.127.0.0.1: INTEGER: 2 (2=local entries{static?}) 1.3.6.1.2.1.4.21.1.9.129.99.142.0: INTEGER: 2 (3=set with net manage protocol) 1.3.6.1.2.1.4.21.1.9.129.99.142.1: INTEGER: 2 (4=icmp redirect) 1.3.6.1.2.1.4.21.1.9.129.99.142.254: INTEGER: 2 (8=rip; 5=egp) 1.3.6.1.2.1.4.21.1.10.0.0.0.0: INTEGER: 0 (route age in secondds) 1.3.6.1.2.1.4.21.1.10.127.0.0.1: INTEGER: 0 1.3.6.1.2.1.4.21.1.10.129.99.142.0: INTEGER: 0 1.3.6.1.2.1.4.21.1.10.129.99.142.1: INTEGER: 0 1.3.6.1.2.1.4.21.1.10.129.99.142.254: INTEGER: 0 1.3.6.1.2.1.4.21.1.11.0.0.0.0: IP ADDRESS: 0.0.0.0 (route mask) 1.3.6.1.2.1.4.21.1.11.127.0.0.1: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.4.21.1.11.129.99.142.0: IP ADDRESS: 255.255.255.0 1.3.6.1.2.1.4.21.1.11.129.99.142.1: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.4.21.1.11.129.99.142.254: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.4.21.1.12.0.0.0.0: INTEGER: -1 (route metric 5) 1.3.6.1.2.1.4.21.1.12.127.0.0.1: INTEGER: -1 1.3.6.1.2.1.4.21.1.12.129.99.142.0: INTEGER: -1 1.3.6.1.2.1.4.21.1.12.129.99.142.1: INTEGER: -1 1.3.6.1.2.1.4.21.1.12.129.99.142.254: INTEGER: -1 1.3.6.1.2.1.4.21.1.13.0.0.0.0: OBJECT IDENTIFIER: 0 (route info) 1.3.6.1.2.1.4.21.1.13.127.0.0.1: OBJECT IDENTIFIER: 0 (for specific MIB) 1.3.6.1.2.1.4.21.1.13.129.99.142.0: OBJECT IDENTIFIER: 0 1.3.6.1.2.1.4.21.1.13.129.99.142.1: OBJECT IDENTIFIER: 0 1.3.6.1.2.1.4.21.1.13.129.99.142.254: OBJECT IDENTIFIER: 0 1.3.6.1.2.1.4.22.1.1.129.99.23.12: INTEGER: 2 (interface number for this table) 1.3.6.1.2.1.4.22.1.1.129.99.142.12: INTEGER: 1 1.3.6.1.2.1.4.22.1.2.129.99.23.12: OCTET STRING: 00 C0 F0 01 0A 75 (HW address) 1.3.6.1.2.1.4.22.1.2.129.99.142.12: OCTET STRING: 00 40 0B 40 2E 96 1.3.6.1.2.1.4.22.1.3.129.99.23.12: IP ADDRESS: 129.99.23.12 (IP address) 1.3.6.1.2.1.4.22.1.3.129.99.142.12: IP ADDRESS: 129.99.142.12 1.3.6.1.2.1.4.22.1.4.129.99.23.12: INTEGER: 4 (type of mapping{4=static}) 1.3.6.1.2.1.4.22.1.4.129.99.142.12: INTEGER: 4 1.3.6.1.2.1.4.23.0: COUNTER: 0 (IP routing discards) 1.3.6.1.2.1.5.1.0: COUNTER: 13477655 (total icmp packets received)ja 1.3.6.1.2.1.5.2.0: COUNTER: 62 (icmp packets with errors) 1.3.6.1.2.1.5.3.0: COUNTER: 96278 (icmp destination unreachables received) 1.3.6.1.2.1.5.4.0: COUNTER: 4500 (icmp time exceeded received) 1.3.6.1.2.1.5.5.0: COUNTER: 0 (icmp parameter problem received)jjka 1.3.6.1.2.1.5.6.0: COUNTER: 3256 (icmp source quench received) 1.3.6.1.2.1.5.7.0: COUNTER: 40 (icmp redirect received) 1.3.6.1.2.1.5.8.0: COUNTER: 172171 (icmp echos request received) 1.3.6.1.2.1.5.9.0: COUNTER: 0 (icmp echo reply received) 1.3.6.1.2.1.5.10.0: COUNTER: 0 (icmp timestamp req received) 1.3.6.1.2.1.5.11.0: COUNTER: 0 (icmp timestamp reply received) 1.3.6.1.2.1.5.12.0: COUNTER: 0 1.3.6.1.2.1.5.13.0: COUNTER: 0 ...and so on... 1.3.6.1.2.1.5.14.0: COUNTER: 174072 (icmp messages sent) 1.3.6.1.2.1.5.15.0: COUNTER: 0 1.3.6.1.2.1.5.16.0: COUNTER: 1901 (icmp dest unreachable sent) 1.3.6.1.2.1.5.17.0: COUNTER: 0 1.3.6.1.2.1.5.18.0: COUNTER: 0 ...and so on, one for each type sent... 1.3.6.1.2.1.5.19.0: COUNTER: 0 1.3.6.1.2.1.5.20.0: COUNTER: 0 1.3.6.1.2.1.5.21.0: COUNTER: 0 1.3.6.1.2.1.5.22.0: COUNTER: 172171 1.3.6.1.2.1.5.23.0: COUNTER: 0 1.3.6.1.2.1.5.24.0: COUNTER: 0 1.3.6.1.2.1.5.25.0: COUNTER: 0 1.3.6.1.2.1.5.26.0: COUNTER: 0 (end of icmp totals for each type) 1.3.6.1.2.1.6.1.0: INTEGER: 4 (retransmission algorithm 4=vanjacobsen) 1.3.6.1.2.1.6.2.0: INTEGER: 1000 (minimum tcp retransmission timeout) 1.3.6.1.2.1.6.3.0: INTEGER: 64000 (max tcp retransmission timeout) 1.3.6.1.2.1.6.4.0: INTEGER: -1 (total tcp connection limit -1=dynamic) 1.3.6.1.2.1.6.5.0: COUNTER: 5806 (number of SYN-SENT->CLOSED direct transitions) 1.3.6.1.2.1.6.6.0: COUNTER: 22494 (number of direct SYN-RCVD->LISTEN transitions) 1.3.6.1.2.1.6.7.0: COUNTER: 3 (number of direct SYN-SENT/SYN-RCVD->CLOSED trans) 1.3.6.1.2.1.6.8.0: COUNTER: 98 (number of direct EST/CLOSE_WAIT->CLOSED transitions) 1.3.6.1.2.1.6.9.0: GAUGE: 0 (number of current tcp connections) 1.3.6.1.2.1.6.10.0: COUNTER: 4193876 (number of tcp segments received) 1.3.6.1.2.1.6.11.0: COUNTER: 8192682 (number of tcp segments sent) 1.3.6.1.2.1.6.12.0: COUNTER: 28 (number of retransmitted segments) 1.3.6.1.2.1.6.13.1.1.0.0.0.0.612.0.0.0.0.0: INTEGER: 2 (existing TCP connection table--this is connection state, 2=listen) 1.3.6.1.2.1.6.13.1.2.0.0.0.0.612.0.0.0.0.0: IP ADDRESS: 0.0.0.0 (local address of tcp connection) 1.3.6.1.2.1.6.13.1.3.0.0.0.0.612.0.0.0.0.0: INTEGER: 612 (local port) 1.3.6.1.2.1.6.13.1.4.0.0.0.0.612.0.0.0.0.0: IP ADDRESS: 0.0.0.0 (remote address) 1.3.6.1.2.1.6.13.1.5.0.0.0.0.612.0.0.0.0.0: INTEGER: 0 (remote port) 1.3.6.1.2.1.6.14.0: COUNTER: 0 (total recd tcp segments with errors) 1.3.6.1.2.1.6.15.0: COUNTER: 31023 (number of tcp segments sent with RST flag) 1.3.6.1.2.1.7.1.0: COUNTER: 325738608 (number of udp datagrams delivered) 1.3.6.1.2.1.7.2.0: COUNTER: 1901 (number of udp datagrams with no listening application) 1.3.6.1.2.1.7.3.0: COUNTER: 16 (number of other undeliverable udp datagrams) 1.3.6.1.2.1.7.4.0: COUNTER: 313591122 (number of udp datagrams sent) 1.3.6.1.2.1.7.5.1.1.0.0.0.0.0: IP ADDRESS: 0.0.0.0 (UDP Listener table) 1.3.6.1.2.1.7.5.1.1.0.0.0.0.111: IP ADDRESS: 0.0.0.0 (one line for each port) 1.3.6.1.2.1.7.5.1.1.0.0.0.0.161: IP ADDRESS: 0.0.0.0 (this is ip addess from which we're willing to accept packets) 1.3.6.1.2.1.7.5.1.1.0.0.0.0.514: IP ADDRESS: 0.0.0.0 (ie. any ip address) 1.3.6.1.2.1.7.5.1.1.0.0.0.0.520: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.7.5.1.1.0.0.0.0.602: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.7.5.1.1.0.0.0.0.604: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.7.5.1.1.0.0.0.0.606: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.7.5.1.1.0.0.0.0.608: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.7.5.1.1.0.0.0.0.610: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.7.5.1.1.0.0.0.0.611: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.7.5.1.1.0.0.0.0.2049: IP ADDRESS: 0.0.0.0 1.3.6.1.2.1.7.5.1.2.0.0.0.0.0: INTEGER: 0 1.3.6.1.2.1.7.5.1.2.0.0.0.0.111: INTEGER: 111 (port number for each listening udp) 1.3.6.1.2.1.7.5.1.2.0.0.0.0.161: INTEGER: 161 1.3.6.1.2.1.7.5.1.2.0.0.0.0.514: INTEGER: 514 1.3.6.1.2.1.7.5.1.2.0.0.0.0.520: INTEGER: 520 1.3.6.1.2.1.7.5.1.2.0.0.0.0.602: INTEGER: 602 1.3.6.1.2.1.7.5.1.2.0.0.0.0.604: INTEGER: 604 1.3.6.1.2.1.7.5.1.2.0.0.0.0.606: INTEGER: 606 1.3.6.1.2.1.7.5.1.2.0.0.0.0.608: INTEGER: 608 1.3.6.1.2.1.7.5.1.2.0.0.0.0.610: INTEGER: 610 1.3.6.1.2.1.7.5.1.2.0.0.0.0.611: INTEGER: 611 1.3.6.1.2.1.7.5.1.2.0.0.0.0.2049: INTEGER: 2049 1.3.6.1.2.1.11.1.0: COUNTER: 5752 (number of snmp messages delivered upwards) 1.3.6.1.2.1.11.2.0: COUNTER: 5752 (number of snmp messages delivered downward) 1.3.6.1.2.1.11.3.0: COUNTER: 0 (number of snmp messages with unsupported version) 1.3.6.1.2.1.11.4.0: COUNTER: 0 (snmp messages with unknown community name) 1.3.6.1.2.1.11.5.0: COUNTER: 0 (number of unallowed snmp operations) 1.3.6.1.2.1.11.6.0: COUNTER: 0 (number of snmp asn.1 or ber errors) 1.3.6.1.2.1.11.8.0: COUNTER: 0 (number of snmp pdu's with "too big" error) 1.3.6.1.2.1.11.9.0: COUNTER: 205 (number of snmp pdu's with "no such name" error) 1.3.6.1.2.1.11.10.0: COUNTER: 0 (number of snmp pdu's with "bad value" error) 1.3.6.1.2.1.11.11.0: COUNTER: 0 (number of snmp pdu's with "readonly" error) 1.3.6.1.2.1.11.12.0: COUNTER: 0 (number of snmp pdu's with generr error) 1.3.6.1.2.1.11.13.0: COUNTER: 5558 (number of MIB's retreived successfully with get-request and get-next pdu's) 1.3.6.1.2.1.11.14.0: COUNTER: 0 (number of successful set-request pdu's) 1.3.6.1.2.1.11.15.0: COUNTER: 113 (number of successful get-request pdu's) 1.3.6.1.2.1.11.16.0: COUNTER: 5653 (number of successful get-next pdu's) 1.3.6.1.2.1.11.17.0: COUNTER: 0 ...and so on...one per pdu operation type... 1.3.6.1.2.1.11.18.0: COUNTER: 0 1.3.6.1.2.1.11.19.0: COUNTER: 0 1.3.6.1.2.1.11.20.0: COUNTER: 0 1.3.6.1.2.1.11.21.0: COUNTER: 0 1.3.6.1.2.1.11.22.0: COUNTER: 0 1.3.6.1.2.1.11.24.0: COUNTER: 0 ...counters for each outbound error type... 1.3.6.1.2.1.11.25.0: COUNTER: 0 (Total snmp get-request pdu's generated here) 1.3.6.1.2.1.11.26.0: COUNTER: 0 (total get-next pdu's generated here) 1.3.6.1.2.1.11.27.0: COUNTER: 0 1.3.6.1.2.1.11.28.0: COUNTER: 5776 (total get-response pdu's generated here) 1.3.6.1.2.1.11.29.0: COUNTER: 0 (total snmp trap pdu's generated here) 1.3.6.1.2.1.11.30.0: INTEGER: 0 (authentication failure trap flag 1=enabled, 2=disabled) That ends the standard RFC1213 MIB Now starts the Netapp Custom MIB with Registry Number 789 1.3.6.1.4.1.789.1.1.1.0: INTEGER: 1 (1=eisa based, 2=pci based) 1.3.6.1.4.1.789.1.1.2.0: OCTET STRING: NetApp Release 4.2a: Fri Sep 5 09:36:36 PDT 1997 1.3.6.1.4.1.789.1.1.3.0: OCTET STRING: 0008055329 (serial id {wrong}) 1.3.6.1.4.1.789.1.2.1.1.0: TIMETICKS: 1016121072 (uptime in ticks {1/100sec}) 1.3.6.1.4.1.789.1.2.1.2.0: TIMETICKS: 33513506 (cpu ticks used since uptime) 1.3.6.1.4.1.789.1.2.1.3.0: INTEGER: 3 (% cpu util since uptime) 1.3.6.1.4.1.789.1.2.1.4.0: TIMETICKS: 982607568 (cpu idle ticks since uptime) 1.3.6.1.4.1.789.1.2.1.5.0: INTEGER: 97 (% idle since last boot) 1.3.6.1.4.1.789.1.2.2.1.0: INTEGER: 311445413 (nfs ops since boot) 1.3.6.1.4.1.789.1.2.2.2.0: INTEGER: 4503517 (total kbytes recd on all nets) 1.3.6.1.4.1.789.1.2.2.3.0: INTEGER: 1224614 (total kbytes trans since boot) 1.3.6.1.4.1.789.1.3.1.1.1.0: COUNTER: 38966 (total rpc ops since cleared) 1.3.6.1.4.1.789.1.3.1.1.2.0: COUNTER: 2 (total rpc rejects since clear) 1.3.6.1.4.1.789.1.3.1.1.3.0: COUNTER: 0 useless wierd error 1.3.6.1.4.1.789.1.3.1.1.4.0: COUNTER: 0 useless wierd error 1.3.6.1.4.1.789.1.3.1.1.5.0: COUNTER: 2 useless wierd error 1.3.6.1.4.1.789.1.3.1.2.1.0: COUNTER: 38948 (total nfs ops since clear) 1.3.6.1.4.1.789.1.3.1.2.2.0: COUNTER: 0 (rejected nfs calls since clear) 1.3.6.1.4.1.789.1.3.1.2.3.1.1.0: COUNTER: 13172 (v2 null calls since clear) 1.3.6.1.4.1.789.1.3.1.2.3.1.2.0: COUNTER: 10983 (v2 gettr calls since clear) 1.3.6.1.4.1.789.1.3.1.2.3.1.3.0: COUNTER: 25 (v2 setattr calls since clear) 1.3.6.1.4.1.789.1.3.1.2.3.1.4.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.1.5.0: COUNTER: 12492 (v2 lookup calls since clear) 1.3.6.1.4.1.789.1.3.1.2.3.1.6.0: COUNTER: 354 1.3.6.1.4.1.789.1.3.1.2.3.1.7.0: COUNTER: 1778 1.3.6.1.4.1.789.1.3.1.2.3.1.8.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.1.9.0: COUNTER: 10 1.3.6.1.4.1.789.1.3.1.2.3.1.10.0: COUNTER: 15 1.3.6.1.4.1.789.1.3.1.2.3.1.11.0: COUNTER: 15 1.3.6.1.4.1.789.1.3.1.2.3.1.12.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.1.13.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.1.14.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.1.15.0: COUNTER: 2 1.3.6.1.4.1.789.1.3.1.2.3.1.16.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.1.17.0: COUNTER: 99 1.3.6.1.4.1.789.1.3.1.2.3.1.18.0: COUNTER: 3 (end v2 calls per op type since clear) 1.3.6.1.4.1.789.1.3.1.2.3.2.1.0: INTEGER: 34 (v2 percentages per op type... 1.3.6.1.4.1.789.1.3.1.2.3.2.2.0: INTEGER: 28 1.3.6.1.4.1.789.1.3.1.2.3.2.3.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.4.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.5.0: INTEGER: 32 1.3.6.1.4.1.789.1.3.1.2.3.2.6.0: INTEGER: 1 1.3.6.1.4.1.789.1.3.1.2.3.2.7.0: INTEGER: 5 1.3.6.1.4.1.789.1.3.1.2.3.2.8.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.9.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.10.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.11.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.12.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.13.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.14.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.15.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.16.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.17.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.2.18.0: INTEGER: 0 (end v2 percents per op type since clear) 1.3.6.1.4.1.789.1.3.1.2.3.3.1.0: COUNTER: 13174 (v2 cached calls per op) 1.3.6.1.4.1.789.1.3.1.2.3.3.2.0: COUNTER: 10983 1.3.6.1.4.1.789.1.3.1.2.3.3.3.0: COUNTER: 25 1.3.6.1.4.1.789.1.3.1.2.3.3.4.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.3.5.0: COUNTER: 12476 1.3.6.1.4.1.789.1.3.1.2.3.3.6.0: COUNTER: 354 1.3.6.1.4.1.789.1.3.1.2.3.3.7.0: COUNTER: 1140 1.3.6.1.4.1.789.1.3.1.2.3.3.8.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.3.9.0: COUNTER: 10 1.3.6.1.4.1.789.1.3.1.2.3.3.10.0: COUNTER: 15 1.3.6.1.4.1.789.1.3.1.2.3.3.11.0: COUNTER: 15 1.3.6.1.4.1.789.1.3.1.2.3.3.12.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.3.13.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.3.14.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.3.15.0: COUNTER: 2 1.3.6.1.4.1.789.1.3.1.2.3.3.16.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.3.3.17.0: COUNTER: 99 1.3.6.1.4.1.789.1.3.1.2.3.3.18.0: COUNTER: 3 (end v2 cached calls per op since clear) 1.3.6.1.4.1.789.1.3.1.2.3.4.1.0: INTEGER: 100 (percent v2 cached calls per op since clear) 1.3.6.1.4.1.789.1.3.1.2.3.4.2.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.1.2.3.4.3.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.1.2.3.4.4.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.4.5.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.1.2.3.4.6.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.1.2.3.4.7.0: INTEGER: 64 1.3.6.1.4.1.789.1.3.1.2.3.4.8.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.4.9.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.1.2.3.4.10.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.1.2.3.4.11.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.1.2.3.4.12.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.4.13.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.4.14.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.4.15.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.1.2.3.4.16.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.3.4.17.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.1.2.3.4.18.0: INTEGER: 100 (percent v2 cached calls per op since clear) 1.3.6.1.4.1.789.1.3.1.2.4.1.1.0: COUNTER: 0 (v3 calls per op since clear) 1.3.6.1.4.1.789.1.3.1.2.4.1.2.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.3.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.4.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.5.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.6.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.7.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.8.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.9.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.10.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.11.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.12.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.13.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.14.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.15.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.16.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.17.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.18.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.19.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.20.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.21.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.1.22.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.1.0: INTEGER: 0 (v3 percent calls per op since clear) 1.3.6.1.4.1.789.1.3.1.2.4.2.2.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.3.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.4.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.5.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.6.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.7.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.8.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.9.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.10.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.11.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.12.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.13.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.14.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.15.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.16.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.17.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.18.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.19.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.20.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.21.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.2.22.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.1.0: COUNTER: 0 (v3 cached calls per op since clear) 1.3.6.1.4.1.789.1.3.1.2.4.3.2.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.3.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.4.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.5.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.6.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.7.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.8.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.9.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.10.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.11.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.12.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.13.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.14.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.15.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.16.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.17.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.18.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.19.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.20.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.21.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.3.22.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.1.0: INTEGER: 0 (v3 percent cached calls per op since clear) 1.3.6.1.4.1.789.1.3.1.2.4.4.2.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.3.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.4.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.5.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.6.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.7.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.8.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.9.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.10.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.11.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.12.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.13.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.14.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.15.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.16.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.17.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.18.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.19.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.20.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.21.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.4.4.22.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.1.2.5.1.0: COUNTER: 0 (reply cache drops because in proress) 1.3.6.1.4.1.789.1.3.1.2.5.2.0: COUNTER: 16 (reply cache drops because short interval since clear) 1.3.6.1.4.1.789.1.3.1.2.5.3.0: COUNTER: 2277 (not in reply cache since clear) 1.3.6.1.4.1.789.1.3.1.2.5.4.0: COUNTER: 21 (reply cache replays since clear) 1.3.6.1.4.1.789.1.3.1.2.5.5.0: COUNTER: 0 (wierd useless reply cache) 1.3.6.1.4.1.789.1.3.2.1.1.0: COUNTER: 311558712 (tot rpc calls since last boot) 1.3.6.1.4.1.789.1.3.2.1.2.0: COUNTER: 66296 1.3.6.1.4.1.789.1.3.2.1.3.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.1.4.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.1.5.0: COUNTER: 66296 1.3.6.1.4.1.789.1.3.2.2.1.0: COUNTER: 311445423 1.3.6.1.4.1.789.1.3.2.2.2.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.3.1.1.0: COUNTER: 44404792 1.3.6.1.4.1.789.1.3.2.2.3.1.2.0: COUNTER: 68865045 1.3.6.1.4.1.789.1.3.2.2.3.1.3.0: COUNTER: 1529369 1.3.6.1.4.1.789.1.3.2.2.3.1.4.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.3.1.5.0: COUNTER: 164028615 1.3.6.1.4.1.789.1.3.2.2.3.1.6.0: COUNTER: 2865558 1.3.6.1.4.1.789.1.3.2.2.3.1.7.0: COUNTER: 14742178 1.3.6.1.4.1.789.1.3.2.2.3.1.8.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.3.1.9.0: COUNTER: 3365809 1.3.6.1.4.1.789.1.3.2.2.3.1.10.0: COUNTER: 527187 1.3.6.1.4.1.789.1.3.2.2.3.1.11.0: COUNTER: 443320 1.3.6.1.4.1.789.1.3.2.2.3.1.12.0: COUNTER: 4899 1.3.6.1.4.1.789.1.3.2.2.3.1.13.0: COUNTER: 1346 1.3.6.1.4.1.789.1.3.2.2.3.1.14.0: COUNTER: 65983 1.3.6.1.4.1.789.1.3.2.2.3.1.15.0: COUNTER: 21674 1.3.6.1.4.1.789.1.3.2.2.3.1.16.0: COUNTER: 1498 1.3.6.1.4.1.789.1.3.2.2.3.1.17.0: COUNTER: 10292726 1.3.6.1.4.1.789.1.3.2.2.3.1.18.0: COUNTER: 81984 1.3.6.1.4.1.789.1.3.2.2.3.2.1.0: INTEGER: 14 1.3.6.1.4.1.789.1.3.2.2.3.2.2.0: INTEGER: 22 1.3.6.1.4.1.789.1.3.2.2.3.2.3.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.2.4.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.2.5.0: INTEGER: 53 1.3.6.1.4.1.789.1.3.2.2.3.2.6.0: INTEGER: 1 1.3.6.1.4.1.789.1.3.2.2.3.2.7.0: INTEGER: 5 1.3.6.1.4.1.789.1.3.2.2.3.2.8.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.2.9.0: INTEGER: 1 1.3.6.1.4.1.789.1.3.2.2.3.2.10.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.2.11.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.2.12.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.2.13.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.2.14.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.2.15.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.2.16.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.2.17.0: INTEGER: 3 1.3.6.1.4.1.789.1.3.2.2.3.2.18.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.3.1.0: COUNTER: 44404793 1.3.6.1.4.1.789.1.3.2.2.3.3.2.0: COUNTER: 68863571 1.3.6.1.4.1.789.1.3.2.2.3.3.3.0: COUNTER: 1526093 1.3.6.1.4.1.789.1.3.2.2.3.3.4.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.3.3.5.0: COUNTER: 163331108 1.3.6.1.4.1.789.1.3.2.2.3.3.6.0: COUNTER: 2863733 1.3.6.1.4.1.789.1.3.2.2.3.3.7.0: COUNTER: 12935354 1.3.6.1.4.1.789.1.3.2.2.3.3.8.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.3.3.9.0: COUNTER: 3351039 1.3.6.1.4.1.789.1.3.2.2.3.3.10.0: COUNTER: 509447 1.3.6.1.4.1.789.1.3.2.2.3.3.11.0: COUNTER: 416832 1.3.6.1.4.1.789.1.3.2.2.3.3.12.0: COUNTER: 1857 1.3.6.1.4.1.789.1.3.2.2.3.3.13.0: COUNTER: 1346 1.3.6.1.4.1.789.1.3.2.2.3.3.14.0: COUNTER: 64481 1.3.6.1.4.1.789.1.3.2.2.3.3.15.0: COUNTER: 18990 1.3.6.1.4.1.789.1.3.2.2.3.3.16.0: COUNTER: 1423 1.3.6.1.4.1.789.1.3.2.2.3.3.17.0: COUNTER: 8128600 1.3.6.1.4.1.789.1.3.2.2.3.3.18.0: COUNTER: 81984 1.3.6.1.4.1.789.1.3.2.2.3.4.1.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.3.4.2.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.3.4.3.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.3.4.4.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.4.5.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.3.4.6.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.3.4.7.0: INTEGER: 88 1.3.6.1.4.1.789.1.3.2.2.3.4.8.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.3.4.9.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.3.4.10.0: INTEGER: 97 1.3.6.1.4.1.789.1.3.2.2.3.4.11.0: INTEGER: 94 1.3.6.1.4.1.789.1.3.2.2.3.4.12.0: INTEGER: 38 1.3.6.1.4.1.789.1.3.2.2.3.4.13.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.3.4.14.0: INTEGER: 98 1.3.6.1.4.1.789.1.3.2.2.3.4.15.0: INTEGER: 88 1.3.6.1.4.1.789.1.3.2.2.3.4.16.0: INTEGER: 95 1.3.6.1.4.1.789.1.3.2.2.3.4.17.0: INTEGER: 79 1.3.6.1.4.1.789.1.3.2.2.3.4.18.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.4.1.1.0: COUNTER: 0 (tot v3 calls since boot) 1.3.6.1.4.1.789.1.3.2.2.4.1.2.0: COUNTER: 157041 1.3.6.1.4.1.789.1.3.2.2.4.1.3.0: COUNTER: 9558 1.3.6.1.4.1.789.1.3.2.2.4.1.4.0: COUNTER: 26034 1.3.6.1.4.1.789.1.3.2.2.4.1.5.0: COUNTER: 2366 1.3.6.1.4.1.789.1.3.2.2.4.1.6.0: COUNTER: 970 1.3.6.1.4.1.789.1.3.2.2.4.1.7.0: COUNTER: 6004 1.3.6.1.4.1.789.1.3.2.2.4.1.8.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.1.9.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.1.10.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.1.11.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.1.12.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.1.13.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.1.14.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.1.15.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.1.16.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.1.17.0: COUNTER: 1 1.3.6.1.4.1.789.1.3.2.2.4.1.18.0: COUNTER: 1146 1.3.6.1.4.1.789.1.3.2.2.4.1.19.0: COUNTER: 307 1.3.6.1.4.1.789.1.3.2.2.4.1.20.0: COUNTER: 15 1.3.6.1.4.1.789.1.3.2.2.4.1.21.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.1.22.0: COUNTER: 5 1.3.6.1.4.1.789.1.3.2.2.4.2.1.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.2.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.3.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.4.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.5.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.6.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.7.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.8.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.9.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.10.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.11.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.12.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.13.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.14.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.15.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.16.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.17.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.18.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.19.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.20.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.21.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.2.22.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.1.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.2.0: COUNTER: 157041 1.3.6.1.4.1.789.1.3.2.2.4.3.3.0: COUNTER: 9558 1.3.6.1.4.1.789.1.3.2.2.4.3.4.0: COUNTER: 25822 1.3.6.1.4.1.789.1.3.2.2.4.3.5.0: COUNTER: 2366 1.3.6.1.4.1.789.1.3.2.2.4.3.6.0: COUNTER: 970 1.3.6.1.4.1.789.1.3.2.2.4.3.7.0: COUNTER: 4684 1.3.6.1.4.1.789.1.3.2.2.4.3.8.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.9.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.10.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.11.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.12.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.13.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.14.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.15.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.16.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.17.0: COUNTER: 1 1.3.6.1.4.1.789.1.3.2.2.4.3.18.0: COUNTER: 1096 1.3.6.1.4.1.789.1.3.2.2.4.3.19.0: COUNTER: 307 1.3.6.1.4.1.789.1.3.2.2.4.3.20.0: COUNTER: 15 1.3.6.1.4.1.789.1.3.2.2.4.3.21.0: COUNTER: 0 1.3.6.1.4.1.789.1.3.2.2.4.3.22.0: COUNTER: 5 1.3.6.1.4.1.789.1.3.2.2.4.4.1.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.2.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.4.4.3.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.4.4.4.0: INTEGER: 99 1.3.6.1.4.1.789.1.3.2.2.4.4.5.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.4.4.6.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.4.4.7.0: INTEGER: 78 1.3.6.1.4.1.789.1.3.2.2.4.4.8.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.9.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.10.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.11.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.12.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.13.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.14.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.15.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.16.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.17.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.4.4.18.0: INTEGER: 96 1.3.6.1.4.1.789.1.3.2.2.4.4.19.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.4.4.20.0: INTEGER: 100 1.3.6.1.4.1.789.1.3.2.2.4.4.21.0: INTEGER: 0 1.3.6.1.4.1.789.1.3.2.2.4.4.22.0: INTEGER: 100 (end tot v3 calls since boot) 1.3.6.1.4.1.789.1.3.2.2.5.1.0: COUNTER: 152 (total reply cache stuff) 1.3.6.1.4.1.789.1.3.2.2.5.2.0: COUNTER: 23532 1.3.6.1.4.1.789.1.3.2.2.5.3.0: COUNTER: 33848969 1.3.6.1.4.1.789.1.3.2.2.5.4.0: COUNTER: 30262 1.3.6.1.4.1.789.1.3.2.2.5.5.0: COUNTER: 23309 (end total reply cache since boot) 1.3.6.1.4.1.789.1.4.1.0: INTEGER: 1 (quota on/off 1=off) 1.3.6.1.4.1.789.1.4.2.0: INTEGER: 0 (quota percent computation progress) 1.3.6.1.4.1.789.1.5.1.0: INTEGER: 904522 (total inodes on root) 1.3.6.1.4.1.789.1.5.2.0: INTEGER: 761794 (inodes used on root) 1.3.6.1.4.1.789.1.5.3.0: INTEGER: 7236173 (max inodes possible) 1.3.6.1.4.1.789.1.5.4.1.1.1: INTEGER: 1 (number id for filesys) 1.3.6.1.4.1.789.1.5.4.1.1.2: INTEGER: 2 1.3.6.1.4.1.789.1.5.4.1.2.1: OCTET STRING: / (filesys name) 1.3.6.1.4.1.789.1.5.4.1.2.2: OCTET STRING: /.snapshot 1.3.6.1.4.1.789.1.5.4.1.3.1: INTEGER: 27421288 (total filesys capacity) 1.3.6.1.4.1.789.1.5.4.1.3.2: INTEGER: 0 1.3.6.1.4.1.789.1.5.4.1.4.1: INTEGER: 24756864 (total filesys used) 1.3.6.1.4.1.789.1.5.4.1.4.2: INTEGER: 0 1.3.6.1.4.1.789.1.5.4.1.5.1: INTEGER: 2664424 (total filesys avail) 1.3.6.1.4.1.789.1.5.4.1.5.2: INTEGER: 0 1.3.6.1.4.1.789.1.5.4.1.6.1: INTEGER: 90 (percent filesys avail) 1.3.6.1.4.1.789.1.5.4.1.6.2: INTEGER: -2147483648 1.3.6.1.4.1.789.1.5.4.1.7.1: INTEGER: 761794 (total inodes used) 1.3.6.1.4.1.789.1.5.4.1.7.2: INTEGER: 0 1.3.6.1.4.1.789.1.5.4.1.8.1: INTEGER: 142728 (total inodes avail) 1.3.6.1.4.1.789.1.5.4.1.8.2: INTEGER: 0 1.3.6.1.4.1.789.1.5.4.1.9.1: INTEGER: 84 (percent inodes used) 1.3.6.1.4.1.789.1.5.4.1.9.2: INTEGER: 0 1.3.6.1.4.1.789.1.5.4.1.10.1: OCTET STRING: / (name of filesys) 1.3.6.1.4.1.789.1.5.4.1.10.2: OCTET STRING: /.snapshot 1.3.6.1.4.1.789.1.6.1.1.1.1: INTEGER: 1 (number reference for each disk) 1.3.6.1.4.1.789.1.6.1.1.1.2: INTEGER: 2 1.3.6.1.4.1.789.1.6.1.1.1.3: INTEGER: 3 1.3.6.1.4.1.789.1.6.1.1.1.4: INTEGER: 4 1.3.6.1.4.1.789.1.6.1.1.1.5: INTEGER: 5 1.3.6.1.4.1.789.1.6.1.1.1.6: INTEGER: 6 1.3.6.1.4.1.789.1.6.1.1.1.7: INTEGER: 7 1.3.6.1.4.1.789.1.6.1.1.1.8: INTEGER: 8 1.3.6.1.4.1.789.1.6.1.1.1.9: INTEGER: 9 1.3.6.1.4.1.789.1.6.1.1.1.10: INTEGER: 10 1.3.6.1.4.1.789.1.6.1.1.1.11: INTEGER: 11 1.3.6.1.4.1.789.1.6.1.1.1.12: INTEGER: 12 1.3.6.1.4.1.789.1.6.1.1.1.13: INTEGER: 13 1.3.6.1.4.1.789.1.6.1.1.1.14: INTEGER: 14 1.3.6.1.4.1.789.1.6.1.1.2.1: OCTET STRING: parity (name for each disk) 1.3.6.1.4.1.789.1.6.1.1.2.2: OCTET STRING: data 1 1.3.6.1.4.1.789.1.6.1.1.2.3: OCTET STRING: data 2 1.3.6.1.4.1.789.1.6.1.1.2.4: OCTET STRING: data 3 1.3.6.1.4.1.789.1.6.1.1.2.5: OCTET STRING: data 4 1.3.6.1.4.1.789.1.6.1.1.2.6: OCTET STRING: data 5 1.3.6.1.4.1.789.1.6.1.1.2.7: OCTET STRING: data 6 1.3.6.1.4.1.789.1.6.1.1.2.8: OCTET STRING: data 7 1.3.6.1.4.1.789.1.6.1.1.2.9: OCTET STRING: data 8 1.3.6.1.4.1.789.1.6.1.1.2.10: OCTET STRING: data 9 1.3.6.1.4.1.789.1.6.1.1.2.11: OCTET STRING: data 10 1.3.6.1.4.1.789.1.6.1.1.2.12: OCTET STRING: data 11 1.3.6.1.4.1.789.1.6.1.1.2.13: OCTET STRING: data 12 1.3.6.1.4.1.789.1.6.1.1.2.14: OCTET STRING: spare 1.3.6.1.4.1.789.1.6.1.1.3.1: INTEGER: 1 (status for each disk) 1.3.6.1.4.1.789.1.6.1.1.3.2: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.3: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.4: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.5: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.6: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.7: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.8: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.9: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.10: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.11: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.12: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.13: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.3.14: INTEGER: 8 (status 1=active, 8=spare) 1.3.6.1.4.1.789.1.6.1.1.4.1: INTEGER: 1 (disk id for each drive) 1.3.6.1.4.1.789.1.6.1.1.4.2: INTEGER: 2 1.3.6.1.4.1.789.1.6.1.1.4.3: INTEGER: 3 1.3.6.1.4.1.789.1.6.1.1.4.4: INTEGER: 4 1.3.6.1.4.1.789.1.6.1.1.4.5: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.4.6: INTEGER: 5 1.3.6.1.4.1.789.1.6.1.1.4.7: INTEGER: 7 1.3.6.1.4.1.789.1.6.1.1.4.8: INTEGER: 8 1.3.6.1.4.1.789.1.6.1.1.4.9: INTEGER: 9 1.3.6.1.4.1.789.1.6.1.1.4.10: INTEGER: 10 1.3.6.1.4.1.789.1.6.1.1.4.11: INTEGER: 11 1.3.6.1.4.1.789.1.6.1.1.4.12: INTEGER: 6 1.3.6.1.4.1.789.1.6.1.1.4.13: INTEGER: 13 1.3.6.1.4.1.789.1.6.1.1.4.14: INTEGER: 12 1.3.6.1.4.1.789.1.6.1.1.5.1: OCTET STRING: 0 (scsi adapter for each drive) 1.3.6.1.4.1.789.1.6.1.1.5.2: OCTET STRING: 0 1.3.6.1.4.1.789.1.6.1.1.5.3: OCTET STRING: 0 1.3.6.1.4.1.789.1.6.1.1.5.4: OCTET STRING: 0 1.3.6.1.4.1.789.1.6.1.1.5.5: OCTET STRING: 0 1.3.6.1.4.1.789.1.6.1.1.5.6: OCTET STRING: 1 1.3.6.1.4.1.789.1.6.1.1.5.7: OCTET STRING: 1 1.3.6.1.4.1.789.1.6.1.1.5.8: OCTET STRING: 1 1.3.6.1.4.1.789.1.6.1.1.5.9: OCTET STRING: 1 1.3.6.1.4.1.789.1.6.1.1.5.10: OCTET STRING: 0 1.3.6.1.4.1.789.1.6.1.1.5.11: OCTET STRING: 0 1.3.6.1.4.1.789.1.6.1.1.5.12: OCTET STRING: 1 1.3.6.1.4.1.789.1.6.1.1.5.13: OCTET STRING: 1 1.3.6.1.4.1.789.1.6.1.1.5.14: OCTET STRING: 1 1.3.6.1.4.1.789.1.6.1.1.6.1: INTEGER: 1 (scsi id of each drive) 1.3.6.1.4.1.789.1.6.1.1.6.2: INTEGER: 2 1.3.6.1.4.1.789.1.6.1.1.6.3: INTEGER: 3 1.3.6.1.4.1.789.1.6.1.1.6.4: INTEGER: 4 1.3.6.1.4.1.789.1.6.1.1.6.5: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.6.6: INTEGER: 1 1.3.6.1.4.1.789.1.6.1.1.6.7: INTEGER: 2 1.3.6.1.4.1.789.1.6.1.1.6.8: INTEGER: 3 1.3.6.1.4.1.789.1.6.1.1.6.9: INTEGER: 4 1.3.6.1.4.1.789.1.6.1.1.6.10: INTEGER: 6 1.3.6.1.4.1.789.1.6.1.1.6.11: INTEGER: 5 1.3.6.1.4.1.789.1.6.1.1.6.12: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.6.13: INTEGER: 5 1.3.6.1.4.1.789.1.6.1.1.6.14: INTEGER: 6 1.3.6.1.4.1.789.1.6.1.1.7.1: INTEGER: 4000 (MB used on each drive) 1.3.6.1.4.1.789.1.6.1.1.7.2: INTEGER: 4000 1.3.6.1.4.1.789.1.6.1.1.7.3: INTEGER: 4000 1.3.6.1.4.1.789.1.6.1.1.7.4: INTEGER: 4000 1.3.6.1.4.1.789.1.6.1.1.7.5: INTEGER: 2000 1.3.6.1.4.1.789.1.6.1.1.7.6: INTEGER: 2000 1.3.6.1.4.1.789.1.6.1.1.7.7: INTEGER: 2000 1.3.6.1.4.1.789.1.6.1.1.7.8: INTEGER: 2000 1.3.6.1.4.1.789.1.6.1.1.7.9: INTEGER: 2000 1.3.6.1.4.1.789.1.6.1.1.7.10: INTEGER: 2000 1.3.6.1.4.1.789.1.6.1.1.7.11: INTEGER: 2000 1.3.6.1.4.1.789.1.6.1.1.7.12: INTEGER: 2000 1.3.6.1.4.1.789.1.6.1.1.7.13: INTEGER: 2000 1.3.6.1.4.1.789.1.6.1.1.7.14: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.8.1: INTEGER: 8192000 (blocks used on each drive) 1.3.6.1.4.1.789.1.6.1.1.8.2: INTEGER: 8192000 1.3.6.1.4.1.789.1.6.1.1.8.3: INTEGER: 8192000 1.3.6.1.4.1.789.1.6.1.1.8.4: INTEGER: 8192000 1.3.6.1.4.1.789.1.6.1.1.8.5: INTEGER: 4096000 1.3.6.1.4.1.789.1.6.1.1.8.6: INTEGER: 4096000 1.3.6.1.4.1.789.1.6.1.1.8.7: INTEGER: 4096000 1.3.6.1.4.1.789.1.6.1.1.8.8: INTEGER: 4096000 1.3.6.1.4.1.789.1.6.1.1.8.9: INTEGER: 4096000 1.3.6.1.4.1.789.1.6.1.1.8.10: INTEGER: 4096000 1.3.6.1.4.1.789.1.6.1.1.8.11: INTEGER: 4096000 1.3.6.1.4.1.789.1.6.1.1.8.12: INTEGER: 4096000 1.3.6.1.4.1.789.1.6.1.1.8.13: INTEGER: 4096000 1.3.6.1.4.1.789.1.6.1.1.8.14: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.9.1: INTEGER: 4095 (physical MB on each drive) 1.3.6.1.4.1.789.1.6.1.1.9.2: INTEGER: 4095 1.3.6.1.4.1.789.1.6.1.1.9.3: INTEGER: 4095 1.3.6.1.4.1.789.1.6.1.1.9.4: INTEGER: 4095 1.3.6.1.4.1.789.1.6.1.1.9.5: INTEGER: 4095 1.3.6.1.4.1.789.1.6.1.1.9.6: INTEGER: 4095 1.3.6.1.4.1.789.1.6.1.1.9.7: INTEGER: 2049 1.3.6.1.4.1.789.1.6.1.1.9.8: INTEGER: 2049 1.3.6.1.4.1.789.1.6.1.1.9.9: INTEGER: 2049 1.3.6.1.4.1.789.1.6.1.1.9.10: INTEGER: 2049 1.3.6.1.4.1.789.1.6.1.1.9.11: INTEGER: 2049 1.3.6.1.4.1.789.1.6.1.1.9.12: INTEGER: 2049 1.3.6.1.4.1.789.1.6.1.1.9.13: INTEGER: 2049 1.3.6.1.4.1.789.1.6.1.1.9.14: INTEGER: 2049 1.3.6.1.4.1.789.1.6.1.1.10.1: INTEGER: 8386728 (physical blocks on each drive) 1.3.6.1.4.1.789.1.6.1.1.10.2: INTEGER: 8386728 1.3.6.1.4.1.789.1.6.1.1.10.3: INTEGER: 8386728 1.3.6.1.4.1.789.1.6.1.1.10.4: INTEGER: 8386728 1.3.6.1.4.1.789.1.6.1.1.10.5: INTEGER: 8386728 1.3.6.1.4.1.789.1.6.1.1.10.6: INTEGER: 8386728 1.3.6.1.4.1.789.1.6.1.1.10.7: INTEGER: 4197400 1.3.6.1.4.1.789.1.6.1.1.10.8: INTEGER: 4197400 1.3.6.1.4.1.789.1.6.1.1.10.9: INTEGER: 4197400 1.3.6.1.4.1.789.1.6.1.1.10.10: INTEGER: 4197400 1.3.6.1.4.1.789.1.6.1.1.10.11: INTEGER: 4197400 1.3.6.1.4.1.789.1.6.1.1.10.12: INTEGER: 4197400 1.3.6.1.4.1.789.1.6.1.1.10.13: INTEGER: 4197400 1.3.6.1.4.1.789.1.6.1.1.10.14: INTEGER: 4197400 1.3.6.1.4.1.789.1.6.1.1.11.1: INTEGER: 0 (raid reconstruction percent) 1.3.6.1.4.1.789.1.6.1.1.11.2: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.3: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.4: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.5: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.6: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.7: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.8: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.9: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.10: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.11: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.12: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.13: INTEGER: 0 1.3.6.1.4.1.789.1.6.1.1.11.14: INTEGER: 0 1.3.6.1.4.1.789.1.1000.1.1.1: INTEGER: 1 (UNKNOWN) 1.3.6.1.4.1.789.1.1000.1.2.1: INTEGER: 1 1.3.6.1.4.1.789.1.1000.1.2.2: COUNTER: 0 1.3.6.1.4.1.789.1.1000.1.2.3: COUNTER: 0 1.3.6.1.4.1.789.1.1000.1.2.4: COUNTER: 0 1.3.6.1.4.1.789.1.1000.1.2.5: COUNTER: 0 1.3.6.1.4.1.789.1.1000.1.2.6: COUNTER: 0 1.3.6.1.4.1.789.1.1000.1.2.7: COUNTER: 0 1.3.6.1.4.1.789.1.1000.1.2.8: COUNTER: 0 1.3.6.1.4.1.789.1.1000.1.3.1: INTEGER: 1 1.3.6.1.4.1.789.1.1000.1.3.2: COUNTER: 189 1.3.6.1.4.1.789.1.1000.1.3.3: COUNTER: 189 1.3.6.1.4.1.789.1.1000.1.3.4: COUNTER: 0 1.3.6.1.4.1.789.1.1000.1.3.5: COUNTER: 189 1.3.6.1.4.1.789.1.1000.1.3.6: COUNTER: 6342 1.3.6.1.4.1.789.1.1000.1.3.7: COUNTER: 51079 1.3.6.1.4.1.789.1.1000.1.3.8: COUNTER: 0

1 0

Re: cvtusers question
by Arnie Thompson 12 Jun '98

12 Jun '98

Possibly the easiest way to give users the same UID would be to set up the generic account option like this: options cifs.generic_account pcuser where "pcuser" is an entry in the /etc/passwd file with a UID:GID pair like this: pcuser::65534:65534:: With this scenario, the filer checks the domain-authenticated user "X" against /etc/passwd to see if "X" is known locally, and if not the filer assigns the generic account "pcuser" to the unknown user "X". All unknown users receive UID 65534 and as far as the filer is concerned, are the same user. At 10:34 AM 6/11/98 -0700, agy wrote: >>Is there a way to force CVTUSER to create the user list export both >>alphabetically AND with ascending UID's? This way, as we add users to >>the filer, we don't have to check for "free UIDs"? Or if we're not even >>USING NFS (which we are not) and all we're using is the "cifs.home_dir" >>option and nothing else, couldn't eveyone have the SAME UID??? > > There is a new version of cvtusers scheduled for July which will >do what you want, as well as giving you the ability to edit the >stuff before it's written to file. Check the NOW site toward >mid-July in the Tools and Utilities section. The name of the >new version is SecureShare Account Migrator. > It is perfectly legal to give all users the same UID. Doing >this results in FAT-style security, i.e. none. If that's >what you want, go for it. This will be a security issue with the current software (5.0.1 and earlier), but with the 5.1 release due soon you will be able to apply an ACL to the file or directory for Windows security. If you need UNIX security on the file as well, better stick with real (and unique) UIDs. > > Actually, since you're an NT shop, let me ask you, do you >use a Domain Controller? If you do, the filer will be happy >to use that for authentication as well, eliminating the >conversion problem altogether. Having a DC doesn't eliminate the problem completely, because you still need to map the user name to a UID:GID pair somewhere. Using NIS, a DC and maintaining the same user naming conventions across platform is the only sure way I've found to eliminate having to maintain the local /etc/passwd file. Arnie

2 1

Re: CVTUSER Questions...
by Arnie Thompson 12 Jun '98

12 Jun '98

Here's an idea for you... Import your /etc/passwd file into some application that accepts character-delimited lists. Sort your list by UID and save it. I used Excel and saved the file in comma-delimited format (.csv), then edited the file and globally replaced the commas with colons. Worked great for me, and now I see Netapp employees in a completely differnt light... Arnie At 10:17 AM 6/11/98 -0500, Weeks, Thomas wrote: > >Hey all.. > >I was planning on using the CVTUSER utils to dump all my NT users into >my FS230's (OT V4.3.4) /etc/passwd file in preparation for using the >filer as a pure CIFS based home drive for our NT login users... (no NFS) > >My Q is... > >Is there a way to force CVTUSER to create the user list export both >alphabetically AND with ascending UID's? This way, as we add users to >the filer, we don't have to check for "free UIDs"? Or if we're not even >USING NFS (which we are not) and all we're using is the "cifs.home_dir" >option and nothing else, couldn't eveyone have the SAME UID??? > >Anyone been here before? > >Thanx... > >Tom > >

1 0

Re: flock problems
by sirbruce＠ix.netcom.com 11 Jun '98

11 Jun '98

On 06/11/98 12:33:52 you wrote: > > >This problem seems to happen about once a month. Wondering if it's a >configuration probably on my end or just an issue with my filer. > >Mail is delivered to ~/.mailbox onto a F540 running 4.3.1D7. and >clients are all Solaris 2.5.1. > >After about a month I start getting lots of calls from users (mostly elm >users, some mutt users) about being unable to read their mailbox. A >truss on the process shows it sleeping waiting for a flock on .mailbox. >mutt uses dotlocking and seems to just hang doing an open(). > >Only solution seems to be a reboot. Any clues or pointers on where I >should be looking? Reboot the filer or the Solaris client? This wasn't clear. There is a good chance that the bug lies in the Solaris lockd, not in the filer. You should apply all of the NFS and locking patches for 2.5.1 (heack, all of the recommended ones really) and see if it goes away. If it doesn't or you can't do this, as an interim measure killing and restarting the locking process on the UNIX client may be a less drastic solution, although I suppose under the right conditions this may result in corrupted files elsewhere in the filesystem. A lock management utility on the client side to browse through and remove bad locks, or a similar command on the filer, would be very useful. Bruce

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters