toasters

toasters@lists.teaparty.net

13531 discussions

Re: CIFS Remote Backup Options
by Matt Day 31 Jul '99

31 Jul '99

Garrett Burke <Garrett.Burke(a)msc.ie> wrote: >I currently use ARCServe 6.5 for backing up a F230,256MB RAM, 4MB NVRAM on >100BaseT full duplex, Extreme S48 switch, running OnTap 5.2.1 Issues that >have bitten us in the past are: > >a) It's slow. Backing up 24GB from the F230 using ARCServe 6.5 build 622 on >a DELL PowerEdge 1300 PIII 450 with 256MB Ram and 15 slot Compaq DLT70 >library (which is actually has a HP C5173-7000) I got 92.43 MB/min last >night which is about average. Note that we have lots of small files (source >code) The 24GB is made up of 315,913 files and 29,525 directories on a >single volume so you may see better performance or worse depending on your >mix. > >[..] > >c) oplocks. This has caused us numerous problems. We now run the backups >with oplocks turned off, as there some sort of interaction between ARCServe >and the oplock code (we tried a few D releases but never got around it) >which means that things run very, very slowly. Like, 2 days to run the >backup! Hi Garrett, There is an oplock bug in 5.2.1 (burt12483) that sometimes delays the delivery of oplock break messages -- I bet that's the performance problem you're hitting with oplocks enabled. The fix for this bug is available in 5.2.2P1 and 5.3. Have you tried either of those releases? Matt

2 1

show_therm
by Graham Knight 31 Jul '99

31 Jul '99

Well, i spent a goodly amount of time integrating the output of "show_therm" into our MRTG graphs, and did some bragging to management about how cool it was (and they agreed). Now, i load rev 5.2.3 of the OS and the command is *gone*!!!! Netapp - why do you do these things to me?!?!?!?!? Graham

1 0

RE: SnapMirror Very Slow
by Melvin, Grant 30 Jul '99

30 Jul '99

Hi, Just wanted to throw in that we discussed with David Midgett (while waiting for the next SnapMirror schedule to be triggered) how he was using SnapMirror. And heard (correct me if I'm wrong David) that his copy of data was being accessed by other clients in read-only fashion effectively balancing the client load across the CFO pair. So not only does David have a (local) disaster recovery copy of his data, but its also accessible (in read-only mode) at all times (after the baseline transfer has completed). Cheers, Grant -----Original Message----- From: alexei(a)mindspring.net [mailto:alexei@mindspring.net] Sent: Thursday, July 29, 1999 3:35 PM To: Sam Schorr Cc: toasters(a)mathworks.com Subject: Re: SnapMirror Very Slow Sam Schorr <sschorr(a)homestead.com> writes: > Actually, there is a very good reason to do both. Clustering only protects > filer head failures. If a volume on a filer loses 2 disks in 1 RAID group, > the volume built on that RAID group is useless and needs to be rebuilt upon > disk repair. So, by using SNAPMIRROR to "almost realtime" copy data to a > read-only volume on another filer, upon disk failure that volume can be made > "live" or the master volume. This is a strategy we are employing to fully > protect our users' data and insure the highest availability of that data. I am not arguing that doing both is not (potentially) good, but doing both on the same set of filers is troublesome. Individually, each solution addresses a set of problems, and each has its own set of problems. With CF (cluster failover), you get transparent (or close to) failover such that a client does not percieve a failure, just a pause. The cluster partner is then serving both sets of data (its own and that of its partner). If you do not size the filer correctly, you are going to be in trouble, especially if you loose a disk during failover. Snapshots are an additional overhead. With snapmirror, you have a copy of the data N minutes old (where N is a function based on the network latency, the size of the volume (clustermap overhead), size of the network pipe and ammount of deltas). In order to make that copy "live", you will need to update mount points across your clients in order to point at the now-read-write snapmirror volume on the other filer. So, doing snapmirror between cluster members is not a clear win. You are better off snapmirroring to a filer that is not part of the cluster. That way you can isolate your disaster backup copy from any potential problems the cluster might experience. Alex

2 1

RE: CIFS Remote Backup Options
by Garrett Burke 30 Jul '99

30 Jul '99

Hi Anissa, I currently use ARCServe 6.5 for backing up a F230,256MB RAM, 4MB NVRAM on 100BaseT full duplex, Extreme S48 switch, running OnTap 5.2.1 Issues that have bitten us in the past are: a) It's slow. Backing up 24GB from the F230 using ARCServe 6.5 build 622 on a DELL PowerEdge 1300 PIII 450 with 256MB Ram and 15 slot Compaq DLT70 library (which is actually has a HP C5173-7000) I got 92.43 MB/min last night which is about average. Note that we have lots of small files (source code) The 24GB is made up of 315,913 files and 29,525 directories on a single volume so you may see better performance or worse depending on your mix. b) careful of share permissions. Make sure when setting up the Job that the username and password entered in the security dialog can connect to the filer. We use the pre & post script option in ARCServe to create and share a snapshot (& turn oplocks off, see below), backup from the share and then unshare the snapshot. c) oplocks. This has caused us numerous problems. We now run the backups with oplocks turned off, as there some sort of interaction between ARCServe and the oplock code (we tried a few D releases but never got around it) which means that things run very, very slowly. Like, 2 days to run the backup! d) watch your network infrastructure. If you are dropping packets then you will see a major performance hit. Of course, the usual thing of ensuring that your duplex setting match on both filer and switch need to be taken care of. Note that the performance figures given at http://www.netapp.com/technology/level3/3052.html are for ARCServe IT 6.6, but I haven't heard of any other performance figures for 6.6 from filer users. Anyone out there using ARCServe IT 6.6 to backup a filer? Regards, GB > ---------- > From: Mohler, Anissa[SMTP:amohler@mail.bokf.com] > Sent: 29 July 1999 18:28 > To: 'toasters(a)mathworks.com' > Subject: CIFS Remote Backup Options > > I am working on design of a backup system for our F740 filer (100G usable) > in a CIFS environment. At this time we have no plans on directly attaching > a > tape backup device to the filer. Our current enterprise backup solution is > ARCserve 6.5 (on NT). > > I have the White Paper on NT Backups and am wondering what is actually in > use in the field. Are there any gotcha's I need to watch out for? Any best > practices out there? > > Thanks! > > Anissa Mohler > amohler(a)mail.bokf.com > BOKf Network Services Group >

1 0

Restore problems.Please help !!!!
by Richard Burton 30 Jul '99

30 Jul '99

Anyone has any insights as to what I am doing wrong?I am trying to restore a single file from a 5 tape dump. The tape inserted in the beginning is the correct tape (tape 5).Should I get any message from restore saying that it liked my tape 5 and would now need the next tape ? Because I inserted tape 4 after 5 and got Wrong volume 2.Can anyone explain why it does not say wrong volume 5 but says wrong volume 1. Moreover why does it crap out on me with the 'Tape Block size should be 10240, not 64512' message ? Any help is greatly appreciated.The dump command I used is : dump 0uf urst0a,urst0a,urst0a,urst0a,rst0a /vol/vol0 bean> restore xvfD rst0a /vol/vol0/test/restore /users/john/lib/hit.c RESTORE: Dump date: Mon Jul 28 15:46:35 PDT 1999 RESTORE: Dumped from: the epoch RESTORE: Level 0 dump of /vol/vol0/ on bean:/vol/vol0/../snapshot_for_backup.5 RESTORE: Label: none RESTORE: Initialize symbol table. RESTORE: Extract directories from tape RESTORE: Warning: cannot create directory /vol/vol0/test/restore: File exists RESTORE: Make node /vol/vol0/test/restore RESTORE: Extract requested files RESTORE: You have not read any tapes yet. Please start with the last tape volume and work towards towards the first. RESTORE: Specify next tape volume #:5 RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: rst0a) urst0a RESTORE: Wrong volume 1 RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) RESTORE: Wrong volume 2 RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) RESTORE: Wrong volume 3 RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) RESTORE: Wrong volume 4 RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) RESTORE: Tape Block size should be 10240, not 64512. RESTORE: Mount tape volume on bean RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) RESTORE: Tape Block size should be 10240, not 64512. RESTORE: Enter ``none'' if there are no more tapes RESTORE: otherwise enter tape name (default: urst0a) none RESTORE: No more tapes, recovery operation aborted bean>

2 1

Re: SnapMirror Very Slow
by alexei＠mindspring.net 29 Jul '99

29 Jul '99

Sam Schorr <sschorr(a)homestead.com> writes: > Actually, there is a very good reason to do both. Clustering only protects > filer head failures. If a volume on a filer loses 2 disks in 1 RAID group, > the volume built on that RAID group is useless and needs to be rebuilt upon > disk repair. So, by using SNAPMIRROR to "almost realtime" copy data to a > read-only volume on another filer, upon disk failure that volume can be made > "live" or the master volume. This is a strategy we are employing to fully > protect our users' data and insure the highest availability of that data. I am not arguing that doing both is not (potentially) good, but doing both on the same set of filers is troublesome. Individually, each solution addresses a set of problems, and each has its own set of problems. With CF (cluster failover), you get transparent (or close to) failover such that a client does not percieve a failure, just a pause. The cluster partner is then serving both sets of data (its own and that of its partner). If you do not size the filer correctly, you are going to be in trouble, especially if you loose a disk during failover. Snapshots are an additional overhead. With snapmirror, you have a copy of the data N minutes old (where N is a function based on the network latency, the size of the volume (clustermap overhead), size of the network pipe and ammount of deltas). In order to make that copy "live", you will need to update mount points across your clients in order to point at the now-read-write snapmirror volume on the other filer. So, doing snapmirror between cluster members is not a clear win. You are better off snapmirroring to a filer that is not part of the cluster. That way you can isolate your disaster backup copy from any potential problems the cluster might experience. Alex

1 0

RE: SnapMirror Very Slow
by Sam Schorr 29 Jul '99

29 Jul '99

Alexei, Actually, there is a very good reason to do both. Clustering only protects filer head failures. If a volume on a filer loses 2 disks in 1 RAID group, the volume built on that RAID group is useless and needs to be rebuilt upon disk repair. So, by using SNAPMIRROR to "almost realtime" copy data to a read-only volume on another filer, upon disk failure that volume can be made "live" or the master volume. This is a strategy we are employing to fully protect our users' data and insure the highest availability of that data. Regards, Sam -----Original Message----- From: alexei(a)mindspring.net [mailto:alexei@mindspring.net] Sent: Thursday, July 29, 1999 1:48 PM To: dmidgett(a)about.com Cc: toasters(a)mathworks.com Subject: Re: SnapMirror Very Slow "David Midgett" <dmidgett(a)about.com> writes: > Has anyone experienced problems with the SnapMirror taking an excessively > long time to complete the transfer. We have two F760's in a cluster > configuration. The mirror is set to update every 15 minutes. There is not > that much data that is changing and the total volume is 107Gb with only 1Gb > used spanning 10 disks. The transfer takes hours for any change to be > replicated. The 'vol snapmirror status' command shows that it is > transferring. The network speed is not an issue. Also connected the two > NetApp's directly to each other with a cross cable. This does not speed it > up. Any insight? Hmm. I don't know if this should work as you describe. The normal overhead for the snapmirror includes moving a constant set of data plus the deltas. Once the initial (level 0) snapmirror finishes, how long do incrementals take? Have you tried with larger intervals? What network interface are you using to conenct the filers? snapmirroring between cluster partners does not seem like it would/should work completely. The whole point of clustering is to have access to both sets of data with a failure, so snapmirroring it between the cluster is an unneccessary step. What occurs when: - snapmirror source filer fails - cluster-failover kicks in - cf partner (snapmirror destination) takes over - snapmirror continues.... how? The filer talks to itself? Try breaking the cluster setup, then do the snapmirror again. See if the speed improves. Perhaps others have better ideas. HTH. Alex

1 0

SnapMirror Very Slow
by David Midgett 29 Jul '99

29 Jul '99

Has anyone experienced problems with the SnapMirror taking an excessively long time to complete the transfer. We have two F760's in a cluster configuration. The mirror is set to update every 15 minutes. There is not that much data that is changing and the total volume is 107Gb with only 1Gb used spanning 10 disks. The transfer takes hours for any change to be replicated. The 'vol snapmirror status' command shows that it is transferring. The network speed is not an issue. Also connected the two NetApp's directly to each other with a cross cable. This does not speed it up. Any insight?

3 3

RE: SnapMirror Very Slow
by Melvin, Grant 29 Jul '99

29 Jul '99

Hi Paul, > Well, have you tried contacting NetApp CS > and asked them to look at your setup? You > may have something different in your > environment or it could be you've uncovered a bug. David HAS contacted NetApp CS and Engineering is helping them troubleshoot the problem. Cheers, Grant

1 0

RE: SnapMirror Very Slow
by Norman, Paul 29 Jul '99

29 Jul '99

> -----Original Message----- > From: alexei(a)mindspring.net [mailto:alexei@mindspring.net] > Sent: Thursday, July 29, 1999 1:48 PM > To: dmidgett(a)about.com > Cc: toasters(a)mathworks.com > Subject: Re: SnapMirror Very Slow > > > "David Midgett" <dmidgett(a)about.com> writes: > > > Has anyone experienced problems with the SnapMirror taking > an excessively > > long time to complete the transfer. We have two F760's in a cluster > > configuration. The mirror is set to update every 15 > minutes. There is not > > that much data that is changing and the total volume is > 107Gb with only 1Gb > > used spanning 10 disks. The transfer takes hours for any > change to be > > replicated. The 'vol snapmirror status' command shows that it is > > transferring. The network speed is not an issue. Also > connected the two > > NetApp's directly to each other with a cross cable. This > does not speed it > > up. Any insight? > > > Hmm. I don't know if this should work as you describe. The > normal overhead > for the snapmirror includes moving a constant set of data > plus the deltas. Correct, overhead is 1/1024 of the volume size. In this case a little over 100MB. > > Once the initial (level 0) snapmirror finishes, how long do > incrementals take? > > Have you tried with larger intervals? The implication here being that an update that does not complete due to network being down or some such will just restart at the next scheduled update time. How are you determining that updates take a long time. Have you done snap list and seen how fast the snapshot names are incrementing. > > What network interface are you using to conenct the filers? > > snapmirroring between cluster partners does not seem like it > would/should > work completely. The whole point of clustering is to have access to > both sets of data with a failure, so snapmirroring it between > the cluster is an > unneccessary step. What occurs when: > > - snapmirror source filer fails > - cluster-failover kicks in > - cf partner (snapmirror destination) takes over > - snapmirror continues.... how? The filer talks to itself? Exactly! The filer is running a virtual machine that actually sends the update to the original physical machine. Actually not as crazy as it first sounds. In fact we do have customers that just have a single filer and want to mirror so that they have two copies of data. [Poof! The engineer in me takes over for the Marketing dweeb that's been talking til now] Alright, maybe we don't have anybody doing it, but we've talked about it with customers. :-) When we first set up customer demos of snapmirroring here in corporate, we did it on a cluster since that was the equipment we had in the demo room. I don't recall any special issues in using it on a cluster. It was hard to see the updates since we had a tiny volume, 30GB, and a direct gigabit connection. Every time we did a status it was idle. Trying to catch the 30MB in flight turned out to be impossible. A sysstat would show the update going once a minute. Looking at the snapshot names incrementing turned out to be the simplest way to see what was happening. > > Try breaking the cluster setup, then do the snapmirror again. > See if the > speed improves. This shouldn't be an issue. > > Perhaps others have better ideas. Well, have you tried contacting NetApp CS and asked them to look at your setup? You may have something different in your environment or it could be you've uncovered a bug. > > HTH. > > > Alex >

1 0

Re: SnapMirror Very Slow
by alexei＠mindspring.net 29 Jul '99

29 Jul '99

"David Midgett" <dmidgett(a)about.com> writes: > Has anyone experienced problems with the SnapMirror taking an excessively > long time to complete the transfer. We have two F760's in a cluster > configuration. The mirror is set to update every 15 minutes. There is not > that much data that is changing and the total volume is 107Gb with only 1Gb > used spanning 10 disks. The transfer takes hours for any change to be > replicated. The 'vol snapmirror status' command shows that it is > transferring. The network speed is not an issue. Also connected the two > NetApp's directly to each other with a cross cable. This does not speed it > up. Any insight? Hmm. I don't know if this should work as you describe. The normal overhead for the snapmirror includes moving a constant set of data plus the deltas. Once the initial (level 0) snapmirror finishes, how long do incrementals take? Have you tried with larger intervals? What network interface are you using to conenct the filers? snapmirroring between cluster partners does not seem like it would/should work completely. The whole point of clustering is to have access to both sets of data with a failure, so snapmirroring it between the cluster is an unneccessary step. What occurs when: - snapmirror source filer fails - cluster-failover kicks in - cf partner (snapmirror destination) takes over - snapmirror continues.... how? The filer talks to itself? Try breaking the cluster setup, then do the snapmirror again. See if the speed improves. Perhaps others have better ideas. HTH. Alex

1 0

RE: CIFS Remote Backup Options
by Benn, Paul 29 Jul '99

29 Jul '99

Hello Annisa, Keeping ARCServe in place should be just fine and would relieve you from having to learn a new piece of backup software (not to mention having to train anybody else in the support staff that might need to use it). The most common (only) "gotchas" that I've personally seen are related to mal-configured file permissions or occasionally name resolution problems. Make sure that the backup application's service account has access to the files and directories that you want to backup. Best of Luck! Regards, Paul Benn Network Appliance -----Original Message----- I am working on design of a backup system for our F740 filer (100G usable) in a CIFS environment. At this time we have no plans on directly attaching a tape backup device to the filer. Our current enterprise backup solution is ARCserve 6.5 (on NT). I have the White Paper on NT Backups and am wondering what is actually in use in the field. Are there any gotcha's I need to watch out for? Any best practices out there?

1 0

Linux, Samba and CIFS
by Sam Schorr 29 Jul '99

29 Jul '99

Folks, We're trying to get a Linux box, using Samba, to mount an NT share to our filers. We have been, quite successfully, accessing the filers from the NT domain they are in using normal UNC share names. We have also, successfully, mounted NT shares from the Linux box using Samba. The failure seems to be in some area of authentication on the part of the filers that is somehow unique to them as other NT systems are quite happy talking to the Linux/Samba mount. Any thoughts? Sam Schorr Homestead Technologies ph: (650) 549-3152 fax: (650) 364-7329 sschorr(a)homestead.com Don't just build a home page...build a Homestead!! http://www.homestead.com

3 2

File Ownership
by Ken Zola 29 Jul '99

29 Jul '99

Has anyone had the problem of Microsoft Word or Excel file writes taking over ownership of a file? I have a 720 at OS version of 5.1.2R3 running both the NFS and CIFS protocols. The filer contains only the root volume which has multiple qtrees of UNIX style security. Scenario: CIFS user#1 creates a Microsoft Word document which has write access at the UNIX group level. CIFS user#2, who is in the same UNIX group, modifies the file and automatically becomes the UNIX owner of the file. This works the same for Excel documents but not for text documents using Notepad. All help is appreciated. Ken

2 1

RE: File Ownership
by Muhlestein, Mark 29 Jul '99

29 Jul '99

This has to do with the way many Windows applications work. When a file is opened the application typically operates on a temporary copy of the original file. The temporary file is of course owned by the user that just created it. When the file is saved, the original file is renamed to become a backup file, and the temporary file is renamed to the original file name. That's how the ownership changes. Mark -----Original Message----- From: Ken Zola [mailto:kenz@cfsmo.honeywell.com] Sent: Thursday, July 29, 1999 8:24 AM To: toasters(a)mathworks.com Subject: File Ownership Has anyone had the problem of Microsoft Word or Excel file writes taking over ownership of a file? I have a 720 at OS version of 5.1.2R3 running both the NFS and CIFS protocols. The filer contains only the root volume which has multiple qtrees of UNIX style security. Scenario: CIFS user#1 creates a Microsoft Word document which has write access at the UNIX group level. CIFS user#2, who is in the same UNIX group, modifies the file and automatically becomes the UNIX owner of the file. This works the same for Excel documents but not for text documents using Notepad. All help is appreciated. Ken

1 0

RE: Linux, Samba and CIFS
by Benn, Paul 29 Jul '99

29 Jul '99

You might want to consider upgrading to Data ONTAP 5.3.2. The smbmount command works with that version. Out of curiosity, is there any reason that you would rather use CIFS than NFS to connect from a Linux box (assuming your filer is licensed for both)? Regards, Paul -----Original Message----- From: Sam Schorr [mailto:sschorr@homestead.com] Sent: Thursday, July 29, 1999 10:49 AM To: 'Benn, Paul'; Sam Schorr; 'toasters(a)mathworks.com' Cc: Stephen Wu; Mike Mcnelly Subject: RE: Linux, Samba and CIFS We are using Samba 2.0.3-8. the filers are running 5.2.1P2D6. -----Original Message----- From: Benn, Paul [mailto:paul.benn@netapp.com] Sent: Thursday, July 29, 1999 10:46 AM To: 'Sam Schorr'; 'toasters(a)mathworks.com' Cc: Stephen Wu; Mike Mcnelly Subject: RE: Linux, Samba and CIFS What are you using to mount the share? What version of Data ONTAP are you using? Regards, Paul -----Original Message----- We're trying to get a Linux box, using Samba, to mount an NT share to our filers. We have been, quite successfully, accessing the filers from the NT domain they are in using normal UNC share names. We have also, successfully, mounted NT shares from the Linux box using Samba. The failure seems to be in some area of authentication on the part of the filers that is somehow unique to them as other NT systems are quite happy talking to the Linux/Samba mount.

1 0

RE: Linux, Samba and CIFS
by Sam Schorr 29 Jul '99

29 Jul '99

We are using Samba 2.0.3-8. the filers are running 5.2.1P2D6. -----Original Message----- From: Benn, Paul [mailto:paul.benn@netapp.com] Sent: Thursday, July 29, 1999 10:46 AM To: 'Sam Schorr'; 'toasters(a)mathworks.com' Cc: Stephen Wu; Mike Mcnelly Subject: RE: Linux, Samba and CIFS What are you using to mount the share? What version of Data ONTAP are you using? Regards, Paul -----Original Message----- We're trying to get a Linux box, using Samba, to mount an NT share to our filers. We have been, quite successfully, accessing the filers from the NT domain they are in using normal UNC share names. We have also, successfully, mounted NT shares from the Linux box using Samba. The failure seems to be in some area of authentication on the part of the filers that is somehow unique to them as other NT systems are quite happy talking to the Linux/Samba mount.

1 0

RE: Linux, Samba and CIFS
by Benn, Paul 29 Jul '99

29 Jul '99

What are you using to mount the share? What version of Data ONTAP are you using? Regards, Paul -----Original Message----- We're trying to get a Linux box, using Samba, to mount an NT share to our filers. We have been, quite successfully, accessing the filers from the NT domain they are in using normal UNC share names. We have also, successfully, mounted NT shares from the Linux box using Samba. The failure seems to be in some area of authentication on the part of the filers that is somehow unique to them as other NT systems are quite happy talking to the Linux/Samba mount.

1 0

CIFS Remote Backup Options
by Mohler, Anissa 29 Jul '99

29 Jul '99

I am working on design of a backup system for our F740 filer (100G usable) in a CIFS environment. At this time we have no plans on directly attaching a tape backup device to the filer. Our current enterprise backup solution is ARCserve 6.5 (on NT). I have the White Paper on NT Backups and am wondering what is actually in use in the field. Are there any gotcha's I need to watch out for? Any best practices out there? Thanks! Anissa Mohler amohler(a)mail.bokf.com BOKf Network Services Group

1 0

RE: Strange routing problem.
by Mohler, Jeff 29 Jul '99

29 Jul '99

Ok, Ive double checked /etc/netmasks (already was there) /etc/notrouter, /etc/defaultrouter (already was there) changed mac addresses on qfe0-qfe3 so the switch doesnt look at all five interfaces on the machine as one MAC, dbl checked VLAN configs on the Cat 5505 ports.. Still, the Sun wants BADLY to route 10.16.118.0 traffic across the public hme0 interface, instead of the up/configured/plugged-in 10.16.118.23 interface. Darnit.. --- Did you make a /etc/notrouter file on your solaris box? This prevents the Solaris box from becoming a router at boot time. And how about /etc/netmasks? I would put two entries in just to be safe: 10.16.118.0 255.255.255.0 10.16.119.0 255.255.255.0 --tmac Timothy A. McCarthy --> System Engineer, Eastern Region. Network Appliance http://www.netapp.com 301-230-5847 Office \ / Page Me at:@@ 301-230-5852 Fax \/ 800-654-9619 On Mon, 26 Jul 1999, Mohler, Jeff wrote: > Greetings: > > I have a routing problem on a 2.6 box, here is the detail. > > I want to send traffic out to 10.16.118.20 on qfe0, which will be a private > 10/100 segment to the NetApp for NFS traffic. I am only using 10.16.118.0 > in this message, because 119.0 does the same thing on qfe1. > > This is a prototype box to configure and test first, then deploy to the > field installed Solaris machines. > > The network is like this: > > > NETAPP-F760:e0 public interface connected to 3/1 on a Cat 5505 Switch, on > VLAN 223 (public addressed traffic) > NETAPP-F760:ech1 channel of e1a and e1b on 10.16.118.0 on 5/1-2 > (channel) on VLAN 118 - 10.16.118.10 > NETAPP-F760:ech2 channel of e1c and e1d on 10.16.119.0 on 5/3-4 > (channel) on VLAN 119 - 10.16.119.10 > > On the sun box I have: > > Sun:e0 public interface connected to 3/2 on Cat 5505 on VLAN 223 > Sun:qfe0 10.16.118.23 connected to 3/15 on Cat 5505 on VLAN 118 > Sun:qfe1 10.16.119.23 connected to 3/16 on Cat 5505 on VLAN 119 > Sun:qfe2 10.16.254.23 not yet connected for ADSM traffic > Sun:qfe3 10.16.3.117 connected to management LAN > > > The interface is up, here is netstat output: > > Routing Table: > Destination Gateway Flags Ref Use Interface > -------------------- -------------------- ----- ----- ------ --------- > 151.142.223.0 151.142.223.53 U 2 282 hme0 > 10.16.118.0 10.16.118.23 U 2 5351 qfe0 > 10.16.119.0 10.16.119.23 U 2 0 qfe1 > 10.16.3.0 10.16.3.117 U 2 3 qfe3 > default 151.142.223.1 UG 0 129 > 127.0.0.1 127.0.0.1 UH 0 4 lo0 > > A traceroute to 10.16.118.10 shows the machine choosing hme0 for a > route...why? > > # traceroute 10.16.118.10 > traceroute: Warning: ckecksums disabled > traceroute: Warning: Multiple interfaces found; using 151.142.223.53 @ hme0 > > > I have an NFS mount on the Sun box to the filer using the 10.16.118.10 > address, and it even shows up as the propler hostname:/<path> in the 'df' > output. > > I can blow large amounts of dd traffic to/from the mount, and I see NO > traffic on the correct Channel (ech1) on the Filer. > >

4 5

fcal tape drives?
by alexei＠mindspring.net 28 Jul '99

28 Jul '99

Has anyone from NetApp started playing with the FCAL tape libraries, like the ones from ADIC or Spectralogic? Support for the Spectralogic Bullfrog would be very cool. Alex

1 0

RE: Strange routing problem.
by Mohler, Jeff 28 Jul '99

28 Jul '99

Yes, /etc/netmasks: 10.16.3.0 255.255.255.0 10.16.118.0 255.255.255.0 10.16.119.0 255.255.255.0 10.16.254.0 255.255.255.0 151.142.223.0 255.255.255.0 I didnt know about the /etc/notrouter option...nothin like learning a little everyday! Anyway, rebooting. And... # traceroute 10.16.118.10 traceroute: Warning: ckecksums disabled traceroute: Warning: Multiple interfaces found; using 151.142.223.53 @ hme0 traceroute to 10.16.118.10 (10.16.118.10), 30 hops max, 40 byte packets 1 *^C# Still there. -----Original Message----- From: Tim McCarthy [mailto:tmac@netapp.com] Sent: Monday, July 26, 1999 10:23 AM To: Mohler, Jeff Cc: toasters(a)mathworks.com Subject: Re: Strange routing problem. Did you make a /etc/notrouter file on your solaris box? This prevents the Solaris box from becoming a router at boot time. And how about /etc/netmasks? I would put two entries in just to be safe: 10.16.118.0 255.255.255.0 10.16.119.0 255.255.255.0 --tmac Timothy A. McCarthy --> System Engineer, Eastern Region. Network Appliance http://www.netapp.com 301-230-5847 Office \ / Page Me at:@@ 301-230-5852 Fax \/ 800-654-9619 On Mon, 26 Jul 1999, Mohler, Jeff wrote: > Greetings: > > I have a routing problem on a 2.6 box, here is the detail. > > I want to send traffic out to 10.16.118.20 on qfe0, which will be a private > 10/100 segment to the NetApp for NFS traffic. I am only using 10.16.118.0 > in this message, because 119.0 does the same thing on qfe1. > > This is a prototype box to configure and test first, then deploy to the > field installed Solaris machines. > > The network is like this: > > > NETAPP-F760:e0 public interface connected to 3/1 on a Cat 5505 Switch, on > VLAN 223 (public addressed traffic) > NETAPP-F760:ech1 channel of e1a and e1b on 10.16.118.0 on 5/1-2 > (channel) on VLAN 118 - 10.16.118.10 > NETAPP-F760:ech2 channel of e1c and e1d on 10.16.119.0 on 5/3-4 > (channel) on VLAN 119 - 10.16.119.10 > > On the sun box I have: > > Sun:e0 public interface connected to 3/2 on Cat 5505 on VLAN 223 > Sun:qfe0 10.16.118.23 connected to 3/15 on Cat 5505 on VLAN 118 > Sun:qfe1 10.16.119.23 connected to 3/16 on Cat 5505 on VLAN 119 > Sun:qfe2 10.16.254.23 not yet connected for ADSM traffic > Sun:qfe3 10.16.3.117 connected to management LAN > > > The interface is up, here is netstat output: > > Routing Table: > Destination Gateway Flags Ref Use Interface > -------------------- -------------------- ----- ----- ------ --------- > 151.142.223.0 151.142.223.53 U 2 282 hme0 > 10.16.118.0 10.16.118.23 U 2 5351 qfe0 > 10.16.119.0 10.16.119.23 U 2 0 qfe1 > 10.16.3.0 10.16.3.117 U 2 3 qfe3 > default 151.142.223.1 UG 0 129 > 127.0.0.1 127.0.0.1 UH 0 4 lo0 > > A traceroute to 10.16.118.10 shows the machine choosing hme0 for a > route...why? > > # traceroute 10.16.118.10 > traceroute: Warning: ckecksums disabled > traceroute: Warning: Multiple interfaces found; using 151.142.223.53 @ hme0 > > > I have an NFS mount on the Sun box to the filer using the 10.16.118.10 > address, and it even shows up as the propler hostname:/<path> in the 'df' > output. > > I can blow large amounts of dd traffic to/from the mount, and I see NO > traffic on the correct Channel (ech1) on the Filer. > >

3 2

RE: Non-NDMP backup solutions?
by Melvin, Grant 27 Jul '99

27 Jul '99

Hi, All BudTool and BudTool related products have a release directory on the old Intelliguard ftp site, ftp.iguard.com. They are all accessible via anonymous ftp login. The path to the patches is: pub/dist/patch/<PRODUCT>/<VERSION>/<PATCH#> Cheers, Grant -----Original Message----- From: Jay Orr [mailto:orrjl@stl.nexen.com] Sent: Tuesday, July 27, 1999 12:44 PM To: Rajeev Agrawala Cc: toasters(a)mathworks.com Subject: RE: Non-NDMP backup solutions? Where can budtool patches be obtained from? While we have support and a login for PDC solutions, they don't have the patches... > I am running 5.2.2P1 (recommended release from netapp) on my toaster. > For backups I am using budtool with ndmp for my toaster. I upgraded my > budtool installation from 4.5 to 4.6 with patches 1,3,4,5,10,11,14,17. ----------- Fujitsu - Nexion, St. Louis, MO Jay Orr (314) 579-6517

1 0

(no subject)
by CATULLO＠aol.com 27 Jul '99

27 Jul '99

unsubscribe toasters

1 0

RE: Non-NDMP backup solutions?
by Rajeev Agrawala 27 Jul '99

27 Jul '99

Hi, After reading this thread, it seems that ndmp is the way to go and most of the incompatibilities between various vendors have been taken care off. I am quoting some from parts from this thread below and at the end I am putting my most recent experience with ndmp which was today itself. "Shaun Erickson" wrote: > Because of the frequent upgrades, (which continue to happen, but for > other reasons) we frequently ran into problems because of > incompatibilities between NetApp's implementation of NDMP and BudTool's. > Then, when we'd try to get support, we were always told that the version > of Ontap we were running wasn't certified with BudTool, so it was always > a major pain to get support. To be fair, BudTool broke NDMP on occasion, > as well, with their upgrades. The end result was the same, however. > > "Melvin, Grant" wrote: > I believe this effort has paid off and that we have fixed > our issues in 5.2.*. For 5.3 we ported the NDMP server to > run in the Java Virtual Machine & support V3. Results so > far have shown some bugs, reported on toasters, but these > have been fixed and we have a very stable product. > I am running 5.2.2P1 (recommended release from netapp) on my toaster. For backups I am using budtool with ndmp for my toaster. I upgraded my budtool installation from 4.5 to 4.6 with patches 1,3,4,5,10,11,14,17. The upgrade broke the file history creation/merge part only for my toaster which is using ndmp. For other file systems (Sun/Irix) file history is working fine. I called Intelliguard (now Legato) for support. First thing the support person does is to point me to their certification matrix ( http://www.iguard.com/products/certmatrix1.html ) which does not have any mention of ONTAP 5.2.2 and hence it is not supported. The person tells me that I am out of luck unless I run a supported version. I pointed the person to the piece of code which was broken, and responsible for the problem, the support person agreed to look at that but at the same told me that no change to budtool code can be made for an *Unsupported* ONTAP release which coincidentally is the **Recommended release** from netapp. I guess, that speaks a lot about **COORDINATION**. The choice I have is to either upgrade to an early access relase (5.3.1), which I won't do on a production toaster, or move away from ndmp. rajeev

2 1

Jump to page:

2026

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