Network and Storage Protocols - Page 39

Rowl · ‎2017-04-04

Ran into a strange problem here, hoping someone can point me in the right direction. We have two Windows 2008 R2 servers that are unable to access a UNC path to an SVM when using the DNS name of the lif. The connection works fine if connecting to the ip address. From these windows servers I can connect to shares by name on other NAS products, and random Windows clients. From these two servers \\svm\share$ fails \\svm.our.dom.com\share$ fails \\10.1.1.1\share$ works (assume 10.1.1.1 is address of lif) \\othernas\share$ works \\windowsServer\share$ works From other Windows clients \\svm\share$ works I checked that the Windows firewall is disabled, credentials cache is empty, time is in sync with AD. Flushed the DNS cache too. So it appears I only have a problem connecting to Netapp CIFS share by name from these two servers. Connecting by ip works, so doesn't look like firewall is blocking me. I know there is a difference in authentication when connecting my address rather than by name, but the details are not clear to me. Something about NTLM vs Kerberos. Thanks -Rowl

craffael · ‎2017-03-08

Hello, I have recently setup a CIFS Server by following this guide https://library.netapp.com/ecm/ecm_get_file/ECMLP2494081 Symptoms: - I can access the CIFS endpoint from windows explorer by typing the IP: \\10.111.112.7 works. - I cannot access the CIFS endpoint from Windows Explorer by specifying the NetBios name: \\ServerS7 doesn't work. - I cannot resolve the NetBios name from a windows workstation: nbtstat -a ServerS7 doesn't find anything - in the OnTap CLI, ::> vserver cifs nbtstat This table is currently empty. To me it looks as if the NetBios/WINS service on the Netapp that should respond to NetBios queries is not running/doesn't accept requests. I've tried to recreate the CIFS Server a few times now (by following the previously mentioned manual) but that doesn't help anything. Here are some more configuration infos: ::> vserver show -vserver svm_cifs Vserver: svm_cifs Vserver Type: data Vserver Subtype: default Vserver UUID: 15dac770-ff50-11e6-9afb-00a098c6d0c7 Root Volume: svm_cifs_root Aggregate: AGGR_01_Node1_Links_SAS NIS Domain: - Root Volume Security Style: ntfs LDAP Client: - Default Volume Language Code: C.UTF-8 Snapshot Policy: default Comment: Quota Policy: default List of Aggregates Assigned: - Limit on Maximum Number of Volumes allowed: unlimited Vserver Admin State: running Vserver Operational State: running Vserver Operational State Stopped Reason: - Allowed Protocols: cifs Disallowed Protocols: nfs, fcp, iscsi, ndmp Is Vserver with Infinite Volume: false QoS Policy Group: - Caching Policy Name: - Config Lock: false IPspace Name: Default Foreground Process: - ::> vserver cifs show -vserver svm_cifs Vserver: svm_cifs CIFS Server NetBIOS Name: SERVERS7 NetBIOS Domain/Workgroup Name: xxx Fully Qualified Domain Name: xxx.LOCAL Organizational Unit: CN=Computers Default Site Used by LIFs Without Site Membership: Workgroup Name: - Authentication Style: domain CIFS Server Administrative Status: up CIFS Server Description: List of NetBIOS Aliases: - After spending more than a day on this issue, I've run out of ideas on how to debug this. Do you have an idea on what could be the problem? Raffael

TSunsLV

After upgrade to 9.9.1 evet log is full with theses errors: ERROR nblade.execsOverLimit: The number of in-flight requests from client with source IP x.x.x.x to destination LIF x.x.x.x (Vserver 18) is greater than the maximum number of in-flight requests allowed (128). The client might see degraded performance due to request throttling. I have already made changes as NetApp KB suggests on NetApp side. But, i can't really find, what settings I must change on VMWare ESX. NFS.MaxQueueSize = 64 , is this one? VMWare is 7.x version.

terryzolinski · ‎2015-03-13

FAS8040 CDOT 8.2.2, 10 GBe, Windows Server 2012 R2. We are currently working on an Exchange server deployment with a "consultant". To put it bluntly, these guys can't answer a simple question about a key piece of the puzzle, the fabric from the hosts to the storage. Building an iSCSI design using a single subnet and dedicated NICs on the servers. The NetApp side is configured properly, using LACP LIFs, creating two target IP addresses. I initially tried to set this up using a single subnet and MPIO, with dual NICs not teamed (each NIC was standalone on the same subnet). Ex. NetApp Targets: LIF1: 192.168.110.180, LIF2: 192.168.110.181 Windows NICs: NIC1: 192.168.110.235, NIC2: 192.168.110.237 The world I come from I'm used to using two separate subnets, so 192.168.110.180, 192.168.111.180 as an example. With the config intially setup, if I disable a port on the switch (or unplug the cable) there is a 30 second timeout before Windows flips over to use the other NIC. So, even though MPIO is setup properly, we still need to wait for Windows to flip to use the other NIC. To me this config doesn't have 2 active paths, but rather one active and one standby. The 30 second convergence time on the Windows host is what I'm trying to solve. This timeout only occurs when simulating a NIC failure on the Windows Server. I haven't found a design document which discusses this exact config, using a single subnet without teaming, which is why I'm coming to the forum. I'm still waiting for the consultant to come back with what their client's have done, but that was weeks ago. Now, I can reconfigure this as LACP or I can configure this to use two subnets. But I'd also like to find out what this consultant is talking about to see if they are even on the right track and there is just a small piece missing. So, LACP will solve this problem I would assume, however I just want to see if anyone else has built a design like this to see if there is just something I'm missing. It's rather disappointing that our consultants recommend a design they can't even explain why it was recommended, nor can they provide any information on how to build out the fabric to our Windows hosts. Thanks in advance.

DanielK · ‎2021-09-07

Hello I have tried scanning a source share for an NFS export without options and it works without problems. However if I try creating an index like this: scan -loglevel DEBUG -newid scanindex1 source.nfs.server:/share it progresses until some point (usually somewhere around 400K and then just endlessly loops through retries 404,246 scanned, 14 retries, 77.4 MiB in (0/s), 3.28 MiB out (0/s), 1m12s Every once in a while a message like this appears xcp: Reopener (19128 isChild False) '192.16.199.2 tcp 2049 nfs3 c0': WARNING: reconnecting... 22 pending requests xcp: Reopener (19128 isChild False) '192.16.199.2 tcp 2049 nfs3 c0': WARNING: reconnected in 0.030s after 1 try during 0s The address 192.16.199.2 is the server where the catalog share resides and also the target storage FAS8300. I can mount the catalogue share and I also see that my catalog ID is created there with all kinds of files but they are all empty. Can anyone help me with this. It also happens when I try to copy and it makes the XCP tool unfortunately completely unusable. I used the old version 1.4 before without any problems, but this new version appears to work differently. Thanks in advance

Board Activity

Unable to access CIFS share by name

OnTap 9.1: CIFS Server NetBios not working

nblade.execsOverLimit: The number of in-flight requests from client with source IP x.x.x.x

iSCSI Network Design - Windows Physical Server

XCP 1.7 hangs when creating index

INSIGHT 2021 Digital: Meet the Specialists 2

We're on Discord, are you?

Meet Explore, NetApp’s digital sales platform