About andris

andris · ‎2012-03-22

To comment on the daily transmissions of AutoSupport... management logs and performance data were changed to daily transmissions to smooth out the (potentially large) amount of information over the week. Previous to 8.1, this information was sent in one large message on Sunday. This occasionally created excessive mail message sizes for SMTP and HTTP servers and was also causing stress on the reception side at NetApp. We're still sending the same level of information as before, but we're now splitting it up into 7 daily "chunks". Another improvement with 8.1 log file collection for AutoSupport involves keeping track of the last collected log entries. They are not resent in subsequent messages, eliminating redundant information from being sent.

andris · ‎2012-03-22

The "wrench" or management Ethernet port on the back of your system provides access to two internal interfaces 1. e0M: an interface you can use to manage your system via TCP/IP protocols (e.g. ssh, snmp, telnet, ONTAPI, etc.) 2. SP: an interface on your service processor - very handy for out-of-band management (remote access to your console port, power control, monitoring of your system) Since they're physically behind a common ethernet port, they need to be on the same IP subnet. In addition, as you saw from syslog, that subnet should be dedicated - not shared with your data-serving GigE interfaces. Based on your IP subnet descriptions, it looks like you've done that. Note: If all of your ethernet connections are going into single switch, you must use VLANs by assigning a VLAN per subnet (and placing the right switch ports for each subnet into the right VLAN). This is required to get true L2 Ethernet isolation between subnets. The #5 in the diagram port is called the "private management" port. The interface behind that port is e0P (P = private). This port is exclusively used for connecting the Alternate Control Path (ACP) Ethernet cables to external NetApp storage shelves (e.g. DS4243) for out-of-band recovery and management from the controller (via the e0P interface). Do you have external shelves? Then we recommend that you set up the ACP ethernet cabling and enable ACP. See: Universal SAS and ACP Cabling Guide

andris · ‎2012-03-20

Please provide the source of this text (link, doc, etc.). The .to destinations will not receive all AutoSupport messages. They are filtered by default rules in Data ONTAP. In 8.0 and later, the customer can tweak those rules with CLI commands.

andris · ‎2012-03-12

Yes. See KB 2016549 for more information. https://kb.netapp.com/support/index?page=content&id=2016549

andris · ‎2012-03-05

Ken, et al. Please report any additional issues via the Feedback link on the Support Site. http://support.netapp.com/eservice/assistant Thank you very much for your feedback. -Andris

andris · ‎2012-03-05

Protocol services by default would be available on all interfaces (some specific limits are placed on the e0M interface, if you have one on your platform). Every tagged VLAN on the VIF would be an "interface", yes. Since you were bothering to separate different protocols with different interface, it sounded like a good idea. https://kb.netapp.com/support/index?page=content&id=3011652 This TR covers this topic: Best Practices for Secure Configuration of Data ONTAP 7G http://media.netapp.com/documents/tr-3649.pdf

andris · ‎2012-03-05

1. AutoSupport information in the Data ONTAP 8.1 System Administration Guide has been updated with good information. 2. Try "man autosupport" from the CLI. 3. The AutoSupport page on the support site has a very nice FAQ. This topic is covered, I believe. http://support.netapp.com/NOW/knowledge/docs/olio/autosupport/

andris · ‎2012-03-05

Kevin, et al. Is the ACP subnet issue being tracked with a bug#? Please provide the number. Or, did you open a technical case and ask for a bug to be opened? If not, please do so. Thanks.

andris · ‎2012-03-03

The customer we built the "D" patch for is successfully sending SMTP via Exchange with it. Perhaps, for your situation, there are other factors at play? Please feel free to open a technical case to pursue this further. In any case, 8.1RC3 is a recommended update to anyone running 8.1RC2 at this time. I think we're spending way too much time talking about a D patch.

andris · ‎2012-03-02

Thank you for clarifying the source of the declaration. I check the D6 fix notes and it is listed there. It should work with that D-Patch, as well.

andris · ‎2012-03-02

Yes, to keep things consistent, I would use tagged VLAN's for all 3 subnets on the VIF and configure your network switch accordingly. You should use interface-specific control for your protocols, too. https://kb.netapp.com/support/index?page=content&id=3011652 Please don't forget to update your /etc/rc file with all of the interface changes. Yes, there's no problem with the filer being multi-homed to multiple IP subnets. 2 considerations to remember: - Your default route should point out the public subnet to that subnet's gateway. - The NFS and iSCSI subnets don't need the default route, as long as all of your hosts are local to those subnets. Correct. Bug 446493 is fixed in 7.3.5.1P1 or later. You are still at risk.

andris · ‎2012-03-02

I'm stating "fixed" based on test results logged in the bug record after the fix was coded. The NetApp-internal bug database does not state that it was fixed in 8.1RC2D6. I don't know why this was declared a "fixed" release for that bug. 8.1RC3 is a "fixed" release.

andris · ‎2012-03-02

Note: Per the KB, you can't have a "-" in the VIF name. Is it a "public" subnet in the Internet sense? Or public to the rest of your company? Hard to design in a forum, but if you have a VLAN-capable GbE switching infrastructure, there's no reason you can't put 3 VLAN's on the VIF: Public, NFS, iSCSI. Your default route entry would point out the Public subnet, allowing the filer to reach big "I" and other subnets for AutoSupport, DNS, NTP, SNMP, etc. You might want to try CLI if System Manager doesn't let you do this, for some reason. BTW, I noticed you're running 7.3.5P1 - You should move off this release (7.3.6 would be ideal) as soon as possible. Details: http://now.netapp.com/NOW/products/csb/csb1106-03.shtml

andris · ‎2012-03-01

Henry, postmaster@xxx.com is only the default. You are free to make each filer's autosupport.from e-mail address unique.

andris · ‎2012-03-01

BTW, it's possible that HTTPS transport to NetApp didn't work because of "" in this option: autosupport.support.proxy "" (value might be overwritten in takeover) Are you by any chance using System Manager 2.0R1? Using it may have erroneously added that "", which Data ONTAP tries to (unsuccessfully) resolve. See Bug 549287. http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=549287 Generally, HTTP/S to NetApp is preferred since you have a more reliable and secure network path (compared with SMTP) and less restrictions on message size.

andris · ‎2012-03-01

Yes, Bug 549239 was fixed in 8.1RC3. Are you familiar with the Bug Comparison Tool on the support site? It's a handy way to see what is fixed between two Data ONTAP releases. http://now.netapp.com/NOW/cgi-bin/relcmp.on?rrel=8.1RC3&rels=8.1RC2&what=fix&notfirst=+Go!

andris · ‎2012-03-01

DNS: It makes things more administratively manual, when resolving any hostnames. I suppose you can always hardcode name/IP mappings in hosts files on all of your components in your environment (filer, hosts). E.g. You might need to do that if you send to support.netapp.com via HTTPS. BMC: The BMC does not pass any form of TCP/IP traffic to the filer from your client (System Manager, telnet, SSH). Your client would need to directly reach the filer's IP addresses for management. Neither does it provide an outgoing path for AutoSupport message from the storage system. It can provide a pass-through for the serial console, though. The BMC can also independently send its own AutoSupport messages for "filer down" problems via SMTP (it inherits the AutoSupport configuration options from its host filer). Subnets: If you're specifying /16 for the subnet, you can't really say that you're carving up .1 and .2 subnets inside this /16 space. With your proposed setup, both NFS and iSCSI will be able to talk to the filer, but you would need to connect everything in the same L2 Ethernet domain and configure all hosts with the /16 subnet mask. This also means you don't have L2 separation between NFS and iSCSI. VLAN's would be your solution for sharing the VIF's - are you sure you can't configure them on VIF's? See: https://kb.netapp.com/support/index?page=content&id=1010910

andris · ‎2012-03-01

Florian, AutoSupport in 8.1 has been significantly overhauled. From the release notes: https://now.netapp.com/NOW/knowledge/docs/ontap/rel81rc3/html/ontap/rnote/GUID-7089A00E-38D4-40D7-A397-AE70D253A5F3.html Excellent and updated information on AutoSupport is available in the System Administration Guide for 8.1. https://now.netapp.com/NOW/knowledge/docs/ontap/rel81rc3/pdfs/ontap/sysadmin.pdf One of the improvements is related to smoothing out the WEEKLY_LOG AutoSupport traffic at both customer sites and back at NetApp, as well as to solve problems with very large AutoSupport messages. To help with these issues: 1. Log files are separated from the WEEKLY LOG and sent daily, i.e. 7 chunks instead of 1 big weekly chunk 2. Performance data is now sent daily (PERFORMANCE DATA), i.e. 7 chunks instead of 1 big weekly chunk 3. Event-based AutoSupport messages send context-sensitive information I hope that helps clarify matters.

andris · ‎2012-03-01

It is most likely a product registration issue with the 3 missing systems - the partner info is not matching these systems, probably. I would click on the "Feedback" link on the support site, pick "data issues", explain the problem, provide all of your details and partner details.

andris · ‎2012-03-01

Ricardo, Can you be more explicit about what RFC's and AUTH methods you are asking for? I assume you're referring to ESMTP AUTH? http://en.wikipedia.org/wiki/Extended_SMTP E.g. Compliance with RFC 4954? http://tools.ietf.org/html/rfc4954 As much details about the requirement you can provide would be appreciated.

andris · ‎2012-02-20

FYI, the -type is now a mandatory field for the invoke command, starting with Data ONTAP 8.0.1.

andris · ‎2012-02-20

Can you clarify what a "traceable User ID" implications are from an SMTP perspective? Alternatively, would switching to using HTTPS transport to NetApp be acceptable?

andris · ‎2012-02-20

Can you download the entire AutoSupport from My AutoSupport? No. If you have access to the system, you can grab the last 40-50 AutoSupport collections (depending on DOT version) from /etc/log/autosupport. In 8.1, you have CLI that lets you specify any of those cached AutoSupport messages and retransmit them to arbitrary SMTP and HTTP destinations. If you feel there's a specific reason why this should be available from My AutoSupport, please elaborate.

andris · ‎2012-01-25

The Flash Cache report is, as stated, simply reporting enabled capacity. It is not (currently) showing operational efficiency of the Flash Cache component. This report is not really useful when run against a system. It's more interesting when looking at your entire NetApp infrastructure across a site or company. Here's an example of the report from a company with a large storage footprint of NetApp systems.

andris · ‎2012-01-24

The "about" link takes you (eventually) to this page. It has short explanations for the reports. https://communities.netapp.com/community/products_and_solutions/efficient_it/my_autosupport_and_autosupport/blog/2011/08/20/my-autosupport-launches-storage-efficiency-20-beta Do you have specific questions that we might be able to address?

Re: Autosupport 8.1 7-mode sends more mails, how to disable?

Re: e0M - Management - SP Port

Re: What are the differences between the options autosupport.to and autosupport.partner.to?

Re: Myasup performance data missing for many customers

Re: My AutoSupport Link Issue

Re: Moving Storage into different Subnet

Re: How to send email to internal mailbox only, but not back to NetApp

Re: 2240 or Data Ontap 8.1RC in production anyone?

Re: 2240 or Data Ontap 8.1RC in production anyone?

Re: 2240 or Data Ontap 8.1RC in production anyone?

Re: Moving Storage into different Subnet

Re: 2240 or Data Ontap 8.1RC in production anyone?

Re: Moving Storage into different Subnet

Re: Send AUSP from a Tracebal User ID

Re: Autosupport emails sent to autosupport@netapp.com not getting registered on website

Re: 2240 or Data Ontap 8.1RC in production anyone?

Re: Moving Storage into different Subnet

Re: BUG on autosupport on 8.1RC2. When it will be fixed?

Re: My AutoSupport Partner Access

Re: Autosupport and SMTP authentication

Re: Caution while manually triggering AutoSupports from C-Mode nodes

Re: Send AUSP from a Tracebal User ID

Re: How do I view /all/ raw autosupport data

Re: Flash Cache Storage Trend Report - Detailed Explaination?

Re: Flash Cache Storage Trend Report - Detailed Explaination?

ONTAP 9.16.1 EAP

ONTAP 9.15.1 EAP