toasters

toasters@lists.teaparty.net

13515 discussions

Does your e0 on the F330 work? HELP
by Daniel Wong 18 Sep '98

18 Sep '98

To all you wonderful workers of magic: I've been using FDDI on f7 just fine, but management decided to go Fastethernet (dropping FDDI) and I can't get e0 to link with our Cisco Catalyst 5000 at either 10 or 100, half or full. Laptop links OK, e0 can't ping anything on the new subnet except itself. Brought down f7 and ifconfiged e0 with f7's IP and same problem. Thus, dgateway and route hasn't changed => must be e0, right? Does anybody know what I'm not doing? I've already tried my spare motherboard and have an RMA for another board here by my side. Config: F330, 256MB, 8MB NVRAM, NetApp Release 4.2a Dual Attached FDDI, no ethernet card. Thanks in advance, Dan -- Daniel E Wong GIS System/Network Administrator City of Spokane mailto:dewong@sprintmail.com 808 W Spokane Falls Blvd mailto:dwong@spokanecity.org Spokane WA 99201-3344 (o) 509/625-6499 (fax) 509/625-6550

1 0

F740 and Exchange
by Jason Middlebrooks 18 Sep '98

18 Sep '98

Is there anything special that has to be done for a 740 filer and Microsoft Exchange to work together? Jason Middlebrooks Systems Engineer Direct Connect Systems 2264 Northwest Parkway, Suite I Marietta, GA 30067 Phone: 770-933-9327 x260 Email: jason(a)directconnect.com <mailto:jason@directconnect.com> Pager: 888-502-1625 Web: www.directconnect.com <http://www.directconnect.com> Fax: 770-933-9272

2 1

Long filenames with Digital Unix and Network Appliance
by David B. Ritch 18 Sep '98

18 Sep '98

We are experiencing a repeatable problem when creating files with long filenames under Digital Unix 4.0 on a filesystem mounted from a NetApp filer. The files are not visible until the filesystem is remounted - that is, when you create the files, you cannot see them. If you mount the filesystem at another mount point, unmount it or remount it, or simply look at it on another nfs client, you can see the files. This apparently only happens when using nfs version 3. We have observed this bug only between a Digital Unix 4.0 (4.0A and 4.0D, at least) client an a NetApp server. We have tested Solaris 2.5 and 2.6 clients, Digital Unix, NetApp, Auspex, and Solaris servers. Anyone have an idea what could cause this? Naturally, the first response from Digital is that it is likely to be a NetApp problem, and the first response from NetApp is that it is likely to be a Digital Unix problem. Any suggestions on how to determine where the problem lies? Here is a script from a DEC support person that demonstrates the problem: -------------------- !#/bin/csh # create a log of datafiles and links to test nfs problem while ( $num < 100 ) @ num = $num + 1 cat /etc/printcap > reallyreallyverylongnamedatafile.$num ln -s reallyreallyverylongnamedatafile.$num 1.$num echo "$num is done" end echo done exit -------------------- When you run it, it should generate 100 files and 100 links. You should be able to run the script, and then "ls | wc" and see about 200 words. When the bug appears, you see only ~160 words. However, you can run the "ls | wc" on another nfs client mounting the same filesystem, and see the expected 200 words. Thanks, David Ritch

6 6

Re: Long filenames with Digital Unix and Network Appliance
by Ketil Kirkerud Elgethun 17 Sep '98

17 Sep '98

"David B. Ritch" <dbritch(a)Home.com> writes: > > We are experiencing a repeatable problem when creating files with long > filenames under Digital Unix 4.0 on a filesystem mounted from a NetApp > filer. The files are not visible until the filesystem is remounted - [...] > We have observed this bug only between a Digital Unix 4.0 (4.0A and > 4.0D, at least) client an a NetApp server. We have tested Solaris 2.5 > and 2.6 clients, Digital Unix, NetApp, Auspex, and Solaris servers. I tested this right now, on a Digital Unix 4.0D client, mounting a F330/5.1R1, and I can't reproduce your problem. (mountopts are v3, rw, nosuid, udp, hard, intr) > > Anyone have an idea what could cause this? Sounds a bit like a caching/cache synchronization problem on the client. > Naturally, the first response from Digital is that it is likely to be a > NetApp problem, and the first response from NetApp is that it is likely > to be a Digital Unix problem. Any suggestions on how to determine where > the problem lies? If, as you say, the files are actually visible on a different client, then I'd suggest you do a snoop/tcpdump to try to see what the DU client asks for during the 'ls'. -- ---Ketil Kirkerud Elgethun, SOL System

2 1

Re: Bad HD
by Jay Sekora 10 Sep '98

10 Sep '98

Leila wrote: > Is it true that when one HD goes bad, it will be reconstructed on the > hotspare, but if you don't pull out bad HD and replace it within the 24 > hours system will shutdown? Not quite; you're confusing two separate things. When a drive fails, the system goes into `degraded' mode. (A second drive failure in the same RAID group at this point will result in loss of data.) When the system is in degraded mode, it will immediately start copying data to a hot spare (*if* one is available!) to replace the failed drive. When that process is complete, the system is no longer in degraded mode, because the hot spare has been made a part of the RAID group, so the RAID group is no longer down a disk. (Of course, though, the whole system is now down one hot spare.) This can be a somewhat lengthy process, depending on the size of the RAID group. What you're thinking of is that by default, if the system has been running in degraded mode for 24 hours (i.e. if a drive failed 24 hours ago and hasn't been replaced either by a hot spare or a new disk), the system will shut down. I think the idea is to reduce the likelihoood of data loss caused by a second disk failure (and make sure the admin knows that something's wrong). At least under 5.1, you can adjust the time limit, so for instance you could make it long enough to cover a long weekend, or if a system were under 24x7 supervision, you could shorten it. Unless your RAID groups are too large and your machine is very heavily loaded, the only case where you're likely to stay in degraded mode for 24 hours (and risk the machine shutting down) is if you *don't* have a hot spare, so the rebuild can't happen. AFAIK, there's no problem leaving a bad drive sitting in the shelf arbitrarily long, as long as you don't need the drive bay for something else (unless the drive is bad in a way that might affect other drives, like if flames or sparks are coming out of it :-). > What happens in a case if you have 2 hotspare? In the normal case, it doesn't make any difference to this scenario, except that you end up (before you physically replace drives) with one hot spare instead of zero. It means if another drive fails *after the RAID group has been rebuilt*, there's a hot spare to replace it. Also, if a drive fails in a different RAID group, you should be OK. -j. -- Jay Sekora <jay(a)ccs.neu.edu> Northeastern University College of Computer Science

2 1

A netapp failover possibility...???
by ian.gardner＠vf.vodafone.co.uk 10 Sep '98

10 Sep '98

Hi, We have two netapp filers serving mainly static data (updated overnight) to several hp-ux clients. If one server fails we can swap the clients onto the other server by mounting and switching symbollic links. eg. on a client: /discs/data -> /netapp1/data If netapp1 fails we mount data from netapp2 and relink: /discs/data -> /netapp2/data Now this leaves processes hanging on the dead server which can be killed using fuser -k netapp1:/data. This is only necessary if memory/swap on the clients is tight, otherwise the "hung" processes will sleep until the server comes back. This is not ideal so I had a thought, since we have Quad 100BaseT cards, in the event of a failure, we could configure up a spare port to be the same name and IP address as the dead server and therefore take over the nfs requests for it. Since we are LIVE I am unable to test this, but subject to the routers and arp tables becoming updated I would have thought this would work. I'm not sure about file locking, but I didn't think this works very well on nfs anyway - does it ? NFS is stateless so it should be ok. Anyone out there tried this or able to on a couple of test boxes ? Cheers Ian Gardner Vodafone Ltd. Newbury UK. ian.gardner(a)vf.vodafone.co.uk

2 1

Re: Bad HD
by sirbruce＠ix.netcom.com 09 Sep '98

09 Sep '98

On 09/09/98 09:36:36 you wrote: >AFAIK, there's no problem leaving a bad drive sitting in the shelf >arbitrarily long, as long as you don't need the drive bay for something >else (unless the drive is bad in a way that might affect other drives, >like if flames or sparks are coming out of it :-). One gotcha is that if you leave a bad drive sitting in the shelf, and the system reboots, it could think the drive is a hot spare and allow it to be used again. I don't think this happens in all circumstances (I think there's a way to mark the drive bad such that it won't be used), but it certainly can (and has) happened in the past. So it's generally a good idea to remove the bad drive from the shelf as soon as possible. Bruce

1 0

SUMMARY: "Calling all F630/FC-AL users"
by just me. 09 Sep '98

09 Sep '98

Well, its been a week, and as such I suppose time for a summary. Last week, I posted the following request for comments: If you are a NetApp F630/FC-AL user and have encountered any (especially recurring) glitches with interactions between the Fibre Channel host adapter and OnTAP, or recurring FC hardware failures I'd appreciate hearing from you. On the flip side, if you are a NetApp F630/FC-AL user and have seen perfect performance from your filer, I'd love to hear about it too. I was surprised to get only 5 responses, one from a fellow considering buying one. Out of the four owners that mailed me, two reported flawless performance, one mentioned problems caused by extreme environmental conditions, and one reported RAID bugs similar to the ones I had seen. Netapp replaced his shelf, as did they mine. I will post an update after we have the new shelf installed if there are any other notables. Their comment on the problem was "the low-level FC/SCSI system was unaware of a particular error sequence and was passing error codes to the RAID level where they caused a panic." They also recommended upgrading to 5.0.2D4. There were some other FC fixes rolled into 5.0.2, I'm not sure if there are additional ones in D4. Steve Clarke <Steven.Clarke(a)ThePLAnet.net> pointed out, "It has been my opinion for a while that there are people at NetApp who can make things happen and others who just make the right noises but do nothing." This has been my experience, too. However once I've been put in touch with the Clueful Folk, they have been dedicated above and beyond the call to resolving my issues. I've heard mumblings out-of-band about the usual low morale problems among their tech support staff and I sincerely hope that Netapp management recognise their amazing dedication. Thanks to Steven Clarke, Matt Stein, Fritz Feltner and Graham Knight for their time responding to my post. Alohas, matto --matt(a)snark.net----------------------------------------------------- Matt Ghali MG406/GM023JP - System Administrator, interQ, Inc AS7506 "Sub-optimal is a state of mind." -Dave Rand, <dlr(a)bungi.com>

1 0

Re: Bad HD
by Daniel Quinlan 08 Sep '98

08 Sep '98

leila.mutevelic(a)rss.rockwell.com writes: > Is it true that when one HD goes bad, it will be reconstructed on the > hotspare, but if you don't pull out bad HD and replace it within the 24 > hours system will shutdown? No, it's not true. > What happens in a case if you have 2 hotspare? If your system has run out of spares and a disk fails, it will be in degraded mode until you replace one or more spares. If an additional disk fails while in degraded mode, you are hosed. Having two spares helps protect you from a second disk failure, as long as that second failure happens after the first reconstruction has finished. However, even with two hot spares, I would recommend replacing replacing failed disks with new spares as soon as possible. - Dan

1 0

Re: Bad HD (fwd)
by beepy＠netapp.com 08 Sep '98

08 Sep '98

I think our system goes into 'degraded' mode when no spare is present. I'm the degenerate. (some mail misaddresses running around.) > Not quite. A failed disk will send the system into 'degenerated' mode if > there is no spare present. The system will shut down after 24 hours in > degenerated mode as a failsafe. However, if a spare disk *is* present, the > system goes into 'reconstruction' mode and rebuilds the failed disk. Once > reconstructed the system is back up and running as usual with no threat of > a failsafe shutdown. > If you have 2 hot spare disks, and one is used to rebuild a failed disk, > then you will have one spare disk remaining. > > leila.mutevelic(a)rss.rockwell.com wrote: > > > Is it true that when one HD goes bad, it will be reconstructed on the > > hotspare, but if you don't pull out bad HD and replace it within the 24 > > hours system will shutdown? > > What happens in a case if you have 2 hotspare? > > > > Thanks, > > --Leila. > > > > -- > Shannon Madison <shannon(a)netapp.com> > Technical Education Manager > > Network Appliance, Inc. > 2770 San Tomas Expressway > Santa Clara, CA 95051 > USA > > Work: (408) 367-3574 > Fax: (408) 367-2151 > > The usual disclaimers apply. > > ----- End of forwarded message from Brian Pawlowski -----

1 0

Bad HD
by leila.mutevelic＠rss.rockwell.com 08 Sep '98

08 Sep '98

Is it true that when one HD goes bad, it will be reconstructed on the hotspare, but if you don't pull out bad HD and replace it within the 24 hours system will shutdown? What happens in a case if you have 2 hotspare? Thanks, --Leila.

2 1

OnTap
by Wm Kevin Shaw 08 Sep '98

08 Sep '98

What is the latest and most stable version of OnTap for a F630 (Non F-CAL)? What configuration issues and bugs should I be aware of? Any Info on configuring CIFS for this version of OnTap would also be appreciated. Thanks in advance. Kevin

1 0

what is the safest way to shutdown the system?
by leila.mutevelic＠rss.rockwell.com 08 Sep '98

08 Sep '98

What would be the safest way to shutdown the system? Thanks, --Leila.

3 2

CODA support on NetApp
by Dan Bethe 06 Sep '98

06 Sep '98

Hi there everyone. What is the likelihood of NetApp ever supporting the CODA filesystem? http://www.coda.cs.cmu.edu Thanks! ` ~ ^ ' ~ ' ` ^ ~ ~ ^ ' ~ ` ` ~ ' ^ ` ~ ~ ` " ` ~ ' ^ " ^ ` ~ ' ~ ^ " ' ~ ` ^ ~ "If I seem too inconclusive, well it's just because it's so elusive." This email has been licensed by the GPL (http://www.gnu.org/philosophy) Dan ((((now seeking a Linux/Unix sysadmin job in Silicon Valley!)))) Bethe

5 6

Re: CODA support on NetApp
by Daniel Quinlan 05 Sep '98

05 Sep '98

Dan Bethe <dtm(a)hex.net> writes: >> Hi there everyone. What is the likelihood of NetApp ever >> supporting the CODA filesystem? >> http://www.coda.cs.cmu.edu Brian Pawlowski <beepy(a)netapp.com> writes: > As in grandson of AFS, disconnected operation? > > I'm curious, who is supporting it now? Many of our engineers who encounter problems using NFS have asked us about CODA and AFS. I am more interested in fixing some of the problems we encounter with NFS rather than introducing new ones, but CODA might be the answer. So, does NetApp have a better answer? - Dan

1 0

volumes and RAID groups
by Brian Rice 05 Sep '98

05 Sep '98

I just got in an F630 with 5.0.2 and four fully-loaded differential shelves. Yowza. It showed up with one volume, vol0, two RAID groups (one for each pair of shelves, I guess), and only two disks in use, in vol0. I want to live dangerously, with one big volume and one RAID group for it. After all, that's how my other F630's running 4.x are configured, and it's worked fine for a long time. So naturally I did something stooopid. I (a) added all the disks, except for a spare, to vol0, (b) set the RAID group size of vol0 to 26, and then (c) noticed in the 5.x documentation that setting the RAID group size AFTER the fact don't do squat. :-( I might have had a prayer if I'd done (b) then (a). Here's what I have now: pacer> sysconfig -r Volume vol0 RAID group 0 RAID Disk HA.Disk_ID Used (MB/blks) Phys (MB/blks) --------- ---------- -------------- -------------- parity 8b.13 8600/17612800 8683/17783240 data 8b.14 8600/17612800 8683/17783240 data 8b.1 8600/17612800 8683/17783240 data 8a.1 8600/17612800 8683/17783240 data 8a.2 8600/17612800 8683/17783240 data 8a.3 8600/17612800 8683/17783240 data 8a.4 8600/17612800 8683/17783240 data 8a.5 8600/17612800 8683/17783240 data 8a.8 8600/17612800 8683/17783240 data 8a.9 8600/17612800 8683/17783240 data 8a.10 8600/17612800 8683/17783240 data 8a.11 8600/17612800 8683/17783240 data 8a.12 8600/17612800 8683/17783240 data 8a.13 8600/17612800 8683/17783240 RAID group 1 RAID Disk HA.Disk_ID Used (MB/blks) Phys (MB/blks) --------- ---------- -------------- -------------- parity 8b.2 8600/17612800 8683/17783240 data 8a.14 8600/17612800 8683/17783240 data 8b.3 8600/17612800 8683/17783240 data 8b.4 8600/17612800 8683/17783240 data 8b.5 8600/17612800 8683/17783240 data 8b.8 8600/17612800 8683/17783240 data 8b.9 8600/17612800 8683/17783240 data 8b.10 8600/17612800 8683/17783240 data 8b.11 8600/17612800 8683/17783240 data 8b.12 8600/17612800 8683/17783240 Spare disks RAID Disk HA.Disk_ID Used (MB/blks) Phys (MB/blks) --------- ---------- -------------- -------------- spare 8b.0 0 8683/17783240 spare 8a.0 0 8683/17783240 And what I want to have is only one RAID group, 0, with one parity and one spare. It looks like I am going to have to clobber vol0 and start over. Am I right? Anybody have experience with offlining then destroying vol0? Brian Rice brice(a)gnac.com

6 7

Re: volumes and RAID groups
by Daniel Quinlan 05 Sep '98

05 Sep '98

Mike Horwath <drechsau(a)tiny.net> writes: > So, with 2 raid groups...it is all still one filesystem? It can be with either one filesystem or two (each one with a single RAID group). There is a nice picture and explanation at: http://www.netapp.com/technology/level3/3027.html To avoid fragmentation problems (as in "I have 50 GB free on one filesystem and 50 GB free on another, but I need 100 GB in one place"), all of our filers are single volume (filesystem). Using multiple RAID groups is a much easier decision. Dan

1 0

Re: volumes and RAID groups
by Brian Rice 05 Sep '98

05 Sep '98

Actually, I thought of another way to get one RAID group: wipe the filer, install 4.x on it, and then uprev it... B-) I am a big fan of having only one configuration, where possible. My other filers are at 4.3.4 right now, and when I upgrade those to 5.1Dx, they will have only one RAID group. I see no reason for this one to be special. My F630's have among them thousands 'n' thousands of hours of run time. I have yet to see a single disk failure, let alone a double-disk failure (knock knock). And I have no plans to put more shelves on them. Finally, if I have one more RAID group, that'll mean one more hot spare plus one more parity disk. When you take into account the purchase of my entire F630, two disks set aside for safety have an opportunity cost (at list prices) of just over $12,000. Is that safety worth $12,000 to me? Well, maybe it is: the not-backed-up-yet data on the rest of a RAID group could exceed $12,000 in replacement value. And maybe it isn't: these failures seem unlikely enough to make that $12,000 feel like earthquake insurance in Bismarck, N.D. Guess this is for me to figure out, huh? Brian

2 1

Re: volumes and RAID groups
by Daniel Quinlan 05 Sep '98

05 Sep '98

hitz(a)netapp.com (Dave Hitz) writes: > But in addition, RAID reconstruction is much faster. When you > reconstruct a failed drive, you have to read all the data on all the > other drives, so if your RAID groups are half as big, then the > reconstruction goes twice as fast. My experience is that reconstruction is more than twice as fast. More like quadruple, depending on server load and size of the RAID group. Does NetApp have recent numbers on reconstruct time? Especially under various NFS loads (reading/writing to disk, not just cache, so the disks are loaded as well). Dan

1 0

Re: volumes and RAID groups
by Daniel Quinlan 05 Sep '98

05 Sep '98

Dave Hitz wrote: >> So at one parity disk per 14 the overhead is 1/14 = 7%, and at one >> parity disk per 26 the overhead is 3.8%. Brian Rice <brice(a)gnac.com> writes: > The cost per usable gigabyte of my F630's has received *considerable* > executive scrutiny recently. So I'm just a leeeetle sensitive about this > kind of thing. You *really* want to use one RAID group per 14 disks. Trust me. Right now, we have 3 F630 systems (40 disk SCSI, 40 disk SCSI, and 26 disk FC). On our first F630, we have a 26 disk RAID group because multiple RAID groups weren't available at the time. On that RAID group, disk reconstructions seem to take forever. Once it took 23 hours, under only moderate load. I tried cranking the raid.reconstruct_speed dial higher (I think I had it set to 3), but then everyone starting getting "nfs server not responding" errors. So, not only are you subject to greater risk during those 23 hours, but your users will complain about how slow everything is (even if the dial is set at 2 or 3). Let's face it, NetApps don't perform very well during disk reconstruction. On a 14 disk RAID group on an F630, the slowest reconstruction we've finished in under 4 hours. The fastest was under 2 hours (on the F630 FC). I guess it's important to note that disk reconstruction speed does not increase linearly. Double the disks in a RAID group and it can easily quadruple the time. Dan

1 0

Re: volumes and RAID groups
by Brian Rice 05 Sep '98

05 Sep '98

Dave Hitz wrote: > So at one parity disk per 14 the overhead is 1/14 = 7%, and at one > parity disk per 26 the overhead is 3.8%. The cost per usable gigabyte of my F630's has received *considerable* executive scrutiny recently. So I'm just a leeeetle sensitive about this kind of thing. > So are you dead-set on living dangerously? Maybe, maybe not. My experience with my existing (identical) F630's suggests I can get away with it. On the other hand, it's bad karma to turn away a life jacket when somebody offers you one "just in case." So I dunno. Let's say, for the sake of argument, that I did decide to live dangerously. So...what's the best way to get a vol0 with one RAID group in it? Brian brice(a)gnac.com

1 0

Re: Support for Network Time Protocol?
by sirbruce＠ix.netcom.com 04 Sep '98

04 Sep '98

On 09/04/98 00:12:22 you wrote: > >I thought this follow-up (to a thread from several months ago) might be >interesting for people at sites that stress time synchronization. > >Daniel Quinlan <quinlan(a)transmeta.com> wrote: > >> To prevent it from happening again, we're remotely monitoring the >> system time of the adminhost (using "mon") to make sure it doesn't >> drift off again. Incidentally, there seems to be no way to remotely >> query the system time from a NetApp (except by creating a new file and >> running stat() on it, or by using unsupported/hidden commands). > >So, I started monitoring the time with the kludgey method of creating a >file and using stat() on it. I wasn't very happy with that method >because it tended to give false alerts, so I eventually disabled it. > >Earlier this week, we had another problem with time synchronization. It >wasn't actually the NetApp, but I still had to rule it out because it >wasn't being monitored. I tried port-scanning a NetApp, looking for some >hidden protocol that might let me reliably query the time. Here's what I >found: > > port tcp udp > ----- ----------- ----------- > 23 telnet - > 80 http - > 111 sunrpc sunrpc > 137 - netbios-ns > 138 - netbios-dgm > 139 netbios-ssn - > 161 - snmp > 514 shell syslog > 520 - route > 602 - unknown > 603 unknown - > 604 - unknown > 605 unknown - > 606 - unknown > 607 unknown - > 608 - unknown > 609 unknown - > 618 - unknown > 619 - unknown > 620 unknown - > 1063 - unknown > 2049 nfs nfs > 10000 unknown - > >A lot of unknown services (ones not listed in /etc/services, some are >probably NDMP. I thought the 600 ports were for rsh, but by they alternate between TCP and UDP, and aren't contiguous, I don't know. I have no idea what 10000 is for. Bruce

4 3

Re: Support for Network Time Protocol?
by Daniel Quinlan 04 Sep '98

04 Sep '98

Daniel Quinlan <quinlan(a)transmeta.com> writes: > I'm also interesting in NTP support, but I think I'd like to see the > current software become a lot more reliable (and complete) before > adding another new feature. All I need is more NetApp crashes because > of NTP bugs. I should add that this happened to us just a few days ago: - xntpd died on our adminhost (that ran the cron job to set the NetApp dates) - time drifted by 8 minutes on the adminhost and the filers over the course over a few days - someone started having problems, managed to figure out that it was because of the time drift, and we fixed it. (Other people probably had problems, but didn't report them.) To prevent it from happening again, we're remotely monitoring the system time of the adminhost (using "mon") to make sure it doesn't drift off again. Incidentally, there seems to be no way to remotely query the system time from a NetApp (except by creating a new file and running stat() on it, or by using unsupported/hidden commands). However, I'm still saying that I don't want NTP until other supported protocols (such as NDMP) start working reliably. Dan

1 1

Calling all F630/FC-AL users
by just me. 02 Sep '98

02 Sep '98

If you are a NetApp F630/FC-AL user and have encountered any (especially recurring) glitches with interactions between the Fibre Channel host adapter and OnTAP, or recurring FC hardware failures I'd appreciate hearing from you. On the flip side, if you are a NetApp F630/FC-AL user and have seen perfect performance from your filer, I'd love to hear about it too. We have had the first F630/FC-AL in Japan in our machine room for the last month or so, and have been through some interesting experiences. Thanks, Matt Ghali --matt(a)bikkle.interq.or.jp------------------------------------------- Matt Ghali MG406/GM023JP - System Administrator, interQ, Inc AS7506 "Sub-optimal is a state of mind." -Dave Rand, <dlr(a)bungi.com>

2 1

Re: Seeing quad 10/100 ethernet ports from NT
by Matt Day 02 Sep '98

02 Sep '98

Cliff Johnson <yrsuser(a)televar.com> wrote: >We have a new F230 installed here (5.1R1, 1.9i firmware), >with a Quad 10/100 card in it. I've configured the 4 ports, >and have no problems talking to (or mounting NFS from) any >of them from the Unix side of the house. > >Unfortunately, the only network connection that shows up >on the NT side of the house is the one on the F230 mother- >board (e0), which is not the one I want the users accessing. > >I can map a network drive using the 4 "other names", (only >if I attach as "nobody", but that's probably another problem), >but I can only "see" the main port in the network neighborhood. >And I'd rather the users not have to memorize the names of the >different ports. > >[..] Hi Cliff, Is your filer's CIFS configured for WINS? If it is, then the filer should be registering all your interfaces with the WINS server using the standard WINS multihomed registration protocol. (This is how a multihomed NT server would register with WINS.) In that situation, CIFS clients that use WINS resolution will choose one of the filer's IP addresses from the registered list. (Depending on the type of client, the address selection algorithm varies; for example, older Microsoft clients tend to choose the address randomly, while NT4 SP3 clients try to be more intelligent. Microsoft's MSDN support web site has some articles detailing this -- try searching for "multihomed" and/or "WINS".) (By the way, as of version 5.1 of Data ONTAP there is a new ifconfig option, "-wins", that can be used to disable WINS registration for a particular interface. It's documented in the na_ifconfig(1) man page. Maybe you should try setting that option on your e0 interface?) If your filer's CIFS is *not* configured for WINS, then CIFS should be broadcasting its presence on each of its interfaces. For example, if you have two interfaces, e0 at 10.0.0.1 and e1 at 192.168.0.1, CIFS will periodically send a broadcast on e0 that reads "FILER is at 10.0.0.1", and on e1 the broadcast will read "FILER is at 192.168.0.1". (Note that each packet only mentions the IP address for its particular interface.) This is how an NT server that isn't configured for WINS would announce itself. Hope that helps some - let me know! Matt Day <mday(a)netapp.com> Network Appliance, Inc.

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