toasters

toasters@lists.teaparty.net

1 participants
13518 discussions

server-ca certs expiring
by cheese＠nosuchhost.net 18 Jun '19

18 Jun '19

hi i have several systems with ontap 9.3P10 and have messages like: 6/12/2019 00:00:01 L1Q-A1 ERROR mgmtgwd.certificate.expiring: A digital certificate with Fully Qualified Domain Name (FQDN) Class2PrimaryCA, Serial Number 85BD4BF3D8DAE369F694D75FC3A54423, Certificate Authority 'Class 2 Primary CA' and type server-ca for Vserver L1Q will expire in the next 25 day(s). what should i do here? my netapp partner told me to renew them via deleteing them and creating new certs. i should create a new server-ca, which is not even an option in ontap (even with advanced privileges) ? i think this must be wrong. i hope others have the same problem and a solution. yours josef

5 7

Is there a best practice for adjust RAID "scrub" options?
by Sylvain Robitaille 05 Jun '19

05 Jun '19

Hello NetApp Gurus. I'm hoping mostly to get some guidance on RAID group scrubbing options and with some luck, perhaps pointers to documentation that would help me determine appropriate values in our environment. We've been seeing what feels like a large number of scrubbing "timeouts" on our filers. Log entries similar to this one: May 28 05:00:02 fc1-ev-n1.console.private [kern.notice] [fc1-ev-n1:raid.scrub.suspended.timer:notice]: Disk scrub suspended because the scrub time limit 240 was exceeded. It will resume at the next weekly/scheduled scrub. What we'd like to know is how concerned we should be about this. Ideally we'd be seeing "scrubs" complete reasonably frequently, but I'm honestly not sure how I could determine how frequently that happens, or how frequently it *should* happen for that matter. The scrub options on the filer have not been changed from the Ontap defaults (NetApp Release 9.5P2, but we've been seeing this with earlier versions as well): Node Option Value Constraint ------- ----------------------- ------ ---------- fc1-n1 raid.media_scrub.rate 600 only_one fc1-n1 raid.scrub.perf_impact low only_one fc1-n1 raid.scrub.schedule none (and the same for the partner node, of course) The "storage raid-options" manual page indicates that the default schedule of daily at 1am for 4 hours, except Sundays when it runs for 12 hours, applies if no explicit schedule is defined. If I examine the scrub status of our aggregates: fc1-ev::> storage aggregate scrub -aggregate * -action status Raid Group:/e1n2_tssd/plex0/rg0, Is Suspended:false, Last Scrub:Thu May 30 02:39:10 2019 Raid Group:/e1n2_t01/plex0/rg0, Is Suspended:true, Last Scrub:Sun May 26 02:55:15 2019, Percentage Completed:65% Raid Group:/e1n2_t02/plex0/rg0, Is Suspended:false, Last Scrub:Thu May 30 02:28:37 2019 Raid Group:/e1n2_root/plex0/rg0, Is Suspended:false, Last Scrub:Thu May 30 03:39:03 2019 Raid Group:/e1n1_root/plex0/rg0, Is Suspended:false, Last Scrub:Wed May 29 02:03:43 2019 Raid Group:/e1n1_d01/plex0/rg0, Is Suspended:true, Last Scrub:Tue May 28 03:22:52 2019, Percentage Completed:7% Raid Group:/e1n1_d01/plex0/rg1, Is Suspended:true, Last Scrub:Wed May 29 02:00:56 2019, Percentage Completed:4% Raid Group:/e1n1_d01/plex0/rg2, Is Suspended:false, Last Scrub:Wed May 29 04:02:50 2019 Raid Group:/e1n1_d01/plex0/rg3, Is Suspended:false, Last Scrub:Wed May 29 04:08:45 2019 Raid Group:/e1n1_d00/plex0/rg0, Is Suspended:true, Last Scrub:Sun Apr 28 06:00:40 2019, Percentage Completed:81% Raid Group:/e1n1_d00/plex0/rg1, Is Suspended:true, Last Scrub:Sun Apr 28 07:38:30 2019, Percentage Completed:80% The truth is I'm not sure how to interpret this output: - Is it the case that each RAID group where "Is Suspended:false" *completed* its scrub at the "Last Scrub" time, while those that are suspended are those for which we're seeing log entries? - Given the default schedule that has the scrub run for 12 hours on Sunday mornings, does it seem odd that /e1n2_t01/plex0/rg0 was suspended last Sunday at 02:55:15, prior to completion? In fact, all those interrupted on a Sunday were interrupted well before 12 hours. Might there be other reasons for suspending scrub operations? The load on this filer is not excessive in any way: CPU utilization is typically comfortably below 50% - How do I determine why the two RAID groups containing e1n1_d00 haven't run scrubbing in over a month? Is there something I should do about that? I've found documentation that explains the options and how to change them, but none that explains how to decide whether I *should* change them, or how to determine what to change them to. I'm interpretting that raid.media_scrub.rate and raid.scrub.schedule could be used together to tune the scrubbing, but am quite unsure how to determine what the best values would be for our filers. Any pointers to documentation that would help here would be hugely appreciated. Thanks in advance ... -- ---------------------------------------------------------------------- Sylvain Robitaille syl(a)encs.concordia.ca Systems analyst / AITS Concordia University Faculty of Engineering and Computer Science Montreal, Quebec, Canada ----------------------------------------------------------------------

3 5

all.zip and all_shelf_fw.zip most current versions
by Alexander Griesser 28 May '19

28 May '19

Hey, I'm interested in the ways people keep their firmware updated on their filers. On the support website, you can download all.zip and all_shelf_fw.zip, but they are most of the time not recent enough, so f.ex. today I could download all.zip from 10-APR-19 and there is more recent firmware for quite some disks dated with 17-May-19. Does anyone know if there is a public/private URL where I can download a "nightly" build or something like this for all.zip? Or is there any URL/FTP/etc. (without having to parse the download website with some selenium scripts or something like that) that I could use to mirror all the firmware files to one of my servers and create the zip file there? Best, Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com> Web: http://www.anexia-it.com<http://www.anexia-it.com/> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

5 11

OSX/Chrome Login to Netapp Support
by Douglas Siggins 24 May '19

24 May '19

Greetings, Throughout the transition to the new support site I was beginning to have SSO issues logging into the netapp support site (endless redirects). I was able to work around that. Now, I can no longer use chrome to login as of approx. 1-2 months ago maybe? I've disabled all extensions and started with new profile without luck. I have no issues logging in with Firefox. Nor using chrome from Windows 10 or just about any linux destop. Is anyone else with Chrome on OSX having similar issues? Regards, Douglas

3 2

DNS woes
by Scott Classen 25 Apr '19

25 Apr '19

Hello, Can anyone help me with this before I open a case with NetApp? dns check on one of my sververs fails (see below where I get an “Operation timed out” error), but I can ping and traceroute from the vserver to the gateway and the DNS servers. sibyls2::*> dns show -vserver als-enable-ds1 Vserver: als-enable-ds1 Domains: als.lbl.gov, lbl.gov Name Servers: 131.243.5.1, 131.243.5.2 Timeout (secs): 2 Maximum Attempts: 1 Is TLD Query Enabled?: true Require Source and Reply IPs to Match: true Require Packet Queries to Match: true sibyls2::*> dns check -vserver als-enable-ds1 Name Server Vserver Name Server Status Status Details ------------- --------------- ------------ -------------------------- als-enable-ds1 down Operation timed out. 131.243.5.1 als-enable-ds1 down Operation timed out. 131.243.5.2 2 entries were displayed. sibyls2::*> ping -node sibyls2-03 -destination 131.243.78.1 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.78.1 is alive sibyls2::*> ping -node sibyls2-03 -destination 131.243.5.1 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.5.1 is alive sibyls2::*> ping -node sibyls2-03 -destination 131.243.5.2 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.5.2 is alive sibyls2::*> ping -node sibyls2-04 -destination 131.243.78.1 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.78.1 is alive sibyls2::*> ping -node sibyls2-04 -destination 131.243.5.1 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.5.1 is alive sibyls2::*> ping -node sibyls2-04 -destination 131.243.5.2 -vserver als-enable-ds1 -wait-response 2000 -count 3 131.243.5.2 is alive sibyls2::*> traceroute -node sibyls2-03 -vserver als-enable-ds1 -destination 131.243.78.1 traceroute to 131.243.78.1 (131.243.78.1), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 0.521 ms * 0.484 ms sibyls2::*> traceroute -node sibyls2-03 -vserver als-enable-ds1 -destination 131.243.5.1 traceroute to 131.243.5.1 (131.243.5.1), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 0.478 ms 0.369 ms 0.376 ms 2 xe-2-2-1.er1-n1.lbl.gov (131.243.244.140) 0.411 ms 0.391 ms 0.330 ms 3 t5-4.ir1-n1.lbl.gov (131.243.244.131) 0.796 ms 1.365 ms 0.524 ms 4 ns.lbl.gov (131.243.5.1) 0.402 ms 0.765 ms 0.936 ms sibyls2::*> traceroute -node sibyls2-03 -vserver als-enable-ds1 -destination 131.243.5.2 traceroute to 131.243.5.2 (131.243.5.2), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 0.446 ms 0.409 ms 0.375 ms 2 nsals.lbl.gov (131.243.5.2) 0.649 ms 1.047 ms 1.080 ms sibyls2::*> traceroute -node sibyls2-04 -vserver als-enable-ds1 -destination 131.243.78.1 traceroute to 131.243.78.1 (131.243.78.1), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 0.443 ms * 0.502 ms sibyls2::*> traceroute -node sibyls2-04 -vserver als-enable-ds1 -destination 131.243.5.1 traceroute to 131.243.5.1 (131.243.5.1), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 0.515 ms 0.402 ms 0.388 ms 2 xe-2-2-1.er1-n1.lbl.gov (131.243.244.140) 0.513 ms 0.344 ms 0.326 ms 3 t5-4.ir3-n2.lbl.gov (131.243.244.129) 1.737 ms 1.618 ms t5-4.ir4-n3.lbl.gov (131.243.244.133) 0.582 ms 4 ns.lbl.gov (131.243.5.1) 0.898 ms 1.213 ms 0.517 ms sibyls2::*> traceroute -node sibyls2-04 -vserver als-enable-ds1 -destination 131.243.5.2 traceroute to 131.243.5.2 (131.243.5.2), 64 hops max, 40 byte packets 1 vlan3078.irals.lbl.gov (131.243.78.1) 2.075 ms 1.451 ms 0.403 ms 2 nsals.lbl.gov (131.243.5.2) 1.198 ms 0.410 ms 0.911 ms

4 10

Per port stats for a particular LIF
by David McWilliams 25 Apr '19

25 Apr '19

I'm looking for stats for each individual port of an IFGRP, I know this was straightforward in 7-mode, but does anyone know how to do this in cDOT? Sláinte, David "Build a man a fire he'll be warm for a day, set a man on fire and he'll be warm for the rest of his life" Terry Pratchett

1 0

ONTAP compatibility with Windows 2019 domains
by Filip Sneppe 24 Apr '19

24 Apr '19

Hi, A customer of ours is planning to upgrade his Active Directory to Windows 2019, and is asking what the minimum required ONTAP version is with support for 2019 domains. >From the IMT I get that only ONTAP 9.4 and 9.5 are (officially) supported, but this seems a bit drastic: just doing a bit of research on new AD features in Windows 2019 shows that there no real changes to the domain and forrest functional levels, and that they are functionally equivalent to 2016 domains. Can anyone provide a little more insight or thoughts on this? Thanks in advance! Filip

2 1

XDP transfer already existing snapshots
by Alexander Griesser 22 Apr '19

22 Apr '19

Hi toasters, I've setup an XDP snapmirror relation on one of our customer systems yesterday with the default MirrorAndVault policy (which includes daily and weekly snapmirror labels). After the baseline transfer, I recognized that no daily and weekly snapshots have been transferred to the destination and after deeper investigation I found out that the customer did set up a custom snapshot policy which was missing the snapmirror labels: Custom-policy 3 true - Schedule Count Prefix SnapMirror Label ---------------------- ----- ---------------------- ------------------- daily 7 daily - weekly 4 weekly - I've now modifed the policy (for all future snapshots) and did also modify all existing snapshots to add the labels: snap modify -vserver vserver -snapshot weekly.* -snapmirror-label weekly -volume * snap modify -vserver vserver -snapshot daily.* -snapmirror-label daily -volume * All snapshots do now show the correct snapmirror label, so I ran `snapmirror update` on the destination, but the old snapshots have not been transferred, which is most likely because they've been created "before" the XDP snapshot on the source volume. Newly created snapshots though, the one which got created overnight now with the new sm "daily" prefix, got transferred with the most recent update. What are my options now to also bring all the old snapshots to the destination? Do I need to reinitialize the relation? Thanks, Alexander Griesser Head of Systems Operations ANEXIA Internetdienstleistungs GmbH E-Mail: AGriesser(a)anexia-it.com<mailto:AGriesser@anexia-it.com> Web: http://www.anexia-it.com<http://www.anexia-it.com/> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

2 1

SAS Connectivity Monitor: DualPathToDiskShelf_Alert
by John Stoffel 17 Apr '19

17 Apr '19

Hi guys, My out of support FAS3120 running 8.1.2 7-Mode has suddenly had two instances of the following message sent via autosupport notifications. SAS Connectivity Monitor: DualPathToDiskShelf_Alert[50:05:0c:c1:02:04:db:ad] on mafs1a at Mon Apr 15 20:04:00 PDT 2019 But I'm not seeing anything in the event or alert logs, nor do I see any problems via sysconfig, storage shelf show, etc. I know the cables haven't been touched since I was just at the site this past weekend and the rack doors are closed and locked. Thanks, John P.S. And yes, this sucker should have been upgraded two years ago, but management won't let us...

4 5

dedup and svm dr with xdp
by Peter D. Gray 17 Apr '19

17 Apr '19

I hope I can explain this clearly. We use svm dr for all our backups using XDP (identity preserve). We have many volumes with dedup enabled (not inline). We have many volumes with dedup not enabled. SVMs have volumes with dedup and no dedup. What is supposed to happen on the destination SVM's? It appears that it is running dedup as well even though I cannot figure out what schedule it is using. Some volumes appear to have the same schedule as the source (auto@10). Other volumes appear to have no schedule at all. You cannot disable dedup on a destination volume while the destination svm is a target. You can after you break the snapmirror relationship. But when you resync, it turns it back on I think. My understanding is that XDP preserves deduplication across the mirror, so no dedup should be required or do anything useful on the target but how to stop it? Any ideas on how this is supposed to work or what I am doing wrong? Regards, pdg

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